Hi,
We have gateway with multi-wan, dynamic dns and ipsec configured and working. When the system failover to the secondary WAN connection, clearos does not update itself to reflect that is communicating from the secondary wan ip address. This is causing connectivity to Azure to fail since its attempting to use the primary wan ip address to connect and authenticate when in fact the secondary ip address is active. The IKE logs show auth attempts to Azure using the wrong IP address. Any idea on how to update interface settings so that IKE works with correct ip address?
Greg
We have gateway with multi-wan, dynamic dns and ipsec configured and working. When the system failover to the secondary WAN connection, clearos does not update itself to reflect that is communicating from the secondary wan ip address. This is causing connectivity to Azure to fail since its attempting to use the primary wan ip address to connect and authenticate when in fact the secondary ip address is active. The IKE logs show auth attempts to Azure using the wrong IP address. Any idea on how to update interface settings so that IKE works with correct ip address?
Greg
In Multi-WAN
Share this post:
Responses (6)
-
Accepted Answer
If ClearOS is working properly with Dynamic DNS, it can failover the IPSec to the secondary IP address if and ONLY IF your IPSec is compatible with using hostnames for its IPSec tunnel...on both sides. You can test if the hostname failover is working with a simple ping from a hotspot or 3rd party by pinging the hostname. This should change when the first ISP goes down based on a 5 minute TTL for the hostname.
Sadly, most IPSec services only allow for IP addresses and not hostnames.
Long ago I made a simple script to kick OpenVPN if a ping across the tunnel isn't working. This could be adapted to IPSec as well.
https://documentation.clearos.com/content:en_us:kb_o_openvpn_connection_script
-Dave Loper
Community Member -
Accepted Answer
-
Accepted Answer
This is tricky. In theory you can have your local IP (i.e. left or right) set to an FQDN. If Dead Peer Detection (DPD) is set up correctly (to "clear" ?), IPsec should then re-read the FQDN. This then relies on you having an FQDN which fails over. Your free poweredbyclear.com FQDN may do this. It relies on DPD working and you will have to wait for DPD to trigger and for your FQDN DNS to propagate through the DNS system. Also, you must not set your poweredbyclear.com to your ClearOS LAN IP so it resolves externally.
A faster way would be to script it. You could try dropping a mini script into /var/clearos/events/network_connected. In the script compare the value of left or right:
and compare it with:grep 'left=' /etc/ipsec/your_file.conf | sed 's/\s*left=//'
or some other method - https://opensource.com/article/18/5/how-find-ip-address-linux. If they are different, update your_file.conf. You will also need to update the associated ipsec secrets file. You can then sledgehammer the restart by restarting ipsec but this will kill any other open ipsec connections. Alternatively you can do:curl ifconfig.co
ipsec secrets
ipset --auto replace your_conn -
Accepted Answer
-
Accepted Answer
All is working now. First, we had to upgrade LTE connection from dhcp to static. For some reason, verizon was NATing or doing other funky thing with the ip address. Even though we saw the dhcp assigned address it differed from what we got when we curl ifconfig.co. Secondly, we used host.poweredbyclear.com instead of ip address for Azure IP Sec config. Lastly, we restarted ip sec to initiate connection to azure. -
Accepted Answer
FWIW, in the secrets file you are not limited to the local and remote IP. You can have as many IP's as you want, so you can leave both local IP's in the secrets file. Alternatively, if you switch the conn to using IKEv2, you can use the local ID (leftid or rightid) in the secrets file preceded with a "@". The left/rightid can be any text string you want but must be specified at both ends of the connection and in libreswan should be preceded with an "@". If not specified it defaults to your external IP.
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »