strange IPSec issue with dyndns

Question

I have this constellation here:

HQ FGT with two WAN and a FGT92D on site with two wan (of which only one is currently up and running).

There is two IPSec S2S tunnels between those both FGT. Just the way there is with 21 other Sites without any problems.

Since the FGT92D does not have static ips I use fortiddns service on both wans (with different ddns names).

Now WAN2 of the 92D is connected to the internet via some cellular hotspot and I encounter this behaviour:

on HQ FGT (300E) I see the request coming in. I see the external IP Of the 92D's WAN2 and I see the 92D sending its IKE and Proposals.

and then HQ FGT tries to resolve remote gw but it always takes the wrong one. It takes the ddns gw from the 2nd tunnel to the 92d.

Looks like this in ipsec log:

ike 0: comes <external ip of wan2 on 92D>:500-><ip of port on HQ FGT where the 92D's remote gw ip is conected>:500,ifindex=24.... ike 0: IKEv2 exchange=SA_INIT id=2f84373beabf61a4/0000000000000000 len=440 ike 0: in 2F84373BEABF61A400000000000000002120220800000000000001B8220000300000002C010100040300000C0100000C800E01000300000802000007030000080300000E000000080400000E28000108000E000016017C1860F754936A8D3BC29C15DBDC2B6A806F814C5BD33273CAFA1D157D414F5C2A308A5765CD48EE97527E465CB21599C22CF315D5260AAA64373B50800CBE26AD05BD9490C1640CCEBFD0E996DA8F3A50E3F9476BF697606DB5BE86525F97CBBDFB08F892802EDF3768C4C9BEF91CDF2EF4A718ED97AA3A82ECE1E009D4F25904A5D61D32AB75E67A7040C8143F2B37FDCA87D652D709FF77CDA74F0785BD76B7D30395AB9537C87087152B7FD1D38DB1EC706FEE3875A4FF6C5CB76DCAE7130CE98AC07A9A052F5DEAD0BA58316303A7807D1DA9619CBF19272CD6260A9B899B9A6071626C8F9436A2D69189CF2C971C55D9355B7C2F1FB5DCF7DE25422900002414A0A9B097116A73820635CF2B2FB0D3DFDC5BA1A8DF5A8E33B8080D6B6F077B2900001C00004004CD728AD1D2FD7CD0C128C8A842FF2761439275772900001C00004005F9337C58413C9586DAE380EC173CB4A7C6AAAE57000000080000402E ike 0:2f84373beabf61a4/0000000000000000:1615029: responder received SA_INIT msg ike 0:2f84373beabf61a4/0000000000000000:1615029: received notify type NAT_DETECTION_SOURCE_IP ike 0:2f84373beabf61a4/0000000000000000:1615029: received notify type NAT_DETECTION_DESTINATION_IP ike 0:2f84373beabf61a4/0000000000000000:1615029: received notify type FRAGMENTATION_SUPPORTED ike 0:2f84373beabf61a4/0000000000000000:1615029: incoming proposal: ike 0:2f84373beabf61a4/0000000000000000:1615029: proposal id = 1: ike 0:2f84373beabf61a4/0000000000000000:1615029: protocol = IKEv2: ike 0:2f84373beabf61a4/0000000000000000:1615029: encapsulation = IKEv2/none ike 0:2f84373beabf61a4/0000000000000000:1615029: type=ENCR, val=AES_CBC (key_len = 256) ike 0:2f84373beabf61a4/0000000000000000:1615029: type=INTEGR, val=AUTH_HMAC_SHA2_512_256 ike 0:2f84373beabf61a4/0000000000000000:1615029: type=PRF, val=PRF_HMAC_SHA2_512 ike 0:2f84373beabf61a4/0000000000000000:1615029: type=DH_GROUP, val=MODP2048. ike 0:<tunnel name (wrong tunnel)>: sending DNS request for remote peer <ddns name of remote gw of wrong tunnel> ike 0:2f84373beabf61a4/0000000000000000:1615029: no proposal chosen ike Negotiate SA Error: ike ike [10215] ike 0: DNS response received for remote gateway <ddns name of remote gw of wrong tunnel>

Why the hell does it do that? The tunnel it uses is not even connected to that interface at HQ FGT!

If I change remote gw of that wrong tunnel and connect it to the interface set to be remote gw on the 92d the tunnel goes up and works.

Also the routing behaves strange. All othere sites do have two tunnels and two routes with different distance/prio and work fine.

With this site it only put up one route and that is always the wrong one of the two routes. Only if I disable the wrong one and leave the working one it does the routing as it should.

I have no explanation for this weird behaviour. But looks to me as if IPSec on Fortigate has a lot of trouble if one uses ddns as remote gw. All other IPSecs have static ip as remote gw and they work fine...

sw2090 · Answer

Ok in addidtion:

when I change both IPSEcs to do IKE V1 aggressive mode and set HQ to only accept specific peer id on each one, the correct ipsec comes up. So looks like if FortiOS messes up ipsec if you use DDNS as remote gw as it is no longer resolved before connecting. I remember seeing in debug log of before 6.2.7 that it regualarly did resolve every FQDN remote gw (including DDNS) so it hat the ip cached. It seems not to do this anymore and thus cannot use the remote gw to find the right tunnel. As it also seems to ignore the device binding at this time it does use what ever I cannot figure out to choose a tunnel and goes wrong.

If you nail it to a peer id it uses that to find the right tunnel and works.

Still it screws the routing though. It does have two routes to Site subnet at HQ one over each of the two IPSEcs with different Prio and distance. Correct tunnel comes up now but it does not put up the static routing over that tunnel. In Routing monitor it always only has the route over the other tunnel that is not currently up while at all other Sites it has both routes in there.

Only if i disable the static route over the tunnel that is not up it uses the correct working route.

Sign up

Login with SSO

Login to the community

Login with SSO