An IPsec tunnel to a third-party device#

You will end up with an IPsec site-to-site tunnel to a device you do not control — a cloud provider's gateway, a customer's firewall, an appliance that speaks IPsec and nothing else. This is the reason to reach for IPsec rather than WireGuard: interoperability.

The Wheelhouse editor stages the whole thing in one go: an IKE group, an ESP group, the pre-shared key, the peer, and one tunnel per pair of prefixes.

Before you start#

• The operator role and a licence.
• The far end's parameters, agreed in writing. IPsec fails silently and asymmetrically; every one of these has to match exactly:

• The local address the tunnel sources from, and the remote peer's address.

Step 1 — Fill in the panel#

Security → IPsec → + Add tunnel.

The editor takes a name, the remote address, the local address (chosen from the router's own addresses), the pre-shared key, the local and remote prefixes, and the algorithm choices. Local and remote prefixes are comma- or space-separated lists, and the editor produces one tunnel per pair — three local prefixes and two remote ones make six tunnels, numbered from 0.

set vpn ipsec interface eth1

set vpn ipsec ike-group IKE-branch key-exchange ikev2
set vpn ipsec ike-group IKE-branch lifetime 28800
set vpn ipsec ike-group IKE-branch proposal 1 encryption aes256
set vpn ipsec ike-group IKE-branch proposal 1 hash sha256
set vpn ipsec ike-group IKE-branch proposal 1 dh-group 14
set vpn ipsec ike-group IKE-branch dead-peer-detection action restart
set vpn ipsec ike-group IKE-branch dead-peer-detection interval 30
set vpn ipsec ike-group IKE-branch dead-peer-detection timeout 120

set vpn ipsec esp-group ESP-branch lifetime 3600
set vpn ipsec esp-group ESP-branch pfs enable
set vpn ipsec esp-group ESP-branch proposal 1 encryption aes256
set vpn ipsec esp-group ESP-branch proposal 1 hash sha256

set vpn ipsec authentication psk branch id 203.0.113.10
set vpn ipsec authentication psk branch id 203.0.113.20
set vpn ipsec authentication psk branch secret <the pre-shared key>

set vpn ipsec site-to-site peer branch authentication mode pre-shared-secret
set vpn ipsec site-to-site peer branch authentication local-id 203.0.113.10
set vpn ipsec site-to-site peer branch authentication remote-id 203.0.113.20
set vpn ipsec site-to-site peer branch local-address 203.0.113.10
set vpn ipsec site-to-site peer branch remote-address 203.0.113.20
set vpn ipsec site-to-site peer branch ike-group IKE-branch
set vpn ipsec site-to-site peer branch default-esp-group ESP-branch
set vpn ipsec site-to-site peer branch connection-type initiate
set vpn ipsec site-to-site peer branch tunnel 0 local prefix 192.0.2.0/24
set vpn ipsec site-to-site peer branch tunnel 0 remote prefix 198.51.100.0/24

The groups are named IKE-<name> and ESP-<name> and written only when you did not point the panel at existing ones — reusing an existing group is how several peers share one policy.

set vpn ipsec interface <if> is added only when the local address's interface is not already listed, so a second tunnel out of the same uplink does not repeat it.

Dead peer detection is on by default: restart after 120 seconds of silence, probing every 30. Turn it off in the panel if the far end objects to it.

Connection type is initiate by default — this router brings the tunnel up. Set it to respond when the far end initiates, which is what you want if this side is behind a changing address.

Step 2 — Open the firewall#

IPsec is UDP 500 for IKE, UDP 4500 when either end is behind NAT, and ESP (protocol 50) for the traffic itself.

set firewall ipv4 input filter rule 110 action accept
set firewall ipv4 input filter rule 110 description 'ipsec ike'
set firewall ipv4 input filter rule 110 protocol udp
set firewall ipv4 input filter rule 110 destination port 500,4500
set firewall ipv4 input filter rule 110 source address 203.0.113.20

set firewall ipv4 input filter rule 111 action accept
set firewall ipv4 input filter rule 111 description 'ipsec esp'
set firewall ipv4 input filter rule 111 protocol esp
set firewall ipv4 input filter rule 111 source address 203.0.113.20

And a forward rule for the traffic inside, matched on the prefixes rather than an interface — IPsec has no tunnel interface in this mode.

set firewall ipv4 forward filter rule 50 action accept
set firewall ipv4 forward filter rule 50 description 'to the branch'
set firewall ipv4 forward filter rule 50 destination address 198.51.100.0/24

Step 3 — Do not masquerade the tunnelled traffic#

Source NAT applied to traffic bound for the tunnel makes it miss the traffic selector, and the tunnel then carries nothing while looking perfectly healthy. If your masquerade rule matches broadly, add an exclusion rule with a lower number.

Check it worked#

The page shows declared peers beside strongSwan's live associations. That pairing is the diagnostic: a peer in the configuration with no association is a tunnel that has not come up. When strongSwan is not initialised at all, the page reports that rather than showing an empty table as if it meant "no tunnels".

show vpn ipsec sa
show vpn ipsec status

Then test through it:

ping -c 3 198.51.100.1

When it does not come up#

The far end's log is as important as yours. IPsec debugging with one side's logs is guesswork.

Undoing it#

The peer's detail panel has Disable, which stages set … disable and keeps the configuration, and Delete, which removes the peer.

delete vpn ipsec site-to-site peer branch
delete vpn ipsec ike-group IKE-branch
delete vpn ipsec esp-group ESP-branch
delete vpn ipsec authentication psk branch

Disable first when you are diagnosing; delete when you are finished with it.

See also#

• WireGuard between two sites — simpler, when both ends are yours
• A default-drop ruleset that admits what you meant
• IPsec — the page, under Security, VPN and accounts

Checked against ui/src/pages/Ipsec.tsx · agent/main.go · docs/deploy.md