IPSEC Site to Site VPN



  • Hi Guys

    To anyone having trouble with Ipsec site to site VPN on pfsense 2.2 try the following things to see if it makes a difference:

    1. For the My Identifier in Phase use either: "Dynamic DNS" or "IP Addres" NOT "My IP Address"

    2. If you are using a DNS forwarder and are using the "Domain Overrides" function to forward domains between sites then in your DNS Forwarder section use "strict Interface binding" and DO NOT bind to "localhost". I found that if I had two sites foo.dyndns.com and bar.dyndns.com which were being connected by IPSEC then pfsense would try to use the ipsec interface to try to reauthorize and rekey.

    3. For Mobile VPN if you want all internet traffic from the mobile client to go over the tunnel then make sure you add "0.0.0.0/0" as the local subnet in the Phase 2 setting.

    I was having issues with tunnel stability and 1 and 2 seem to have stabalized the tunnel for now but stil keeping my figures crossed.

    SAM



  • Never mind IPSEC had crashed overnight and saw all tunnels were down this AM. So ignore everything I said earlier … Ipsec in 2.2 totally blows and forget production it is not even test lab worthy as we found its only making us frustrated. A whole days effort wasted trying to get tunnels up and hopefully migrate to 2.2 in production but will totally be holding off for now.



  • @sammybernard:

    1. For the My Identifier in Phase use either: "Dynamic DNS" or "IP Addres" NOT "My IP Address"

    "IP Address" and "My IP Address" do the same thing, I don't see any circumstance where they don't. Could you share your config?

    @sammybernard:

    2. If you are using a DNS forwarder and are using the "Domain Overrides" function to forward domains between sites then in your DNS Forwarder section use "strict Interface binding" and DO NOT bind to "localhost". I found that if I had two sites foo.dyndns.com and bar.dyndns.com which were being connected by IPSEC then pfsense would try to use the ipsec interface to try to reauthorize and rekey.

    Could you clarify what you mean by that? How and where did you see using the IPsec interface to rekey?

    @sammybernard:

    3. For Mobile VPN if you want all internet traffic from the mobile client to go over the tunnel then make sure you add "0.0.0.0/0" as the local subnet in the Phase 2 setting.

    Which should have always been true, but racoon didn't necessarily enforce that where it should have.

    @sammybernard:

    So ignore everything I said earlier … Ipsec in 2.2 totally blows and forget production it is not even test lab worthy as we found its only making us frustrated.

    Not true at all, the vast majority of circumstances work perfectly. There clearly are some that don't, but we'll need to know more about what you're doing to help.



  • the "IP Address" and "My IP Address"  workaround doesn't really good.

    We are still getting tunnels that stay connected but pass no traffic.

    and we have 4 firewalls connecting to one at one of our datacenters.

    this is a problem that started with 2.2



  • Whats we saw was that 2.2 had no issue bringing up the tunnel but once the tunnels were up they were unstable and if there is a disconnect they don't get reestablished irrespedgive of whether DPD was on or off. For example, if you establish a tunnel between two pfsense appliances both running 2.2 and connected through their interfaces and can see that they data is going through. If you then do to the interfaces section and disconnect your WAN, wait 2-3 minutes until the Dashboard applets now show that all tunnels are down, now reconnect your WAN and confirm. Wait again until the WAN comes up you will see that the tunnels stay down and never come up even if your wan ip never changed.

    Its almost like when the interfaces get updated, either due disconnect or reconnect or due to a dynamic IP refresh, pfsense does not seem to refresh 'charon/strongwan' to tell it that interface status changed and it should try to re-establish the tunnels. In the logs all you see are DPD messages or that the WAN interface does not exist even though in reality the interface does exist and is up and running. It simply gives the WAN IP address and keeps saying interface not found.



  • I too have the problems that Sammybernard describes…

    After 2.2 update, my tunnels were working fine but when the phase1 lifetime is up, the tunnels go down and are never refreshed. I have to restart the ipsec daemon to get the tunnels up and working again

    same thing if the wan goes down for any reason and then up again, the tunnels stay down

    I see this problem with the following scenarios :

    pf 2.2 <-> pf 2.2 (ike v2)
    pf 2.2 <-> pf 1.2.3 (ike v1 main mode)
    pf 2.2 <-> netgear DG834 (ike v1 main mode)



  • same here. tunnels that are going from 2.2 to 2.1.3 are working so far, but 2.2 to 2.2 is going down and had to be restarted



  • I also have an occasional tunnel-down for several seconds until it gets back up. Sometimes I have to restart the strongswan service.
    IKEv1, main mode, certificates.

    I tried to switch to IKEv2, but those tunnels were not coming up at all.
    I hope to have some time on the weekend to diagnose this further



  • I should also add that we looked at the bug in pfsense that relates to "states table" not being cleared / adjusted when interfaces change … we tested with both settings ... ie clearing that states table and not clearing the states table and still no difference. This setting is I think in the Miscellaneous section / advanced settings area. Just thought I'd add that since tunnels still did not get reestablished in either scenario.



  • ipsec status says that tunnel is established but no traffic is going through. have to disconnect and reconnect the tunnel from the status page every time. 10 other tunnels (2.2 to 2.1.3) are working fine



  • Just wondering if any of the Developers managed to replicate the problem I described above and if you guys had any insight ???

    https://forum.pfsense.org/index.php?topic=87636.msg482884#msg482884



  • Seems there are possibly multiple different issues in this thread. One thing to check is make sure you don't have "prefer old SAs" enabled on the advanced tab. That was confirmed to fix multiple systems I worked on last week where there were issues after rekeying. That's rarely been desirable and isn't on by default but seems a number of systems have it enabled and have it configured inconsistently between sides. It's another of those things that probably should have broken pre-upgrade, but changes in behavior with strongswan made it more likely to break.



  • Thanks cmb … I made sure it was not enabled and still noticing the same problem. Tunnels DO NOT come back on again if I disconnect and reconnect the WAN interface. Still seeing the DPD messages only without any reconnect.



  • Didn't want to take over someone else's thread as I see the devs want to isolate issues to a thread but just wondering if the devs were able to replicate this issue or had a fix. I see there were no open tickets about this on the bug tracker.



  • Here is the LOG file. As I previously have mentioned … when my IP address changes from a disconnect/reconnect situation, for some reason that information is not passed onto Charon. As you can see from the logs, charon is till passing the old IP address to the remote site and we get the "error writing to socket: Can't assign requested address"

    SAM




  • For the Devs:

    From what I can tell there is some sort of a race condition that is being created. It was described on Stringswan forums too:

    https://wiki.strongswan.org/issues/543

    https://wiki.strongswan.org/issues/193



  • Just to update folks on the forum. We have been following this issue for a while and it appears the Devs were finally able to replicate this. Looks like a fix is being tragetted for 2.2.1. You can follow the link below to monitor progress.

    https://redmine.pfsense.org/issues/4341