Why VyOS

VyOS is an open source, Debian-based network operating system that provides enterprise routing, firewalling, and VPN features on commodity hardware. It gives you flexibility that traditional hardware appliances often restrict, and it allows your router to be treated like any other version-controlled, reproducible component in your infrastructure.

What We Are Building

A complete routing system that includes:

• A VyOS instance at home, even if it sits behind NAT or CGNAT.
• A VyOS instance on a VPS with a real public IP.
• A tunnel between them using WireGuard.
• Multiple internal subnets behind the home router.
• Routing from the VPS to all internal subnets.
• The option to expand into dynamic routing later.

The result is a stable, predictable path between your cloud environment and your home lab, without depending on unreliable port forwarding or exposing unnecessary surfaces.

Addressing and Design

A practical design looks like this:

• Home internal networks under 10.42.0.0/16
• Individual subnets like 10.42.0.0/24 and 10.42.1.0/24
• A point to point WireGuard tunnel such as 172.24.32.0/31
• A public IP on the VPS plus whatever gateway the provider assigns
• Default route on the home router via local WAN
• Default route on the VPS via datacenter gateway

The topology is intentionally simple. The tunnel becomes the backbone, and the VPS acts as the externally reachable control point.

Home Router Configuration (VyOS Behind NAT)

set interfaces ethernet eth0 address '10.21.21.10/24'
set interfaces ethernet eth0 description 'WAN'

set interfaces ethernet eth1 address '10.42.0.1/24'
set interfaces ethernet eth1 description 'LAB1'

set interfaces ethernet eth2 address '10.42.1.1/24'
set interfaces ethernet eth2 description 'LAB2'

set nat source rule 10 description 'Outgoing NAT'
set nat source rule 10 outbound-interface 'eth0'
set nat source rule 10 source address '10.42.0.0/16'
set nat source rule 10 translation address 'masquerade'

set interfaces wireguard wg0 address '172.24.32.1/31'
set interfaces wireguard wg0 description 'home-to-vps'
set interfaces wireguard wg0 peer VPS allowed-ips '172.24.32.0/31,10.42.0.0/16'
set interfaces wireguard wg0 peer VPS persistent-keepalive '15'
set interfaces wireguard wg0 peer VPS port '8765'
set interfaces wireguard wg0 peer VPS pubkey '<VPS_PUBLIC_KEY>'
set interfaces wireguard wg0 private-key '<HOME_PRIVATE_KEY>'

set protocols static route 0.0.0.0/0 next-hop '10.21.21.1'

set system host-name 'vyos-home-edge'
set service ssh port '22'

commit
save

VPS Router Configuration (VyOS with Public IP)

set interfaces ethernet eth0 address '<VPS_PUBLIC_IP>/23'

set interfaces wireguard wg0 address '172.24.32.0/31'
set interfaces wireguard wg0 description 'vps-to-home'
set interfaces wireguard wg0 peer Home allowed-ips '172.24.32.0/31,10.42.0.0/16'
set interfaces wireguard wg0 peer Home pubkey '<HOME_PUBLIC_KEY>'
set interfaces wireguard wg0 port '8765'

set protocols static route 0.0.0.0/0 next-hop '<VPS_PROVIDER_GATEWAY>'

set system host-name 'vyos-vps'
set service ssh port '22'

commit
save

Once both ends are configured and WireGuard handshakes successfully, you have a functioning private backbone between your home lab and the cloud.

Generating WireGuard Keys Using the Built In PKI Commands

You can create keypairs directly using the generate pki wireguard key-pair command. This method returns both the private and public keys in a single step and avoids unnecessary manual piping or intermediate files when using something like wg genkey

The command can be run from operational mode.

generate pki wireguard key-pair

A typical output looks like this:

Private key: 0NLc86fck3qtkBA133fh6K8sGckgQzHR2rBypr+LgHk=
Public key:  H6iVTlr44l6Z+DaGKD3aYr7QZXjG1rpdUYhbm2NjnQQ=

You paste the private key directly into the interface configuration.

