Tracert to other side of VPN ends up at default gateway



  • Hey guys, I am truly mistified by some behaviour of my PFsense boxes.

    I've got 2 units connected by IPsec over the internet.
    Unit A can ping to Unit B's LAN, but not the other way around.
    I try to ping the LAN interface of unit A from the webinterface on unit B: no reply
    When I tracert to the LAN IP, the route ends up at the default gateway and wants to go to the internet.

    Unit A is a box only for VPN connections
    Unit B is also a router for wifi/dmz/lan subnets

    I am under the impression that routing between the VPN subnets should work by default (defining the phase 2 subnets should add create a route in the routingtable right?)

    Am I wrong here? Should I do more manual configuration? Setting up gateways and routes to the other subnet on the VPN appliance?
    Please note I test from the VPN boxes themselves. I am aware I need to specify the subnets on the default gateway on the subnets themselves.
    I just assumed that the boxes do not rely on the default gateway to provide their own interface as next hop for VPN traffic. That would not make sense. At least, not to me.

    Please help me out here. Firewall is already wide open, allowing any protocol and any traffic on both IPsec, WAN, LAN and floating interfaces.
    This has already taken me hours… I hope it's something stupid.. at least I can move forward then



  • Basically my question is: Should I manually create a gateway for the VPN and specify the VPN subnets that are on the other end?

    There is currently no route to any VPN subnet in the routing table



  • IPsec tunnel mode doesn't have routes. Never create routes or gateways in that circumstance, if you did, delete them. Where traffic isn't going across the VPN it's because it doesn't match a configured phase 2.



  • Thanks for clearing that up for me. It steered me into the phase 2 configuration. Which included a /24 subnet specifucation on a network adres ending with an actual IP. (254 instead of 0)
    This however did not fix the problem. The whole thing is rather complex since it's a combination of Firewall and VPN boxes in an Azure network.
    The Azure fabric has it's own networking properties. I didn't mention this before because I wanted my question about routing over IPsec to be clear and understand the behavior.

    I fiddled around a little bit with static or DHCP on Azure on the VPN box and ruined it. Rebuild the setup and decided to exclude the remote side out of the equation by setting up 2 VNET's on Azure and rebuild the entire scenario without the inherited config of Side B (non-azure).
    It's worked straight away. So then I setup VPN connections to Side B on both the Azure test Vnets. Same problem in both the Azure boxes, so problem was originating from Side B.

    First thing I did was create floating rules to allow ICMP from all internal networks. That didn't fix it. Then I set those allow rules to "Quick" to be allowed straight on being matched.
    This also didnt fix the problem. Then I realized the Ping had to come from one of the internal nics and I specified the LAN interface as the "from" network on the webinterface.
    This resolved the situation on Side B. Now it's possible to ping the LAN interfaces of all VPN routers.

    I've spend a lot of time thinking it was somehow connected to the VPN config, while actually it was firewall logic blocking the traffic. Side B is a box that had a year uptime until I updated it this week because I couldn't get the VPN working on the old version. Inherited config made it very hard to understand and fix this problem. I ended up looking in the wrong place and spending a lot of time with that. Hopefully someone is helped with fiddling efforts

    Thanks for the community support and the refresh of my networking logics. The rules that apply in this field are very specific. A structured approach to troubleshooting is the way to go.
    Thanks again