Build a Vyatta IKEv2 Site-to-Site VPN

A site-to-site VPN joins two private subnets through dedicated gateways. Hosts on either side use ordinary LAN addresses; routing policy selects the traffic that crosses the encrypted tunnel.

Design decisions to make first

• The protected subnets must not overlap each other or the tunnel CIDR.
• Each gateway needs a stable reachable IPv4 address or DNS name.
• WAN interfaces must precede LAN interfaces so the generated mapping stays deterministic.
• Routers on each LAN need a route to the remote subnet through the VPN gateway.
• Firewalls must permit UDP 500 and 4500, plus ESP where NAT traversal is not in use and the selected forwarding paths.

Deployable OpenFactory prompt

This prompt is intentionally a lab contract. It fixes every interface, subnet, selector, and assertion so OpenFactory can build and test the complete topology. Replace the WAN lab addresses before applying the resulting bundle in production.

Build and validate a stock Vyatta/DANOS IKEv2 site-to-site VPN named `branch-vyatta` as a BUILD_PLAN. Do not build Linux ISOs for the routers.

Create two nodes named `site-a-router` and `site-b-router` with `device_kind=router.vyatta` and `appliance_config={"image":"stock-vyatta","install_to_disk":true}`. Site A has `172.31.221.10/24` on the shared `wan` network and `10.80.0.1/24` on `site-a-lan`. Site B has `172.31.221.20/24` on `wan` and `10.90.0.1/24` on `site-b-lan`. The WAN gateway is `172.31.221.1`, WAN is the only default-route network, and WAN must be the first interface on both routers. Do not create recipes for the router nodes.

Create two additional `device_kind=linux-build` Debian Trixie computers with the `headless` and `ssh` features plus iproute2, iputils-ping, and curl. `site-a-computer` has one static interface, `10.80.0.10/24`, on `site-a-lan`; give it an `os.startup_scripts` oneshot named `remote-lan-route`, after `network-online.target`, that runs `ip route replace 10.90.0.0/24 via 10.80.0.1`. `site-b-computer` has one static interface, `10.90.0.10/24`, on `site-b-lan`; give it the same oneshot name, running `ip route replace 10.80.0.0/24 via 10.90.0.1`. `plan.recipes` must contain exactly these two computer recipes. Both computers must be topology nodes connected to their respective protected LANs.

Set `plan.vpn` to protocol `ikev2`, implementation `vyatta`, mode `site-to-site`, authentication `x509`, tunnel CIDR `10.252.21.0/24`, listen port `500`, and no clients. Site A's public endpoint is `172.31.221.10`, protected subnet is `10.80.0.0/24`, and connection type is `initiate`. Site B's public endpoint is `172.31.221.20`, protected subnet is `10.90.0.0/24`, and connection type is `respond`.

Use the stock DANOS `security vpn ipsec` configuration tree, IKEv2, X.509 authentication, AES-256-GCM, and explicit local and remote traffic selectors. Add group assertions on both routers that `/config/config.boot` contains `site-to-site` and that `ipsec statusall` executes. Add `command_output` assertions expecting `ready` that run `ip route get 10.90.0.10 | grep -q 'via 10.80.0.1' && ping -c 3 -W 5 10.90.0.10 >/dev/null && echo ready` on `site-a-computer`, and `ip route get 10.80.0.10 | grep -q 'via 10.90.0.1' && ping -c 3 -W 5 10.80.0.10 >/dev/null && echo ready` on `site-b-computer`. OpenFactory must boot the managed stock images and both protected-LAN computers, apply both endpoint configurations, prove traffic crosses between the LAN computers, and put the CA and private endpoint material in the owner-only deployment bundle.

What OpenFactory builds

The topology uses two backend-managed stock Vyatta/DANOS router images plus one Debian computer on each protected LAN. The bundle contains a private CA, one certificate and key per router, exact DANOS CLI commands, and an apply script for each site. Private credentials are generated after the plan is accepted, outside the language-model response, and stored in an owner-only deployment ZIP.

The group test boots both endpoints and both LAN computers on the authored WAN and LAN networks, applies each endpoint's private files, and then runs topology assertions. The assertions confirm the configuration is persisted under the stock security vpn ipsec tree, the IPsec tooling executes on both routers, and the LAN computers can communicate across the tunnel.

How the DANOS configuration is assembled

The generated command set creates one IKE group, one ESP group, and one security vpn ipsec site-to-site peer entry per router. The peer entry binds the local address, X.509 files, dead-peer detection, and tunnel 1's local and remote prefixes. commit validates the candidate tree; save writes it to /config/config.boot.

X.509 identity failures and selector mismatches look similar from the application side, so inspect them separately. First confirm both certificates chain to the generated CA and the peer identities match. Then inspect the IKE SA, the child SA, and the installed policies before testing LAN traffic. The DANOS VPN schema reference lists the stock security vpn ipsec tree used by the prompt.

UDP 500 starts IKE. NAT traversal moves encapsulated ESP to UDP 4500 when a NAT is detected; otherwise the path must also pass IP protocol 50. Test both the security associations and traffic in both directions.

Production rollout

1. Download the private bundle and verify its manifest before moving files.
2. Replace lab WAN addresses with the real endpoints and confirm interface names.
3. Install only Site A files on Site A and only Site B files on Site B.
4. Add LAN routes for the remote protected subnet, or make the VPN gateway the relevant LAN router.
5. Open the required UDP ports and allow forwarding only between the declared selectors.
6. Test routing in both directions, MTU-sensitive traffic, tunnel recovery, and key or certificate rotation.

Compare this implementation with the Linux WireGuard site-to-site guide, or use the road-warrior guide for individual roaming clients.