Hello, Community! The holiday season in the Northern hemisphere is over and it's very visible in the commit log. There are lots of things that happened in VyOS in September — that includes a new, more performant kernel mode NetFlow sensor; the equally long-awaited support for using firewall groups in WAN load balancing rules; improvements that will hopefully make config corruption on power loss very unlikely; TLS support for syslog; and many more smaller features and fixes.
ssh-dss key support will be removed in future VyOS versions (T7839)We've been investigating what it will take to upgrade the base system to a newer Debian version and found an issue that is unlikely to affect many people but its impact can be huge for those it does affect.
The version of OpenSSH that comes with Debian Trixie completely removed support for legacy ssh-dss (DSA) keys.
That means that when we switch the base system from Debian Bookworm to Debian Trixie in the future, all users that use those keys will be locked out of the system.
DSA keys have been deprecated in OpenSSH for a long time, but we kept supporting them to ensure compatibility.
Since we'll be unable to support them in the future, we added a prominent deprecation warning on login. If you have users configured with ssh-dss keys, you will see a warning like this:
DEPRECATION WARNING: Support for SSH-DSA keys is deprecated and will
be removed in VyOS 1.6. Please update affected keys to a supported
algorithm (e.g., RSA, ECDSA or ED25519) to avoid authentication
failures after the upgrade. The following users are using SSH-DSS keys
for authentication.
User "vyos" with deprecated public-key named: fooTo ensure you will not be locked out, simply replace the SSH key with a more modern and secure type, ECDSA or RSA with key length over 2048.
Historically, NetFlow sensor implementation in VyOS was based on the pmacct project. Unfortunately, it's not fast enough to cope with the bandwidth of modern networks, and we received many complaints about its performance, so we had to look for alternatives.
We settled on ipt-netflow. First, it's a kernel module and this fact alone makes its operation much faster and less expensive, since there's no need for context switches. Second, we knew that a number of users were already using it in production networks instead of the official pmacct-based netflow and reported that it worked well for them, so we felt quite confident about it.
Even though it's an iptables module, none of the kernel APIs it uses are deprecated at the moment and it works fine in the NFT framework, so the risk of incompatibility with future kernels seems low.
The configuration syntax is largely compatible with the original, we only made a few small changes and they are all handled by migration scripts:
system flow-accounting interface is now system flow-accounting netflow interfacesource-address is now a per-server rather than a global option, e.g. set system flow-accounting netflow server 192.0.2.1 source-address 203.0.113.1disable-imt, buffer-size, packet-length, timeout, and syslog-facility.In other words, after upgrade, your NetFlow configuration should work as before, but much faster.
Is ipt-netflow the ultimate NetFlow sensor implementation? It may or may not be. Depending on how the ecosystem evolves, we may undetake refreshing it to integrate it into the NFT framework properly, or consider an alternative implementation, if it appears. But for now, it seems to solve the long-standing NetFlow performance problem well enough.
Being able to use groups in WAN load balancing rules was one of the most long-standing feature requests, as you can see from the task number that's in the low hundreds.
Now you can match any firewall group type (address, network, domain, and port groups) in source and destination statements of load balancing rules. For a minimal example:
vyos@vyos# show firewall
group {
address-group SomeGroup {
address 192.168.1.4
address 192.168.1.5
address 172.16.0.15
}
}
[edit]
vyos@vyos# show load-balancing
wan {
interface-health eth0 {
nexthop 192.0.2.1
test 10 {
target 192.0.2.1
type ping
}
}
rule 10 {
interface eth0 {
}
source {
group {
address-group SomeGroup
}
}
}
}Formerly, the only supported container network type was bridge, but now it's possible to configure MACVLAN networks as well:
set container network <network name> gateway <IPv4 or IPv6 address>
set container network <network name> type macvlan mode <bridge|private|vepa>
set container network <network name> type macvlan parent <physical interface>set protocols isis interface <INTERFACE NAME> fast-reroute lfa <level-1 | level-2> enable
set protocols isis interface <INTERFACE NAME> fast-reroute lfa <level-1 | level-2> exclude interface <INTERFACE NAME>
set protocols isis interface <INTERFACE NAME> fast-reroute remote-lfa <level-1 | level-2> maximum-metric <METRIC>
set protocols isis interface <INTERFACE NAME> fast-reroute remote-lfa [level-1 | level-2] tunnel mpls-ldp
set protocols isis interface <INTERFACE NAME> fast-reroute ti-lfa <level-1 | level-2> [node-protection [link-fallback]]show interfaces vxlan <interface name> statistics
show interfaces vxlan <interface name> vlan <vlan-id> statisticsset firewall ipv4 forward filter disable-conntrack (T7475)soft <in|out> option with all BGP peer reset commands (T7516).set protocols bgp peer-group <name> solo (T6438)set policy route-map test rule 10 match rpki-extcommunity <valid|invalid|notfound> (T1124)system login (T7820) and is now the default password hash algorithm (T7852)frr_exporter now exports IPv6 BGP sessions (T7851)enable-pass-nd-and-dhcpv6 option is set (T7842)For a long time, we were getting reports about rare but serious issues when configuration files could be corrupted or even disappear completely after hardware reset or power loss.
We made multiple improvements over time but a complete fix was elusive — those issues would just appear less frequently.
Now we tracked down one deep cause — the /config directory was created using a bind mount call that interfered with inode updates at later points. We fixed the mount and switched the configuration saving function to use atomic writes, which should fix most config corruption issues.
However, if you see any corruption or loss, please report them! And if you want to give it your own stress testing, please report the outcomes as well.
run show firewall ipv6 prerouting raw shows the correct default action now, accept rather than drop (T6857)run show nat <source|destination> rules (T7696)set system conntrack options that could lead to invalid generated configs (T7700)show dhcp server leases no longer incorrectly omits some leases (T5992)run show interfaces (T7746)podman command no longer cause errors (T6673)run show interfaces output for L2TPv3 interfaces (T7721)