VPN Client Can't Ping LAN Clients After Replacing LAN Router

Discussion in 'Routers' started by Nick, Nov 19, 2012.

  1. Nick

    Nick New Around Here

    Joined:
    Nov 19, 2012
    Messages:
    2
    Hi, I just replaced my old router (TRENDnet TEW-633GR) with an ASUS RT-N66U. I've copied over all of my settings (port forwarding, static routes, etc) to get the new router set up and running. However, I'm having issues with VPN clients not being able to communicate with LAN clients. I'm using Windows Server 2008 R2 Standard RRAS as the VPN server, and it was working fine until I replaced the router.

    First, a few IP addresses on the LAN:
    Router: 192.168.1.1
    VPN Server: 192.168.1.76 and 192.168.128.2 (Single NIC; this server also handles DHCP, DNS, and file/print sharing.)
    VPN Client: 192.168.128.3
    LAN Desktop: 192.168.1.50 and 192.168.1.51 (Dual NICs)
    LAN Laptop: 192.168.1.204 (or 192.168.1.244 when connected through VPN)

    The VPN client (another server running Windows Server 2008 R2 Web edition) is unable to ping anything except the VPN server (either of its IPs work), the router, and any other VPN clients. However, any of the directly-connected LAN clients (such as 192.168.1.50) can ping the VPN client, and it will respond. Even though my desktop and laptop are connected directly to the LAN, if I connect to the VPN server on either of them, I can access the remote VPN client that way. Firewalls and client machine software/configurations should be mostly ruled out since it worked with the old router. Oddly enough, the router and VPN client can ping each other both ways without issue. I am using the stock ASUS firmware that came with the router as well.

    Any ideas on what could be causing this?

    Thanks!
     
  2. Nick

    Nick New Around Here

    Joined:
    Nov 19, 2012
    Messages:
    2
    Turns out the router's firewall was dropping packets from the VPN clients (possibly because they're on a different subnet or because of how the VPN server adds clients to the network). Oddly enough, nothing was showing up in the firewall logs about it dropping these packets.

    Anyhow, I was able to fix it by running iptables -t nat -A POSTROUTING -o br0 -s 192.168.0.0/16 -d 192.168.0.0/16 -j MASQUERADE on the router. (By default, it had 192.168.1.0/24.) I was able to figure this out thanks to lfbb's post regarding a related issue.
     
    Last edited: Nov 19, 2012

Share This Page