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

Decide the addressing and routing contract before generating credentials. The two protected LANs and tunnel network must be distinct, each gateway needs a reachable endpoint, and every LAN router and firewall must know exactly which remote prefix is allowed across the tunnel.

• 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

The prompt is a testable lab contract, not a production shortcut. It fixes every interface, subnet, selector, credential boundary, and assertion so the four-node topology can be evaluated consistently. Replace reserved WAN addresses and confirm every interface mapping before installing the private bundle.

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. Credentials are generated after the plan is accepted, outside the language-model response, and stored in an owner-only deployment ZIP.

The registered group test is designed to boot both endpoints and both LAN computers on the authored WAN and LAN networks, apply each endpoint's private files, and run 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. A completed run and its managed-image identifiers, not this article alone, are the evidence that a specific image revision passed.

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 site-to-site test plan includes X.509 tunnel coverage, while the DANOS 2105 release notes show the release identifier format and show version output. DANOS documentation is archival, so record show version, the managed-image identifier, and the bundle manifest for the exact image you test.

UDP 500 starts IKE. When NAT traversal is negotiated, ESP is encapsulated on UDP 4500 as specified by RFC 3948; otherwise the path must pass ESP as IP protocol 50. The IKEv2 exchange itself is defined by RFC 7296. Inspect ipsec statusall, verify the expected selectors, and test application traffic in both directions.

Production rollout

Treat the generated bundle as deployment input that still needs environment-specific review. Record the exact image and manifest, replace every lab endpoint, install only the credentials assigned to each site, constrain forwarding to declared prefixes, and prove recovery and rotation before carrying production traffic.

A completed result applies only to the recorded inputs. Any change to the image, manifest, endpoint, route, forwarding policy, credential, or relevant package invalidates that result and requires the full contract to run again.

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.