IPSec VTI - can ping from pfSense but not from LAN computer

mclaborn

I have an IPSec VPN with Phase 2 defined as "Routed (VTI)". Both P1 and P2 are connected. From pfSense I can ping 10.91.50.33 which is on the LAN side of the remote end, but I can't ping 10.91.50.33 from a computer on the local side LAN.

The associated interface is enabled. I have a static route for the 10.91.0.0/16 network.

Packet capture on LAN shows the outgoing PING but no replies.

Packet capture on the VPN interface does not show anything.

There is an allow all rule on the IPSec interface.

What am I missing?

viragomann

@mclaborn
Maybe the destination device blocks access from outside of its own subnet.
This is the default behavior of the most network activated computers.

mclaborn

@viragomann I think if that were the case I would not be able to ping from the pfSense.

mclaborn

I feel like this has something to do with routing. Packet capture shows pings trying to go out on the WAN interface rather than the VPN interface.

gabacho4

@mclaborn Can you please specify what IP subnets are at each side of your connection? You say you have a static route for 10.91.0.0/16 but at which end? And does the other end have a static route set up for the opposite side? You've given scant details really.

EDIT: please provide screenshots of your P1 and P2 for both sides of the ipsec connection. I will have to trust that you've created the appropriate interfaces on each side and added the necessary firewall rules. Also, I will assume that you've created policy based routing (PBR) rules that allow local LAN to use VTI interface for remote IPs access.

gabacho4

@mclaborn I strongly believe you are missing PBR rule(s).

mclaborn

@gabacho4 Missing PBR was the problem, thank you.

Weird though - I modeled this new VPN after an existing one that is working correctly and the existing one does not have any PBR.

gabacho4

@mclaborn glad it’s working now. Don’t see how the other could possibly be working without PBR if it is a VTI IPSec setup. That’s the whole point of VTI. If it’s a traditional policy-based IPSec connection (tunnel mode for the P2) then yes, you don’t need the PBR because the policy creates those routes.

mclaborn

@gabacho4 I don't understand either. The one that is working without PBR does have static routes defined (on the local end).

gabacho4

@mclaborn is the vti gateway set as the default for your network?

rcoleman-netgate

@mclaborn said in IPSec VTI - can ping from pfSense but not from LAN computer:

I don't understand either. The one that is working without PBR does have static routes defined (on the local end).

I had a ticket last night from someone that had a PBR and a VTI and he couldn't get anything going because the pings were hitting the PBR rule and pushing it out.

Our solution was to disable the PBR to verify, but then I suggested he set up a rule that takes all non-RFC1918 addresses and PBR that out his WAN2 instead. He'll likely go that route in the end but it was a definite learning experience for both of us.

mclaborn

@gabacho4 No

mclaborn

@rcoleman-netgate That's just as strange as mine. It feels like there is something flaky going on here with routing and VTI. I'm willing to dig into it more if you want to try to figure it out.

rcoleman-netgate

@mclaborn Do packet captures... first on the interface it comes in on, then on the one it should go out on, then on the rest... that's how we confirmed it was a PBR that was passing his ICMP for the VTI destination out through WAN2.

mclaborn

@rcoleman-netgate I did that already as I was trying to figure it out. Doing a ping from a computer on the LAN to an address on the other side of the VPN, before adding PBR:

packet capture on LAN shows ping outgoing but no reply
packet capture on VTI does not show anything
packet capture on WAN shows ping outgoing but no reply

rcoleman-netgate

@mclaborn Ok from there Id check the Routes table, I'd check all your firewall rules, and I'd run a tracert to see if if it going somewhere funky.

Also check your Outbound NAT rules to see if there's a redirect there, too, or maybe you have a 1:1 that is translating the IP to something else.