IPSec Tunnel Doesn't Work with Dynamic DNS

[hillsitsupp]

Hi

I'm using a Teltonika RUT240 in passthrough mode to add 4G to a Fortigate 60E running 7.0.12. It seems to work well enough, and the Forti interface connected to the Teltonika gets its public IP. The idea is to create a second IPsec tunnel on the 4G interface and aggregate it with the main IPsec tunnel on the main WAN interface for  redundancy.

I can only get a tunnel up on the 4G interface if I set the 200e at the other end to expect dial-up. If I try it using the dynamic DNS FQDN of the 60E,   I get "no SA proposal chosen" and it fails.

It appears you can't add a dial-up IPSec tunnel to an aggregate - set type dynamic and set aggregate enable appear to be mutually exclusive - so I want to get it working using dynamic DNS.

Does anyone have any idea why IPSec is failing when I try to use dynamic DNS at the 200E end?

Error reads "ike Negotiate ISAKMP SA Error: ike 0:b822f87e5d0c811d/0000000000000000:17474: no SA proposal chosen"

[hbac]

Hi @hillsitsupp,

Does the dynamic DNS resolve to the correct IP address? We need to run ike debugs on both sides to find the root cause. Please refer to https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-IPsec-VPNs-tunnels/ta-p/195955

No proposal chosen usually means there is a configuration mismatch. 

Regards, 

[hillsitsupp]

It turns out the DDNS address isn't the address the other Forti sees the tunnel originating from.

There must be some NAT happening downstream of the 4G interface :(

[HarshChavda]

Hello @hillsitsupp ,

It's likely that some form of NAT is taking place downstream of your 4G interface. This could be happening at the Teltonika RUT240, or it could be done by the 4G service provider itself.  Make sure the Teltonika RUT240 is in passthrough mode, as you mentioned, to ensure it's not performing NAT. Check if there are any settings related to NAT or firewall that could be affecting the traffic. Enable NAT traversal (NAT-T) on both ends of the IPSec tunnel. This is designed to help VPN traffic traverse NAT devices.If your 4G service provider offers the option, consider using a static public IP address for your 4G connection. This would make the VPN configuration simpler and more reliable. 

[hillsitsupp · Accepted solution]

I got it working by changing the APN on the 4G device. This bypasses the CGNAT. I asked in a local forum for the 4G provider, and someone knew the correct APN name to use.

[mle2802]

Hi there,

I believe the issue is with DNS cache on the 200E. As the IP is changed and 200E still have the DNS cache to an old one, the SA is not matching. In dialup, 200E will always responder and does not expect any IP from the other peer as long as the other site initiated the negotiation, the tunnel will be up.

Regards,

[sw2090]

I also had issues with ipsec and ddns. In my case the problem is that the other side does nothave a static public ip so I have to use ddns. DDNS itself works fine on my FGT and resolves correctly. However even though the IPSec goes down once the other side's public ip changes the first time because the DDNS does update but the IPSec stack does not and I still see an old ip listed as remote gw on that tunnel. 

Due to that I changed to dial up because that only needs a remote gw on the side that is dialling in but not on the side it is dialling into. That worked. 

However using dial up I ran into yet annother issue with sd-wan vpn and routing and dial up tunnels...

[HarshChavda]

Hello @hillsitsupp 

The "no SA proposal chosen" error typically indicates a mismatch in the security settings between the two ends of the IPSec tunnel. However, your situation is a bit more complex due to the use of Dynamic DNS and the desire to aggregate tunnels. Double-check that the Phase 1 and Phase 2 settings match exactly on both ends of the tunnel. This includes encryption algorithms, hash algorithms, DH groups, and lifetime settings. Ensure that the Dynamic DNS is correctly configured and updated on the FortiGate 60E. Verify that the FQDN resolves to the correct IP address. Make sure that the FortiGate 200E is configured to use the FQDN and not an IP address for the remote gateway. If NAT is involved (which is likely, given the 4G interface), ensure that NAT traversal is enabled on both ends. Dial-up and static tunnels have different behaviors. Dial-up is generally used when you have a dynamic IP address, but it may not support all the features you need (like aggregation). The command diag debug application ike -1 can provide detailed information about the IKE negotiation process. Ensure that the Teltonika device is not altering the IPSec packets in a way that causes the FortiGate to reject them. Check logs on both ends for any additional clues as to why the SA proposal is not being accepted. 

[hillsitsupp]

It was the 4G provider using some carrier grade NAT. I managed to get it working by changing the APN on the 4G device, which bypasses the NAT.

Thanks for taking a look at it.