jtgerdes
asked on
Need help with Route ADD command
Ok, I did this once a month or so ago and now I can't figure out how I did it. I have a SonicWALL with SonicPoints setup and two virtual access points - one for internal network access and one for guest access using the SonicWALL guest services. I have the SonicPoints on their own network and the whole dual virtual access point thing is working great - with the exception of the internal access thing. The internal wireless network does give you internet access but does not give you access to the wired network. Everything is good in the firewall on the SonicWALL, I had a SonicWALL support guy double check that and the two networks are communicating at the SonicWALL level, but the server is not responding to ping requests. When I first set this up I stumbled upon a fix that involved running a Route ADD command, but for some reason I can't figure out what I did to get it to work and why it was only a temporary fix that doesn't work any more. I'm thinking I didn't make it persistent the first time? Here are some other details:
Wired network 192.168.168.0-192.168.169.
Internal Wireless network 192.168.171.0-254 SN 255.255.255.0
Any help on this would be great. Thanks.
Wired network 192.168.168.0-192.168.169.
Internal Wireless network 192.168.171.0-254 SN 255.255.255.0
Any help on this would be great. Thanks.
This may not have anything to do with your problem, but the TCP stacks in older versions of windows aren't as 'classless' as they should be, using (and listening for) the wrong broadcast address on networks with what used to be called "Class C" addresses using subnet masks smaller than /24 (and 255.255.254.0 = /23).
e.g. XP machines having addresses in the 192.168.168.xxx portion will use and listen for 192.168.168.255 as the broadcast address, even though 192.168.168.255 is a valid address (ergo might be assigned to a device) and the proper broadcast address should be 192.168.169.255 for everything on the wired portion.
The only work around for that problem (because microsoft is not going to provide further fixes for it) is to not use 192.168.xxx.xxx for subnets with masks smaller than /24. i.e. use 10.xxx.xxx.xxx or 172.16.xxx.xxx-172.32.xxx.
If I recall correctly, the problem was fixed in vista with service pack 2, and server 2008 with service pack 1. All versions of windows prior to that (those that came with a TCP stack, anyway... windows 1, 2 and 3 did not) had the problem; all versions of windows since then have it fixed.
e.g. XP machines having addresses in the 192.168.168.xxx portion will use and listen for 192.168.168.255 as the broadcast address, even though 192.168.168.255 is a valid address (ergo might be assigned to a device) and the proper broadcast address should be 192.168.169.255 for everything on the wired portion.
The only work around for that problem (because microsoft is not going to provide further fixes for it) is to not use 192.168.xxx.xxx for subnets with masks smaller than /24. i.e. use 10.xxx.xxx.xxx or 172.16.xxx.xxx-172.32.xxx.
If I recall correctly, the problem was fixed in vista with service pack 2, and server 2008 with service pack 1. All versions of windows prior to that (those that came with a TCP stack, anyway... windows 1, 2 and 3 did not) had the problem; all versions of windows since then have it fixed.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Well, I figured out that my problem is actually related to the fact that the server I'm trying to access from the wireless network is using a Cisco PIX for a gateway. But I'm awarding points for effort and this answer provides the most basic thing to check if my situation were more straightforward. Thanks.
http://help.mysonicwall.com/sw/eng/general/ui1/6600/Advanced/Routes.htm
http://help.mysonicwall.com/sw/eng/705/ui2/23100/Network/Add_Route_Policy.htm