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, and every field of both is edited on the page. The agent generates a tunnel's key pair: the private key goes straight into the pending changes and never reaches a browser, and the page shows the public key to hand to peers.
Add device sets up a phone or a laptop in one step. The agent makes the device's keys, gives it the next free address in the tunnel, and writes its configuration — the router as its peer, the address to connect to, the router as its DNS server — shown once as a QR code and a file. The device's private key exists in that configuration and nowhere else: not on the router, not in a log, not in the audit trail.
A tunnel whose port the input firewall drops says so, and the rule that lets peers in is one click. Adding a device says when the router's DNS service would not answer it, or the forward firewall would drop its traffic.
WireGuard ships as a feature module — a catalogue entry that gates a native page rather than running a container — so it is switched on 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, so a tunnel that is "up" in one sense and not the other reads as exactly that.
One panel adds a peer and changes it afterwards: the remote and local addresses, the networks on each side — a tunnel per pair — a pre-shared key that is written and never shown, or certificates from the router's own store, the IDs, and the IKE and ESP groups with their encryption, integrity, DH group, lifetimes, perfect forward secrecy and dead peer detection. A group several peers share names them before it is changed, and deleting a peer takes its key and the groups nothing else uses.
OpenVPN#
Add instance builds a server, a client or one end of a site-to-site tunnel, with the
certificates it needs: named from the router's own pki tree, minted by the agent, or
pasted in and checked — the certificate against the CA, the key against the certificate —
and a tls-crypt or tls-auth key. It offers the input firewall rule for the port the
instance listens on. Every field of an instance is edited afterwards.
A server runs its clients from its settings. Add client has the agent sign a
certificate with the server's authority, its private key sealed in the pending changes.
Download gives an administrator the client's .ovpn file, assembled from the server's
own configuration and audited; no other private key the router holds is ever in it.
Revoke puts the client on a revocation list the authority signs, which the server
checks every client against — deleting a certificate would not stop a device that holds
its file.
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.
Fail-open, twice over
An inline engine sits in the packet path, so the question that matters is what happens when it stops. Each layer of the answer was verified separately on 2026-08-29.
queue-options bypassfails open. With no consumer on the queue, traffic still flows — 0% loss. Withoutbypassthe same test black-holes at 100%, which is how you know the bypass is what is carrying it.- A host-network container with
NET_ADMINreaches the host's netfilter queue. - The engine genuinely verdicts: running, with bypass off, loss is 0%. The only way traffic survives a non-bypassing queue is if something is accepting each packet.
The two layers are the firewall's bypass and Suricata's own nfq.fail-open.
The interface enables it by routing an existing accept rule through the engine: same match, same permitted traffic, now inspected. A terminal queue rule that then accepts is the accept it replaced, so no new hole is opened. A fresh interface-wide rule is offered too, and flagged as such on the panel.
Read on#
- Firewall and NAT — where the queue rule lives.
- The wiki: WireGuard, IPsec, OpenVPN and inline IPS.
Bring up a tunnel and read the change
WireGuard is native configuration here, so a peer is a diff you can review and a commit you can roll back.