Configure VyOS: Building an Enterprise Software Router with BGP, Firewall, and NAT

Real-World Problem: The Enterprise Edge Gateway Dilemma

Six months ago, our infrastructure hit a wall at our Ashburn colocation facility. We needed dual 10Gbps redundant edge gateways to connect three on-premise Kubernetes clusters (roughly 140 worker nodes) to upstream transit providers and a 5Gbps AWS Direct Connect circuit. Our legacy Juniper MX240 chassis were reaching end-of-life. Vendor renewal quotes exceeded $68,000 for support and license renewals alone, and replacement lead times stretched past 18 weeks.

Under pressure to hit launch targets, we tried a makeshift approach. We provisioned two Dell PowerEdge R640 servers running Ubuntu 22.04, installed FRRouting for BGP, scripted nftables for NAT and stateful filtering, and glued the stack together with Ansible.

Within three weeks, the setup buckled under operational reality. Routing policy changes regularly trampled existing firewall state tables. When a BGP flap triggered dropped prefixes during an afternoon peak, pinpointing the cause required cross-referencing four flat configuration files, tracking systemd-networkd quirks, and tailing separate daemon logs across multiple terminals.

Root Cause Analysis: Why Ad-Hoc Linux Routers Fail at Scale

Standard Linux distributions push packets with exceptional speed. However, they lack the cohesive architecture of a dedicated network operating system. Stitching together a production edge router on general-purpose Linux creates three persistent failure modes:

• Configuration Fragmentation: Dynamic routing (FRR/BIRD), packet filtering (nftables), IP assignment (netplan), and kernel tuning (sysctl) live in disconnected silos. No shared engine links interface MTU changes to BGP path MTU discovery or TCP MSS clamping.
• Lack of Atomic Commits and Rollbacks: A single misplaced bracket in an nftables ruleset aborts execution midway. This leaves your packet filter partially applied, which can drop traffic or sever out-of-band management sessions without any automated recovery path.
• State Synchronization Inconsistencies: Restarting dynamic routing daemons independently of connection tracking frequently invalidates conntrack states. Active TCP sessions drop, causing micro-outages during routine mid-day maintenance.

Solutions Compared: Hardware Appliances vs. General Linux vs. VyOS

When selecting the backbone for high-throughput routing and edge security, four architectures typically compete:

The Best Approach: Deploying VyOS with BGP, Zone Firewall, and NAT

VyOS combines the raw line-rate performance of the Linux kernel with a unified, carrier-grade management model reminiscent of JunOS. Every command targets a single declarative syntax tree. You get transactional commits, instant rollback checkpoints, and predictable state validation out of the box.

In our production cutover, two bare-metal 1U servers running VyOS 1.4 handled sustained 9.2Gbps throughput at sub-millisecond latencies, dropping our hardware footprint to a fraction of the original appliance costs. Here is the exact blueprint to deploy an edge gateway with dual interfaces—WAN (eth0) and LAN (eth1)—complete with zone-based security policies, outbound source NAT, and eBGP route advertisements.

1. Initial Setup and Interface Assignment

Open a console or SSH session to your VyOS node. Enter configuration mode and assign static IP addresses and descriptive tags to your WAN and LAN ports:

configure

# Configure WAN interface connected to upstream ISP transit
set interfaces ethernet eth0 address '198.51.100.2/30'
set interfaces ethernet eth0 description 'WAN-Uplink-ISP1'

# Configure LAN gateway interface for internal workloads
set interfaces ethernet eth1 address '10.100.0.1/24'
set interfaces ethernet eth1 description 'LAN-Production-Core'

# Set hostname and upstream recursive DNS resolvers
set system host-name 'gw-core-01'
set system name-server '1.1.1.1'
set system name-server '8.8.8.8'

commit
save

2. Building a Zone-Based Stateful Firewall

VyOS relies on zone-based security. Instead of binding firewall rules to physical interfaces, you organize interfaces into security zones and apply directional policies between them. This approach prevents rule bloat as your topology grows.

Construct explicit policies for WAN-to-LAN, LAN-to-WAN, and control-plane traffic targeting the router itself (LOCAL):

# Define WAN-to-LAN: block inbound traffic while preserving session replies
set firewall ipv4 name WAN_TO_LAN default-action 'drop'
set firewall ipv4 name WAN_TO_LAN rule 10 action 'accept'
set firewall ipv4 name WAN_TO_LAN rule 10 description 'Allow established/related traffic'
set firewall ipv4 name WAN_TO_LAN rule 10 state 'established'
set firewall ipv4 name WAN_TO_LAN rule 10 state 'related'
set firewall ipv4 name WAN_TO_LAN rule 20 action 'drop'
set firewall ipv4 name WAN_TO_LAN rule 20 description 'Drop malformed and invalid packets'
set firewall ipv4 name WAN_TO_LAN rule 20 state 'invalid'

