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

On the SonicWALL, I have enabled VPN and configured the L2TP server to use to 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         On-link

(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 mask

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?

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 ( 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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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