Bug #6370


IPSEC bound to WAN gateway group and Dynamic DNS doesn't to fail back tunnel to WAN on DDNS update

Added by Steven Perreau almost 8 years ago. Updated over 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


I first found this happening on 2.3, but waited until post upgrade on 2.3.1 and tested again extensively.
The tunnel only rebuilds back from WAN2 to WAN at reauth time.

Each firewall P1 "My identifier" set as "Dynamic DNS" and with the correct FQDN of that local firewall's FQDN.

Actions #1

Updated by Josh H about 7 years ago

I too have this issue in 2.3.2. Internet fails back to primary interface but IPsec does not always fail back to primary interface. Dynamic dns will get stuck on failover interface. I wish the checkbox to reload ipsec on failover would be left there for cases when this breaks in different versions.

Actions #2

Updated by Steven Perreau about 6 years ago

Tested with 2.3.4 - IPsec still does not fail back to primary until reauth.

A checkbox that forced IPsec to rebuild on Dynamic DNS changing when the IPSec is bound to the same gateway group as Dynamic DNS would be useful.

Actions #3

Updated by Jim Pingle over 4 years ago

See also: #8286

Actions #4

Updated by Marc H almost 4 years ago

This is a real problem when backup WAN is a high cost or low capacity link such as LTE/3G mobile. The objective is to rely on the link only as long as necessary, and then resume using tier 1 link as soon as it is restored. With current behavior (2.4.5), when primary WAN is restored, new traffic will resume over the primary link but IPSec traffic remains on the backup link. Need a way to force IPSec to reconnect in this scenario.

More general feature request that would also solve this issue is at

Actions #5

Updated by Viktor Gurov over 2 years ago

  • Status changed from New to Confirmed

I see the same issue on 21.05

Actions #6

Updated by Jim Pingle over 2 years ago

This may be fixed by #12315 -- please re-test on a current Plus 21.09 or CE 2.6.0 snapshot.


Also available in: Atom PDF