set interfaces wireguard wg0 private-key '0NLc86fck3qtkBA133fh6K8sGckgQzHR2rBypr+LgHk='

The public key is shared with the peer router, and it is safe to transmit because it does not reveal any sensitive information.

DHCP Server Configuration for Internal Subnets

Compared to older VyOS Versions, 1.5, includes a significantly updated DHCP service model, moving away from the older ISC DHCP implementation toward a Kea based backend. The configuration structure is cleaner and allows per subnet options without excessive repetition. If your home router is serving multiple internal networks, each VLAN or physical interface can run its own DHCP pool with independent lease ranges, DNS settings, and gateway assignments.

The example below creates DHCP pools for two internal networks, 10.42.0.0/24 and 10.42.1.0/24, matching the earlier topology. Each pool defines the default gateway, DNS servers, and a dynamic address range. VyOS automatically binds a DHCP pool to the interface that contains the matching network.

# Enable the DHCP service
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 default-router '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 dns-server '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 lease '86400'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 range 1 start '10.42.0.100'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 range 1 stop '10.42.0.200'

set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 default-router '10.42.1.1'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 dns-server '10.42.1.1'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 lease '86400'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 range 1 start '10.42.1.100'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 range 1 stop '10.42.1.200'

commit
save

If you need to provide additional DHCP options such as NTP servers, PXE boot parameters, or domain search lists, VyOS 1.5 allows them at the subnet level. For example:

set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 ntp-server '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 domain-name 'lab.internal'

Static reservations can also be configured so that specific MAC addresses receive deterministic IP assignments. This is useful for servers, hypervisors, or embedded devices that require consistent addressing.

set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 static-mapping web01 ip-address '10.42.0.10'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 static-mapping web01 mac-address 'aa:bb:cc:dd:ee:ff'

VyOS automatically reconfigures Kea when you commit changes, and leases are tracked in the usual state files under /run/kea. For larger networks you can integrate Kea with a database backend, but for most home or lab environments the built in configuration is sufficient and reliable.

Dynamic Routing Between Home and VPS

Static routes work well for small or fixed networks, but they become a maintenance burden as your environment grows. If you expect to introduce additional subnets, more tunnel endpoints, or multi site connectivity, dynamic routing lets routers share reachability information automatically. VyOS 1.5 supports multiple dynamic routing protocols using FRR as the backend. In this topology the two most relevant choices are BGP and OSPF.

Dynamic routing does not replace your WireGuard tunnel or the point to point addressing. It simply automates what you previously defined manually. The tunnel still carries traffic, but prefixes are now learned rather than configured statically.

Using BGP for Prefix Exchange

BGP is well suited to situations where you control multiple routing domains or when networks are spread across geographically distinct sites. A home router advertising lab subnets to a VPS router fits this model cleanly. BGP is also protocol agnostic regarding the underlying transport, so running it over WireGuard is straightforward.

The example below uses private autonomous system numbers. Each router uses a loopback as the BGP router identifier. The home router originates the internal subnets under 10.42.0.0/16, and the VPS learns these automatically.

Home Router Configuration

set interfaces loopback lo address '10.255.255.1/32'

set protocols bgp 65010 neighbor 172.24.32.0 remote-as '65020'
set protocols bgp 65010 neighbor 172.24.32.0 update-source 'wg0'

set protocols bgp 65010 network '10.42.0.0/24'
set protocols bgp 65010 network '10.42.1.0/24'

set protocols bgp 65010 parameters router-id '10.255.255.1'

commit
save

VPS Router Configuration

set interfaces loopback lo address '10.255.255.2/32'

set protocols bgp 65020 neighbor 172.24.32.1 remote-as '65010'
set protocols bgp 65020 neighbor 172.24.32.1 update-source 'wg0'

set protocols bgp 65020 parameters router-id '10.255.255.2'

commit
save

After committing, each router installs learned prefixes into its routing table. Any new subnet added on the home side can be announced simply by adding another network statement in BGP without touching the VPS configuration.

Route Filtering and Future Expansion

