IPsec Site to Site VPN to Multiple Endpoints with dynmic IP

Started by browne, May 07, 2025, 02:34:52 PM

Previous topic - Next topic
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?

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.
Hardware:
DEC740

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.

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.
Hardware:
DEC740

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?

May 07, 2025, 06:56:47 PM #5 Last Edit: May 07, 2025, 07:02:13 PM by 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.
Hardware:
DEC740

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.
Hardware:
DEC740