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

Question

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

Enrico Zaninelli 1

Hi guys,
I've set up a VPN in Windows exploiting the "Incoming connection" feature and a DDNS service (no-ip.com).

Follows my configuration:

Remote LAN (vpn server LAN):

192.168.1.0/24
router IP 192.168.1.1
VPN server pc (static) 192.168.1.50
Firewall on server pc temporarily disabled
PPP interface 192.168.10.1
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: 192.168.10.1 - 192.168.10.10 (outside from remote LAN as Microsoft says)

My local LAN (clients LAN)

10.0.0.0/24
router IP 10.0.0.1
PPP interface 192.168.10.2 (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 192.168.1.0 using remote PPP interface 192.168.10.1 as gateway:

route add 192.168.1.0 mask 255.255.255.0 192.168.10.1 if <PPP interface number on client>

I am able to ping the remote VPN server on 192.168.1.50, but I cant ping any other device on remote LAN 192.168.1.0/24.
Iv'e also tried to use same LAN segment 192.168.1.0/24 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

Thanks

Answer 1

Gary Nebbett 4,786

Hello Enrico,

The systems in the remote LAN don't know how to route to 192.168.10.2; 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.

Gary

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

Enrico Zaninelli 1 Reputation point

2022-11-04T08:20:24.163+00:00
Do you mean to keep the VPN address pool within the same subnet of remote LAN 192.168.1.0/24 ?

My DHCP server (router on 192.168.1.1) is already set on the pool 192.168.1.51 - 192.168.1.254, so the first 50 addresses are free.

The problem is that if I try to change the VPN address pool to 192.168.1.31 - 192.168.1.40 (on the remote LAN subnet), i correctly connect and receive the IP on client, but I can't see anything anymore! (even not VPN server).

This two routes are automatically added (31 is the server PPP inferface, 33 is the client one):

192.168.1.0 255.255.255.0 192.168.1.31 192.168.1.33 26 192.168.1.33 255.255.255.255 On-link 192.168.1.33 281

I've removed the static route I created before.
The strange thing is that the first route is pretty much the same I've added before..

If I run "arp -a" on the client, for the PPP interface I have:

Interface: 192.168.1.33 --- 0x3c Address Physical address Type 192.168.1.31 static 224.0.0.22 static 224.0.0.251 static 239.255.255.250 static 255.255.255.255 static

31 is the server PPP interface, but still can't ping it, and nothing else

Hope you can help me

Thanks
Gary Nebbett 4,786 Reputation points

2022-11-04T11:21:30.503+00:00

Hello Enrico,

The new set-up looks OK (matches my set-up).

If possible/practicable, I would suggest making a network trace on the VPN server. The commands that I used to do that were:

pktmon start --capture --comp nics --trace --provider Microsoft-Windows-WFP --file-name why.etl

pktmon stop

In the image below, one can see the "proxy ARP" request/response and the ICMP packets (twice - since they are received by the VPN server on one interface and then forwarded on another).

The WFP provider will show if the Windows Filtering Platform is responsible for any dropped packets.

The commands pktmon etl2pcap or pktmon etl2txt can convert the capture data (why.etl) to more common formats or you can share the data here...

Gary
Enrico Zaninelli 1 Reputation point

2022-11-04T14:57:30.86+00:00
Hi Gary,
thank you so much for your support!

before doing this tempt I need an explanation because I'm new to pktmon command:

Where do I have to execute it? On the server I think, or not?

How do I have to execute the start/stop commands:

Manually and consecutively (start and then stop after few seconds)?

Manually with some commands between them? If yes, what kind of command? ping, arp.... ?

In a batch file without anything between them?

I've tried some options with conversion of the result to a file txt, but it has much lines (I think I will need to filter on ICMP, ARP, ecc, or open with WireShark).
I'd like to retry after your explanation on how to use the command

Thanks a lot,

Enrico

Answer 2

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

Gary

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

2 answers

Activity