Windows VPN - Can connect and ping VPN server but cannot ping any other devices on remote LAN

Enrico Zaninelli 1 Reputation point

Hi guys,
I've set up a VPN in Windows exploiting the "Incoming connection" feature and a DDNS service (

Follows my configuration:

Remote LAN (vpn server LAN):

  • router IP
  • VPN server pc (static)
  • Firewall on server pc temporarily disabled
  • PPP interface
  • Forwarded ports 1723 and 47 TCP/UDP on router toward server pc

VPN connection settings on server

  • static ip pool to be assigned to vpn clients: - (outside from remote LAN as Microsoft says)

My local LAN (clients LAN)

  • router IP
  • PPP interface (correctly received from server)

VPN connection settings on client

  • "Use default gatway on remote LAN" checkbox DISABLED (in VPN connection properties > IPv4 properties > Advanced)

I've added the following route to reach remote LAN using remote PPP interface as gateway:

route add mask if <PPP interface number on client>

I am able to ping the remote VPN server on, but I cant ping any other device on remote LAN
Iv'e also tried to use same LAN segment for remote server LAN and local clients LAN but had same result.
Both machines client and server are Windows 10 pc

I've been testing for so much hours without success

Any help will be appreciated


Windows 10 Network
Windows 10 Network
Windows 10: A Microsoft operating system that runs on personal computers and tablets.Network: A group of devices that communicate either wirelessly or via a physical connection.
2,294 questions
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. Gary Nebbett 5,761 Reputation points

    Hello Enrico,

    The systems in the remote LAN don't know how to route to; your ping requests probably reach their target but the ping responses can't be sent.

    I find it easier to set the address pool on the VPN server to a range of the remote LAN that is not allocated by the remote LAN DHCP server (by configuring the remote LAN DHCP server appropriately). This means that no additional routes are needed (on the VPN client or on the systems in the remote LAN); the VPN server uses "proxy ARP" to receive packets from the remote LAN destined for one of its VPN clients.


    P.S. There is no need to disable the firewall on the VPN server.

  2. Gary Nebbett 5,761 Reputation points

    Hello Enrico,

    I would first suggest executing the commands on the VPN server (as I said in my previous message). There is more chance that a trace executed on the VPN server will contain a hint about the cause of the problem. It is possible that a trace on the VPN client might also contain a sufficient hint. Another consideration is what is possible/practical - we need to both control the tracing and (try to) use the VPN connection; if you can't have easy access to both sides (client and server) at the same time, then all that might be possible is tracing on the client.

    The start and stop trace commands should "surround" some behaviour that one wants to investigate (e.g. sending a ping request and not receiving a ping response). In your case (assuming that the VPN connection is successfully established - Windows reports "Connected") then a simple ping command or two would be sufficient (perhaps one ping attempt to the VPN server on its "home network" address ( and one ping attempt to another IP device in the same network (printer, TV, whatever is connected and turned on)).

    Keeping trace data "short" is a good thing, but in this case I don't expect much trace data - I don't think that there is any need for "special measures" to keep the trace data short.

    I normally only filter network data on capture when I am investigating a specific protocol's behaviour - too much filtering risks losing useful information when one is not sure exactly what one is looking for.

    Loading the trace data (after conversion) into Wireshark would probably be the most comfortable option for analysis (if you have that installed) - one can then use Wireshark filters to focus on specific aspects of the behaviour.

    Just converting the trace file to text and using text editor searching/filtering should also be possible in this case but perhaps needs more experience.


    0 comments No comments