Even in private routing domains it is good practice to control which prefixes are exchanged. VyOS supports route maps, prefix lists, and communities for filtering or tagging routes. For a two site topology filtering is optional, but once additional routers or intermediate hops are added, these tools provide stability and control.

For example, prefix lists can be used to prevent accidental advertisements of internal ranges you do not want exposed across the tunnel.

Using OSPF for Simpler Multi Subnet Environments

If both routers participate in a single shared routing domain and you want automatic neighbor discovery, OSPF is a simpler alternative. OSPF requires interfaces to be reachable at layer 3, which is satisfied by the WireGuard link network. OSPF is well suited to lab environments where simplicity outweighs strict routing policy.

Home Router OSPF Configuration

set protocols ospf parameters router-id '10.255.255.1'

set protocols ospf area 0 network '172.24.32.0/31'
set protocols ospf area 0 network '10.42.0.0/24'
set protocols ospf area 0 network '10.42.1.0/24'

commit
save

VPS Router OSPF Configuration

set protocols ospf parameters router-id '10.255.255.2'

set protocols ospf area 0 network '172.24.32.0/31'

commit
save

OSPF will discover neighbors across the WireGuard link and exchange LSAs describing each internal subnet. Any new network added to the home router is integrated simply by adding it to the OSPF area configuration.

Choosing Between BGP and OSPF

Both protocols achieve dynamic routing, but they solve slightly different operational needs.

• BGP gives precise control over what you advertise and accept, which becomes important once the network grows beyond two sites.
• OSPF provides straightforward link state routing inside a shared domain and often requires less initial configuration.
• BGP is preferable when your VPS acts as a central aggregation point for multiple remote sites.
• OSPF is ideal when you want automatic discovery with minimal policy overhead.

These options remain compatible with the underlying WireGuard topology, and both approaches eliminate the need for per subnet static routes on the VPS. If you want, I can add examples for route maps, prefix lists, or running both protocols concurrently in segmented VRFs.

Static Routing, the Simple Approach

If you prefer predictability and do not expect many internal subnet changes, static routes are the simplest method.

set protocols static route 10.42.0.0/24 next-hop 172.24.32.1
set protocols static route 10.42.1.0/24 next-hop 172.24.32.1
commit
save

This ensures the VPS knows where to send traffic for each internal network.

Dynamic Routing for Larger Topologies

If you intend to add multiple routers or scale the architecture, dynamic routing such as BGP becomes useful. VyOS can advertise subnets from your home router up to the VPS, removing the need for manual route additions. This is not required for the simple setup, but it becomes valuable as your topology grows.

Why This Architecture Works Well

This model offers several benefits:

• It bypasses CGNAT and unreliable port forwarding by using a stable tunnel.
• All outbound traffic can optionally leave through the VPS, centralizing filtering or monitoring.
• It cleanly supports multiple isolated home subnets.
• VyOS gives you full control without locking you into proprietary hardware.
• You can grow into dynamic routing, VRRP, additional VPN endpoints, or multi site connectivity without redesigning the foundation.

Caveats to Keep in Mind

• Static routes must be updated manually when new subnets appear.
• WireGuard in this pattern works best when connections originate from the home side because the VPS has a fixed public endpoint.
• Security is intentionally minimal in this guide. In production you should add firewall policies, restrict management access, and audit services.
• Private networks never traverse the public Internet, so the tunnel must always be up for routing to work.

Possible Next Steps

You can extend this tutorial into a more complete infrastructure spine. Some natural expansions include:

• Introducing BGP for subnet auto advertisement.
• Adding firewall groups, policy based routing, and segmentation.
• Supporting “road warrior” WireGuard clients.
• Using cloud init to deploy VyOS images programmatically.
• Adding redundancy with VRRP.

Conclusion

By combining VyOS on a home router with VyOS on a public VPS and linking them with a tunnel, you gain a flexible backbone that works regardless of NAT, ISP restrictions, or lab complexity. This pattern scales, is easy to automate, and gives you full control over how your internal and external networks communicate.