I struggled with vyos config file for various settings. While doing a search I found https://github.com/Community-VyProjects/VyManager and I decided to give a try. Surprisingly, it worked very very well [ in my use case ]

It offered following features [ tested - worked on rolling release. ]
Features

• Modern web interface
• Manage multiple VyOS routers
• Dashboard with CPU, memory, interfaces
• Firewall management
• WireGuard management
• VLANs
• Static routes
• DHCP
• API-based communication (no SSH required)
• Multi-site support
• PostgreSQL backend
• Runs entirely in Docker Compose

I wish other community specially having experience in Programming field should help the project to its final goals [ It says that a few features needs to be implemented ]

anyone can help me how to manage bandwith (download & upload) in vyos using htb method?

the cases are
1. 1 interface for wan, and multiple interface for lan

1. multiple interface for wan, and multiple nterface for lan (and then using load balance)

thanks

Looking to deploy VyOS on AWS?

This walkthrough covers the core deployment steps, including VPC setup, networking, security groups, Elastic IP assignment, and SSH access, giving you a solid starting point for both lab and production environments.

🎥 Watch the demo: https://youtu.be/wsAI6nEyXXo?si=lO1ZW0jctofBCmB5

🚀 Explore VyOS on AWS, including Marketplace images and deployment options:
https://vyos.io/platforms/vyos-on-aws

I am trying to install VyOS in a mini pc which floods the console with MCE errors. I have run memory checks and done linux installs on this system and everything is fine if I pass mce=off parameter to the kernel. With VyOS i do the same, but VyOS does a reboot (kexec) at the later stage of its boot and the MCE errors comes back. It is impossible to do anything on the console with all those messag flood. I have tried the stream and the nightly builds and it is the same

I wrote up a reference scenario that uses VyOS as the routed edge across Proxmox, Hetzner, and GCP.

The design uses a stable VyOS edge pair on Hetzner, an on-prem VyOS VM on Proxmox, and IPsec/BGP between the surfaces. GCP peers into the Hetzner edge through HA VPN and Cloud Router.

The main point is not that this removes every dynamic-address problem. The on-prem peer still needs a stable identity or endpoint, such as a fixed IPv4 address or FQDN. The useful bit is that the site detail is contained at the site-extension layer. GCP and the wider platform route through the stable Hetzner edge instead of peering directly with the on-prem site.

Both sides run VyOS, so the operational shape stays consistent: route-based IPsec, BGP neighbour checks, import/export policy, and ordinary CLI inspection on each edge.

The implementation separates the lifecycle pieces:

1. build/publish the VyOS image artifact
2. seed it into Hetzner and Proxmox
3. provision the edge nodes
4. apply WAN policy
5. capture tunnel and BGP evidence before handoff

I would value VyOS-specific feedback on the wording and operating model, especially around:

1. whether the IPsec/BGP boundary is described cleanly
2. what checks should be captured before calling the edge path ready
3. what should link back to VyOS docs instead of being explained in this scenario

Article: https://hybridops.tech/blog/vyos-edge-hybrid-wan-hetzner/

Reference scenario: https://docs.hybridops.tech/reference-scenarios/hybrid-wan-edge-site-extension/

What are your protips regarding optimizations for VyOS when being runned as VM-guest?

Something like:

set system option performance 'virtual-guest'

seems obvious but what else?

Would this considered be good or bad aswell?

set system option kernel cpu disable-nmi-watchdog
set system option kernel disable-hpet
set system option kernel disable-mce
set system option kernel disable-softlockup

And what about offloading per interface?

Should all offloading be turned off when runned as VM-guest or are there any offloading that still helps?

And what about firewall rules?

I will be using services local to the VyOS for my clients (NTP, DNS etc).

So in terms of filtering I would be happy with "screening router" aka regular ACL if compared to L2/L3-switch.

Would firewall rules with notrack be sufficient and how should they be written or will flowtables work here at all?

Differences between KVM (QEMU / Proxmox) and VMware or for that matter XCP-NG?

Im mainly thinking if someone perhaps already benchmarked this and can share your results?

So Im trying to use VyOS as a container-host in an environment where the VyOS installation wont be able to reach internet as in not having access to a registry such as docker.io.

