IPSec Tunnels up between pfSense 2.44 firewall but can't ping inside LAN even with rules set...
-
Not a good move... I took the inside LAN down! Back to the drawing board....
-
Yes, you should not need to uncheck the bypass-lan.
You should be able to ping across the tunnel from Diag > Ping but only if you choose LAN as the source there.
Check the packet counters on the Status > IPSec page when you're pinging, are they increasing both in and out?
Steve
-
@stephenw10 Thank You! That helped tremendously. I am able to ping that LAN on the other side of the VPN from Diag>Ping after choosing the LAN as a Source Address. I am not able to ping a device/PC on the other side. The PC is pingable from it's LAN/Firewall. Thoughts on how to clear this up? Thanks so much!
-
It seems likely that clients on one side of the tunnel do not have a route back to the other side via the pfSense box.
Is the pfSense box the default gateway for clients on both sides?
If it is (or should be) that I would run a packet capture on the LAN interface at both sides and filter for ICMP and the ping target. Re-run the ping and see exactly where it is failing.
Steve
-
@stephenw10 Yes, clients on both sides are using the default gateway of the pfSense LAN on their side. I can ping the client from the local LAN's pfSense box. But I can not ping the client through the VPN even from the pfSense box using Diag > Ping w/ LAN selected.
I have set up a Gateway Route to the LAN on the other end and also attached a Static Route to the far LAN.
When I do a Packet Capture I see the ping request arrive on the other end but no reply from the client.
-
Sounds like it could be a software firewall running on the target that only allows pings from it's own subnet.
Steve
-
@stephenw10 Thanks for replying. Both firewalls are running pfSense 2.44 software, so where in pfSense should I look?
-
Not in the tunnel endpoints, on the target server itself. So windows firewall will block pings from outside it's own subnet for example. Other software firewalls behave similarly.
However that should not stop you pinging the pfSense B LAN IP address from a client in the pfSense A LAN subnet and vice versa.
Steve
-
Oh, yes, that's probably what's happening! Thanks!
Yes, can successfully ping the other LAN's IP through the VPN.
Making progress! I also can ping a remote printer from Site BC, but not from Site EB. I'll compare settings on both. Getting closer! -
Ok, if you can ping the opposite LAN IP from a client and do that in both directions then the VPN is working and so it routing.
Very likely a block at the target device causing other pings to fail.Steve
-
I was able to do a packet capture on the LAN using pfSense at the target side. It shows the Requests coming in but no Replies from the printer. I can ping this same printer from another VPN. I've checked the rules at the LAN, IPSec, and they appear to be the same as the other side.
-
Hmm, you would exepct something like a printer to respond usually.
If requests are coming across the tunnel and leaving the LAN interface correctly but you don't see any replies then it's either not replying or it's replying to the wrong place.
What is between pfSense and the printer? Anything that could block the ping request or just a switch?
Is the request leaving the pfSense LAN using the correct MAC address for the printer?Both those seem unlikely, this seems like a bad route or a bad subnet mask.
If you capture on LAN filtering by just the printers IP do you see it ARPing for the source device directly?
That's what you would see if it has a subnet mask that covers both sites for example.Steve
-
As you can see below the ping from my location 10.0.6.120 gets through to the printer 172.16.146.8 via another VPN (IPCOP to pfSense). But at the same time ping requests from a PC at remote Site BC 172.16.152.10 over a VPN (IPCop to pfSense) to the same printer 172.16.146.8 shows only the Requests with no replies.
There is a Cisco Switch between the pfSense LAN and the printer.
Where would I see the ARPing or is that reflected below?
09:15:10.813147 IP 10.0.6.120 > 172.16.146.8: ICMP echo request, id 1, seq 7203, length 40
09:15:10.813255 IP 172.16.146.8 > 10.0.6.120: ICMP echo reply, id 1, seq 7203, length 40
09:15:11.089730 IP 172.16.152.10 > 172.16.146.8: ICMP echo request, id 3, seq 54738, length 40
09:15:11.822299 IP 10.0.6.120 > 172.16.146.8: ICMP echo request, id 1, seq 7204, length 40
09:15:11.822407 IP 172.16.146.8 > 10.0.6.120: ICMP echo reply, id 1, seq 7204, length 40
09:15:12.834229 IP 10.0.6.120 > 172.16.146.8: ICMP echo request, id 1, seq 7205, length 40
09:15:12.834342 IP 172.16.146.8 > 10.0.6.120: ICMP echo reply, id 1, seq 7205, length 40
09:15:13.839218 IP 10.0.6.120 > 172.16.146.8: ICMP echo request, id 1, seq 7206, length 40
09:15:13.839321 IP 172.16.146.8 > 10.0.6.120: ICMP echo reply, id 1, seq 7206, length 40
09:15:14.844269 IP 10.0.6.120 > 172.16.146.8: ICMP echo request, id 1, seq 7207, length 40
09:15:14.844367 IP 172.16.146.8 > 10.0.6.120: ICMP echo reply, id 1, seq 7207, length 40
09:15:15.865548 IP 10.0.6.120 > 172.16.146.8: ICMP echo request, id 1, seq 7208, length 40
09:15:15.865657 IP 172.16.146.8 > 10.0.6.120: ICMP echo reply, id 1, seq 7208, length 40
09:15:15.949179 IP 169.244.13.129 > 172.16.147.6: ICMP net 172.16.112.206 unreachable, length 115
09:15:16.097467 IP 172.16.152.10 > 172.16.146.8: ICMP echo request, id 3, seq 54739, length 40
09:15:16.872300 IP 10.0.6.120 > 172.16.146.8: ICMP echo request, id 1, seq 7209, length 40
09:15:16.872412 IP 172.16.146.8 > 10.0.6.120: ICMP echo reply, id 1, seq 7209, length 40
09:15:17.880722 IP 10.0.6.120 > 172.16.146.8: ICMP echo request, id 1, seq 7210, length 40 -
I'm reporting the same thing across many sites. All my sites are on 2.44.
One thing I want to add. If I set up a new tunnel under 2.44 there is no way the tunnel would ever pass traffic but tunnels set up prior to upgrade are still connected ... however today we had a power outage at one of the sites. Tunnel is now not passing traffic but the tunnel shows it's up under status.
I've done everything and I can state that there is no traffic going thru IPSEC tunnels under 2.44.
Open VPN is fine. I'm now trying to switch to L2TP. Hope there is a fix soon.
Thanks -
@bpados That's not the same thing you should start a new thread.
Try disabling Async-Crypto in IPSec > Advanced if it's enabled.Steve
-
@oklord Ok, if that was filtered only by the printer IP and not also by ICMP then I would expect to see ARP requests there.
It is suspicious though that the closer subnet is not seeing replies. If that subnet on the printer were set to /20 instead of /24 that would happen.
Other targets should work though unless the subnet is set that way for everything at that site.Steve
-
@bpados
I have an update to my previous response. I think systems that are upgaded to 2.44 are the only ones effected. I could be wrong and I don't feel like staying up late as I can't mess with production endpoints, but units that are 2.44 from the start the IPSEC tunnel traffic down don't seem to apply. -
@stephenw10 subnet on printer is actually /16 or 255.255.0.0
-
Changed the subnet on the printer to /24 and that WORKED! Thanks so much Stephen! Great job by YOU!
