IPSEC pf v2.3 strongswan to ddns enpoint not rebuilding tunnel on ddns update



  • Overview / Backbound

    • Site a to site b - using ipsec

    • Both ends with WAN and WAN2 in a WANgroup

    • Both sites using DDNS and IPSEC tunnels built from local WANgroup to distinguished name sitea.ddns.net and sitebddns.net (not their real DDNS fqdn's)

    • IPSEC advanced option "make before break" set ON under sitea and siteb firewalls

    The fault - tunnel not rebuilding on ddns update

    • Something happened some 5.5 hours ago and siteb (the initiator) built the IPSEC V2 tunnel to sitea's WAN2 ip.

    • The tunnel is still running siteb WAN to sitea WAN2

    • Siteb firewall, you can do a DNS lookup of sitea.ddns.net and it returns sitea WAN ip

    • Sitea ddns says sitea.ddns.net is WAN IP and it's green, status ok

    • The problem is the tunnel has not rebuild / flipped so that siteb WAN builds to sitea WAN even though both sides agree on sitea.ddns.net being WAN

    What needs to be fixed / the bug
    Strongswan / IPSEC needs to monitor ddns and rebuild (or at least give us an option) to force a tunnel rebuild if the ddns entry updates.



  • Just to add a little more information, the phase 1 lifetime is 28800 seconds (default), and the phase 2 lifetime is also set at 28800 seconds. I set the phase 2 lifetime higher than the 3600 default as it really doesn't add anything to security re-keying frequently. I mean, if you can break the tunnel encryption within the 28800 seconds, then, the whole things broken anyway, so re-keying every hour seems excessive to me.

    I'm monitoring the tunnel and the phase 2 lifetime is due to expire shortly on the site b (initiator side) so I'll post back what happens after that timer expires and a reauth occurs.



  • Not a direct answer to your question, but as I have just posted on another topic, I have never found this to work reliably.

    A better way to configure this is to set up GRE tunnels over IPsec in transport mode. In this way, it becomes routable, then you can use OSPF or whatever routing protocol to handle the failover.



  • Could the problem be because I have chosen the "My identifier" on the phase one proposal as "Distinguished name" and in fact I needed to select the "My identifier" of "Dynamic DNS" on both firewalls?

    This topic says different code paths are used between the two different identifiers to determine the local IP address and the change thereof.
    https://forum.pfsense.org/index.php?topic=434.0



  • That sounds like the rc.newipsecdns issue that was fixed in 2.3.1.



  • Excellent, I'm upgrading all firewalls tonight to 2.3.1 and will retest DDNS failover, should the "My identifier" be changed to "Dynamic DNS" on both firewalls as well?

    I assume yes.



  • Right.

    DDNS IP address change on 2.3.1 doesn't trigger a tunnel rebuild.

    • I upgraded 3 clustered firewall pairs (6 x pfsense firewalls (4 x C2758 & 2 x SG-8860)).

    • I ensured that the P1 "My identifier" on each firewall is setup to the correct ddns FQDN and the type is set as "Dynamic DNS"

    • I failed the WAN, re established the WAN and waited.

    • Even after some 30+ minutes of the WAN up, both the local and remote firewalls agreeing that the DDNS was of the local firewall WANgroup was now "WAN", the tunnel did not rebuild to use the local WAN IP.



  • I've posted a bug report to redmine issue number 6370.



  • @Steven:

    Could the problem be because I have chosen the "My identifier" on the phase one proposal as "Distinguished name" and in fact I needed to select the "My identifier" of "Dynamic DNS" on both firewalls?

    This topic says different code paths are used between the two different identifiers to determine the local IP address and the change thereof.
    https://forum.pfsense.org/index.php?topic=434.0

    I use Dynamic DNS as Identifier and normally it works fine, however if a failover occures bahavior is the same as for you, it doesn't reload the tunnels properly.  So this does not fix anything…



  • @georgeman:

    Not a direct answer to your question, but as I have just posted on another topic, I have never found this to work reliably.

    A better way to configure this is to set up GRE tunnels over IPsec in transport mode. In this way, it becomes routable, then you can use OSPF or whatever routing protocol to handle the failover.

    @georgeman: If read about this, but I haven't quite understood how it works, could you please explain a little bit more?
    I have Site A with 2 WANs (static IPs) and Site B with one WAN (Dynamic IP). For both Sites I'm using Dyndns.
    So it's like

    Site A Wan 1 (Main)      Site A Wan 2 (Backup)
              l                                l
              l                                l     
                  site_A.dyndns.org
                              l
                              l
                  site_B.dyndns.org
                              l
                      Site B (WAN)

    With iPsec Tunnel using the dyndns FQDNs as endpoints.

    How is the Setup if I want to use your solution with Ipsec Transport / GRE / OSPF?
    How do I have to setup IPsec? Still using Dyndns? or multiple Tunnels simultaniously?
    Is there any howto / Tutorial on this?



  • The idea is to have multiple IPsec tunnels running at the same time, and handle the failover with a routing protocol.

    In your case, since site B has only one connection, you run into an additional issue: the IPsec daemon does not select a gateway by itself, this is based on system routes. When you select an interface on the P1 settings, it just adds a route towards the other endpoint address through that interface's gateway. So this means that ALL connections with "destination: the other site IP address" will be routed through the same WAN. That means, you cannot have 2 tunnels with the same destination but different source WANs.

    Still, this can be worked out by setting a "GIF over IPsec over GRE" configuration:

    • Setup GRE tunnels between the all the WANs (this needs to be GRE and not GIF for OSPF to work)
    • Configure IPsec transport mode between the GRE interfaces addresses
    • Configure GIF tunnels with the GRE addresses as endpoints (this can be GIF since you most likely won't be using anything multicast, and you save a couple of bytes on the headers)
    • Use these GIF addresses to route (OSPF for example)

    It is a quite complicated setup (and there are a few unresolved bugs in between), but it works well. You also have to set the appropriate MTU/MSS on the interfaces to avoid fragmentation.

    Anyway, I don't remember at the moment whether you can use a DDNS hostname as a GRE tunnel destination…



  • Georgeman, Thank you for the explanation!
    But that sounds quite complicated  :o I'm afraid that even if I could set it up nobody else here could figure out how it works in case I'm not there if something goes wrong….
    I think it would be easier to set up some kind of watchdog that simply restarts strongswan in case a WAN failover occures..?
    Has anybody realized something like that?

    @ Steven Perreau: Any update on your Bug report?



  • No answer on my bug report and this problem still exists.



  • This problem still exists.

    Pls help me.