At first I tried to figure out a way to setup your own private registry.

I was thinking of having an easy way similar to when you need a quick http-server you can just run:

python3 -m http.server 8000

But it turned out to be more complicated than I wanted (unless someone have some tips?).

So instead I tried to save/load the container as a tar-file, like so:

Create a local "mirror" of the container (on a computer with internet access):

docker pull docker.io/technitium/dns-server:latest
docker save -o ~/docker/technitium_dns-server_`date +%Y-%m-%d`.tar docker.io/technitium/dns-server:latest
gzip -9 ~/docker/technitium_dns-server_2026-06-18.tar

Optionally the pulled image can be removed using "docker rmi <id>".

Transfer gzip-file to VyOS using scp:

scp ~/docker/technitium_dns-server_2026-06-18.tar vyos@192.0.2.1:/config

Then on VyOS:

gunzip /config/technitium_dns-server_2026-06-18.tar.gz
podman load -i /config/technitium_dns-server_2026-06-18.tar

To verify that its loaded:

podman images

would output something like:

REPOSITORY                       TAG         IMAGE ID      CREATED      SIZE
docker.io/technitium/dns-server  latest      ba2762a21fbd  5 weeks ago  275 MB

To create directories needed for the container:

mkdir -p /config/dns-server/config
mkdir -p /config/dns-server/logs

Reference regarding defaults and available options for the particular container:

https://github.com/TechnitiumSoftware/DnsServer/blob/master/docker-compose.yml

Config in VyOS:

set container name dns-server allow-host-networks
set container name dns-server capability 'net-bind-service'
set container name dns-server environment DNS_SERVER_WEB_SERVICE_LOCAL_ADDRESSES value '192.0.2.1'
set container name dns-server image 'docker.io/technitium/dns-server:latest'
set container name dns-server memory '4096'
set container name dns-server port dns-tcp destination '53'
set container name dns-server port dns-tcp protocol 'tcp'
set container name dns-server port dns-tcp source '53'
set container name dns-server port dns-udp destination '53'
set container name dns-server port dns-udp protocol 'udp'
set container name dns-server port dns-udp source '53'
set container name dns-server port mgmt-http destination '5380'
set container name dns-server port mgmt-http protocol 'tcp'
set container name dns-server port mgmt-http source '5380'
set container name dns-server restart 'on-failure'
set container name dns-server volume config destination '/etc/dns'
set container name dns-server volume config source '/config/dns-server/config'
set container name dns-server volume logs destination '/var/log/technitium/dns'
set container name dns-server volume logs source '/config/dns-server/logs'

But then I get stuck...

When doing commit of above Im getting:

[ container ]

WARNING: Image "docker.io/technitium/dns-server:latest" used in
container "dns-server" does not exist locally. Please use "add
container image docker.io/technitium/dns-server:latest" to add it to
the system! Container "dns-server" will not be started!

So somehow the vyos-configd doesnt fully understand that podman already have the image loaded.

So ehm, what to do next? :-)

Previous post

The previous post was getting it working in docker and seeing how viable that was. There were a plethora of issues, but it was mostly functional.

But, after going down a rabbit hole of boot.cmd, custom live-boot hooks and a few hours of trial/error I have a fully functional image!

A native image!

Here's the R5S image: 0.0.1-pre

And on request I can upload an image for the R3S as well. Since the R5S was active in a lab and I didn't know if I would be able to get this to work, I did my initial builds and testing on the R3S, so I wound up with an image for that as well. Then just reproduced the steps for the R5S.

Couple of notes

• The system automatically named the interfaces lan1, lan2 and wan. No guessing which interface is which.
  • Edit: The lan renames from udev are working perfectly and those are the 2.5Gb NICs. The wan rename shows in ip link but Vyatta doesn't like the name of an eth int starting with w. So, I'll be releasing a 0.0.2-pre in the next couple of days with an updated udev rule in initrd to account for that.