# Define LAN-to-WAN: permit internal hosts outbound Internet access
set firewall ipv4 name LAN_TO_WAN default-action 'accept'

# Define WAN-to-LOCAL: shield the router management and routing engine
set firewall ipv4 name WAN_TO_LOCAL default-action 'drop'
set firewall ipv4 name WAN_TO_LOCAL rule 10 action 'accept'
set firewall ipv4 name WAN_TO_LOCAL rule 10 description 'Allow established/related control plane'
set firewall ipv4 name WAN_TO_LOCAL rule 10 state 'established'
set firewall ipv4 name WAN_TO_LOCAL rule 10 state 'related'
set firewall ipv4 name WAN_TO_LOCAL rule 20 action 'accept'
set firewall ipv4 name WAN_TO_LOCAL rule 20 description 'Allow inbound BGP from upstream peer'
set firewall ipv4 name WAN_TO_LOCAL rule 20 protocol 'tcp'
set firewall ipv4 name WAN_TO_LOCAL rule 20 destination port '179'
set firewall ipv4 name WAN_TO_LOCAL rule 20 source address '198.51.100.1'

# Assign interfaces to security zones
set firewall zone WAN interface 'eth0'
set firewall zone LAN interface 'eth1'
set firewall zone LOCAL local-zone

# Attach directional filtering policies to zone pairs
set firewall zone LAN from WAN firewall name 'WAN_TO_LAN'
set firewall zone WAN from LAN firewall name 'LAN_TO_WAN'
set firewall zone LOCAL from WAN firewall name 'WAN_TO_LOCAL'

commit
save

3. Configuring Outbound Source NAT (Masquerade)

Workloads in the private 10.100.0.0/24 subnet need address translation to access upstream networks through the WAN link:

# Translate private subnet traffic exiting through WAN eth0
set nat source rule 100 description 'Outbound internet masquerade'
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 source address '10.100.0.0/24'
set nat source rule 100 translation address 'masquerade'

commit
save

4. Configuring Enterprise eBGP Peering

Dynamic routing keeps traffic flowing if an upstream circuit degrades. In this layout, your local autonomous system (AS 65001) peers with an upstream ISP (AS 64512 at 198.51.100.1) and announces your assigned public block (203.0.113.0/24).

Prefix filters protect upstream routing tables by ensuring you only advertise addresses you explicitly own:

# Set local BGP autonomous system number and router ID
set protocols bgp system-as '65001'
set protocols bgp parameters router-id '198.51.100.2'

# Configure upstream transit peer
set protocols bgp neighbor 198.51.100.1 address-family ipv4-unicast
set protocols bgp neighbor 198.51.100.1 remote-as '64512'
set protocols bgp neighbor 198.51.100.1 description 'Transit-ISP1-Uplink'
set protocols bgp neighbor 198.51.100.1 update-source 'eth0'

# Restrict outbound route announcements to approved company subnets
set policy prefix-list PL-EXPORT-PREFIXES rule 10 action 'permit'
set policy prefix-list PL-EXPORT-PREFIXES rule 10 prefix '203.0.113.0/24'

# Apply the prefix list filter to an outbound route map
set policy route-map RM-BGP-OUT rule 10 action 'permit'
set policy route-map RM-BGP-OUT rule 10 match ip address prefix-list 'PL-EXPORT-PREFIXES'

# Bind the route map to outbound announcements for the ISP neighbor
set protocols bgp neighbor 198.51.100.1 address-family ipv4-unicast route-map export 'RM-BGP-OUT'

# Generate static anchor route and originate prefix into BGP
set protocols static route 203.0.113.0/24 blackhole
set protocols bgp address-family ipv4-unicast network '203.0.113.0/24'

commit
save

5. Verification and Operational Runbook

Type exit to leave configuration mode. Run these operational commands to verify your neighbor adjacencies, active NAT sessions, and packet drop counters:

# Confirm BGP state shows Established along with accepted prefix count
show bgp summary

# Review routes advertised to your upstream provider
show ip bgp neighbors 198.51.100.1 advertised-routes

# Inspect active conntrack address translations under load
show nat source translations

# Monitor live packet counters for the WAN-to-LAN firewall
show firewall name WAN_TO_LAN statistics

Misconfigurations happen. When an unvetted rule locks out traffic during maintenance, revert immediately to the previous working state without rebooting the appliance:

# Review recorded commit history and timestamps
show system commit-history

# Revert instantly to the prior operational configuration
configure
rollback 1
commit
exit

VyOS provides the control of Linux without its fragmentation. By combining transactional configuration, native FRR routing, and zone-based filtering on off-the-shelf x86 hardware, you retain full ownership of your network perimeter—without five-figure support renewals.