IPSec Tunnels up between pfSense 2.44 firewall but can't ping inside LAN even with rules set...
-
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!