Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have several LAN devices connected via a physical wired network to a SonicWALL TZ210 on subnet 192.168.2.0/24. Several of those devices are assigned DHCP addresses in the range 192.168.2.100 to 192.168.2.199 and some of them have static addresses below 192.168.2.100 or above 192.168.2.240.

On the SonicWALL, I have enabled VPN and configured the L2TP server to use 192.168.2.201 to 192.168.2.220 as the local L2TP pool.

I can establish a VPN connection into the SonicWALL and as expected I get an IP address in the L2TP pool range. From the VPN device (an iPhone, but I don't think that's revelvant) I can ping other devices on the LAN, but not Windows devices - pinging MacOSX, Ubuntu, SonicWALL all work fine (both static and DHCP addresses), but not Windows. The Windows machines can ping any device except the VPN connected one. All other combinations of devices can ping each other successfully - the only failure is Windows<-->VPN.

From a little research, it seems the problem is related to routing on Windows. The route entry for the LAN shows this:

Network Destination        Netmask          Gateway       Interface
      192.168.2.0    255.255.255.0         On-link     192.168.2.173

(This is for a Win7 PC; Win XP is similar, but Gateway is listed as the local IP address, the same as Interface.)

This "On-link" indicates that all traffic destined for the LAN is being sent through the the local NIC and not via the SonicWALL default gateway. If I change the route to use the SonicWALL as the gateway I can ping Windows<-->VPN successfully, as expected:

route change 192.168.2.0 mask 255.255.255.0 192.168.2.254

So, although I have a workaround, it's not really practical (or desirable) to go around every Windows PC and force it to send all LAN traffic through the SonicWALL. Are there any other solutions?

  • Whatever OSX and Ubuntu are doing when I ping the VPN device, they are managing to correctly route through the SonicWALL. Does OSX/Ubuntu always do this or are they being clever if the destination IP is not found on the physical LAN? Can Windows be made to do the same?
  • Is it possible to make the SonicWALL respond to the L2TP pool addresses on the Physical LAN?
  • Something else?
share|improve this question
add comment

1 Answer 1

up vote 0 down vote accepted

Well the Windows clients are working correctly as far as I'm concerned. The route to the local network is the interface connected to that network that has an ip address in that network. When communicating with another host connected to the same network, the Windows clients will ARP for the MAC address of the destination ip address. Because the VPN client ip address is in the same network, Windows clients see the VPN address as local and ARP for the MAC address and get no reply. I see two solutions for this:

  1. Configure the VPN client DHCP pool to be on another network (192.168.3.0/24) and let the Sonicwall handle routing traffic between the LAN and the VPN network.

  2. Figure out how to configure the Sonicwall to perform proxy ARP for the VPN clients so that when the Windows 7 clients ARP for a VPN client ip address the Sonicwall replies on behalf of the VPN client, the Windows 7 client then passes the traffic to the Sonicwall, which then routes the traffic to the VPN client.

share|improve this answer
    
Thanks for that. I've no doubt that the Windows clients are behaving correctly but I guess I'm swayed by the OSX and Linux clients behaving better. I was hoping there was a way to make Windows do the same. Regarding your suggestions: 1) The SonicWALL help specifically says that the L2TP pool should be in the LAN address space; I'm not averse to trying another subnet but I wanted to try and make it work the way appears to be intended; 2) That sounds like it would do the trick, but I can't find any way to configure proxy ARP on the SonicWALL. –  Dave Hartnoll Oct 19 '11 at 8:56
    
I have now had the opportunity to try suggestion 1 and it works well so I'm marking this answer as accepted. –  Dave Hartnoll Oct 19 '11 at 13:21
    
Glad you got it sorted out. –  joeqwerty Oct 19 '11 at 23:15
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.