Link to home
Start Free TrialLog in
Avatar of Pumpernickel
PumpernickelFlag for United States of America

asked on

VPN clients can't be pinged by LAN

I have a pptp vpn setup using pfsense.  The clients can connect and ping the LAN hosts but the hosts can't ping the clients.  I think its something with the firewall ports.  Everything is on the same subnet and same ipsubnet.  Screenshots are located at the link below.  Any ideas?,30625.0.html
Avatar of surbabu140977
Flag of India image

My bet would be problem in reverse routes. Something somewhere routes are mixed up. Do a traceroute from clients to hosts and vice-versa, hopefully you will see where it's stuck.

Are you trying this setup in same subnet???

Avatar of Pumpernickel


Yes there both 10.1.10.x subnet.  The computers are attached the the AD domain and they are assigned static ips by pfsense.  Pfsense is not the dhcp server though, there is a separate dhcp dns server.  But when I checked the clients ip, they are connecting as... ex.  But the dns server has them as a static ip of  Maybe I have to setup a vhost?
what's the practicality and purpose of vpn in same lan?
Access shares and network drives and load their profile.  Why, do you have a different suggestion?  The reason I need the ping is because of the monitoring software. It can't even see the device on the network.  I'm starting to think it could be because the dns is pointing to a different ip than the vpn ip
actually, I have never come across a situation where people need vpn working in same lan....... may be i am missing something here......
They need to be able to access the local Network Drives and load their synced my documents.  Thats why I kept them in the same LAN.
Normally you cannot ping XP machine by default...
It sounds like a dns issue - to confirm try pinging by IP address instead of machine name. If that works we can try to figure out why DNS registration isn't completing properly.

Good Luck
my guess is your DHCP server may be assigning an IP address already assigned to the LAN.  i had this challenge and had to configure a separate subnet for the vpn clients.  once i did that, the issue went away.  what's acting as a dhcp server?
Well the IPs are staticly assigned by pfSense (which is the vpn server).  The DHCP server is on the domain controller and isn't even aware of the vpn connections... I can try to manually add them to the DNS and attempt to see if that will work.  Thanks for that suggestion
If they are indeed static where the same client always gets the same IP address you should be able to manage them statically in DNS also. This process tends to break down where you have a user with a laptop that can either come in from home over vpn, or carry their machine into the office and plug into the LAN and get a different IP from DHCP.

You might want to do something with a script that executes "ipconfig /registerdns" when it connects and gets an IP address. Domain login script perhaps?
Can pfSense utilize your Internal DHCP server to assign addresses? If so that might be the best fix. I know Microsoft RRAS can do that for pptp connections but not that familier with pfSense.
@cmb991 :: since the IPs are statically assigned and the vpn IPs are on the same subnet as the IPs assigned by your DC, then i assume the IP addresses assigned by pfSense are not in the DHCP range, correct assumption?
I will try to statically assign them.   Digitap,  you are correct. They are not in the same dhcp range. They are in the same subnet though,
ok...good.  i think that's the answer i was originally looking for.  i assume the ping that's failing is by IP, correct?  if so, the gateway of the vpn clients and LAN clients are different, yes?
I tried to ping the ip of the vpn client.  But that doesn't work. Then I tired to ping the domain controller from the client and that did work.  Also, the vpn client can't access hosts by their name, only ip.  Pfsense is the gateway, which the lab uses and the vpn clients connect to so I would assume there both the same gateway. I will double check though
If they are on the same IP subnet then pfSense must be bridging the VPN clients to the LAN segment, so if a machine on a subnet goes to ping another machine on the same subnet no gateway would be required to complete the icmp echo/echo-reply. Likewise if pinging by IP address that takes DNS out of the picture (though that may still be an issue).

It works from the client to the LAN, but not from the LAN to the client. That leaves two possibilities (as I see it).

1. Firewall on the client is blocking the ping request
2. pfSense is blocking the traffic

Explore those possibilities and let us know.
Avatar of The--Captain
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Okay so if I'm setting up the Proxy ARP (Virtual IPs), should my interface be WAN or LAN for the VPN clients ip?
Okay so adding it to the wan worked.  Now my only problem is, how can I do the host names for the computers?  The LAN clients can't ping the host vpn client NOR can the vpn clients ping the lan host names.  Is this something I would have to do via DNS or would this be another item that would be configured from pfSense?
So now you can ping both ways by IP address, but not by hostname? If so, then yes - this is something that is typically handled by DNS. If entries are relatively static (but not registering in your DNS server) then it may be as simple as just creating static entries in your DNS for your remote users. To go the other way you will likely need to configure your remote clients to use the internal DNS server when they are connected.

I didn't consider the need for proxy-arp because originally echo-replies were being processed ok. For that to work I would  have assumed the arp for the reply address was registered on the LAN. I guess in this case if the pfSense is the default gateway for the LAN perhaps the LAN clients just blindly sent echo replies to the gateway.
"I didn't consider the need for proxy-arp because originally echo-replies were being processed ok"

That's a logical assumption.  

I think there's more going on here than meets the eye (hence the proxy-arp suggestion).  Maybe NAT on top of everything else (which might explain some of the DNS confusion).