IPsec¶
IPsec builds a site-to-site VPN to equipment that does not speak WireGuard — most commercial firewalls and ISP-supplied routers.
Where:
- Connectivity > VPN tunnels lists every tunnel with its state, Far end and Networks reached. Edit configuration opens the tunnel's form.
- Connectivity > Interfaces & network > + Add Interface > IPsec creates one by hand. Create a tunnel on an empty VPN tunnels page goes to the Integrations catalogue.
Creating a tunnel¶
| Field | Meaning |
|---|---|
| Name / Description | How the tunnel is listed |
| Remote gateway address | Where the far gateway can be reached. Required — without it this device cannot start the tunnel |
| Local address | Leave empty (defaults to the WAN address) unless this device has more than one uplink |
| Local Subnet | The network on this side to make reachable |
| Remote Subnet | The network on the far side |
| Local identity (name) / Remote identity (name) | Optional FQDN identities. Fill only if the far side expects names; left empty, the addresses are used |
| Pre-Shared Key | The shared secret, identical on both ends |
Click Create IPsec, then apply and confirm.
The far side must mirror it¶
| This side | Far side |
|---|---|
| Local Subnet | Remote Subnet |
| Remote Subnet | Local Subnet |
| Local identity | Remote identity |
| Remote identity | Local identity |
| Pre-Shared Key | The same key |
The two subnets must not overlap: two sites both on 192.168.1.0/24 cannot be joined until one is renumbered.
Editing a tunnel¶
Edit IPsec — name shows the same fields. Leave Pre-Shared Key as it is to keep the current key; changing it breaks the tunnel until the far side is changed to match.
The pre-shared key is stored in the device configuration
It is obscured in the form but readable by anyone who can read the configuration. Do not reuse a key that protects anything else.
Tunnel state¶
The VPN tunnels page and the chip on the interface row show:
| State | Meaning |
|---|---|
| Up · traffic | Packets have crossed in both directions |
| Up · idle | Ready; nothing has used it yet. Send traffic between the two subnets to confirm |
| Authenticated | The ends authenticated, but no data channel was established — usually a subnet mismatch |
| Connecting | Still trying to reach the far end: unreachable peer, or a key, identity or proposal mismatch |
| Refused by the far end | The far end rejected authentication — usually a wrong pre-shared key or an unexpected identity |
| Down | No policy on the device, or the IKE daemon is not running |
| Incomplete | No remote gateway address, so the tunnel cannot be attempted |
| Unknown | The gateway has not reported on this tunnel |
Click the chip on the interface row (Show tunnel status) for the detail: the phase, Received / Sent counters, Established age, Rekey in, and the Tunnel daemon log, which says why a tunnel is stuck.
Making traffic flow¶
Traffic arriving through the tunnel is filtered by the Security policy like any other. Without a rule permitting the remote subnet, the default deny applies and a working tunnel looks broken.
To test, ping an address in the remote subnet from a machine in the local subnet. A ping from the gateway itself (Diagnostics > Ping) leaves from the gateway's own address, which is outside the tunnel's subnets, so it fails even on a working tunnel.