IPsec Failover project...

[jorgevisentini]

Ok, but this means we have to use if_ipsec which is currently not supported.

I know.
But this functionality is not specific to StrongSwan, it does not have failover, we can read in its documentation.
This is a functionality implemented in the specific part of each product. Each one implements its logic and works together with Strongswan, Libreswan...

Libreswan has it's own interface support (software), and FreeBSD introduced with 11.0 if_ipsec (OS). Don't know how exactly Sophos does it, they also use strongswan, but the old version 4 (no IKEv2!!!). Also ASA e.g. introduced route based VPN very late.

So... the only distribution I got to see the failover script was Sophos, in this case both UTM and XG and both are big scripts...

[jorgevisentini]

I see this one timely more realistic (OPN to OPN):
https://github.com/opnsense/core/issues/952

I've seen this post. Today I even use OpenVPN with redundancy for client and it works perfectly, although I have to add the second IP manually in the configuration file, but it would not apply in that case.

[nzkiwi68]

Hi.

First time post here, but, I'm a very experience network engineer with a particular bent on network security and firewalls. I come from a background of originally doing packet filters in routers, to a long time SonicWALL partner, then pfsense and now seriously looking at OPNsense.

What I desperately miss from SonicWALL days was their excellent IPsec failover.

I would change pfsense to OPNsense in a heartbeat if we can get a decent IPsec multi wan failover solution that works. This what all the expensive brand name firewalls do well.

Consider this:
2 sites, siteMAIN and siteBRANCH
Both sites have dual WAN and clustered firewalls

With SonicWALL, it's possible to have the remote static IP address both loaded in phase1 for siteMAIN to siteBRANCH (WAN1 and WAN2) and vice versa. On WAN1 failing at either siteMAIN or siteBRANCH, IPsec rapidly heals and the tunnel continues working, I'm talking about losing only a few pings.
Also, just as critical, the state is NOT lost. I suspect SonicWALL (and others) cleverly do not drop nor reset state on a multi WAN IPsec tunnel.
Perhaps the mechanism is based around knowing the phase2 networks, state is not lost on phase2 local-remote networks.

I notice that using the current system of dynamic DNS to get around IPsec fail-over has some major shortcomings:
1. DDNS takes quite a while to detect and respond to fail-over, upwards of a minute
2. State is lost during the fail-over which wrecks telnet and SSH sessions and that causes network chaos

FreeBSD with pfsync, CARP and the multi WAN  is great. We just need a robust IPsec multi WAN fail-over.

Back to my example, and a bit more detail:

• siteMAIN, WANm1 and WANm2
• siteBRANCH, WANb1 and WANb2

WANm1 fails at siteMAIN:

• Multi WAN at siteMAIN handles the transition from WANm1 to WANm2 no problem for the firewall itself
• The issue is siteBRANCH WANb1 today doesn't accept traffic from WANm2
• State is lost

[mimugmail]

@franco:

- Second dropdown list for "Interface backup" (in P1)
- Second dropdown list for "Remote backup gateway" (in P1)
- Adding a P1 remote X automatically creates a "far gateway" which is monitored via apinger
- IF locale gateway of Interface (WAN primary) is down, change templating to IP of backup interface "left"
- IF far gateway is down leave left as is but change templating for "right"

I could imagine this is not too hard to setup .. but not sure if apinger works this way

[franco]

We can keep this in a ticket, but the usage of "apinger" makes me doubt the long-term stability of this solution. Maybe we can do some other kind of monitoring and / or a manual ping command helper?

Apinger used to do exactly this: probe remote servers for availability, but in the course of pfSense was turned into a gateway monitoring solution that shall stop working because it requests a full bind to the interface IP *and* a monitoring route, both of which do not scale well:

We'd ideally want this to be a solution that works on top of multi-wan, not being stuck to its limitations of fixed-link behaviour.

There is, however, a gateway "ping" script for IPsec already which could be used to pull this off by pinging inside the tunnel and using this information?

https://github.com/opnsense/core/blob/master/src/sbin/ping_hosts.sh


Cheers,
Franco

[mimugmail]

@franco: I'll have a look, thanks

@jorge: Would you open an issue?

[jorgevisentini]

I'm so sorry, my english skills are bad 

@nzkiwi68
Your logic are perfect.
I have another idea... Have a siteMAIN with 2 tunnels (P1) with 1 diferent IP in each.

We can keep started the 2 tunnels and use metric of route. If route 1 not ping the remote internal network (P2) then try the route 2. Like this...

I try with DDNS but I did not get success because of the time it takes to change the IP. Even with paid DDNS.


@mimugmail
Sorry my english again, i dont understend "@jorge: Would you open an issue?"
Whre I open issue?

@franco
I dont know if I talk nonsense but I use "fping" to test my hosts. It works very well.