Second IPSec issues / IPSec redundancy queries



  • Hello Team,

    I stumbled upon a frowning issue on one of the PFSense devices that I manage. I am still quite new to the environment, so it may be something on my end, but the behavior seems all too buggy to me to be expected.

    Here is what I am talking about. First of all - a network diagram of the site that the particular PFSense resides (its the device on the right on the screen):

    0_1532927038165_4d0c2958-457d-41ce-9d34-a2ba24d9a61b-image.png

    At the moment we're in the process of replacing one of the internet providers (Provider 1 will be replaced by Provider 3). At the moment all lines are active and running. The LAN network reaches the PFSense over the trunk with provider 2.

    As this is a remote site, I have all traffic flowing over an IPSec tunnel to main office over Provider 2. The phase 2 entry on this side is from LAN network to 0.0.0.0, getting the entire traffic flowing over the tunnel. This is up and running fine.

    On Friday, I configured a new sub-interface for Provider 3 and started configuring the secondary IPSec tunnel. Phase 1 was fine and even Phase 2 works fine when the defined traffic is from "Test Host to 0.0.0.0". This is working absolutely fine.

    So after seeing the working flow for the test host, I disabled the primary tunnel, so that there is no overlap of the SA for the two tunnels. Once that was done I changed the phase2 entry from "test host to any" to "lan subnet to any". After bouncing the tunnel, both ends of the tunnel show phase 2 as up and running, however traffic is not flowing at all over the tunnel and I don't see ANY traffic whatsoever on the LAN interface. On the packet captures I see traffic from main office going over the IPSec tunnel and leaving the LAN interface. On the test host itself I see traffic arriving to it from the main office (ping from my machine to the test machine). I see the replies leaving the test machine, however those are never seen on the PFSense.

    Changing back the phase 2 rule from "lan subnet to any" to "test host to any" and I start seeing all traffic from LAN subnet (various machines, not just test host) on the PFSense and traffic hits the tunnel now.

    I considered that this could be a problem with the phase2 overlapping with the disabled tunnel, so I deleted the entry from that other tunnel, however the behavior remains the same.

    Rebooting the PFSense - I would see that one ping from my machine to the test host would go over the problematic tunnel, before it drops again.

    Any assistance on this would be greatly appreciated, as I've been bumping my head on it for a good 15+ hours.

    On a sidenote - what I am trying to achieve overall is to have IPSec redundancy, so I have the following additional questions:

    1. Is secondary peer supported on the PFSense?
    2. How does the PFSense react on two tunnels with the same phase 2 entires - while one of them is disabled and the other one is active?
    3. What would be a best practice and/or recommendation to run IPSec redundancy?
    4. Is route based VPN supported on the device? If so, any particular notes on NATs/Rules?

    Thank you in advance.

    Best regards,
    Nick



  • Any clues on this anyone?

    This has been bugging me over the past two weeks.



    1. Is secondary peer supported on the PFSense?
    2. How does the PFSense react on two tunnels with the same phase 2 entires - while one of them is disabled and the other one is active?
    3. What would be a best practice and/or recommendation to run IPSec redundancy?
    4. Is route based VPN supported on the device? If so, any particular notes on NATs/Rules?

    1- No. You can use a dynamic hostname, but that's another discussion.
    2- Not sure what your issue is, I have used disabled tunnels at several sites. Just disable the primary on both sites, clear any active sessions, and enable the secondary on both sides.
    3- Skipping this, it varies based on situation.
    4- See the release notes for the upcoming 2.4.4 release for routed IPSec.