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.

One panel adds the whole thing: the peer, its pre-shared key, the networks on each side, and the IKE and ESP groups.

Before you start#

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

This router	The other end
IKE version (IKEv2 by default)	The same
Encryption and integrity, for IKE and for ESP (AES-256 and SHA-256 by default)	The same
DH group (14 by default)	The same
Perfect forward secrecy	The same
Lifetimes (8 hours for IKE, 1 hour for ESP by default)	The same, or the device's own rules for lifetimes that differ
Pre-shared key	The same
Local and remote networks	Mirrored
Local and remote IDs	Mirrored — usually the two public addresses

The other end's public address, and which of this router's addresses it will talk to.

Step 1 — Add the peer#

Protect → IPsec → Add peer.

Peer

Name: branch.
Remote addresses: the other end's public address, 203.0.113.20.
Local address: the router's address on the uplink, 203.0.113.10. For an uplink whose address changes, choose DHCP on that interface.
Connection: Connect at once brings the tunnel up from this side. Choose Wait for the other end when the other end initiates — the usual choice when this side's address changes.

Networks

Local networks: 192.0.2.0/24, the network behind this router.
Remote networks: 198.51.100.0/24, the network behind the other end.

Each pair becomes one tunnel: two local networks and two remote ones make four, and the other end has to list the same pairs.

Authentication

Pre-shared key: the key you agreed. The panel does not show it again; to change it, enter a new one.
Local ID and Remote ID: leave them empty to use the two addresses, unless the other end was told something else.

Key exchange (IKE) and Traffic encryption (ESP)

New group makes an IKE group and an ESP group for this peer, IKE-branch and ESP-branch, with the defaults above; change any value to what was agreed. Choosing an existing group instead shares its policy with the peers that already use it — the panel names them, because a change to the group changes them too. Dead peer detection, on by default, restarts the tunnel when the other end stops answering; turn it off if the other end objects.

Add peer, then Apply changes.

Step 2 — Open the firewall#

IPsec arrives on the uplink as UDP 500 for the key exchange, UDP 4500 when either end is behind NAT, and ESP for the traffic itself. On the Firewall page, accept all three in the input chain from the other end's address.

Then the traffic inside: a forward rule accepting traffic between 192.0.2.0/24 and 198.51.100.0/24, matched on the networks — this kind of tunnel has no interface to match on.

Step 3 — Do not masquerade the tunnelled traffic#

Source NAT applied to traffic bound for the tunnel changes its source, it then matches none of the tunnel's networks, and the tunnel carries nothing while looking healthy. If your masquerade rule matches the LAN broadly, add a rule before it that leaves traffic to 198.51.100.0/24 untranslated.

Check it worked#

The peer's row turns Connected, with how long it has been up, and Security associations lists its tunnel with the traffic through it. A peer in the table with no association is a tunnel that has not come up; the page says when IPsec is not running at all.

Then test through it, from a host on the LAN:

bash

ping -c 3 198.51.100.1

When it does not come up#

Symptom	Almost always
Not connected, nothing arrives from the other end	The input firewall, or the wrong address on either side.
The key exchange completes, no traffic tunnel	The ESP proposal, or networks that are not each other's mirror image.
Comes up, drops after an hour	A lifetime mismatch, or dead peer detection on one side only.
Connected, no traffic passes	The networks, source NAT on the tunnelled traffic, or the forward rule.
Works one way	The other end's forward rules, or its networks.

The other end's log matters as much as this router's. IPsec debugging with one side's logs is guesswork.

Changing or removing it#

Select the peer to change anything — the networks, the key, the groups, the connection. Save changes adds only what differs. Turned off keeps the peer configured and stops it connecting, which is the first move when diagnosing. Delete peer removes the peer, its pre-shared key, and its groups when no other peer uses them.