VPN and intrusion detection#

Encrypted transport and packet inspection, both built on what the base already has rather than bolted on beside it.

WireGuard#

In-kernel, because the base is Linux. Tunnels and peers are ordinary configuration objects: the page lists them, adds peers, and stages set interfaces wireguard … like everything else. Keys can be generated by the router.

WireGuard ships as a feature module — a catalogue entry that gates a native page rather than running a container — so it is installed from the app store in one click and stages nothing. Configuration outranks the flag: a tunnel that exists on the router shows its page whether or not the module is marked installed.

IPsec#

The IPsec page puts configured peers next to strongSwan's live security associations, which is the comparison you need when a tunnel is "up" in one sense and not the other.

The site-to-site editor builds the whole thing — IKE group, ESP group, pre-shared key, peer and traffic selectors — with modern defaults, and shows the commands:

What the site-to-site editor builds, in outline

set vpn ipsec ike-group IKE-office key-exchange ikev2
set vpn ipsec ike-group IKE-office proposal 1 encryption aes256
set vpn ipsec esp-group ESP-office proposal 1 encryption aes256
set vpn ipsec authentication psk office id 203.0.113.2

Both ends need the same key and mirrored selectors, which the page says on the panel rather than leaving you to find out.

OpenVPN#

Instances are listed with per-mode status, and can be disabled or deleted.

Suricata, twice#

As a detector. VyOS ships Suricata and drives it from service suricata, in af-packet mode: it watches a copy of the traffic and raises alerts. That is what the IDS page surfaces — the intent from the configuration, the reality of whether a Suricata process is running, and, when the agent is on the router and can read the log, the alerts themselves.

The page does not call that "IPS". A detector cannot drop.

As an inline engine. True prevention needs the engine in the packet path, which on Linux means NFQUEUE. The firewall hands matched packets to a kernel queue with action queue and queue-options bypass; a host-network Suricata container running -q 0 verdicts each one. All of it is native configuration, so it diffs, commits, rolls back and survives an image upgrade, and it works with the agent off-router because the engine is a container you stage through the Commit Bar.

The safety argument is the reason to trust it, and every layer of it was proven on the bench before a line of interface was written (2026-08-29):

queue-options bypass fails open. With no consumer on the queue, traffic still flows — 0% loss. Without bypass the same test black-holes at 100%, which is how you know the bypass is what is carrying it.
A host-network container with NET_ADMIN reaches the host's netfilter queue.
The engine genuinely verdicts: running, with bypass off, loss is 0%. That is the decisive test — the only way traffic survives a non-bypassing queue is if something is accepting each packet.

Fail-open twice over: the firewall's bypass, and Suricata's own nfq.fail-open.

The interface enables it the safe way — by routing an existing accept rule through the engine. Same match, same permitted traffic, now inspected. A terminal queue rule that then accepts is exactly the accept it replaced, so no new hole is opened. A fresh interface-wide rule is offered too, and flagged, with the reasoning on the panel.

Read on#

Firewall and NAT — where the queue rule lives.
The wiki: WireGuard and inline IPS.