Skip to main content
sw2090
SuperUser
sw2090
SuperUser
June 26, 2020
Question

strange dyndns behaviour on ipsec s2s vpn

  • June 26, 2020
  • 2 replies
  • 7741 views

Hiho,

 

ran into yet annother issue:

 

I have one ipsec tunnel that uses a dyndns FQDN as remote gw as the other side doesn't have static wan ip. 

The tunnel was set up as usuall with th eFQDN as gateway. It used to work for quite a while.

Since the IP is not static the dyndns on the opposite Site is done by fortiddns service. Both sides have FGT100E on 6.0.8 .

Now some day the first side stopped resolving the dyndns FQDN and since then uses some cached data. Of course the IP on the oppsite side changed meanwhile. 

 

When I do "exec ping <fqdn>" on this Side on cli it does resolve to the correct ip in there. But IPSec monitor still shows an old  IP and the tunnel does not come up.

I already cleared fqdn and hostname cache of dnsproxy service on this side with no change.

So seems only just ipsec does not resolve that fqdn and uses cached data instead.

 

Does anyone have a hint where that is cached an dhow can i either flush that or make ipsec resolve the ddns again?

    2 replies

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    June 26, 2020

    Hmmm, makes me wonder why a trillion other s2s VPNs with dyndns addresses are working OK.

    If you watch the DNS process (diag deb app dns -1) you'll see that the dynamic target addresses are requested periodically by the FGT. This is why a tunnel will come up after the remote side changed it's WAN IP.

    Of course, caching dynamic FQDNs is not smart (and I hope FortiOS treats them differently...). At least after the TTL has expired the FGT has to query again.

     

    In short:

    - do you see those dynamic requests, at least once per TTL period?

    - if you use a different dyndns provider, does the reconnect time shorten? in my case, it did so extremly, switching from a free to a paid DynDNS account. The way FortiDDNS works could be the reason why changes are not propagated in time.

     

    Finally, have a go at v6.0.10. It's a fine release IMHO, fixing some issues related to IPsec VPNs (fragmentation issues).

    sw2090
    SuperUser
    sw2090Author
    SuperUser
    June 29, 2020

    yeah I'm wondering too.

    I do have a 2nd S2S Ipsec from a different FGT to the same ddns address and tht one works fine.

    Just that one FGT seems not to requery the ddns at all. It has a wrong IP for months now.

    I did diag debug app dns -1 but I did not see anything within the last couple of minutes. Is there any way to look upp the TTL on this FGT?

     

    And as I said its in ipsec only. If I exec ping to the ddns on cli it is resolved correct and works fine.

     

    torisa
    torisa
    New Member
    November 12, 2020

    Hi,

     

    Im gonna bumb this since Im facing this issue too. We have FortiOS 6.2.4 and IPSec DynDNS records are not updating.

     

    Did you found any solution for this?

     

    MOdendaal
    MOdendaal
    New Member
    March 27, 2021

    I know it's been a while, but this may be helpful. If I'm understanding your problem correctly, the remote IP changes, but the central gateway does not update its tunnel with the new remote gateway DDNS address, and still thinks the old tunnel is "up". I assume that if you manually bring the tunnel down and up again, it corrects itself?

     

    If this is your scenario, then I had this issue too a while back. To overcome this, I enabled DPD (Dead Peer Detection) on the phase1 interface in question, on the static IP gateway, and forced it to "on-idle". You could use "on-demand" as well, but that only works if there is outgoing traffic that is being sent on a fairly frequent basis. If there's no outgoing traffic to that gateway, then "on-idle" is your best bet.

     

    Like such:

     

    FGT-static (vdom1) # config vpn ipsec phase1-interface
    FGT-static (phase1-interface) # edit dynamic-vpn
    FGT-static (dynamic-vpn) # set dpd on-idle
    FGT-static (dynamic-vpn) # end

     

    The theory behind this is that the central gateway will monitor the traffic on that tunnel. With "on-idle" DPD, IPSEC traffic is monitored until there's no IPSEC traffic traversing. When there's no IPSEC traffic detected, it starts sending "R U There" messages to the remote tunnel peer (in this case, the "wrong" DDNS IP). If no response is received, it makes a conscious decision to bring the tunnel down and re-initiate it. This should then re-initiate it with the correct new DDNS IP.

     

    Good luck.

     

    Matt

     

    Terms & ConditionsAccessibility statement