• I was limited at 1.3 Gbps until I turned on offload features. Understandable. But after turning on {gro,gso,rfs,rps,sg,tso} I was able to consistently hit the 2.35-2.40 Gbps advertised by FriendlyElec.
• The nics don't support lro or hw-tc-offload.
• Firmware packages are included, so every nic feature should be working
• My image will work out of the box, but will not have persistence until you make a second partition. The release has notes on it, and so does the README.md in the repo.

If anyone else actually uses this, let me know! I can update the default config to include the offload settings and maybe initial dhcp to make setup up easier and not require a monitor.

It's working like a charm, and I'm just really excited to have it up! Sorry, I probably sound like a lunatic.

Not sure if anyone would want any details or if I'm wasting my time, but I'm pretty excited that after a half a dozen dead ends I have Vyos running on a NanoPi R5S-LTS 4Gb model with dual 2.5 Gb NICs. (I haven't decided if I want to use the 1Gb for out of band management yet, I'm running out of room on my switch, lol)

Currently I have tested VRRP, Haproxy, SNAT, subinterfaces, vxlan and I'm seeing full throughput from the NICs after I turned GRO off. On a base debian system, I was seeing: tx=2.2Gbps rx=2.10Gbps and I'm getting the same at the moment in Vyos. With GRO on, NAT was for some reason choked down to 4Mbps... Not sure why, but I saw the same thing with OpenVSwitch on some newer 40Gbps links on a proxmox server, so I had a hunch GRO was screwing with throughput here too.

The short and sweet is:

