right. That isn't the case here, as the LAN uses 192.168.0 just to be different from the norm. Since then, we've found that the problem is name resolution. By using the IP address of the machine on the LAN that she needs to reach, she has no problem.
So I'm going to leave this open for the next phase of this - how to get remote name resolution to travel over the VPN, so that (for example) typing "ping <name>" will work. For more info, we do not run either DHNS or windows name services on the LAN (and really don't want to) and, as mentioned about, it is not a domain - it is a simple LAN. Name resolution works fine through the usual peer-to-peer mechanisms on the LAN - can these same mechanisms route?
Main Topics
Browse All Topics





by: RobWillPosted on 2009-09-20 at 18:12:19ID: 25379732
The most common cause of this is the site from which the user is connecting is using the same local subnet as the VPN server, such as both sites using an address like 192.168.1.x.
If the client disables in their VPN connection "use remote default gateway" they will not even be able to connect to the VPN server. The subnets MUST be different or routing cannot take place.