Prerequisites

• A working Proxmox installation (see Getting Started with Proxmox VE)
• A VyOS ISO — the free download at vyos.net/get provides the rolling release. The LTS release requires building from source — see the VyOS build instructions if you need a stable long-term release. For a homelab the rolling release is typically fine.
• Two network bridges configured on your Proxmox host — one connected to the home network, one for the lab network

Why VyOS as a VM

Running VyOS inside Proxmox rather than on dedicated hardware keeps the router within the same management plane as everything else. You can snapshot it before making configuration changes, back it up on a schedule alongside your other VMs, and migrate it to another node if you need to take the host down for maintenance.

The trade-off is that the router shares physical resources with the host. In practice this is not a problem — VyOS is extremely lightweight and a router VM needs very little CPU or RAM.

Creating the VM in Proxmox

Create a new VM in the Proxmox UI with the following settings. For a full walkthrough of the creation wizard and CPU type trade-offs, see Creating a VM in Proxmox.

The most important part is the network configuration.

Adding Two Network Interfaces

VyOS needs one interface for each network it connects:

Attach both bridges to the VM before starting it. In Proxmox, this is done under the VM’s Hardware tab — add two Network Devices and select the appropriate bridge for each.

Proxmox bridges are configured under System → Network on each node. If you have not yet created separate bridges for your two networks, do that first.

Installing VyOS

Boot the VM from the ISO. VyOS starts a live session — it is not installed to disk automatically.

Log in with vyos / vyos, then run the installer:

1

install image

Follow the prompts to write VyOS to the virtual disk. Accept the defaults unless you have a reason to change them. Once complete, reboot and remove the ISO from the VM.

Official reference: VyOS Installation Guide

VyOS Configuration Basics

VyOS uses a commit/save model — changes are staged and only take effect when you run commit. They are only persisted across reboots when you run save.

1
2
3
4
5

configure          # enter configuration mode
set ...            # make changes
commit             # apply changes (takes effect immediately)
save               # write to disk (survives reboot)
exit               # leave configuration mode

This model makes it safe to experiment — if you commit a change that breaks something, you can reboot without saving and the previous configuration is restored.

Basic Interface Configuration

After booting into the installed system, enter configuration mode and set up the two interfaces.

Assign an IP on the lab-facing interface:

1
2
3
4

configure

set interfaces ethernet eth1 address '10.x.x.1/24'
set interfaces ethernet eth1 description 'Lab network'

Configure the uplink to the home network — either a static IP or DHCP depending on your RouterOS setup:

1
2
3
4
5
6

# Static
set interfaces ethernet eth0 address '192.168.x.x/24'
set interfaces ethernet eth0 description 'Home network uplink'

# Or DHCP
set interfaces ethernet eth0 address 'dhcp'

Set a default route via the home router:

1

set protocols static route 0.0.0.0/0 next-hop '192.168.x.x'

Commit and save:

1
2

commit
save

Full interface configuration reference: VyOS Ethernet Interfaces

Routing Instead of NAT

A common approach at this point is to configure NAT (masquerade) on VyOS so that lab devices appear to come from the VyOS uplink IP when talking to the home network. I chose not to do this.

Instead, I added a static route on the MikroTik router pointing the lab subnet to the VyOS uplink IP as the next hop. This means the home network knows how to reach lab devices directly, and no address translation takes place anywhere in the path.

1
2
3

# On MikroTik RouterOS (IP → Routes → Add)
Dst. Address: 10.x.x.0/24
Gateway:      192.168.x.x   ← VyOS eth0 IP on the home network

The benefits of this over NAT are significant:

Real IPs are preserved end-to-end. With NAT, every connection from the lab appears to come from the VyOS uplink address. Without NAT, the actual source IP is visible throughout — in firewall logs, application logs, and packet captures. This makes debugging dramatically easier.

Bidirectional reachability without extra config. Home network devices can reach lab services directly by IP, without needing a VPN, a reverse proxy, or any additional forwarding rules on VyOS. The route on MikroTik handles the return path cleanly.

No connection tracking overhead. NAT requires the router to maintain a state table for every active connection so it knows how to rewrite return packets. Pure routing carries no such overhead — packets are forwarded based on the routing table alone.

Firewall rules are simpler and more meaningful. Rules written against real IPs are easier to reason about. You are not working around address translation when deciding what to permit or deny.

Foundation for BGP. When Kubernetes services are later exposed via BGP, the load balancer IPs advertised to VyOS are routed — not NATted — back to the home network. Having established a routed topology from the start means that layer fits in naturally.

What’s Next

The VyOS setup described here is intentionally minimal — a single router providing a clean routed boundary between the home and lab networks. Future tutorials will build on this foundation:

• DHCP and DNS forwarding — assigning IP addresses and resolving names for lab hosts
• VRRP redundancy — adding a second VyOS instance for failover
• BGP peering with Kubernetes — dynamically routing Kubernetes service IPs through VyOS