IPSec Connections setup with PSK

Started by shpokas, July 17, 2025, 06:39:20 PM

Previous topic - Next topic
Hi,
I have some questions how to configure new IPSec Connections with good old PSKs when there are multiple IPSec tunnels on the same router.

First question - PSK setup.
I have multiple IPSec tunnels configured, in all of them OpnSense firewall is identified by it's IP address. Note, I cannot change remote end setup, I can only migrate existing connections.

So, in "VPN: IPsec: Pre-Shared Keys" I have multiple PSKs defined, local identifier is always OpnSense's external IP address.
But how is then this PSK referred in Connection setup?
Or, to put this differently, how do I find "ID" and "Round" values when setting up a new connection?

It may seem easy when you have just one tunnel and one PSK, but I have multiple.
Thanks,
shpokas

Check out this migration guide:

Migrate from Tunnels to Connections

https://docs.opnsense.org/manual/vpnet.html
Hardware:
DEC740

July 17, 2025, 07:31:37 PM #2 Last Edit: July 17, 2025, 07:36:58 PM by shpokas
Thanks. But this is exactly what I was asking about - when there are multiple keys and multiple connections (I downloaded my swanctl.conf, yes), then in new, Connection setup for each "Pre-Shared Key" the "Local Identifier"-  which is the value of "id" in "local-0" - is the same (local) IP address.
This means I have to specify the same "Id" for each tunnel, but how can this work if actual keys are different?

Each PSK can have the same local identifier, but they need unique remote ones.
Hardware:
DEC740

Today at 11:08:28 AM #4 Last Edit: Today at 11:11:34 AM by shpokas
Well, it works, and thanks for forcing me to read documentation carefully.
But it leaves a lot to be wished for.
  • PSK seems to be just forced into certificate authentication presentation and is conterintuitive. Not sure which one of them is the major use case. In my experience nobody uses certificates for tunnels.
  • now MOBIKE default value has reversed.
  • it is possible to enter more than one network in children setup, which was not possible before, but that does not work anyway.
  • life time and rekey time value migration is a mess, although I reckon current setting may be closer to Strongswan presentation.
  • reqid value, which was not even visible in legacy setup, but now, according to documentation, is highly recommended, is difficult to track and can be easily be set to the same value for multiple children.

Well sometimes having less magic leads to more explicit configuration.

- I had to use certificates before, its quite common when setting up roadwarrior IPsec setups (EAP-TLS), but also in S2S when higher security than just a PSK is needed. https://docs.opnsense.org/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.html
- Having multiple networks in the same child works, just depends on the peer on the other side. Between two OPNsense or a recent strongswan peer it works just fine, other vendors might need tunnel isolation, meaning one child SA per traffic selector.
- The reqid value is just needed if you have a mix of legacy and connection tunnels at the same time. If you migrated everything to connection the requid can be deleted as they will be auto generated.

Just give this component some time, it is way more powerful than the old GUI.
Hardware:
DEC740

Quote from: Monviech (Cedrik) on Today at 11:39:36 AMHaving multiple networks in the same child works, just depends on the peer on the other side. Between two OPNsense or a recent strongswan peer it works just fine, other vendors might need tunnel isolation, meaning one child SA per traffic selector.

I figured as much: that entering multiple networks in a single child vs. creating multiple children corresponds with the old "tunnel isolation" setting. Thanks for confirming.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)


Pah! Documentation! Where we are going we don't need "documentation"! :-)
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)