IPsec Site to Site VPN to Multiple Endpoints with dynmic IP

[browne]

Hello everyone,

I'm working on an existing infrastructure which is a new infrastructure to me. The network previously used three SonicWalls (one per site). Because of a very limited budget, only the main site can be migrated right now.

Current setup:
Main site: OPNsense (running on the latest business edition release) with two DSL lines (static IPs: 1.1.1.1 and 2.2.2.2) in failover mode, plus an LTE connection that is manually activated only if both DSL lines fail.
Two remote sites: each with a SonicWall, a single DSL line, and a dynamic IP (changes almost daily)

I'm trying to establish two site-to-site VPNs (one per remote site). Previously, both SonicWalls connected to 1.1.1.1 using IKEv1 Aggressive Mode. I'm trying to replicate this with OPNsense, but only one VPN connection works at a time.
Right now both VPNs are configured in IKEv1 Main Mode, i tried it with Aggressive Mode but it didnt seem to work at all.

The issue:
Site A: uses AES256-SHA256-ECP256 – connects successfully
Site B: uses AES256-SHA256-MODP2048 (the highest supported by that SonicWall) – fails to connect

Log shows:
Received proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Configured proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256

I've created two separate IPsec configs on OPNsense with the correct proposals. Both use 1.1.1.1 as the local address and 0.0.0.0/0 as remote peer.
Both have different local IKE IDs, remote IKE IDs and Pre Shared Keys which of course match with the corresponding remote site.
However, OPNsense seems to match only by IP and not by IKE ID. As a temporary workaround, I let Site A connect to 1.1.1.1 and Site B to 2.2.2.2. Ultimately, both should prefer 1.1.1.1 and automatically fail over to 2.2.2.2 if the primary DSL fails.

Is there a way to get this to work with the current SonicWalls and the OPNsense?

[Monviech (Cedrik)]

Can you tell me if both DSL lines use the same Gateway?

If yes, that is an unsupported configuration and the routing will not work correctly.

[browne]

They use a different Gateway.

I forgot to mention that both VPNs work if they use a different DSL line, but i want them on the same since the second DSL Line is only a backup.

[Monviech (Cedrik)]

I think what you evaluated might be true if the PSKs are not evaluated correctly. Maybe as a workaround you could assign the same PSK value to both of the remote tunnels, and configure just one PSK on OPNsense that matches for all tunnels with the IP address local identifier 1.1.1.1 and empty remote identifier.

[browne]

if i set the PSK values on both to the same, then the OPNsense would still match only based on the ip address and still use only one of the two configs.
Then the proposal would still not match for the second VPN.

I could set both VPNs to use the same proposal, then that would leave me basically with only one config for both remotes.
Can the OPNsense differentiate which ip network needs to go to which remote if anything else is identical?

[Monviech (Cedrik)]

Maybe you have to specify the identifier and prefix it. I dont know for sure though since I always used static IP addresses as identifiers.

https://docs.strongswan.org/docs/latest/config/identityParsing.html

What I know from the past though when I ran many tunnels in connections, is that I could only do one tunnel that had a dynamic remote endpoint, and n tunnels that were static in local and remote endpoints.

Though this might have been a configuration issue on my end, I opted for using multiple different external IPs to spread the dynamic endpoint tunnels out that expected 0.0.0.0/0. Kinda what works for you now with two ISPs.

[Monviech (Cedrik)]

Or try to set FQDNs in Phase 1 which are updated via dyndns to point to the correct IP addresses of the Sonicwalls, that will probably match the corrext policies too.

[browne]

Sorry for not responding over the past week.

I spent some time testing different identifier settings, which of course caused some connection issues during configuration.
I wasn't able to get this to work using just one DSL line.
Even though the connection only dropped for a few seconds at a time, employees at the remote sites told the manager they were unable to work.

Because of that, I was told to stop changing anything as soon as it's working.

We'll see what happens when the main DSL line goes down – but until then, I'd say this scenario doesn't really work with OPNsense.
So I guess it's kinda solved for now.

Anyway, thanks for your help Monviech!

[Monviech (Cedrik)]

Thanks for the response.

The scenario should work with FQDNs that are updated via Dynamic DNS in Phase 1 (as remote IP address for the remote firewall with the dynamic IP) as then the policies could be mapped to the correct IPs.

The main issue is using 0.0.0.0 as remote IP.

Though IPsec with Dyndns is always a bit flakey.