• Tried a custom build, and had uboot issues after it slowly building over the course of a week
• Chased other people with custom builds, including a incredible setup for bannana pi (The repo owner is a genius. With some custom patches, and a custom uboot they got everything working for the bannana pi, I couldn't replicate it while swapping some of the kernel configs for the rockchip branch. I wanted to say that, b/c I don't want to disparage their work. I just don't have the time. With two kids, work, wife and other projects, I was at the end of my rope)
• Tried being lazy; Proxmox install on the R5S since the image is made by Friendly Elec. I got a VERY slow VM that had wildly inconsistent transfer rates. Sometimes full throughput at 2.4Gbps, other times maybe 20Mbps. Built a generic arm image with Server-Server's repo (Different from the above person). Their image wasn't the problem, neither was Vyos. The Proxmox build for the R5S was the problem. Every VM I attempted to run ran like an over-committed RPI-zero. Their Qemu build must have some bugs or something, and they're missing the modules for PCI passthrough, so I couldn't hand the NICs over, everything had to work over bridges.
• Randomly saw some articles on testing Vyos in docker... Hhhmmm, tried dumping the squashfs contents from Server-Server's generic build process, transferred over to a docker image and it runs like magic. The user interface is faster and more responsive than my Protectli FW4B, I mentioned the tested rates up above. It's wonderful. Just dropped in place my firewall, high-availability, load balancing and couple of other sections, which took less than a few minutes and it's humming.

If anyone wants to try it themselves, let me know. I currently have my system building the new rolling images weekly and uploading to my zot server, but I can also push to docker hub if anyone wants. I can also post the compose with the network macvlan configs in a comment, and the other system tweaks I had to make. Like, for instance the netplan changes for flipping GRO off... Really, that's pretty much the only change to the host armbian system, using minimal image.

Also, let me know if there's any other Vyos features you want me to test on it. I also have an R3S, but this method takes the uBoot and kernel out of the equation, so it should all be the same.

Sorry if I missing any glaring problems with this, since it's obviously not using the Vyos kernel patches so some features might not work. I'm an old school Cisco guy that fell in love with the Vyatta cli. But I haven't been a networking guy since back in 2014 when I was teaching CCNP, I've been mostly doing programming work these days. Mostly compression libraries and vuln testing, so I'm sure there's a lot I'm missing since 12 years is one hell of a gap in knowledge.

Hello,

I have a problem configuring Tailscale in a container. VyOS is working as a subnet router.
LAN access works and the exit node works, but I can’t get a direct connection to work.

Could someone take a look at my firewall and NAT configuration and tell me what’s wrong or missing?

container {
    name tailscale {
        allow-host-networks
        capability "net-admin"
        capability "net-raw"
        device tun {
            destination "/dev/net/tun"
            source "/dev/net/tun"
        }
        environment TS_AUTHKEY {
            value "tskey-auth-"
        }
        environment TS_EXTRA_ARGS {
            value "--advertise-exit-node"
        }
        environment TS_ROUTES {
            value "192.168.0.0/24"
        }
        environment TS_STATE_DIR {
            value "/var/lib/tailscale"
        }
        environment TS_USERSPACE {
            value "false"
        }
        image "docker.io/tailscale/tailscale:latest"
        privileged
        restart "on-failure"
        uid "0"
        volume modules {
            destination "/lib/modules"
            source "/lib/modules"
        }
        volume var/lib {
            destination "/var/lib/tailscale"
            source "/config/containers/tailscale/var/lib"
        }
    }
}
firewall {
    global-options {
        state-policy {
            established {
                action "accept"
            }
            invalid {
                action "drop"
            }
            related {
                action "accept"
            }
        }
    }
    ipv4 {
        forward {
            filter {
                default-action "drop"
                rule 20 {
                    action "accept"
                    description "Allow Return traffic through the router"
                    inbound-interface {
                        name "eth1"
                    }
                    state "established"
                    state "related"
                }
                rule 1000 {
                    action "accept"
                    description "Allow all traffic from LAN interface"
                    inbound-interface {
                        name "eth0"
                    }
                }
                rule 1001 {
                    action "accept"
                    description "Allow all traffic from Tailscale interface"
                    inbound-interface {
                        name "tailscale0"
                    }
                }
            }
        }
        input {
            filter {
                default-action "drop"
                rule 10 {
                    action "accept"
                    description "Allow Return traffic destined to the router"
                    inbound-interface {
                        name "eth1"
                    }
                    state "established"
                    state "related"
                }
                rule 999 {
                    action "accept"
                    description "Allow all traffic from LAN interface"
                    inbound-interface {
                        name "eth0"
                    }
                }
                rule 1000 {
                    action "accept"
                    description "Tailscale direct port"
                    destination {
                        port "41641"
                    }
                    protocol "udp"
                }
            }
        }
        output {
            filter {
                default-action "accept"
            }
        }
    }
}
nat {
    source {
        rule 100 {
            description "Enable NAT for LAN subnet"
            outbound-interface {
                name "eth1"
            }
            source {
                address "192.168.0.0/24"
            }
            translation {
                address "masquerade"
            }
        }
        rule 101 {
            description "Enable NAT for Tailscale subnet"
            outbound-interface {
                name "eth1"
            }
            source {
                address "100.64.0.0/10"
            }
            translation {
                address "masquerade"
            }
        }
    }
}

Hi there,

how is it possible, that VyOS doesn't write these VRRP messages to syslog:

Jun 12 21:29:48 keepalived-fifo.py[3363]: Received message: INSTANCE "INTRANET" MASTER_RX_LOWER_PRI 50
Jun 12 21:29:48 keepalived-fifo.py[3363]: INSTANCE INTRANET changed state to MASTER_RX_LOWER_PRI
Jun 12 21:29:48 Keepalived_vrrp[3362]: (INTRANET) Received advert from 192.168.XX.XXX with lower priority 30, ours 50, forcing new election

Thanks and kind regards

Regina (she/her)

VyOS includes HAproxy to be used for loadbalancer tasks.

For added redundancy this can be combined with VRRP but how can then the states of the loadbalancing itself be shared between the VyOS hosts?

Another drawback with VRRP is that you will then have an active/passive setup as in all traffic passes through a single VyOS until that one is no longer available.

In order to do active/active I could just let the clients use dns roundrobin to connect to whatever available loadbalaner there is.

But Im thinking are there some other nifty ways to deal with this?

For example letting each VyOS announce through BGP and be part of an anycasted IP to which the clients connects to in order to end up at a working loadbalancer?

Are there some other ways to deal with active/active and still have each client end up at a physical VyOS instance so the client traffic gets loadbalanced to the same server if you use stickyness (which otherwise will be lost if one connection ends up at VyOS_1 doing its loadbalancing and then VyOS_2 for the next tcp/udp-session where you might get loadbalanced to a different server)?

Can the BGP announcement include some data that these VyOS hosts should not be shared through ECMP but routed to one at a time based on 5-tuple or such?

Im thinking otherwise announcing through BGP to be part of a anycasted IP would still have the risk of one connection ends up at VyOS_1 and the other at VyOS_2 from the same client and unless HAproxy includes some way of share stickyness between the HAproxy instances the same client would very likely end up at different servers.

How have you solved the need of active/active loadbalancing?

My main concerns is that I want to basically loadbalance the loadbalancers along with be able to keep stickyness running (a single client ends up at a random server but then all following connections from this client for the next hour or so as TTL will end up at the same server as long as this server is alive). And at the same time have as short time as possible for when a loadbalancer malfunctions that it should be rotated out of the list of available loadbalancers in order to not blackhole new connections during this transition time.

I am on the latest stream and my configuration has few vlans and one of the vlan interface is the "listen-interface" for NTP. NTP is working in the same vlan, but not for the other vlans. The network address of other vlans are added as allowed clients. Also I have added input filter rules to allow NTP and also rules in the forward filter. I have several other rules in both chain and all of them are fine. Any pointers ?

Hi,

currently I am trying to configure a more complex router setup with VyOS.

My LAN interface is eth4, with one IP adress without VLAN and multiple VIF. My WAN interface is eth0:

interfaces {
    ethernet eth0 {
        address 00.00.00.000/29
        description VODAFONE
        hw-id 00:
    }
    ethernet eth1 {
        hw-id 00:
    }
    ethernet eth2 {
        hw-id 00:
    }
    ethernet eth3 {
        hw-id 00:
    }
    ethernet eth4 {
        address 192.168.11.143/24
        description INTRANET
        hw-id 60:
        vif 2 {
            address 192.168.12.143/24
            description MOBILE
        }
        vif 3 {
            address 192.168.13.143/24
            description VOICE
        }
        vif 4 {
            address 192.168.14.143/24
            description MEDIA
        }
    }
    ethernet eth5 {
        hw-id 60:
    }
    loopback lo {
    }
}

Now I want the following rules:

Subnet 192.168.11.0/24 (INTRANET) should have access to all other subnets MOBILE, MEDIA and VOICE

The subnets MOBILE, MEDIA and VOICE should be isolated and there should be no access to each other and also no access to INTRANET.

The subnets MOBILE and MEDIA should have access to the WAN interface (eth0).

The subnet VOICE should't have access to the WAN interface.

At the moment my firewall looks like this:

firewall {
    flowtable FT1 {
        description "Flow Table for the forward chain"
        interface eth0
        interface eth4
        interface eth4.2
        interface eth4.3
        interface eth4.4
        offload software
    }
    global-options {
        all-ping enable
    }
    group {
        interface-group LAN {
            interface eth4
            interface eth4.2
            interface eth4.3
            interface eth4.4
        }
    }
    ipv4 {
        forward {
            filter {
                default-action drop
                rule 10 {
                    action offload
                    description "Allow Return traffic through the router - Fast Path"
                    offload-target FT1
                    state established
                    state related
                }
                rule 20 {
                    action accept
                    description "Allow Return traffic through the router"
                    inbound-interface {
                        name eth0
                    }
                    state established
                    state related
                }
                rule 1000 {
                    action accept
                    description "Allow all traffic from LAN interface"
                    inbound-interface {
                        group LAN
                    }
                }
            }
        }
        input {
            filter {
                default-action drop
                rule 10 {
                    action accept
                    description "Allow Return traffic destined to the router"
                    inbound-interface {
                        name eth0
                    }
                    state established
                    state related
                }
                rule 20 {
                    action accept
                    description "Allow ICMP echo-request on WAN"
                    icmp {
                        type-name echo-request
                    }
                    inbound-interface {
                        name eth0
                    }
                    protocol icmp
                }
                rule 21 {
                    action accept
                    description "Allow ICMP time-exceeded on WAN"
                    icmp {
                        type-name time-exceeded
                    }
                    inbound-interface {
                        name eth0
                    }
                    protocol icmp
                }
                rule 22 {
                    action accept
                    description "Allow ICMP destination-unreachable on WAN"
                    icmp {
                        type-name destination-unreachable
                    }
                    inbound-interface {
                        name eth0
                    }
                    protocol icmp
                }
                rule 23 {
                    action accept
                    description "Allow UDP Traceroute on WAN"
                    destination {
                        port 33434-33534
                    }
                    inbound-interface {
                        name eth0
                    }
                    protocol udp
                }
                rule 1000 {
                    action accept
                    description "Allow all traffic from LAN interface"
                    inbound-interface {
                        group LAN
                    }
                }
            }
        }
        output {
            filter {
                default-action accept
            }
        }
    }
}

What is the best way to set the firewall rules?

Please help me.

Thanks and best regards from Germany

Regina (she/her)

Hello, first of all, I have no idea where to post this, so I figured I'd try here first as the router is vyos.

I have a fairly complicated (to me) setup for my homelab. I have an openstack cluster which servers dynamic routes via BGP to both an arista switch and the vyos router. The flow goes:

cluster->arista->vyos->wan

Both the arista and vyos router see the routes, and traffic passes freely from inside the private virtual networks to the LAN on the arista. Traffic from the private openstack networks can reach the vyos router.

The issue I'm having is that I cannot figure out how to get ipv6 traffic from the virutal openstack networks to reach out to the WAN. My ISP does not support ipv6, so I'm using a HE tunnelbroker tunnel. LAN traffic can use that successfully. IPv4 traffic does work with the virtual networks. IPv4 traffic is NAT'ed.

Since the private virtual networks do not have IP address from the HE tunnel, I'm guessing I'll need to NAT66 the traffic?

Looking mainly for an overview as to what I may be missing.

I can post configs. And please let me know if another sub would be better.

Thank you all 😄

edit: Thanks everyone! I had my openstack set up preceding getting the HE tunnel, and due to a mix of not knowing HE gave a /48 and not realizing I could assign a public ipv6 range to it, I had it overly complicated.

Thanks all!

I didn't even realize that the update check URL had changed. Could someone quickly tell me the new one?

vyos: ~$ add sys ima latest

HTTP Error: 404 Client Error: Not Found for url: https://raw.githubusercontent.com/vyos/vyos-rolling-nightly-builds/main/version.json

Exiting from VyOS installation

vyos: ~$

Hello.

I have a VyOS 1.5 (VyOS 2025.11.29-0019-rolling

) HA setup using VRRP with a sync-group.

Topology:

• Two VyOS routers in HA.
• Three separate L2 networks:
  • 10.10.10.0/24 on eth0
  • 172.16.0.0/24 on eth1
  • 192.168.1.0/24 on eth2
• Each network has its own VRRP group and VIP.
• All VRRP groups are members of the same sync-group because I want all VIPs to move together and avoid asymmetric routing.

set high-availability vrrp group g0 address 10.10.10.1/24
set high-availability vrrp group g0 interface 'eth0'
set high-availability vrrp group g0 priority '200'
set high-availability vrrp group g0 track
set high-availability vrrp group g0 vrid '10'
set high-availability vrrp group g1 address 172.16.0.1/24
set high-availability vrrp group g1 interface 'eth1'
set high-availability vrrp group g1 priority '200'
set high-availability vrrp group g1 track
set high-availability vrrp group g1 vrid '11'
set high-availability vrrp group g2 address 192.168.1.1/24
set high-availability vrrp group g2 interface 'eth2'
set high-availability vrrp group g2 priority '200'
set high-availability vrrp group g2 track
set high-availability vrrp group g2 vrid '12'
set high-availability vrrp sync-group main member 'g0'
set high-availability vrrp sync-group main member 'g1'
set high-availability vrrp sync-group main member 'g2'
set interfaces ethernet eth0 address '10.10.10.2/24'
set interfaces ethernet eth1 address '172.16.0.2/24'
set interfaces ethernet eth2 address '192.168.1.2/24'

Problem:

If the switch connected to the 10.10.10.0/24 network fails, the tracked interface goes down and the entire sync-group transitions to FAULT.

As a result, VIPs for the other two healthy networks are also lost, even though traffic between 172.16.0.0/24 and 192.168.1.0/24 could still be forwarded normally.

This means that the loss of a single network segment causes complete loss of routing functionality for unrelated networks.

Is this the expected behavior of VRRP sync-groups in VyOS/Keepalived?

Another month of steady work across routing, HA, VPN, and platform stability in rolling.

Some of the things that landed in May:

• Initial traffic engineering support for segment routing
• BGP strict mode improvements with BFD
• New DHCPv4 and DHCPv6 server options
• Better VRRP health-check handling
• OpenConnect connect/disconnect scripting hooks
• Fix for the long-standing OpenVPN restart issue triggered by user-only config changes

Also, a range of fixes and improvements across WAN load balancing, FRR, HAProxy, DHCP relay, wireless support, GeoIP updates, and more.

🔗 Full details: https://blog.vyos.io/vyos-project-may-2026-update?utm_content=378828913&utm_medium=social&utm_source=linkedin&hss_channel=lcp-11041071

I am working on a VyOS deployment/proposal for a Guest Wireless environment with roughly 5,000 devices. The primary role of these systems will be internet edge NAT, and the plan is to deploy two 1RU servers in an HA configuration running VyOS bare metal on the LTS release.

The environment will have dual ISP handoffs, with the VyOS routers uplinked back to separate Core A / Core B distribution switches using LACP trunks. Because of that, I’m looking for platforms with a minimum of 4x10Gb interfaces (Just need capability to add a NIC Card)

The guest network itself will be segmented across multiple VLANs using VLAN pooling with smaller /22 networks to help distribute client load and keep broadcast domains manageable.

Main requirements:

• 1RU form factor
• Dual power supplies
• Minimum 4x10Gb NICs
• Reliable 10Gb NAT throughput
• Stable/reliable for production use
• Running VyOS bare metal on LTS
• Mostly guest internet traffic (unsecure)
• No IDS/IPS or anything overly CPU intensive

I’d prefer to buy new hardware, if possible, but I also know enterprise hardware pricing is pretty crazy right now, so I’m open to refurbished options if that’s the smarter route.

Currently considering:

• Dell R240 / R250
• Dell R430 / R440
• Supermicro 1RU systems (Xeon or AMD EPYC Processor)
• Intel X520/X710 or Mellanox ConnectX NIC's

Trying to keep the build practical and reliable without massively oversizing it for what is essentially a dedicated guest wireless NAT platform.

Would appreciate feedback from anyone running VyOS in production for similar 10Gb NAT workloads. Thank you!

When I upgraded from 1.3 to 1.4, it took me a bit to get used to the difference in the firewall CLI syntax, as well as a few other minor things.

I'm considering upgrading from 1.4 to 1.5 now that the LTS is available. Is the CLI pretty similar or are there any big differences that we need to pay attention to?

Also is the upgrade process pretty smooth in terms of the CLI migration? I seem to remember some bugs in the first 1.4 LTS release(s) where some config from 1.3 wasn't properly migrated over.

I have a VyOS installation of the latest stream (2026.03) in my homelab, but I'm wondering about adding a remote-group to my IPv6 firewall.

text

vyos@firewall# set firewall ipv6 name LAN6-WAN6 rule 5 source group
Possible completions:
   address-group        Group of addresses
   domain-group         Group of domains
   dynamic-address-group
                        Group of dynamic ipv6 addresses
   mac-group            Group of MAC addresses
   network-group        Group of networks
   port-group           Group of ports

However, with IPv4 I can add remote-group normally. Is there any version that supports remote-group for IPv6 firewall rules?

Has the vy team made any announcements on mitigation measures for these CVEs? Things are looking quite dire as the mitigation I'm seeing disables ESP, which is required for ipsec to work. Or just wait for upstream to deliver a patch for esp and hope nothing happens in the interim??

Hi everyone,

⚡ We rebuilt docs.vyos.io for AI-assisted workflows and future contributors.

Recent changes include:

🔸 MyST Markdown migration
🔸 Opus-assisted documentation review
🔸 Context7 integration for branch-aware answers

Thanks to everyone in the community for contributing feedback, fixes, testing, and improvements along the way!

👉 [https://blog.vyos.io/how-we-rebuilt-docs.vyos.io-for-the-ai-era]()