Docs Vyos Io en Latest
Docs Vyos Io en Latest
1 About 2
2 History 3
3 Changelog 6
11 Troubleshooting 1128
15 Development 1282
18 Debugging 1299
19 Testing 1303
21 Coverage 1315
i
Index 2277
ii
VyOS Documentation, Release 1.5.x (circinus)
Get / Build VyOS Quickly Build your own Image or take a look at how to download a free or supported version.
Install VyOS Read about how to install VyOS on Bare Metal or in a Virtual Environment and how to use an image
with the usual cloud providers
Configuration and Operation Use the Quickstart Guide, to have a fast overview. Or go deeper and set up advanced
routing, VRFs, or VPNs for example.
Automate Integrate VyOS in your automation Workflow with Ansible, have your own local scripts, or configure VyOS
with the HTTPS-API.
Examples Get some inspiration from the Configuration Blueprints to build your infrastructure.
Contribute and Community
There are many ways to contribute to the project.
Add missing parts or improve the Documentation.
Discuss in Slack or the Forum.
Or you can pick up a Task and fix the code.
CONTENTS 1
CHAPTER
ONE
ABOUT
2
CHAPTER
TWO
HISTORY
There once was a network operating system based on Debian GNU/Linux, called Vyatta.*0 2006 onwards, it was a
great free software alternative to Cisco IOS and Jupiter JUNOS. It came in two editions: Vyatta Core (previously
Vyatta Community Edition) that was completely free software, and Vyatta Subscription Edition that had proprietary
features and was only available to paying customers.†0
Vyatta was acquired by Brocade Communication Systems in 2012. Shortly after, Brocade renamed Vyatta Subscription
Edition to Brocade vRouter, discontinued Vyatta Core and shut down the community forum without a notice. The bug
tracker and Git repositories followed next year.
It’s worth noting that by the time Brocade acquired Vyatta, development of Vyatta Core was already stagnated. Vyatta
Subscription Edition (and thus, Vyatta development as a whole) had been replacing core components with proprietary
software, meaning few features made it to Vyatta Core, and those that did were bug-ridden and hamstrung.
In 2013, soon after Vyatta Core was abandoned, the community forked the last Vyatta Core version (6.6R1) and VyOS
Project came into being. Sentrium SL was established by VyOS maintainers in 2014 to fund VyOS development by
selling support, consulting services and prebuilt long-term support images.
Brocade was acquired by Broadcom in 2016 and sold what remains of erstwhile Vyatta to AT&T in 2017, who in turn
sold it to Ciena in 2021.
VyOS major versions used to be named after elements in order of atomic numbers. With 1.2, this naming scheme was
replaced with the much cooler scheme of Latin names of IAU designated constellations by solid angle area, starting
from the smallest.
0 From the Sanskrit adjective “Vyātta” (), meaning opened.
0 A business model comparable to that of Redis, rather than that of VyOS today.
3
VyOS Documentation, Release 1.5.x (circinus)
Released just in time for holidays on 22 December 2013, Hydrogen was the first major VyOS release. It fixed features
that were broken in Vyatta Core 6.6 (such as IPv4 BGP peer groups and DHCPv6 relay) and introduced command
scripting, a task scheduler and web proxy LDAP authentication.
Helium was released on 9 October 2014, exactly on the day VyOS Project first came into being in the previous year.
Helium came with a lot of new features, including an event handler and support for L2TPv3, 802.1ad QinQ and IGMP
proxy, as well as experimental support for VXLAN and DMVPN (the latter of which was also broken in Vyatta Core
due to its reliance on a proprietary NHRP implementation).
Crux (the Southern Cross) came out on 28 January 2019 and was the first major release of VyOS as we know it today.
The underlying Debian base was upgraded from Squeeze (6) to Jessie (8).
Although Crux came with too many new features to mention here, some noteworthy ones are: an mDNS repeater,
a broadcast relay, a high-performance PPPoE server, an HFSC scheduler, as well as support for Wireguard, unicast
VRRP, RPKI for BGP and fully 802.1ad-compliant QinQ ethertype. The telnet server and support for P2P filtering
were removed.
Crux is the first version to feature the modular image build system. CLI definitions began to be written in the modern,
verifiable XML templates. Python APIs were introduced for command scripting and configuration migration. Intro-
duction of new Perl and shell code was proscribed and the rewriting of legacy Perl code in pure Python began with
Crux.
As of 2022, Crux is still supported and maintained.
The current long-term support version of VyOS, Equuleus (the Pony) came out on 21 December 2021, once again in
time for the winter holidays.
Equuleus brought many long-desired features with it, most notably an SSTP VPN server, an IPoE server, an Open-
Connect VPN server and a serial console server, in addition to reworked support for WWAN interfaces, support for
GENEVE and MACSec interfaces, VRF, IS-IS routing, preliminary support for MPLS and LDP, and many other ini-
tialisms.
As of 2022, Equuleus is in the stable.
Sagitta (the Arrow) is the codename of the current development branch, so there’s no VyOS 1.4 yet.
Circinus (the Compass) is the codename of the upcoming development branch, so there’s no VyOS 1.5 yet.
Unlike Vyatta, VyOS never had (nor will ever have) proprietary code. The only proprietary material in VyOS is non-
code assets, such as graphics and the trademark “VyOS”.‡0 This means you can build your own long-term support
images (as the entire toolchain we use is free software) and even distribute them, given you rename it and remove
such assets before building. Although note that we do not provide support for images distributed by a third-party. See
the artwork license and the end-user license agreement at /usr/share/vyos/EULA in any pre-built image for more
precise information.
0 This is not unlike how Linus Torvalds owns the trademark “Linux”.
THREE
CHANGELOG
3.1.1 2024-04-26
3.1.2 2024-04-25
• T6263 (bug): Multicast: Could not commit multicast config with multicast join group
using source-address
• T5833 (bug): Not all AFIs compatible with VRF
3.1.3 2024-04-24
3.1.4 2024-04-23
• T6260 (bug): image-tools: remove failed image directory if 'No space left on
device' error
• T6261 (default): Typo in op_mode connect_disconnect print statement for
check_ppp_running
• T6237 (feature): IPSec remote access VPN: ability to set EAP ID of clients
6
VyOS Documentation, Release 1.5.x (circinus)
3.1.5 2024-04-22
3.1.6 2024-04-21
3.1.7 2024-04-20
• T6252 (bug): gre tunnel - doesn't allow configure jumbo frame more than 8024
3.1.8 2024-04-19
3.1.9 2024-04-17
• T6168 (bug): add system image does not set default boot to current console type in
compatibility mode
• T6243 (bug): Update vyos-http-api-tools for package idna security advisory
• T6154 (enhancment): Installer should ask for password twice
• T5966 (default): Adjust dynamic dns configuration address subpath to be more
intuitive and other op-mode adjustments
• T5723 (default): mdns repeater: Always reload systemd daemon before applying
changes
• T5722 (bug): Failing to add route in failover if gateway not in the same interface
network
• T5612 (default): Miscellaneous improvements and fixes for dynamic DNS configuration
• T5574 (default): Support per-service cache management for dynamic dns providers
3.1.10 2024-04-16
3.1.11 2024-04-15
• T6163 (bug): kea-dhcp4-server crashes due to incorrect lease file permissions after
1.5-rolling-202403120022 -> 1.5-rolling-202403230018 upgrade
• T6100 (bug): NAT config migration error in 1.4.0-epa1 if invalid address/network
defined in 1.3.6 version
• T6174 (bug): can't view dhcp server leases if logged in as a tacacs account
• T5734 (bug): OpenVPN server dh-params that are not in PKI error
3.1.12 2024-04-14
3.1.13 2024-04-13
• T6173 (bug): Build Causes Errors When "--version" Contains Slashes ("/")
• T2518 (feature): Support NAT for ipv6(NPT)
3.1.14 2024-04-12
3.1.15 2024-04-11
3.1.16 2024-04-10
3.1.17 2024-04-09
• T6121 (feature): Extend service config-sync for sections vpn, policy, vrf
3.1.18 2024-04-08
• T6197 (bug): IPoE-server interface client-subnet looks broken or works with the
wrong logic
• T6196 (bug): Route-map and summary-only do not work in BGP aggregation at the same
time
• T6068 (feature): dhcp server: allow switching between load-balanced and hotspare
mode
3.1.19 2024-04-07
• T6205 (bug): ipoe: error in migration script logic while renaming mac-address to
mac node
• T5862 (bug): Default MTU is not acceptable in some environments
• T6208 (feature): container: rename "cap-add" CLI node to "capability"
• T6188 (feature): Add Firewall Rule Description to "show firewall" commands
• T1244 (default): Support for StartupResync in conntrackd
3.1.20 2024-04-06
3.1.21 2024-04-05
3.1.22 2024-04-04
3.1.23 2024-04-03
• T6198 (feature): configverify: add common helper for PKI certificate validation
• T6192 (feature): Multi VRF support for SSH
3.1.24 2024-04-02
3.1.25 2024-04-01
3.1.26 2024-03-31
3.1.27 2024-03-29
• T6159 (bug): Openvpn Server Op-cmd adds heading "OpenVPN status on vtunx" for every
client connection
3.1.28 2024-03-28
3.1.29 2024-03-26
• T6066 (bug): Setting same network in different ospf area will raise exception
3.1.30 2024-03-25
• T6145 (bug): Service config-sync does not rely on priorities but must
3.1.31 2024-03-24
3.1.32 2024-03-23
3.1.33 2024-03-22
• T6136 (bug): Configuring a dynamic address group, config script did not check
whether the group was created
• T6130 (bug): [1.3.6->1.4.0-epa2 Migration] BGP "set community" missing
• T6090 (bug): [1.3.6->1.4.0-epa1 Migration] policy route fails due tcp flag case
sensitivity
• T6155 (default): ixgbe: failed to initialize because an unsupported SFP+ module
type was detected.
• T6125 (feature): Support 802.1ad (0x88a8) vlan filtering for bridge
3.1.34 2024-03-21
3.1.35 2024-03-20
3.1.36 2024-03-19
• T6127 (bug): Ability to view logs for rules with Offload not functional
• T6138 (bug): Conntrack table op-mode fails with flowtable offload entries
3.1.37 2024-03-15
3.1.38 2024-03-12
3.1.39 2024-03-11
• T6098 (bug): Description doesnt seem to allow for non international characters
• T2998 (bug): SNMP v3 oid "exclude" option doesn't work
• T6107 (bug): Nginx does not allow big config queries for configure endpoint API
• T6096 (bug): Config commits are not synced properly because 00vyos-sync is deleted
by vyos-router
• T6093 (bug): Incorrect dhcp-options vendor-class-id regex
• T6083 (feature): ethtool: move string parsing to JSON parsing
3.1.40 2024-03-08
3.1.41 2024-03-07
3.1.42 2024-03-06
3.1.43 2024-03-05
3.1.44 2024-03-04
3.1.45 2024-03-02
• T6081 (bug): QoS policy shaper target and interval wrong calcuations
3.1.46 2024-02-29
3.1.47 2024-02-28
3.1.48 2024-02-26
• T6064 (bug): Can not build VyOS if repository it not cloned to a branch
• T5754 (default): Update to StrongSwan 5.9.11
3.1.49 2024-02-25
• T6060 (feature): op-mode: container: support removing all container images at once
3.1.50 2024-02-24
• T5909 (bug): Container registry with authentication prevents config load (section
container) after reboot
3.1.51 2024-02-23
3.1.52 2024-02-22
3.1.53 2024-02-21
3.1.54 2024-02-19
• T5971 (default): Create the same view of ppp section for all accel-ppp services
• T6029 (default): Rewrite Accel-PPP services to an identical feature set
• T3722 (bug): op-mode IPSec show vpn ike sa always shows L-TIME 0
3.1.55 2024-02-18
3.1.56 2024-02-17
• T5972 (feature): login: add possibility to disable individual local user accounts
3.1.57 2024-02-16
• T6009 (bug): Firewall - Time not working properly when not using UTC
• T6005 (bug): Error on adding a wireguard interface to OSPFv3
• T6019 (feature): Bump nftables and libnftnl version
• T6001 (default): Add option to enable resolve-via-default
• T5965 (bug): WWAN modems using raw-ip do not work with dhclient/dhcp6c
• T5245 (bug): Wireless interfaces do not get IPv6 link-local address assigned
3.1.58 2024-02-15
• T5977 (bug): nftables: Operation not supported when using match-ipsec in outbound
firewall
• T2612 (bug): HTTPS API, changing API key fails but goes through
• T5989 (bug): IP subnets not usable in UPnP ACLs
• T5719 (default): mdns repeater: Add op-mode commands
• T4839 (feature): Dynamic Firewall groups
3.1.59 2024-02-14
• T6034 (feature): rpki: move file based SSH keys for authentication to PKI subsystem
• T5981 (bug): IPsec site-to-site migrated PKI ca certificates are created with an '@'
• T5930 (bug): vrf - route-leak not work using route-target both command.
• T5709 (bug): IPoE-server fails if next pool mentioned but not defined
• T2044 (bug): RPKI doesn't boot properly
• T6032 (feature): bgp: add EVPN MAC-VRF Site-of-Origin support
• T5960 (default): Rewriting authentication section in accel-ppp services
3.1.60 2024-02-13
• T5928 (bug): Configuration fails to load on boot if offloading has VLAN interfaces
defined
• T5064 (bug): Value validation for domain-groups seems to be broken
3.1.61 2024-02-12
3.1.62 2024-02-10
• T6023 (bug): rpki: add support for CLI knobs expire-interval and retry-interval
3.1.63 2024-02-09
3.1.64 2024-02-08
3.1.65 2024-02-07
3.1.66 2024-02-06
3.1.67 2024-02-05
• T5974 (bug): QoS policy shaper is currently miscalculating bandwidth and ceil values
for the default class
• T5865 (feature): Rewrite ipv6 pool section to ipv6 named pools in Accel-ppp services
3.1.68 2024-02-02
• T5739 (bug): Password recovery does not work if public keys are configured
• T5955 (feature): Rootless containers/set uid/gid for container
• T6003 (feature): Add 'show rpki as-number' and 'show rpki prefix'
• T5848 (feature): Add triple-isolate flow isolation option to CAKE QoS policy
3.1.69 2024-02-01
• T5995 (bug): Kernel NIC-drivers for Huawei NICs are not properly enabled
• T5978 (bug): ethernet: hw-tc-offload does not actually get enabled on the NIC
• T5979 (enhancment): Add configurable kernel boot parameters
• T5973 (bug): vrf: RTNETLINK answers: File exists
• T5967 (bug): Multi-hop BFD connections can't be established; please add minimum-ttl
option.
• T5619 (default): Update the Intel ixgbe driver due to issues with Intel X533
3.1.70 2024-01-31
3.1.71 2024-01-30
• T5980 (feature): Add image-tools support for configurable kernel boot options
3.1.72 2024-01-29
• T5988 (bug): image-tools: a check of valid image name is missing from 'add image'
• T5994 (bug): Fix typo in 'remote' module preventing 'add system image' via ftp
3.1.73 2024-01-26
3.1.74 2024-01-25
3.1.75 2024-01-22
3.1.76 2024-01-21
3.1.77 2024-01-20
3.1.78 2024-01-19
• T5897 (bug): VyOS with Cloud-init and VRF stucks at reboot/shutdown process
• T5554 (bug): Disable sudo for PAM RADIUS
• T4754 (default): Improvement: system login: show configured 2FA OTP key
• T5857 (bug): show interfaces wireless info
• T5841 (default): Remove old ssh-session-cleanup.service
• T5884 (default): Minor description fix (op-mode: generate wireguard)
• T5781 (default): Add ability to add additional minisign keys
3.1.79 2024-01-18
3.1.80 2024-01-17
• T5923 (bug): Config mode system_console.py is not aware of revised GRUB file
structure
• T4658 (feature): Rename DPD action `hold` to `trap`
3.1.81 2024-01-16
3.1.82 2024-01-15
3.1.83 2024-01-12
3.1.84 2024-01-11
3.1.85 2024-01-10
• T5791 (default): Update dynamic dns configuration path to be consistent with other
areas of VyOS
• T5708 (default): Additional dynamic dns improvements to align with ddclient 3.11.1
release
• T5573 (bug): Fix ddclient cache entries
• T5614 (default): Add conntrack helper matching on firewall
3.1.86 2024-01-09
• T5898 (bug): Replace partprobe with partx due to unable to install VyOS
• T5840 (feature): Upgrade Kea to 2.4.x
• T5838 (feature): Add Infiniband kernel modules
• T5785 (bug): API output of show container image broken
• T5249 (feature): Add rollback-soft feature to rollback without a reboot
• T2511 (feature): Migrate vyatta-op-quagga to new XML format
• T5905 (bug): pki: IPsec and VTI interface priority inversion when using x509
site-to-site peer
3.1.87 2024-01-08
3.1.88 2024-01-07
3.1.89 2024-01-06
3.1.90 2024-01-05
3.1.91 2024-01-03
• T5880 (bug): verify_source_interface should not allow dynamic interfaces like ppp,
l2tp, ipoe or sstpc client interfaces
• T5879 (bug): tunnel: sourceing from dynamic pppoe0 interface will fail on reboots
3.1.92 2024-01-02
3.1.93 2024-01-01
• T5883 (bug): Preserve file ownership in /config subdirs on add system image
• T5474 (feature): Establish common file name pattern for XML conf mode commands
3.1.94 2023-12-30
• T5875 (bug): login: removing and re-adding a user keeps the home directory but UID
will change, thus SSH keys no longer work
• T5653 (feature): Command to display fingerprint
3.1.95 2023-12-29
3.1.96 2023-12-28
3.1.97 2023-12-25
• T5855 (feature): Migrate "set service lldp snmp enable" -> `set service lldp snmp"
• T5837 (bug): vyos.configdict.node_changed does not return keys per adding
• T5856 (bug): SNMP service removal fails
3.1.98 2023-12-23
3.1.99 2023-12-22
3.1.100 2023-12-21
3.1.101 2023-12-20
• T5823 (feature): Protocol BGP add default values for config dictionary
• T5798 (enhancment): reverse-proxy load-balancing service should support multiple
certificates for frontend
3.1.102 2023-12-19
3.1.103 2023-12-18
3.1.104 2023-12-15
3.1.105 2023-12-14
3.1.106 2023-12-13
3.1.107 2023-12-12
3.1.108 2023-12-11
• T5741 (bug): WAN Load Balancing failover route tables aren't created
3.1.109 2023-12-10
3.1.110 2023-12-09
3.1.111 2023-12-08
• T5782 (enhancment): Use a single config mode script for https and http-api
• T5768 (enhancment): Remove auxiliary http-api.conf for simplification of http-api
config mode script
3.1.112 2023-12-04
• T5769 (bug): VTI tunnels lose their v6 Link Local addresses when set down/up
3.1.113 2023-12-03
3.1.114 2023-11-27
• T5763 (bug): Fix imprecise check for remote file name in vyos-load-config.py
• T5783 (feature): frr: smoketests must notice any daemon crash
3.1.115 2023-11-26
3.1.116 2023-11-25
• T5655 (bug): commit-archive: Ctrl+C should not eror out with stack trace, signal
should be cought
3.1.117 2023-11-24
3.1.118 2023-11-23
• T5659 (bug): VPP cannot add interface to dataplane if it already has an address
configured
3.1.119 2023-11-22
• T5767 (feature): Add reboot and poweroff the system via API
• T5729 (bug): Firewall, nat and policy route - Switch to valueless
• T5681 (feature): Interface match - Simplified and unified cli
• T5643 (feature): NAT - Allow interface groups on nat rules
• T5616 (feature): Firewall mark - Add capabilities for matching firewall mark
• T5590 (default): Firewall "log enable" logs every packet
3.1.120 2023-11-21
• T5762 (bug): http: api: smoketests fail as they can not establish IPv6 connection
to uvicorn backend server
3.1.121 2023-11-18
3.1.122 2023-11-16
3.1.123 2023-11-15
3.1.124 2023-11-13
3.1.125 2023-11-10
• T5727 (bug): validator: Use native URL validator instead of regex-based validator
3.1.126 2023-11-08
3.1.127 2023-11-07
3.1.128 2023-11-06
3.1.129 2023-11-03
3.1.130 2023-11-02
3.1.131 2023-11-01
3.1.132 2023-10-31
3.1.133 2023-10-27
3.1.134 2023-10-26
3.1.135 2023-10-23
3.1.136 2023-10-22
• T5254 (bug): Modification of any interface setting sets MTU back to default when MTU
has been inherited from a bond
• T5671 (feature): vxlan: change port to IANA assigned default port
3.1.137 2023-10-21
3.1.138 2023-10-20
3.1.139 2023-10-19
3.1.140 2023-10-18
3.1.141 2023-10-17
3.1.142 2023-10-16
3.1.143 2023-10-14
• T5629 (bug): Policy local-route bug after migration to destination node address
3.1.144 2023-10-12
• T5649 (bug): vyos-1x should generate XML cache after building command templates for
less cryptic error on typo
3.1.145 2023-10-10
3.1.146 2023-10-08
3.1.147 2023-10-06
3.1.148 2023-10-05
3.1.149 2023-10-04
3.1.150 2023-10-03
3.1.151 2023-09-28
3.1.152 2023-09-24
3.1.153 2023-09-22
3.1.154 2023-09-20
3.1.155 2023-09-19
3.1.156 2023-09-18
3.1.157 2023-09-15
3.1.158 2023-09-11
3.1.159 2023-09-10
3.1.160 2023-09-09
• T5423 (bug): ipsec: no output for op-cmd "show vpn ike secrets"
3.1.161 2023-09-08
• T5560 (bug): VyOS version in current branch should be changed from 1.4 to 1.5
3.1.162 2023-09-07
3.1.163 2023-09-06
3.2.1 2024-04-25
• T6263 (bug): Multicast: Could not commit multicast config with multicast join group
using source-address
• T5833 (bug): Not all AFIs compatible with VRF
3.2.2 2024-04-24
3.2.3 2024-04-23
• T6260 (bug): image-tools: remove failed image directory if 'No space left on
device' error
• T6261 (default): Typo in op_mode connect_disconnect print statement for
check_ppp_running
• T6237 (feature): IPSec remote access VPN: ability to set EAP ID of clients
3.2.4 2024-04-22
3.2.5 2024-04-21
3.2.6 2024-04-20
• T6252 (bug): gre tunnel - doesn't allow configure jumbo frame more than 8024
3.2.7 2024-04-19
3.2.8 2024-04-17
• T6168 (bug): add system image does not set default boot to current console type in
compatibility mode
• T6243 (bug): Update vyos-http-api-tools for package idna security advisory
• T6154 (enhancment): Installer should ask for password twice
• T5966 (default): Adjust dynamic dns configuration address subpath to be more
intuitive and other op-mode adjustments
• T5723 (default): mdns repeater: Always reload systemd daemon before applying
changes
• T5722 (bug): Failing to add route in failover if gateway not in the same interface
network
• T5612 (default): Miscellaneous improvements and fixes for dynamic DNS configuration
• T5574 (default): Support per-service cache management for dynamic dns providers
• T5360 (bug): ddclient generating abuse
3.2.9 2024-04-15
3.2.10 2024-04-14
3.2.11 2024-04-13
• T6173 (bug): Build Causes Errors When "--version" Contains Slashes ("/")
• T2518 (feature): Support NAT for ipv6(NPT)
• T6238 (default): vyos-build Check pull request title requires the python script
• T6235 (default): Git check PR status: conflicts and resolution
3.2.12 2024-04-12
• T5871 (default): ipsec remote access VPN: specify "cacerts" to disambiguate mulitple
remote access configurations
• T5870 (default): ipsec remote access VPN: add x509 ("pubkey") authentication
• T5772 (default): Require HTTPS API server configurations to include at least one key
if key-based auth is used
• T5447 (feature): Allow static MACsec keys with peers
• T4221 (default): Add a template filter for converting scalars to single-item lists
• T3766 (feature): containers: Expanding options for networking and building
containers
3.2.13 2024-04-11
3.2.14 2024-04-10
3.2.15 2024-04-09
3.2.16 2024-04-08
• T6197 (bug): IPoE-server interface client-subnet looks broken or works with the
wrong logic
• T6196 (bug): Route-map and summary-only do not work in BGP aggregation at the same
time
• T6068 (feature): dhcp server: allow switching between load-balanced and hotspare
mode
3.2.17 2024-04-07
• T6205 (bug): ipoe: error in migration script logic while renaming mac-address to
mac node
• T6039 (bug): cloud-init DNS search-domain causes configuration migration/validation
error
• T5862 (bug): Default MTU is not acceptable in some environments
• T6208 (feature): container: rename "cap-add" CLI node to "capability"
• T6188 (feature): Add Firewall Rule Description to "show firewall" commands
• T1244 (default): Support for StartupResync in conntrackd
3.2.18 2024-04-06
3.2.19 2024-04-05
3.2.20 2024-04-04
3.2.21 2024-04-03
• T6198 (feature): configverify: add common helper for PKI certificate validation
• T6192 (feature): Multi VRF support for SSH
3.2.22 2024-04-02
3.2.23 2024-04-01
3.2.24 2024-03-31
3.2.25 2024-03-28
3.2.26 2024-03-26
• T6066 (bug): Setting same network in different ospf area will raise exception
3.2.27 2024-03-25
• T6145 (bug): Service config-sync does not rely on priorities but must
3.2.28 2024-03-24
3.2.29 2024-03-23
3.2.30 2024-03-22
• T6136 (bug): Configuring a dynamic address group, config script did not check
whether the group was created
• T6130 (bug): [1.3.6->1.4.0-epa2 Migration] BGP "set community" missing
• T6090 (bug): [1.3.6->1.4.0-epa1 Migration] policy route fails due tcp flag case
sensitivity
• T6155 (default): ixgbe: failed to initialize because an unsupported SFP+ module
type was detected.
• T6125 (feature): Support 802.1ad (0x88a8) vlan filtering for bridge
• T5624 (default): Remove /etc/debian_version from the image
3.2.31 2024-03-21
3.2.32 2024-03-20
3.2.33 2024-03-19
• T6127 (bug): Ability to view logs for rules with Offload not functional
• T6138 (bug): Conntrack table op-mode fails with flowtable offload entries
3.2.34 2024-03-15
3.2.35 2024-03-12
3.2.36 2024-03-11
• T6098 (bug): Description doesnt seem to allow for non international characters
• T6070 (bug): bnx2x NIC causes a commit error due to incorrect implementation of EEE
status reading
• T2998 (bug): SNMP v3 oid "exclude" option doesn't work
• T6107 (bug): Nginx does not allow big config queries for configure endpoint API
• T6096 (bug): Config commits are not synced properly because 00vyos-sync is deleted
by vyos-router
• T6093 (bug): Incorrect dhcp-options vendor-class-id regex
• T6083 (feature): ethtool: move string parsing to JSON parsing
• T6069 (bug): HTTP API segfault during concurrent configuration requests
• T6057 (feature): Add ability to disable syslog for conntrackd
• T5504 (feature): Keepalived VRRP ability to set more than one peer-address
• T5717 (feature): ospfv3 - add allow to set metric-type to ospf redistribution while
frr docs says its possible.
• T6071 (bug): firewall: CLI description limit of 256 characters cause config upgrade
issues
3.2.37 2024-03-08
3.2.38 2024-03-07
3.2.39 2024-03-06
3.2.40 2024-03-05
3.2.41 2024-03-04
3.2.42 2024-03-02
• T6081 (bug): QoS policy shaper target and interval wrong calcuations
3.2.43 2024-02-29
3.2.44 2024-02-28
• T6055 (bug): PKI error: "failed to install x value" when executed the command from
conf mode
• T4270 (bug): dns forwarding - When "ignore-hosts-file" is unset, local hostname of
router resolves to 127.0.1.1
3.2.45 2024-02-27
• T6065 (bug): Duplicate lines in build-vyos-image script cause sagitta build to fail
• T5080 (bug): Conntrack enabled by default
3.2.46 2024-02-26
• T6064 (bug): Can not build VyOS if repository it not cloned to a branch
• T5754 (default): Update to StrongSwan 5.9.11
3.2.47 2024-02-25
• T6060 (feature): op-mode: container: support removing all container images at once
3.2.48 2024-02-24
• T5909 (bug): Container registry with authentication prevents config load (section
container) after reboot
3.2.49 2024-02-23
3.2.50 2024-02-22
3.2.51 2024-02-21
3.2.52 2024-02-19
• T5971 (default): Create the same view of ppp section for all accel-ppp services
• T6029 (default): Rewrite Accel-PPP services to an identical feature set
• T3722 (bug): op-mode IPSec show vpn ike sa always shows L-TIME 0
3.2.53 2024-02-18
3.2.54 2024-02-17
• T5972 (feature): login: add possibility to disable individual local user accounts
3.2.55 2024-02-16
• T6009 (bug): Firewall - Time not working properly when not using UTC
• T6005 (bug): Error on adding a wireguard interface to OSPFv3
• T2113 (bug): OpenVPN Options error: you cannot use --verify-x509-name with
--compat-names or --no-name-remapping
• T6019 (feature): Bump nftables and libnftnl version
• T3471 (bug): DHCP hook is not able to detect all running DHCP instances
• T6015 (default): "journalctl_charon" file does not contain data in the generated
"ipsec debug-archive" file
• T6001 (default): Add option to enable resolve-via-default
• T5965 (bug): WWAN modems using raw-ip do not work with dhclient/dhcp6c
• T5418 (bug): PPPoE-Server Client IP pool Subnet
• T5245 (bug): Wireless interfaces do not get IPv6 link-local address assigned
3.2.56 2024-02-15
• T5977 (bug): nftables: Operation not supported when using match-ipsec in outbound
firewall
• T2612 (bug): HTTPS API, changing API key fails but goes through
• T5989 (bug): IP subnets not usable in UPnP ACLs
• T5890 (default): OTP key generation is broken
• T5719 (default): mdns repeater: Add op-mode commands
• T4839 (feature): Dynamic Firewall groups
• T4801 (feature): Support for building AWS-ready ISO
• T3993 (enhancment): Extend HTTP API GraphQL support
• T3991 (bug): PKI operational command return traceback
• T3780 (bug): VTI not being brought down when tunnel is down
• T3001 (feature): Disable spectre mitigation patches from CLI
• T562 (feature): PDNS: Add support for authoritative dns server
• T71 (feature): Add virtual IP and route installation policy options for IPsec
• T5496 (default): `show firewall` error
• T4038 (default): Rewrite `vyatta-image-tools.pl` in Python
• T4997 (default): Add DHCP client user hooks dir
• T775 (feature): Config Sync between two VyOS routers
• T381 (feature): config nodes for EasyRSA CAs
• T118 (feature): Native Zabbix Support
3.2.57 2024-02-14
• T6034 (feature): rpki: move file based SSH keys for authentication to PKI subsystem
• T5981 (bug): IPsec site-to-site migrated PKI ca certificates are created with an '@'
• T5930 (bug): vrf - route-leak not work using route-target both command.
• T5709 (bug): IPoE-server fails if next pool mentioned but not defined
• T4119 (bug): Issue with l2tp remote-access ipv6 configuration
• T2044 (bug): RPKI doesn't boot properly
• T6032 (feature): bgp: add EVPN MAC-VRF Site-of-Origin support
• T5960 (default): Rewriting authentication section in accel-ppp services
3.2.58 2024-02-13
• T5928 (bug): Configuration fails to load on boot if offloading has VLAN interfaces
defined
• T5482 (bug): Chrony NTP Server Fails To Sync Time
• T5064 (bug): Value validation for domain-groups seems to be broken
3.2.59 2024-02-12
3.2.60 2024-02-10
• T6023 (bug): rpki: add support for CLI knobs expire-interval and retry-interval
• T1090 (default): Webproxy overhaul
3.2.61 2024-02-09
3.2.62 2024-02-08
3.2.63 2024-02-07
3.2.64 2024-02-06
3.2.65 2024-02-05
• T5974 (bug): QoS policy shaper is currently miscalculating bandwidth and ceil values
for the default class
• T5865 (feature): Rewrite ipv6 pool section to ipv6 named pools in Accel-ppp services
3.2.66 2024-02-02
• T5739 (bug): Password recovery does not work if public keys are configured
• T5955 (feature): Rootless containers/set uid/gid for container
• T5941 (bug): [1.3.5 -> 1.4.0-RC1 Migration] Orphaned Configuration Nodes Cause
Issues
• T6003 (feature): Add 'show rpki as-number' and 'show rpki prefix'
• T5848 (feature): Add triple-isolate flow isolation option to CAKE QoS policy
3.2.67 2024-02-01
• T5995 (bug): Kernel NIC-drivers for Huawei NICs are not properly enabled
• T5978 (bug): ethernet: hw-tc-offload does not actually get enabled on the NIC
• T5979 (enhancment): Add configurable kernel boot parameters
• T5973 (bug): vrf: RTNETLINK answers: File exists
• T5967 (bug): Multi-hop BFD connections can't be established; please add minimum-ttl
option.
• T5619 (default): Update the Intel ixgbe driver due to issues with Intel X533
3.2.68 2024-01-31
3.2.69 2024-01-30
• T5980 (feature): Add image-tools support for configurable kernel boot options
3.2.70 2024-01-29
• T5988 (bug): image-tools: a check of valid image name is missing from 'add image'
• T5994 (bug): Fix typo in 'remote' module preventing 'add system image' via ftp
3.2.71 2024-01-26
3.2.72 2024-01-25
3.2.73 2024-01-22
3.2.74 2024-01-21
3.2.75 2024-01-20
3.2.76 2024-01-19
• T5897 (bug): VyOS with Cloud-init and VRF stucks at reboot/shutdown process
• T5554 (bug): Disable sudo for PAM RADIUS
• T4754 (default): Improvement: system login: show configured 2FA OTP key
• T5857 (bug): show interfaces wireless info
• T5841 (default): Remove old ssh-session-cleanup.service
• T5543 (bug): Fix source address handling in static joins
• T5884 (default): Minor description fix (op-mode: generate wireguard)
• T5781 (default): Add ability to add additional minisign keys
3.2.77 2024-01-18
3.2.78 2024-01-17
• T5923 (bug): Config mode system_console.py is not aware of revised GRUB file
structure
• T4658 (feature): Rename DPD action `hold` to `trap`
• T5932 (bug): 1.4-rolling-202304120317 to 1.4.0-rc1: dynamic dns migration fail
3.2.79 2024-01-16
• T5951 (bug): [1.4.0-RC2] show hardware dmi Operational Mode Command Broken
• T5937 (bug): [1.3.5 -> 1.4.0-RC1 Migration] IPv6 BGP Neighbor Peer Groups Missing /
Not Migrated
• T5889 (bug): Migration NAT 5-to-6 bug
• T5859 (bug): Invalid format of pool range in accel-ppp services
• T5842 (feature): Rewrite PPTP service to get_config_dict
• T5801 (feature): Rewrite L2TP service to get_config_dict
• T5688 (default): Create the same view of pool configuration for all accel-ppp
services
3.2.80 2024-01-15
3.2.81 2024-01-14
3.2.82 2024-01-12
3.2.83 2024-01-11
3.2.84 2024-01-10
3.2.85 2024-01-09
• T5898 (bug): Replace partprobe with partx due to unable to install VyOS
• T5838 (feature): Add Infiniband kernel modules
• T5785 (bug): API output of show container image broken
• T5410 (feature): Improve `utils.convert.convert_data()` to process all stdtypes
• T5269 (default): OpenVPN non-TLS site-to-site mode deprecation
• T5249 (feature): Add rollback-soft feature to rollback without a reboot
• T4944 (default): Prevent op mode functions from returning bare literals in raw
output
• T4910 (default): Rewrite the remote access VPN op mode in the new style
• T4470 (feature): Rewrite load-balancing wan to XML/Python
• T3763 (bug): wireguard checks if port already binding
• T3489 (bug): NUMA has been disabled for the past few years and no-one has noticed
• T3476 (feature): Update availability check
• T2845 (bug): BGP conf_mode unable to delete configuration with peer-group
• T2844 (bug): BGP conf_mode errors disable-send-community
• T2755 (default): Requirements for partial interface setup
• T2721 (enhancment): Set FQ-CoDel as the default queueing mechanism for every class
in Shaper
• T2511 (feature): Migrate vyatta-op-quagga to new XML format
• T2302 (default): Convert configuration scripts from executables to modules and use a
script runner
• T2281 (feature): DHCP and Static IPs on Same Interface
• T2216 (default): Containerized third-party applications for VyOS
• T2171 (feature): Unify creation and manipulation of interfaces
• T1759 (feature): Replacing Vyatta::Interface perl
• T2408 (enhancment): DHCP Relay upstream and downstream interfaces
• T1297 (feature): Add GARP settings to VRRP/keepalived
3.2.86 2024-01-08
3.2.87 2024-01-07
3.2.88 2024-01-06
3.2.89 2024-01-05
3.2.90 2024-01-04
3.2.91 2024-01-03
• T5880 (bug): verify_source_interface should not allow dynamic interfaces like ppp,
l2tp, ipoe or sstpc client interfaces
• T5879 (bug): tunnel: sourceing from dynamic pppoe0 interface will fail on reboots
• T4500 (bug): Missing firewall logs
3.2.92 2024-01-02
3.2.93 2024-01-01
• T5883 (bug): Preserve file ownership in /config subdirs on add system image
• T5474 (feature): Establish common file name pattern for XML conf mode commands
3.2.94 2023-12-30
• T5875 (bug): login: removing and re-adding a user keeps the home directory but UID
will change, thus SSH keys no longer work
• T5653 (feature): Command to display fingerprint
3.2.95 2023-12-29
3.2.96 2023-12-28
3.2.97 2023-12-25
• T5855 (feature): Migrate "set service lldp snmp enable" -> `set service lldp snmp"
• T5837 (bug): vyos.configdict.node_changed does not return keys per adding
• T5856 (bug): SNMP service removal fails
3.2.98 2023-12-24
3.2.99 2023-12-22
3.2.100 2023-12-21
• T5778 (bug): The show dhcp server leases operation mode command does not work as
expected
• T5775 (default): Migrated Firewall Global State Policy ineffective on latest
firewall zone config
• T5637 (bug): Firewall default-action log
• T5796 (bug): Openconnect - HTTPS security headers are missing
• T3580 (feature): Refactoring firewall ipv6 rule icmpv6
• T2898 (feature): Support NDP proxy
• T2229 (feature): PPPOE Default Queue type selection
3.2.101 2023-12-20
• T5823 (feature): Protocol BGP add default values for config dictionary
• T5798 (enhancment): reverse-proxy load-balancing service should support multiple
certificates for frontend
3.2.102 2023-12-19
3.2.103 2023-12-18
3.2.104 2023-12-15
3.2.105 2023-12-14
3.2.106 2023-12-13
3.2.107 2023-12-12
• T4704 (feature): Allow to set metric (MED) to rtt with rtt,+rtt or -rtt
• T5815 (enhancment): Add load_config module
• T5413 (default): Deny the opportunity to use one public/private key pair on both
wireguard peers.
3.2.108 2023-12-11
• T5741 (bug): WAN Load Balancing failover route tables aren't created
3.2.109 2023-12-10
3.2.110 2023-12-09
3.2.111 2023-12-08
• T5782 (enhancment): Use a single config mode script for https and http-api
• T5768 (enhancment): Remove auxiliary http-api.conf for simplification of http-api
config mode script
• T5809 (default): Enable GRUB support for gzip compressed kernels
3.2.112 2023-12-04
• T5769 (bug): VTI tunnels lose their v6 Link Local addresses when set down/up
3.2.113 2023-12-03
3.2.114 2023-11-30
3.2.115 2023-11-28
• T4276 (bug): IPsec peers dh-group negotiation issue with pfs enabled and multiple
proposals configured with IKEv1
3.2.116 2023-11-27
• T5763 (bug): Fix imprecise check for remote file name in vyos-load-config.py
• T5783 (feature): frr: smoketests must notice any daemon crash
3.2.117 2023-11-26
3.2.118 2023-11-25
• T5655 (bug): commit-archive: Ctrl+C should not eror out with stack trace, signal
should be cought
• T4946 (default): Rewrite "add system image" in the new op-mode
• T4454 (default): `install-image` should check free storage
3.2.119 2023-11-24
3.2.120 2023-11-23
3.2.121 2023-11-22
• T5767 (feature): Add reboot and poweroff the system via API
• T5729 (bug): Firewall, nat and policy route - Switch to valueless
• T5681 (feature): Interface match - Simplified and unified cli
• T4877 (bug): Need verification in using import vrf and import vpn, export vpn
commands
• T4021 (bug): Long commit time on bridge interface with 1-4094 allowed VLAN tags
• T5338 (feature): Add 'mpls bgp forwarding' feature
• T3818 (bug): BGP export route-map only works after bgpd restart
• T5590 (default): Firewall "log enable" logs every packet
• T5426 (default): Add exceptions in vici functions calls
3.2.122 2023-11-21
• T5762 (bug): http: api: smoketests fail as they can not establish IPv6 connection
to uvicorn backend server
3.2.123 2023-11-20
• T2816 (default): Rewrite IPsec scripts with the new XML/Python approach
3.2.124 2023-11-18
3.2.125 2023-11-16
3.2.126 2023-11-15
3.2.127 2023-11-13
3.2.128 2023-11-10
• T5727 (bug): validator: Use native URL validator instead of regex-based validator
3.2.129 2023-11-08
3.2.130 2023-11-07
3.2.131 2023-11-06
3.2.132 2023-11-05
3.2.133 2023-11-03
3.2.134 2023-11-02
3.2.135 2023-11-01
3.2.136 2023-10-31
3.2.137 2023-10-27
• T5652 (bug): Config migrate to image upgrade does not properly generate home
directory
• T4057 (bug): Commit time for deleting sflow configuration ~1.5 min
3.2.138 2023-10-26
3.2.139 2023-10-23
3.2.140 2023-10-22
• T5254 (bug): Modification of any interface setting sets MTU back to default when MTU
has been inherited from a bond
• T5671 (feature): vxlan: change port to IANA assigned default port
3.2.141 2023-10-21
3.2.142 2023-10-20
3.2.143 2023-10-19
3.2.144 2023-10-18
3.2.145 2023-10-17
3.2.146 2023-10-16
3.2.147 2023-10-14
• T5629 (bug): Policy local-route bug after migration to destination node address
3.2.148 2023-10-13
• T5227 (feature): mDNS reflector should allow additional domains to browse and allow
filtering services
• T5166 (feature): Remove local minisign package from build repo for 1.4
• T5118 (bug): Cleanup vestigial ntp completion script
• T5115 (default): Support custom port for name servers for forwarding zones
• T5113 (default): PDNS: Support custom port for DNS forwarders
• T5112 (feature): Enable support for Network Time Security (NTS) for chrony
• T5143 (enhancment): Apply constraint on powerdns forward-zones configuration
3.2.149 2023-10-12
• T5649 (bug): vyos-1x should generate XML cache after building command templates for
less cryptic error on typo
3.2.150 2023-10-10
3.2.151 2023-10-08
3.2.152 2023-10-06
• T5096 (feature): Change 'accept' firewall rule action from 'return' to 'accept'
• T5576 (feature): Add bgp remove-private-as all option
• T3506 (default): Migrate loadkey command to op-mode
3.2.153 2023-10-05
3.2.154 2023-10-04
3.2.155 2023-10-03
3.2.156 2023-10-01
3.2.157 2023-09-30
3.2.158 2023-09-28
3.2.159 2023-09-26
3.2.160 2023-09-25
3.2.161 2023-09-24
3.2.162 2023-09-23
3.2.163 2023-09-22
3.2.164 2023-09-20
3.2.165 2023-09-19
3.2.166 2023-09-18
3.2.167 2023-09-15
• T5581 (feature): Add "show ip nht" op-mode command (IPv4 nexthop tracking table)
3.2.168 2023-09-11
3.2.169 2023-09-10
3.2.170 2023-09-09
3.2.171 2023-09-08
• T5502 (bug): Firewall - wrong parser for inbound and/or outbound interface
• T5460 (feature): Firewall - remove config-trap
• T5450 (feature): Firewall interface group - Allow inverted matcher
• T4426 (default): Add arpwatch to the image
• T4356 (bug): DHCP v6 client only supports single interface configuration
3.2.172 2023-09-07
3.2.173 2023-09-06
3.2.174 2023-09-05
3.2.175 2023-09-04
• T5536 (bug): show dhcp client leases caues No module named 'vyos.validate'
• T5506 (bug): Container bridge interfaces do not have a link-local address
3.2.176 2023-09-03
• T5538 (bug): Change order within variable lb_config_tmpl to fit order of manpage and
fix some typos
• T4612 (feature): Support arbitrary netmasks in firewall rules
3.2.177 2023-08-31
• T5190 (feature): Cloud-Init cannot fetch Meta-data on machines where the main
Ethernet interface is not eth0
• T4895 (bug): Tag nodes are overwritten when configured by Cloud-Init from User-Data
• T4776 (bug): NVME storage is not detected properly during installation
• T5531 (feature): Containers add label option
• T5525 (default): Change dev.packages.vyos.net repo to rolling-packages.vyos.net
vyos-build:current uses
3.2.178 2023-08-30
3.2.179 2023-08-29
• T3940 (bug): DHCP client does not remove IP address when stopped by the
02-vyos-stopdhclient hook
• T3713 (default): Create a meta-package for user utilities
• T3339 (bug): Cloud-Init domain search setting not applied
• T3577 (bug): Generating vpn x509 key pair fails with command not found
3.2.180 2023-08-28
• T4745 (bug): CLI TAB issue with values with '-' at the beginning in conf mode
• T5472 (bug): NAT redirect should not require port
3.2.181 2023-08-27
3.2.182 2023-08-26
3.2.183 2023-08-25
3.2.184 2023-08-24
3.2.185 2023-08-23
• T5469 (default): Incorrect dependency set in the openvpn-dco package when building
VyOS for arm64
• T5387 (feature): dhcp6c: add a no release option
• T5491 (feature): Hostapd - AP-Mode - allow white-/blacklisting of Clients
• T4889 (default): Add nftables NAT REDIRECT [to localhost] to CLI
3.2.186 2023-08-22
• T5407 (bug): Static routes pointed to container networks fail to persist after
reboot
3.2.187 2023-08-20
• T5470 (bug): wlan: can not disable interface if SSID is not configured
3.2.188 2023-08-18
• T5488 (bug): System conntrack ignore does not take any effect
3.2.189 2023-08-17
• T4202 (bug): NFT: Zone policies fail to apply when "l2tp+" is in the interface list
• T5409 (feature): Add 'set interfaces wireguard wgX threaded'
• T5476 (feature): netplug: replace Perl helper scripts with a Python equivalent
• T5223 (bug): tunnel key doesn't clear
• T5490 (feature): login: add missing regex for home direcotry and radius server key
3.2.190 2023-08-16
• T5483 (bug): Residual dhcp-server test file causing zabbix-agent smoketest to fail
3.2.191 2023-08-15
• T5293 (feature): Support for Floating Rules (Global Firewall-Rules that are
automatically applied before all other Zone Rules)
• T5273 (default): Add op mode commands for displaying certificate details and
fingerprints
• T5270 (default): Make OpenVPN `tls dh-params` optional
3.2.192 2023-08-14
3.2.193 2023-08-12
• T5467 (bug): ospf(v3): removing an interface from the OSPF process does not clear
FRR configuration
3.2.194 2023-08-11
3.2.195 2023-08-10
3.2.196 2023-08-09
3.2.197 2023-08-07
• T5406 (bug): "update webproxy blacklists" fails when vrf is being configured
• T5302 (bug): QoS class with multiple matches generates one filter rule but expects
several rules
• T5266 (bug): QoS- HTB error when match with a dscp parameter for queue-type
'priority'
• T5071 (bug): QOS-Rewrite: DSCP match missing
3.2.198 2023-08-06
3.2.199 2023-08-05
3.2.200 2023-08-04
3.2.201 2023-08-03
3.2.202 2023-08-02
3.2.203 2023-08-01
3.2.204 2023-07-31
• T5421 (feature): Add arg to completion helper 'list_interfaces' to filter out vlan
subinterfaces
3.2.205 2023-07-29
3.2.206 2023-07-28
3.2.207 2023-07-27
• T5368 (feature): FastNetmon service ids ddos-protection add support sflow mode
3.2.208 2023-07-26
3.2.209 2023-07-25
• T5377 (feature): ospf: add graceful restart FRR feature (RFC 3623)
3.2.210 2023-07-21
• T5373 (bug): LLDP seems to be running even if its disabled on all interfaces
• T5328 (default): bgp: Incorrect warning showed for address-family configured with
neighbor as interface
• T5363 (bug): Bash history file does not exists after reboot and ony other file in
home directory
• T5385 (bug): reference_tree: catch parse error on non-transcluded files
• T5361 (bug): "monitor log" behaves like "show log"
3.2.211 2023-07-20
3.2.212 2023-07-19
3.2.213 2023-07-17
3.2.214 2023-07-16
3.2.215 2023-07-15
3.2.216 2023-07-14
3.2.217 2023-07-13
3.2.218 2023-07-12
3.2.219 2023-07-11
• T5314 (bug): QOS Default classes are not configured with correct qdisc
• T4862 (bug): webproxy domain-block does not work
• T4844 (bug): Incorrect permissions of the safeguard DB directory
• T4815 (bug): Fix various name server config issues
• T4810 (bug): Op-mode show/monitor log pppoe interface does not show any logs
• T4758 (feature): Rewrite show dhcp server to vyos.opmode format
• T4262 (bug): install image doesn't respect chosen root partition size
• T3810 (bug): webproxy squidguard rules don't work properly after rewriting to
python.
• T1928 (bug): Is the 'Welcome to VyOS' message when using SSH an information leak?
• T1877 (default): Feature Request: Allow NAT to use network and address groups
• T4813 (feature): L3VPN over GRE Tunnels
• T4943 (bug): Radius SSH login displays "permission denied" on 1.4 rolling release
• T4542 (default): route-map: "match prefix-len" incorrect behavior
• T4392 (default): Multiline login banner text reports error on commit
3.2.220 2023-07-10
• T5345 (bug): Error incorrectly raised in revised multi_to_list when tag node value
name == tag node name
• T3578 (bug): Prefix-List(6) update cause empty prefix-list(6)
• T762 (feature): Include rulseset in firewall
3.2.221 2023-07-06
3.2.222 2023-07-04
• T5333 (bug): Policy base routing PBR generetes incorrect rules with name POSTROUTING
• T5081 (feature): ISIS and OSPF syncronization with IGP-LDP sync
3.2.223 2023-07-03
3.2.224 2023-07-02
• T5332 (bug): Show policy route not working when no interface is configured
3.2.225 2023-07-01
3.2.226 2023-06-30
3.2.227 2023-06-29
• T5320 (enhancment): Add warning when entering config mode after a boot configuration
error
3.2.228 2023-06-28
3.2.229 2023-06-26
3.2.230 2023-06-25
• T5240 (bug): Service router-advert failed to start radvd with more then 3
name-servers
• T5312 (bug): Nonescaped special character in help text
3.2.231 2023-06-24
3.2.232 2023-06-22
• T5297 (default): Utility function to check if config under node has been changed
between revisions
3.2.233 2023-06-20
• T5300 (bug): verification of port availability can return false negative on boot
• T5248 (feature): Ability to load config via API in JSON format
3.2.234 2023-06-19
3.2.235 2023-06-18
• T5256 (bug): QoS expects protocol number but not protocol name
3.2.236 2023-06-13
• T5258 (bug): git Actions use ubuntu-22.04 instead of deprecated ubuntu-18.04 for PR
conflicts checker
• T5222 (feature): Add load-balancing reverse-proxy based on haproxy
• T5213 (feature): Accel-ppp sending accounting interim updates acct-interim-interval
option
• T5171 (feature): Use XML for conf-mode "load-balancing wan" instead of legacy
templates
3.2.237 2023-06-12
3.2.238 2023-06-10
3.2.239 2023-06-09
• T5253 (bug): MPLS config removed at boot when wireguard interfaces present
3.2.240 2023-06-05
3.2.241 2023-06-02
• T5252 (bug): Route distinguisher and route targets changing upon adding interface to
new VRF
• T5251 (bug): Uncaught errors for functions delete/delete_value in Python module
configtree.py
3.2.242 2023-06-01
• T5127 (bug): VPNv4/VPNv6 routes are not reinstalled following link flap
3.2.243 2023-05-28
3.2.244 2023-05-25
3.2.245 2023-05-24
3.2.246 2023-05-23
3.2.247 2023-05-22
3.2.248 2023-05-21
3.2.249 2023-05-17
• T5226 (default): Deduplicate and standardize validators and constraints for hostname
and IP address
• T5225 (bug): BGP allowas-in unusable
• T5208 (bug): Failed to start nvmf-autoconnect.service during the boot
3.2.250 2023-05-16
3.2.251 2023-05-15
3.2.252 2023-05-12
3.2.253 2023-05-10
• T5209 (bug): dhclient load-balancing exit hook 04-dhcp-wanlb returned non-zero exit
status
• T5065 (bug): Mixing `destination port xxx` and `destination group port-group yyy` in
firewall rules doesn't work, but can be commited
• T5060 (feature): add a VRRP 'maintenance mode'
3.2.254 2023-05-09
3.2.255 2023-05-06
3.2.256 2023-05-05
3.2.257 2023-05-04
3.2.258 2023-05-03
3.2.259 2023-05-02
• T5042 (bug): Command 'show vpn ipsec remote-access' does not work
3.2.260 2023-04-27
3.2.261 2023-04-25
• T5179 (bug): multi nodes defined in XML are not properly represented as list in
get_config_dict()
3.2.262 2023-04-17
3.2.263 2023-04-13
3.2.264 2023-04-11
3.2.265 2023-04-10
3.2.266 2023-04-07
• T5149 (bug): op-mode openvpn should not raise error in case interface is disabled
3.2.267 2023-04-06
3.2.268 2023-04-05
3.2.269 2023-04-04
3.2.270 2023-04-03
• T5139 (feature): IKE life-time should start from 0 for disable rekey
• T4173 (bug): Wan Load Balancing - Error on firewall NAT rules
3.2.271 2023-04-02
3.2.272 2023-04-01
3.2.273 2023-03-31
3.2.274 2023-03-30
3.2.275 2023-03-29
3.2.276 2023-03-28
• T5043 (feature): Need to create reset command for IKEv2 remote-access vpn
connections
3.2.277 2023-03-27
• T5099 (feature): IPoE server add option 'next-pool' for named ip pools
• T5106 (feature): Extend generation of API client requests to configsession native
functions and composite requests
• T5104 (bug): DHCP default route issues with static routes in VRFs
• T5079 (feature): xml: schema extension to support defaultValues on tagNodes
• T5114 (feature): bgp: implement new CLI commands introduced in FRR 8.5
3.2.278 2023-03-23
3.2.279 2023-03-22
• T5068 (feature): Generate op-mode API client requests along with schema generation
3.2.280 2023-03-21
3.2.281 2023-03-20
3.2.282 2023-03-19
3.2.283 2023-03-17
• T5092 (bug): IPoE-server named pool must not rely on the authentication type
• T5091 (bug): IPoE server with RADIUS authentication does not verify radius
configuration
3.2.284 2023-03-16
3.2.285 2023-03-13
• T5074 (bug): Show IPSEC SA failed if remote access IKEv2 vpn is used.
• T4973 (bug): show dhcp server leases error for lease time 4294967295
3.2.286 2023-03-11
3.2.287 2023-03-09
• T5066 (bug): Different GRE tunnel but same tunnel keys error
• T4952 (feature): Improve interface completion helper CLI experience
3.2.288 2023-03-08
• T4381 (default): OpenVPN: Add "Tunnel IP" column in "show openvpn server"
operational command
• T4872 (bug): Op-mode show openvpn misses a case when parsing for tunnel IP
3.2.289 2023-03-07
• T2838 (bug): Ethernet device names changing, multiple hw-id being added
• T5051 (feature): Use Literal types to provide op-mode CLI choices and API enums
• T4900 (default): Cache intermediary results of get_config_diff in Config instance
3.2.290 2023-03-05
3.2.291 2023-03-03
3.2.292 2023-03-02
3.2.293 2023-03-01
• T5015 (bug): Invalid format character error at hfsc class settings help text
3.2.294 2023-02-28
• T5029 (feature): Nginx change default root directory and fix regex
• T5025 (bug): Time-zone validation failed
• T4955 (bug): Openconnect radiusclient.conf generating with extra authserver
• T4843 (feature): Command-line arguments in container config
• T4219 (feature): support incoming-interface (iif) in local PBR
• T3903 (bug): Containers: after command "reboot" the host system will reboot after
1.5 minutes
3.2.295 2023-02-27
3.2.296 2023-02-26
3.2.297 2023-02-25
• T5008 (bug): MACsec CKN of 32 chars is not allowed in CLI, but works fine
• T5007 (bug): Interface multicast setting is invalid
• T5027 (bug): OpenVPN options and site-to-site cannot pass smoketest
• T4978 (bug): KeyError: 'memory' container_config['memory'] on upgrading to 1.
4-rolling-202302041536
• T5034 (bug): Migrate multicast CLI node to valueLess
• T4948 (feature): pppoe: add CLI option to allow definition of host-uniq flag
3.2.298 2023-02-24
3.2.299 2023-02-23
• T5013 (feature): Extend accelppp.py op-mode to get subnet start stop info from
config
• T5002 (feature): Add uk (United Kingdom) keymap
3.2.300 2023-02-22
3.2.301 2023-02-21
3.2.302 2023-02-20
• T5005 (feature): Skip user authentication for PPPoE Server with noauth option
3.2.303 2023-02-16
3.2.304 2023-02-15
3.2.305 2023-02-14
• T4968 (bug): VPN IPsec check dpd and close action for empty values
• T1993 (feature): Extended pppoe rate-limiter
3.2.306 2023-02-13
3.2.307 2023-02-12
3.2.308 2023-02-11
3.2.309 2023-02-10
3.2.310 2023-02-07
3.2.311 2023-02-01
3.2.312 2023-01-31
3.2.313 2023-01-30
3.2.314 2023-01-29
3.2.315 2023-01-28
• T4961 (bug): Uncaught configtree error allows ntp migration 1-to-2 to fail silentlly
on config.boot.default
3.2.316 2023-01-27
3.2.317 2023-01-26
3.2.318 2023-01-25
3.2.319 2023-01-24
3.2.320 2023-01-23
3.2.321 2023-01-22
3.2.322 2023-01-21
• T4799 (bug): PowerDNS >= 4.7 does not get reloaded by vyos-hostsd
• T4878 (bug): Any interface bonding changes cause interface flapping
• T4387 (default): Create additional smoketests for multiwan PBR & load-balanced
configurations
3.2.323 2023-01-20
3.2.324 2023-01-17
3.2.325 2023-01-15
• T4832 (feature): dhcp: Add IPv6-only dhcp option support (RFC 8925)
• T4937 (feature): ocserv: upgrade package to version 1.1.6
• T4918 (bug): Odd show interface behavior
• T3008 (feature): Migrate from ntpd to chronyd
3.2.326 2023-01-13
3.2.327 2023-01-12
3.2.328 2023-01-10
3.2.329 2023-01-09
3.2.330 2023-01-08
3.2.331 2023-01-07
3.2.332 2023-01-05
3.2.333 2023-01-04
3.2.334 2023-01-03
3.2.335 2023-01-02
3.2.336 2022-12-31
3.2.337 2022-12-30
3.2.338 2022-12-28
3.2.339 2022-12-26
3.2.340 2022-12-25
3.2.341 2022-12-24
3.2.342 2022-12-23
3.2.343 2022-12-21
• T4887 (bug): Schema generation from op-mode functions should set default 'false' on
boolean arguments
3.2.344 2022-12-18
3.2.345 2022-12-15
3.2.346 2022-12-14
3.2.347 2022-12-12
• T4861 (feature): Openconnect restart on adding users - Aborts all active connections
3.2.348 2022-12-09
• T4865 (bug): container impossible to generate local image from a file if it requires
install some pkgs
3.2.349 2022-12-05
3.2.350 2022-12-04
3.2.351 2022-12-02
3.2.352 2022-12-01
3.2.353 2022-11-29
3.2.354 2022-11-27
3.2.355 2022-11-24
• T4794 (bug): show firewall name <name> - Can't use .items() on a list
• T4714 (feature): Delete unused ipset from the filecaps
• T3541 (bug): Route Map large community set additive is missing
3.2.356 2022-11-23
• T4836 (feature): Kernel: enable new features like switchdev, ESP in TCP and HSR
• T4835 (bug): SNMPD configuration incorrect for IPv6
• T4819 (feature): Allow printing Warning messages in multiple lines with \n
• T4807 (feature): Need to fix traceroute help completion
• T4660 (feature): Reorganize route map set community CLI
• T4526 (bug): keepalived-fifo.py unable to load config
3.2.357 2022-11-22
3.2.358 2022-11-21
3.2.359 2022-11-20
3.2.360 2022-11-19
• T4826 (bug): Wrong key type is used for SSH SK public keys
• T4720 (feature): Ability to configure SSH HostKeyAlgorithms
• T4828 (default): Raise appropriate op-mode errors in ipsec.py 'reset_peer'
3.2.361 2022-11-18
• T4821 (bug): Correct calling of config mode script dependencies from firewall.py
3.2.362 2022-11-17
3.2.363 2022-11-15
3.2.364 2022-11-12
3.2.365 2022-11-09
3.2.366 2022-11-08
3.2.367 2022-11-06
3.2.368 2022-11-05
3.2.369 2022-11-01
• T4764 (bug): NAT tables vyos_nat and vyos_static_nat not deleting after deleting nat
• T4177 (bug): Strip-private doesn't work for service monitoring
3.2.370 2022-10-31
3.2.371 2022-10-29
3.2.372 2022-10-28
3.2.373 2022-10-27
3.2.374 2022-10-26
3.2.375 2022-10-25
3.2.376 2022-10-24
• T4772 (default): Return list of dicts in 'raw' output of route.py instead of dict
with redundant information
3.2.377 2022-10-23
• T3723 (bug): op-mode IPSec show vpn ipsec sa output with underscores
3.2.378 2022-10-21
• T4768 (default): Change name of api child node from 'gql' to 'graphql'
3.2.379 2022-10-18
3.2.380 2022-10-17
3.2.381 2022-10-14
3.2.382 2022-10-13
• T4746 (bug): Monitoring nft. table vyos_filter by default does not exist but
telegraf checks this table
• T4744 (bug): BGP directly connected neighbors don't compatible with ebgp-multihop
• T4716 (feature): SSH ability to configure RekeyLimit
• T4343 (default): Expose powerdns network-timeout for service dns forwarding
• T4312 (bug): Telegraf configuration doesn't accept IPs for URL
• T4274 (default): Extend OpenConnect RADIUS Timeout to Permit 2FA Entry
3.2.383 2022-10-12
• T4747 (bug): Monitoring influxdb template input exec plugin does not work
• T4740 (bug): Show conntrack table ipv6 fail
• T4730 (bug): Conntrack-sync error - listen-address is not the correct type in config
as it should be
3.2.384 2022-10-11
• T4742 (bug): Autocomplete in policy route rule x set table / does not show the
tables created in the static protocols
• T4741 (bug): set firewall zone Local local-zone failed
• T4680 (bug): Telegraf prometheus-client listen-address invalid format
3.2.385 2022-10-10
3.2.386 2022-10-09
3.2.387 2022-10-08
3.2.388 2022-10-07
3.2.389 2022-10-04
3.2.390 2022-09-29
3.2.391 2022-09-27
3.2.392 2022-09-21
3.2.393 2022-09-20
3.2.394 2022-09-17
3.2.395 2022-09-16
3.2.396 2022-09-15
• T4679 (bug): OpenVPN site-to-site incorrect check for IPv6 local and remote address
• T4691 (feature): Upgrade Linux Kernel to latest 5.15.y train
• T4630 (bug): Prevent attempts to use the same interface as a source interface for
pseudo-ethernet and MACsec at the same time
• T4696 (default): Extend bgp parameters for bgp bestpath peer-type multipath-relax
3.2.397 2022-09-12
3.2.398 2022-09-09
3.2.399 2022-09-06
3.2.400 2022-09-05
3.2.401 2022-09-01
3.2.402 2022-08-31
3.2.403 2022-08-29
3.2.404 2022-08-26
3.2.405 2022-08-25
3.2.406 2022-08-24
3.2.407 2022-08-23
3.2.408 2022-08-22
• T4089 (bug): Show nat destination rules shows ip address instead of interface 'any'
• T4632 (bug): VLAN-aware bridge not working
• T4637 (feature): Upgrade to podman 4.2.0
3.2.409 2022-08-20
• T4596 (bug): "show openconnect-server sessions" command does not work in the
openconnect module
3.2.410 2022-08-19
3.2.411 2022-08-18
3.2.412 2022-08-17
3.2.413 2022-08-16
• T4592 (bug): macsec: can not create two interfaces using the same source-interface
• T4584 (bug): hostap: create custom package build
• T4413 (default): Add an API endpoint with basic system stats
• T4537 (bug): MACsec not working with cipher gcm-aes-256
3.2.414 2022-08-15
3.2.415 2022-08-14
• T4579 (bug): bridge: can not delete member interface CLI option when VLAN is
enabled
• T4421 (default): Add support for floating point numbers in the numeric validator
• T3507 (bug): Bond with mode LACP show u/u in show interfaces even if peer is not
configured
3.2.416 2022-08-12
• T4603 (feature): Need a config option to specify NAS-IP-Address for vpn l2tp
3.2.417 2022-08-10
3.2.418 2022-08-08
• T4586 (feature): Add to NAT66: SNAT destination address and DNAT source address.
3.2.419 2022-08-04
3.2.420 2022-08-02
3.2.421 2022-08-01
3.2.422 2022-07-31
• T4580 (bug): Handle the case of op-mode file names with hyphens in GraphQL schema/
resolver generation
3.2.423 2022-07-30
• T4575 (feature): vyos.utill add new wrapper "rc_cmd" to get the return code and
output
• T4562 (feature): Rewrite show vrf to new format
• T4545 (feature): Rewrite show nat source rules
• T4543 (bug): Show source nat statistics shows incorrect interface
• T4503 (default): Prevent op mode scripts from restarting services if there's a
commit in progress
• T4411 (feature): Add migration for service monitoring telegraf influxdb
3.2.424 2022-07-29
3.2.425 2022-07-28
3.2.426 2022-07-27
• T4571 (bug): Sflow with vrf configured does not use vrf to validate agent-address IP
from vrf-configured interfaces
• T4552 (bug): Unable to reset IPsec IPv6 peer
3.2.427 2022-07-26
3.2.428 2022-07-25
3.2.429 2022-07-22
3.2.430 2022-07-21
3.2.431 2022-07-20
3.2.432 2022-07-18
• T4523 (feature): OP-mode Extend conntrack output to get marks, zones and directions
• T4228 (bug): bond: OS error thrown when two bonds use the same member
• T4539 (feature): qat: update Intel QuickAssist release version 1.7.L.4.16.0-00017
• T4534 (bug): bond: bridge: error out if member interface is assigned to a VRF
instance
• T4525 (bug): Delete interface from VRF and add it to bonding error
• T4522 (feature): bond: add ability to specify mii monitor interval via CLI
• T4535 (feature): FRR: upgrade to stable/8.3 version
• T4521 (bug): bond: ARP monitor interval is not configured despite set via CLI
• T4540 (feature): firmware: update to Linux release 20220708
3.2.433 2022-07-17
• T4028 (bug): FRR 8.1 routes not being applied to routing table after reboot if an
interface has 2 ip addresses
3.2.434 2022-07-15
3.2.435 2022-07-14
• T4491 (bug): Use empty string for internal name of root node of config_tree
3.2.436 2022-07-13
3.2.437 2022-07-12
3.2.438 2022-07-10
• T3836 (bug): Setting a default IPv6 route while getting IPv4 gateway via DHCP
removes the IPv4 gateway
3.2.439 2022-07-09
3.2.440 2022-07-07
• T4456 (bug): NTP client in VRF tries to bind to interfaces outside VRF, logs many
messages
• T4509 (feature): Feature Request: DNS64
3.2.441 2022-07-06
3.2.442 2022-07-05
3.2.443 2022-07-04
3.2.444 2022-07-01
3.2.445 2022-06-29
3.2.446 2022-06-28
3.2.447 2022-06-27
• T4484 (default): Firewall op-mode summary doesn't correctly handle address group
containing ranges
3.2.448 2022-06-25
3.2.449 2022-06-22
3.2.450 2022-06-20
3.2.451 2022-06-18
3.2.452 2022-06-17
• T4209 (bug): Firewall incorrect handler for recent count and time
3.2.453 2022-06-16
3.2.454 2022-06-15
3.2.455 2022-06-12
• T4420 (feature): Feature Request: ocserv: show configured 2FA OTP key
• T4380 (default): Feature Request: ocserv: 2FA OTP key generator in VyOS CLI
3.2.456 2022-06-10
3.2.457 2022-06-09
3.2.458 2022-06-08
3.2.459 2022-05-31
3.2.460 2022-05-30
3.2.461 2022-05-29
3.2.462 2022-05-28
3.2.463 2022-05-26
3.2.464 2022-05-25
3.2.465 2022-05-21
3.2.466 2022-05-20
3.2.467 2022-05-19
3.2.468 2022-05-17
3.2.469 2022-05-16
3.2.470 2022-05-12
3.2.471 2022-05-11
3.2.472 2022-05-10
3.2.473 2022-05-07
• T4361 (bug): `vyos.config.exists()` does not work for nodes with multiple values
• T4354 (bug): Slave interfaces fall out from bonding during configuration change
• T4419 (feature): vrf: support to disable IP forwarding within a given VRF
3.2.474 2022-05-06
3.2.475 2022-05-05
3.2.476 2022-05-03
3.2.477 2022-05-01
• T4369 (bug): OpenVPN: daemon not restarted on changes to "openvpn-option" CLI node
• T4363 (bug): salt-minion: default mine_interval option is not set
• T4353 (feature): Add Jinja2 linter to vyos-1x build process
3.2.478 2022-04-29
3.2.479 2022-04-28
• T4400 (bug): Container OP mode has delete where show and update should be
3.2.480 2022-04-27
3.2.481 2022-04-26
3.2.482 2022-04-25
• T4390 (feature): op-mode: extend "show log" and "monitor log" with additional
daemons/subsystems to read journalctl logs
• T4391 (bug): PPPoE: IPv6 not working after system boot
3.2.483 2022-04-24
• T4342 (bug): "show ip ospf neighbor address x.x.x.x" gives "unknown command" error
3.2.484 2022-04-23
3.2.485 2022-04-22
• T4389 (feature): dhcp: add vendor option support for Ubiquity Unifi controller
3.2.486 2022-04-21
• T4384 (feature): pppoe: replace default-route CLI option with common CLI nodes
already present for DHCP
3.2.487 2022-04-20
• T4345 (bug): New firewall code does not accept "rate/time interval" syntax used in
old config
• T4231 (feature): Feature Request: ocserv: 2FA (password+OTP) support in
Openconnect
3.2.488 2022-04-19
• T4379 (bug): PPPoE: default-route lost after applying additional static routes
• T4344 (bug): DHCP statistics not matching, conf-mode generates incorrect pool name
with dash
• T4268 (bug): Elevated LA while using VyOS monitoring feature
3.2.489 2022-04-18
3.2.490 2022-04-15
3.2.491 2022-04-13
• T4333 (feature): Jinja2: add plugin to test if a variable is defined and not none
to reduce template complexity
3.2.492 2022-04-08
• T4331 (bug): IPv6 link local addresses are not configured when an interface is in a
VRF
• T4347 (default): Return complete and consistent error codes from HTTP API
• T4339 (bug): wwan: tab-completion results in "No such file or directory" if there
is no WWAN interface
• T4338 (bug): wwan: changing interface description should not trigger reconnect
• T4324 (bug): wwan: check alive script should only be run via cron if a wwan
interface is configured at all
3.2.493 2022-04-07
3.2.494 2022-04-06
• T4308 (feature): Op-comm "Show log frr" to view specific protocol logs
3.2.495 2022-04-04
• T4329 (bug): Bgp policy route-map bug with set several extcommunity rt
3.2.496 2022-04-02
3.2.497 2022-04-01
3.2.498 2022-03-31
3.2.499 2022-03-29
3.2.500 2022-03-26
• T4321 (default): Allow BGP neighbors between different VIFs on the same VyOS
3.2.501 2022-03-24
• T4301 (bug): The "arp-monitor" option in bonding interface settings does not work
• T4294 (bug): Adding a new openvpn-option does not restart the OpenVPN process
• T4290 (bug): BGP source-interface fails to commit
• T4230 (bug): OpenVPN server configuration deleted after reboot when using a VRRP
virtual-address
3.2.502 2022-03-23
3.2.503 2022-03-21
3.2.504 2022-03-20
• T4298 (default): vyos-vm-images: fix ansible group name and remove obsolete empty
command
3.2.505 2022-03-18
3.2.506 2022-03-15
3.2.507 2022-03-14
3.2.508 2022-03-12
• T4296 (bug): Interface config injected by Cloud-Init may interfere with VyOS native
• T4265 (feature): Add op-mode for bgp flowspec state and routes
3.2.509 2022-03-11
• T4297 (bug): Interface configuration saving fails for ice/iavf based interfaces
because they can't change speed/duplex settings
3.2.510 2022-03-09
3.2.511 2022-03-05
3.2.512 2022-03-03
• T4283 (feature): Add support to "reject" routes - emit an ICMP unreachable when
matched
3.2.513 2022-03-01
3.2.514 2022-02-28
3.2.515 2022-02-26
3.2.516 2022-02-24
3.2.517 2022-02-23
3.2.518 2022-02-21
3.2.519 2022-02-20
3.2.520 2022-02-19
3.2.521 2022-02-17
3.2.522 2022-02-16
3.2.523 2022-02-15
• T4160 (bug): Firewall - Error in rules that matches everything except something
• T3006 (bug): Accel-PPP & vlan-mon config get invalid VLAN
• T3494 (bug): DHCPv6 leases traceback when PD using
• T1292 (bug): Issues while deleting all rules from a firewall
3.2.524 2022-02-13
3.2.525 2022-02-11
3.2.526 2022-02-08
3.2.527 2022-02-07
• T4233 (bug): ssh: sync regex for allow/deny usernames to "system login"
3.2.528 2022-02-06
• T4223 (bug): policy route cannot have several entries with the same table
• T4216 (bug): Firewall: can't use negated groups in firewall rules
• T4178 (bug): policy based routing tcp flags issue
• T4164 (bug): PBR: network groups (as well as address and port groups) don't resolve
in `nftables_policy.conf`
• T3970 (feature): Add support for op-mode PKI direct install into an active config
session
• T3828 (bug): ipsec: Subtle change in "pfs enable" behavior from equuleus -> sagitta
3.2.529 2022-02-05
• T4226 (bug): VRRP transition-script does not work for groups name which contains
-(minus) sign
3.2.530 2022-02-04
3.2.531 2022-02-03
• T4218 (bug): firewall: rule name is not allowed to start with a number
• T3643 (bug): show vpn ipsec sa doesn't show tunnels in "down" state
3.2.532 2022-02-01
• T4224 (bug): Ethernet interfaces configured for DHCP not working on latest rolling
snapshot (vyos-1.4-rolling-202201291849-amd64.iso)
• T4225 (bug): Performance degration with latest rolling release
• T4220 (bug): Commit broke dhclient 78b247b724f74bdabab0706aaa7f5b00e5809bc1
• T4138 (bug): NAT configuration allows to set incorrect port range and invalid port
3.2.533 2022-01-28
• T4184 (bug): NTP allow-clients address doesn't work it allows to use ntp server for
all addresses
• T4217 (bug): firewall: port-group requires protocol to be set - but not in VyOS 1.3
3.2.534 2022-01-27
3.2.535 2022-01-25
3.2.536 2022-01-24
3.2.537 2022-01-23
3.2.538 2022-01-21
3.2.539 2022-01-20
• T4171 (bug): Interface config migration error on 1.2.8 -> 1.4 upgrade
3.2.540 2022-01-19
3.2.541 2022-01-18
• T4159 (bug): Empty firewall group (address, network & port) generates invalid
nftables config, commit fails
• T4155 (bug): PBR: `set table main` fails in `firewall.py` with newer rolling
releases
• T3873 (feature): Zone based Firewall - Filter traffic in same zone
• T3286 (feature): Switch the firewall from iptables to nftables
• T292 (feature): [ZBF] Allow filtering intra zone traffic
3.2.542 2022-01-17
• T3164 (bug): console-server ssh does not work with RADIUS PAM auth
3.2.543 2022-01-15
3.2.544 2022-01-14
3.2.545 2022-01-13
3.2.546 2022-01-12
• T4174 (bug): Validation fails when entering port range with upper port 65535
• T4162 (bug): VPN ipsec ike-group - Incorrect value help for ikev2-reauth
• T4161 (bug): Policy route-map - Incorrect value help for local preference
• T4152 (bug): NHRP shortcut-target holding-time does not work
3.2.547 2022-01-11
3.2.548 2022-01-10
• T3299 (bug): Allow the web proxy service to listen on all IP addresses
• T3115 (feature): Add support for firewall on L3 VIF bridge interface
3.2.549 2022-01-09
3.2.550 2022-01-08
3.2.551 2022-01-07
3.2.552 2022-01-06
• T4135 (bug): Declare zone policy firewall without local zone errors
• T4130 (bug): Firewall state policy errors chain
• T4141 (bug): Set high-availability vrrp sync-group without members error
3.2.553 2022-01-04
• T4134 (bug): Incorrect firewall protocol completion help uppercase and duplicates
• T4132 (bug): Impossible to show a specific firewall group
3.2.554 2022-01-03
• T4126 (feature): Ability to set priority to site to site IPSec vpn tunnels
• T4052 (bug): Validator return traceback on VRRP configuration with the script path
not in config dir
• T4128 (bug): keepalived: Upgrade package to add VRF support
3.2.555 2021-12-31
• T4081 (bug): VRRP health-check script stops working when setting up a sync group
3.2.556 2021-12-30
3.2.557 2021-12-29
• T4111 (bug): IPSec generates wrong configuration colons for IPv6 peers
• T4023 (feature): Add grepcidr or similar functionality
• T4086 (default): system login banner is not removed on deletion.
3.2.558 2021-12-28
• T3380 (bug): "show vpn ike sa" does not display IPv6 peers
3.2.559 2021-12-27
3.2.560 2021-12-26
• T4104 (bug): RAID1: "add raid md0 member sda1" does not restore boot sector
• T4108 (default): OSPFv3: add support for auto-cost parameter
• T4107 (default): OSPFv3: add support for "default-information originate"
3.2.561 2021-12-25
3.2.562 2021-12-24
3.2.563 2021-12-23
3.2.564 2021-12-22
• T3678 (bug): VyOS 1.4: Invalid error message while deleting ipsec vpn configuration
• T3356 (feature): Script for remote file transfers
3.2.565 2021-12-21
• T4083 (bug): Cluster heartbeat doesn't start b.c lack of directory /run/heartbeat/
• T4070 (bug): NATv4 : inbound-interface type "any" is missing.
• T4053 (bug): VRRP impossible to set scripts out of the /config directory
• T3931 (bug): SSTP doesn't work after rewriting to PKI
3.2.566 2021-12-20
3.2.567 2021-12-19
3.2.568 2021-12-17
• T4059 (bug): VRRP sync-group transition script does not persist after reboot
3.2.569 2021-12-16
3.2.570 2021-12-15
• T4077 (bug): op-mode: bfd: drop "show protocols bfd" in favour of "show bfd"
• T4073 (bug): "show protocols bfd peer <>" shows incorrect peer information.
3.2.571 2021-12-14
3.2.572 2021-12-12
3.2.573 2021-12-10
• T4068 (feature): Python: ConfigError should insert line breaks into the error
message
3.2.574 2021-12-09
3.2.575 2021-12-07
3.2.576 2021-12-06
3.2.577 2021-12-04
3.2.578 2021-12-02
3.2.579 2021-12-01
• T3695 (bug): OpenConnect reports commit success when ocserv fails to start due to
SSL cert/key file issues
3.2.580 2021-11-30
3.2.581 2021-11-29
• T3946 (enhancment): Automatically resize the root partition if the drive has extra
space
3.2.582 2021-11-28
3.2.583 2021-11-27
• T3755 (feature): ospf: adjust to new FRR 8 syntax where "no passive-interface "
moved to interface section
• T3753 (feature): frr: upgrade to stable/8.1 release train
3.2.584 2021-11-26
• T3978 (bug): containers add network without declaring prefix raise ConfigError
3.2.585 2021-11-25
3.2.586 2021-11-24
3.2.587 2021-11-23
• T3990 (bug): WATCHFRR: crashlog and per-thread log buffering unavailable (due to
files left behind in /var/tmp/frr/ after reboot)
3.2.588 2021-11-20
3.2.589 2021-11-19
• T4003 (bug): API for "show interfaces ethernet" does not include the interface
description
• T4011 (bug): ethernet: deleting interface should place interface in admin down
state
3.2.590 2021-11-18
3.2.591 2021-11-17
3.2.592 2021-11-15
• T3994 (bug): VRF: unable to delete vrf when name contains numbers, hyphen or
underscore
• T3960 (bug): FRR Misconfig when using multiple VRF VNI
• T3724 (feature): Allow setting host-name in l2tp section of accel-ppp
• T645 (feature): Allow multiple prefixes in ipsec tunnel
3.2.593 2021-11-10
3.2.594 2021-11-09
3.2.595 2021-11-07
3.2.596 2021-11-06
3.2.597 2021-11-05
3.2.598 2021-11-04
3.2.599 2021-11-03
3.2.600 2021-11-01
3.2.601 2021-10-31
3.2.602 2021-10-29
3.2.603 2021-10-28
• T3951 (bug): After resetting vti ipsec tunnel old child SA still active
• T3941 (bug): "show vpn ipsec sa" shows established time of parent SA not child SA's
• T3916 (feature): Add additional Linux capabilities to container configuration
3.2.604 2021-10-27
• T3944 (bug): VRRP fails over when adding new group to master
3.2.605 2021-10-22
3.2.606 2021-10-21
3.2.607 2021-10-20
3.2.608 2021-10-19
• T3396 (bug): syslog can't be configured with an ipv6 literal destination in 1.2.x
3.2.609 2021-10-18
• T3002 (default): VRRP change on IPSec interface causes packet routing issues
3.2.610 2021-10-17
3.2.611 2021-10-16
• T3879 (bug): GPG key verification fails when upgrading from a 1.3 beta version
3.2.612 2021-10-15
3.2.613 2021-10-14
3.2.614 2021-10-13
3.2.615 2021-10-12
• T3216 (bug): Removal of restricted-shell broke configure mode for RADIUS users
• T3881 (bug): Wrong description for container section restart
• T3868 (bug): Regex and/or wildcard not accepted with large-community-list
• T3701 (bug): ipoe server fails to start when configuring radius dynamic-author on
ipoe
3.2.616 2021-10-10
• T3750 (bug): pdns-recursor 4.4 issue with dont-query and private DNS servers
• T3885 (default): dhcpv6-pd: randomly generated DUID is not persisted
• T3899 (enhancment): Add support for hd44780 LCD displays
3.2.617 2021-10-09
• T3894 (bug): Tunnel Commit Failed if system does not have `eth0`
3.2.618 2021-10-08
3.2.619 2021-10-05
3.2.620 2021-10-04
• T3888 (bug): Incorrect warning when poweroff command executed from configure mode.
• T3890 (feature): dhcp(v6): provide op-mode commands to retrieve both server and
client logfiles
• T3889 (feature): Migrate to journalctl when reading daemon logs
3.2.621 2021-10-03
3.2.622 2021-10-02
3.2.623 2021-09-30
3.2.624 2021-09-28
3.2.625 2021-09-27
3.2.626 2021-09-26
• T3860 (bug): Error on pppoe, tunnel and wireguard interfaces for IPv6 EUI64
addresses
• T3857 (feature): reboot: send wall message to all users for information
• T3867 (bug): vxlan: multicast group address is not validated
• T3859 (bug): Add "log-adjacency-changes" to ospfv3 process
• T3826 (bug): PKI: op-mode - do input validation when listing certificates
3.2.627 2021-09-25
• T3657 (default): BGP neighbors ipv6 not able to establish with IPv6 link-local
addresses
3.2.628 2021-09-23
• T3850 (bug): Dots are no longer allowed in SSH public key names
3.2.629 2021-09-21
3.2.630 2021-09-20
3.2.631 2021-09-19
3.2.632 2021-09-18
• T3831 (bug): External traffic stops routing when IPSEC tunnel comes up with
interface vti0
• T1968 (default): Allow multiple static routes in dhcp-server
• T3838 (feature): dhcp-server - sync cli for name-servers to other subsystems
• T3839 (feature): dhcp-server: Allow configuration of a DNS server and domain name
on the shared-network level
3.2.633 2021-09-17
• T3830 (bug): ipsec: remote-id no longer included in IKE AUTH if not explicitly
specified
3.2.634 2021-09-11
• T3402 (feature): Add VyOS programming library for operational level commands
3.2.635 2021-09-10
• T3802 (bug): Commit fails if ethernet interface doesn't support flow control
• T3819 (bug): Upgrade Salt Stack 3002.3 -> 3003 release train
• T915 (feature): MPLS Support
3.2.636 2021-09-09
3.2.637 2021-09-07
• T1894 (bug): FRR config not loaded after daemons segfault or restart
• T3807 (bug): Op Command "show interfaces wireguard" does not show the output
3.2.638 2021-09-06
• T3806 (bug): Don't set link local ipv6 address if MTU less then 1280
• T3803 (default): Add source-address option to the ping CLI
• T3431 (bug): Show version all bug
• T2920 (bug): Commit crash when adding the second mGRE tunnel with the same key
3.2.639 2021-09-05
• T3804 (feature): cli: Migrate and merge "system name-servers-dhcp" into "system
name-server"
3.2.640 2021-09-04
• T3619 (bug): Performance Degradation 1.2 --> 1.3 | High ksoftirqd CPU usage
3.2.641 2021-09-03
• T3788 (bug): Keys are not allowed with ipip and sit tunnels
• T3634 (feature): Add op command option for ping for do not fragment bit to be set
• T3798 (feature): bgp: add support for "neighbor <X> local-as replace-as" option
3.2.642 2021-09-02
• T3792 (bug): login: A hypen present in a username from "system login user" is
replaced by an underscore
• T3790 (bug): Does not possible to configure PPTP static ip-address to users
• T2947 (bug): Nat translation many-many with prefix does not map 1-1.
3.2.643 2021-08-31
• T3789 (feature): Add custom validator for base64 encoded CLI data
• T3782 (default): Ingress Shaping with IFB No Longer Functional with 1.3
3.2.644 2021-08-30
3.2.645 2021-08-29
3.2.646 2021-08-28
• T3743 (bug): l2tp doesn't work after reboot if outside-address not 0.0.0.0
3.2.647 2021-08-27
• T3182 (bug): Main blocker Task for FRR 7.4/7.5 series update
• T3568 (feature): Add XML for firewall conf-mode
• T2108 (default): Use minisign/signify instead of GPG for release signing
3.2.648 2021-08-26
3.2.649 2021-08-25
• T3773 (bug): Delete the "show system integrity" command (to prepare for a
re-implementation)
• T3775 (bug): Typo in generated Strongswan VPN-config
3.2.650 2021-08-24
• T3772 (bug): VRRP virtual interfaces are not shown in show interfaces
3.2.651 2021-08-23
3.2.652 2021-08-22
3.2.653 2021-08-20
• T1950 (default): Store VyOS configuration syntax version data in JSON file
3.2.654 2021-08-19
3.2.655 2021-08-18
• T3752 (bug): generate pki certificate file xxx doesn't touch file
3.2.656 2021-08-16
3.2.657 2021-08-15
3.2.658 2021-08-14
3.2.659 2021-08-13
• T3749 (bug): V4/V6 Counters in network container validation aren't being reset
• T3728 (bug): FRR not respect configured RD and RT for L3VNI
• T3727 (bug): VPN IPsec ESP proposal and ESP presented in config missmatch
• T3740 (bug): HTTPs API breaks when the address is IPv6
3.2.660 2021-08-12
3.2.661 2021-08-11
3.2.662 2021-08-09
• T3720 (bug): IPSec set vti secondary address cause interface disable
3.2.663 2021-08-08
3.2.664 2021-08-05
3.2.665 2021-08-04
3.2.666 2021-08-02
• T3601 (default): Error in ssh keys for vmware cloud-init if ssh keys is left empty.
3.2.667 2021-08-01
3.2.668 2021-07-31
3.2.669 2021-07-30
3.2.670 2021-07-23
• T3699 (bug): login: verify selected "system login user" name is not already used by
the base system.
• T3698 (default): Support bridge monitoring
3.2.671 2021-07-13
• T3679 (default): Point the unexpected exception message link to the new rolling
release location
3.2.672 2021-07-11
• T3665 (bug): Missing VRF support for VxLAN but already documented
3.2.673 2021-07-10
3.2.674 2021-07-09
3.2.675 2021-07-06
3.2.676 2021-07-03
3.2.677 2021-07-01
3.2.678 2021-06-29
3.2.679 2021-06-25
• T3641 (feature): Upgrade base system from Debian Buster -> Debian Bullseye
• T3649 (feature): Add bonding additional hash-policy
3.2.680 2021-06-23
3.2.681 2021-06-22
3.2.682 2021-06-21
3.2.683 2021-06-20
3.2.684 2021-06-19
3.2.685 2021-06-18
3.2.686 2021-06-17
• T3624 (feature): BGP: add support for extended community bandwidth definition
3.2.687 2021-06-16
• T3623 (default): Fix for dummy interface option in the operational command "clear
interfaces dummy"
• T3630 (feature): op-mode: add "show version kernel" command
3.2.688 2021-06-13
• T3620 (feature): Rename WWAN interface from wirelessmodem to wwan to use QMI
interface
• T2173 (feature): Add the ability to use VRF on VTI interfaces
• T3622 (feature): WWAN: add support for APN authentication
• T3606 (bug): SNMP unknown notification OID
• T3621 (bug): PPPoE interface does not validate if password is supplied when username
is set
3.2.689 2021-06-12
3.2.690 2021-06-11
3.2.691 2021-06-10
3.2.692 2021-06-08
3.2.693 2021-06-07
3.2.694 2021-06-06
• T842 (feature): Adopt VyOS CLI to latest StrongSwan options and deprecated Keywords
3.2.695 2021-06-04
3.2.696 2021-06-03
3.2.697 2021-06-02
3.2.698 2021-06-01
• T3585 (default): Fix NHRP module for updated interfaces tunnel syntax
• T3594 (bug): Disable by default service strongswan-starter
3.2.699 2021-05-30
3.2.700 2021-05-29
• T1944 (bug): FRR: Invalid route in BGP causes update storm, memory leak, and failure
of Zebra
• T1888 (feature): Update to StrongSwan 5.9.1
3.2.701 2021-05-27
3.2.702 2021-05-26
• T3540 (bug): Keepalived memory utilisation issue when constantly getting its state
in JSON format
3.2.703 2021-05-24
3.2.704 2021-05-23
3.2.705 2021-05-22
3.2.706 2021-05-21
3.2.707 2021-05-20
3.2.708 2021-05-19
3.2.709 2021-05-18
3.2.710 2021-05-15
3.2.711 2021-05-14
• T3346 (bug): nat 4-to-5 migration script fails when a 'source' or 'destination' node
exists but there are no rules
• T3248 (default): Deal with VRRP mode-force command that exists in 1.2 but not in 1.3
• T3426 (default): add support for script arguments to vyos-configd
3.2.712 2021-05-13
3.2.713 2021-05-12
• T3302 (default): Make vyos-configd relay stdout from scripts to the user's console
• T3542 (bug): udev net.rules not installed in image since may 2nd
3.2.714 2021-05-10
3.2.715 2021-05-09
3.2.716 2021-05-06
3.2.717 2021-05-05
3.2.718 2021-05-04
3.2.719 2021-05-02
• T3511 (bug): Update libnss-mapuser and libpam-radius packages from CUMULUS Linux
3.2.720 2021-05-01
3.2.721 2021-04-29
3.2.722 2021-04-28
3.2.723 2021-04-27
3.2.724 2021-04-25
• T3490 (bug): priority inversion on PBR "policy route" create, breaks default route
from dhcp (live iso)
• T3468 (bug): Tunnel interfaces aren't suggested as being available for bridging
(regression)
• T3497 (bug): Prefix list with rule containing only action is not detected as error
during parse
• T3492 (bug): BGP Configuration Migration failed (badly!) from rolling 202102240218
to rolling 202104221210
• T1802 (feature): Wireguard QR code in cli for mobile devices
3.2.725 2021-04-24
3.2.726 2021-04-23
3.2.727 2021-04-20
• T3488 (bug): Specifying an invalid "interface address" like dhcph leads to commit
error
3.2.728 2021-04-18
3.2.729 2021-04-17
3.2.730 2021-04-15
3.2.731 2021-04-14
3.2.732 2021-04-13
3.2.733 2021-04-12
3.2.734 2021-04-10
3.2.735 2021-04-09
• T3464 (bug): OSPF: route-map names containing a hypen are not "found"
3.2.736 2021-04-08
3.2.737 2021-04-05
• T3438 (bug): VRF: removing vif which belongs to a vrf, will delete the entire vrf
from the operating system
• T3418 (bug): BGP: system wide known interface can not be used as neighbor
3.2.738 2021-04-04
3.2.739 2021-03-31
3.2.740 2021-03-30
3.2.741 2021-03-29
3.2.742 2021-03-28
• T3440 (bug): HTTP API: give uvicorn time to initialize before restarting Nginx proxy
3.2.743 2021-03-27
• T3423 (bug): Cannot create ipv4 static route for default gateway in vrf
3.2.744 2021-03-26
3.2.745 2021-03-24
3.2.746 2021-03-22
3.2.747 2021-03-21
3.2.748 2021-03-20
• T3392 (bug): vrrp over dhcp default route bug (unexpected vrf)
• T3373 (feature): Upgrade to SaltStack version 3002.5
• T3329 (default): "system conntrack ignore" rules can no longer be created due to an
iptables syntax change
• T3300 (feature): Add DHCP default route distance
• T3306 (feature): Extend set route-map aggregator as to 4 Bytes
3.2.749 2021-03-18
3.2.750 2021-03-17
• T3413 (bug): Configuring invalid IPv6 EUI64 address results in "OSError: illegal IP
address string passed to inet_pton"
3.2.751 2021-03-14
3.2.752 2021-03-13
3.2.753 2021-03-11
• T3305 (bug): Ingress qdisc does not work anymore in 1.3-rolling-202101 snapshot
• T2927 (bug): isc-dhcpd release and expiry events never execute
3.2.754 2021-03-09
3.2.755 2021-03-08
3.2.756 2021-03-07
3.2.757 2021-03-04
3.2.758 2021-03-02
3.2.759 2021-02-28
3.2.760 2021-02-27
3.2.761 2021-02-26
3.2.762 2021-02-24
3.2.763 2021-02-22
3.2.764 2021-02-21
3.2.765 2021-02-19
3.2.766 2021-02-18
• T3259 (default): many dnat rules makes the vyos http api crash, even showConfig op
timeouts
3.2.767 2021-02-17
3.2.768 2021-02-16
3.2.769 2021-02-15
• T3311 (bug): BGP Error: Remote AS must be set for neighbor or peer-group
3.2.770 2021-02-14
3.2.771 2021-02-12
• T3301 (bug): Wrong format and valueHelp for policy as-path-list regex
3.2.772 2021-02-11
3.2.773 2021-02-08
3.2.774 2021-02-05
3.2.775 2021-02-04
3.2.776 2021-02-03
3.2.777 2021-02-02
• T3018 (bug): Unclear behaviour when configuring vif and vif-s interfaces
• T3255 (default): Rewrite protocol RPKI to new XML/Python style
• T3263 (feature): OSPF Hello subsecond timer
3.2.778 2021-01-31
3.2.779 2021-01-30
3.2.780 2021-01-29
3.2.781 2021-01-27
3.2.782 2021-01-26
• T3251 (bug): PPPoE client trying to authorize with the wrong username
• T3256 (default): Add XML for protocol RPKI [conf-mode]
3.2.783 2021-01-25
3.2.784 2021-01-24
3.2.785 2021-01-23
3.2.786 2021-01-17
3.2.787 2021-01-16
3.2.788 2021-01-15
3.2.789 2021-01-14
3.2.790 2021-01-12
3.2.791 2020-12-20
3.2.792 2020-11-29
3.3.1 2024-04-25
3.3.2 2024-04-23
3.3.3 2024-04-17
3.3.4 2024-04-12
3.3.5 2024-04-10
• T6124 (bug): Docker equuleus build image doesn't build due to fpm
3.3.6 2024-04-08
• T6196 (bug): Route-map and summary-only do not work in BGP aggregation at the same
time
3.3.7 2024-04-07
3.3.8 2024-04-05
• T2590 (bug): DHCPv6 not updating nameservers and search domains since replacing
isc-dhcp-client with WIDE dhcp6c
3.3.9 2024-04-04
3.3.10 2024-04-02
3.3.11 2024-04-01
• T6193 (bug): dhcp-client: invalid warning "is not a DHCP interface but uses DHCP
name-server option" for VLAN interfaces
3.3.12 2024-03-22
3.3.13 2024-03-11
3.3.14 2024-03-07
3.3.15 2024-03-06
• T6088 (bug): Configuration corrupted after saving and powercut or force reboot
3.3.16 2024-02-16
• T2113 (bug): OpenVPN Options error: you cannot use --verify-x509-name with
--compat-names or --no-name-remapping
• T5418 (bug): PPPoE-Server Client IP pool Subnet
3.3.17 2024-02-15
• T2612 (bug): HTTPS API, changing API key fails but goes through
• T656 (enhancment): Rewrite wirelessmodem in new style XML interface definition
3.3.18 2024-02-14
3.3.19 2024-02-08
3.3.20 2024-02-07
3.3.21 2024-02-02
3.3.22 2024-02-01
• T5967 (bug): Multi-hop BFD connections can't be established; please add minimum-ttl
option.
3.3.23 2024-01-22
3.3.24 2024-01-20
3.3.25 2024-01-19
3.3.26 2024-01-14
3.3.27 2024-01-13
3.3.28 2024-01-11
• T5275 (default): Add op mode commands for exporting certificates to PEM files with
correct headers
• T5274 (default): Add a deprecation warning for OpenVPN site-to-site with pre-shared
secret
• T3191 (bug): PAM RADIUS freezing when accounting does not configured on RADIUS
server
3.3.29 2024-01-10
3.3.30 2024-01-09
3.3.31 2024-01-08
3.3.32 2023-12-29
3.3.33 2023-12-22
• T4760 (bug): VyOS does not support running multiple instances of DHCPv6 clients
3.3.34 2023-12-21
• T5714 (bug): IPSec VPN: op-mode: "show log vpn" does not show results
• T3039 (feature): Resize a root partition and filesystem automatically during
deployment in virtual environments
• T2404 (bug): Cannot change MTU
• T2353 (bug): Interface [conf_mode] errors parent task
• T5796 (bug): Openconnect - HTTPS security headers are missing
3.3.35 2023-12-19
3.3.36 2023-12-18
3.3.37 2023-12-15
3.3.38 2023-12-12
3.3.39 2023-11-30
3.3.40 2023-11-28
• T5777 (bug): frr: backport and upstream recent bgpd daemon crashes
3.3.41 2023-11-27
• T5763 (bug): Fix imprecise check for remote file name in vyos-load-config.py
3.3.42 2023-11-25
• T5655 (bug): commit-archive: Ctrl+C should not eror out with stack trace, signal
should be cought
3.3.43 2023-11-24
• T5402 (bug): VRRP router with rfc3768-compatibility sends multiple ARP replies
3.3.44 2023-11-22
3.3.45 2023-11-15
• T5661 (enhancment): Add show show ssh dynamic-protection attacker and show log ssh
dynamic-protection
• T1276 (bug): dhcp relay + VLAN fails
3.3.46 2023-11-07
3.3.47 2023-11-06
3.3.48 2023-10-26
• T5684 (bug): services using VRF generates the error "Failed to load BPF prog:
'Operation not permitted'" when the system boots.
• T5594 (bug): VRRP - Error if using IPv6 Link Local as hello source address
3.3.49 2023-10-21
3.3.50 2023-10-19
3.3.51 2023-10-17
• T5235 (bug): SSH keys with special characters cannot be applied via Cloud-init
3.3.52 2023-10-08
3.3.53 2023-10-06
3.3.54 2023-10-04
3.3.55 2023-09-25
3.3.56 2023-09-20
3.3.57 2023-09-11
3.3.58 2023-09-10
3.3.59 2023-09-08
3.3.60 2023-09-05
3.3.61 2023-09-04
3.3.62 2023-08-31
• T5190 (feature): Cloud-Init cannot fetch Meta-data on machines where the main
Ethernet interface is not eth0
• T5140 (bug): Firewall network-group problems
• T4895 (bug): Tag nodes are overwritten when configured by Cloud-Init from User-Data
• T4874 (default): Add Warning message to Equuleus
• T4855 (bug): Trying to create more than one tunnel of the same type to the same
address causes unhandled exception
• T4776 (bug): NVME storage is not detected properly during installation
• T3546 (feature): Add support for running scripts on PPPoE server session events
• T738 (feature): Add local-port and resolver port options for powerdns in CLI
configuration tree
3.3.63 2023-08-30
• T5221 (bug): BGP as-override behavior differs from new FRR and other vendors
• T4933 (default): Malformed lines cause vyos.util.colon_separated_to_dict fail with a
nondescript error
• T4790 (bug): RADIUS login does not work if sum of timeouts more than 50s
• T4475 (bug): route-map does not support ipv6 peer
• T4459 (bug): API service with VRF doesn't work in 1.3.1
• T4407 (bug): Network-config v2 is broken in Cloud-init 22.1 and VyOS 1.3
• T4113 (bug): Incorrect GRUB configuration parsing
• T1764 (bug): Use lists instead of whitespace-separated strings in vyos.config
• T4121 (bug): Nameservers from DHCP client cannot be used in specific cases
• T4151 (feature): IPV6 local PBR Support
• T4306 (default): Do not check for ditry repository when building release images
3.3.64 2023-08-29
• T3940 (bug): DHCP client does not remove IP address when stopped by the
02-vyos-stopdhclient hook
• T3713 (default): Create a meta-package for user utilities
• T3339 (bug): Cloud-Init domain search setting not applied
• T2640 (feature): Running VyOS inside Docker containers
• T3577 (bug): Generating vpn x509 key pair fails with command not found
3.3.65 2023-08-28
• T4745 (bug): CLI TAB issue with values with '-' at the beginning in conf mode
• T2611 (bug): Prefix list names are shared between ipv4 and ipv6
• T2296 (default): Upgrade WALinux to 2.2.41
• T2123 (default): Configure 3 NTP servers
• T469 (bug): Problem after commit with errors
3.3.66 2023-08-25
3.3.67 2023-08-24
3.3.68 2023-08-23
3.3.69 2023-08-20
• T5470 (bug): wlan: can not disable interface if SSID is not configured
3.3.70 2023-08-17
3.3.71 2023-08-15
• T5273 (default): Add op mode commands for displaying certificate details and
fingerprints
• T5270 (default): Make OpenVPN `tls dh-params` optional
3.3.72 2023-08-10
• T5329 (bug): Wireguard interface as GRE tunnel source causes configuration error on
boot
3.3.73 2023-07-24
3.3.74 2023-07-17
3.3.75 2023-07-14
• T305 (default): loadbalancing does not work with one pppoe connection and another
connection of either dhcp or static
3.3.76 2023-07-13
3.3.77 2023-07-12
3.3.78 2023-07-11
• T2118 (bug): Failure to boot after power outage due to dirty filesystem and no fsck
in initramfs
3.3.79 2023-07-05
3.3.80 2023-06-30
3.3.81 2023-06-26
3.3.82 2023-06-25
• T5240 (bug): Service router-advert failed to start radvd with more then 3
name-servers
3.3.83 2023-06-21
3.3.84 2023-06-13
3.3.85 2023-05-29
3.3.86 2023-05-19
3.3.87 2023-05-12
3.3.88 2023-05-08
3.3.89 2023-04-27
• T5175 (bug): http-api: error in MultiPart parser for FastAPI version >= 0.91.0
• T5176 (bug): http-api: update vyos-http-api-tools for FastAPI security
vulnerability
3.3.90 2023-04-13
3.3.91 2023-04-05
• T4975 (bug): CLI does not work after cutting off the power or reset
• T5136 (bug): Possible config corruption on upgrade
3.3.92 2023-04-01
3.3.93 2023-03-31
3.3.94 2023-03-29
• T5033 (bug): generate-public-key command fails for address with multiple public keys
like GitHub
• T5097 (bug): the operational command "show interfaces ethernet ethx" doesn't reflect
a call to 'clear counters'
3.3.95 2023-03-21
3.3.96 2023-03-19
3.3.97 2023-03-16
3.3.98 2023-03-09
• T5066 (bug): Different GRE tunnel but same tunnel keys error
3.3.99 2023-03-08
• T4381 (default): OpenVPN: Add "Tunnel IP" column in "show openvpn server"
operational command
• T4872 (bug): Op-mode show openvpn misses a case when parsing for tunnel IP
3.3.100 2023-03-07
• T2838 (bug): Ethernet device names changing, multiple hw-id being added
• T2649 (default): Ensure configration mode scripts conform to coding guidelines
• T4900 (default): Cache intermediary results of get_config_diff in Config instance
3.3.101 2023-03-03
3.3.102 2023-02-28
3.3.103 2023-02-25
• T5008 (bug): MACsec CKN of 32 chars is not allowed in CLI, but works fine
• T5007 (bug): Interface multicast setting is invalid
• T5017 (bug): Bug with validator interface-name
• T4992 (bug): Incorrect check is_local_address for bgp neighbor with option
ip_nonlocal_bind set
• T4978 (bug): KeyError: 'memory' container_config['memory'] on upgrading to 1.
4-rolling-202302041536
• T4948 (feature): pppoe: add CLI option to allow definition of host-uniq flag
3.3.104 2023-02-22
• T5011 (bug): Some interface drivers don't support min_mtu and max_mtu and verify_mtu
check should be skipped
3.3.105 2023-02-18
3.3.106 2023-02-16
3.3.107 2023-02-15
3.3.108 2023-02-14
3.3.109 2023-02-13
3.3.110 2023-02-11
3.3.111 2023-02-08
3.3.112 2023-02-07
• T4117 (bug): Does not possible to configure PoD/CoA for L2TP vpn
3.3.113 2023-02-01
3.3.114 2023-01-30
3.3.115 2023-01-24
• T4949 (feature): Backport "monitor log" and "show log" op-mode definitions from
current to equuleus
• T4947 (feature): Support mounting container volumes as ro or rw
3.3.116 2023-01-23
3.3.117 2023-01-22
3.3.118 2023-01-21
3.3.119 2023-01-17
3.3.120 2023-01-15
• T4832 (feature): dhcp: Add IPv6-only dhcp option support (RFC 8925)
• T4918 (bug): Odd show interface behavior
3.3.121 2023-01-09
3.3.122 2023-01-07
3.3.123 2023-01-05
3.3.124 2023-01-03
• T4869 (bug): A network with `/32` or `/128` mask cannot be removed from a
network-group
3.3.125 2022-12-31
3.3.126 2022-12-26
3.3.127 2022-12-18
3.3.128 2022-12-15
3.3.129 2022-12-04
3.3.130 2022-12-02
• T4122 (bug): interface ip address config missing after upgrade from 1.2.8 to 1.3.0
(when redirect is configured?)
• T1024 (feature): Policy Based Routing by DSCP
3.3.131 2022-11-23
3.3.132 2022-11-21
3.3.133 2022-11-06
• T2913 (bug): Failure to install fpm while building builder docker image
3.3.134 2022-11-04
3.3.135 2022-11-01
3.3.136 2022-10-31
• T1875 (feature): Add the ability to use network address as BGP neighbor (bgp listen
range)
• T4785 (feature): snmp: Allow !, @, * and # in community name
3.3.137 2022-10-21
3.3.138 2022-10-18
3.3.139 2022-10-13
3.3.140 2022-10-12
• T4730 (bug): Conntrack-sync error - listen-address is not the correct type in config
as it should be
3.3.141 2022-10-11
3.3.142 2022-10-04
3.3.143 2022-09-17
3.3.144 2022-09-15
• T4679 (bug): OpenVPN site-to-site incorrect check for IPv6 local and remote address
• T4630 (bug): Prevent attempts to use the same interface as a source interface for
pseudo-ethernet and MACsec at the same time
3.3.145 2022-09-12
3.3.146 2022-09-05
3.3.147 2022-08-29
3.3.148 2022-08-26
3.3.149 2022-08-23
3.3.150 2022-08-22
• T4629 (bug): Raised ConfigErrors contain dict instead of only the dict key
• T4632 (bug): VLAN-aware bridge not working
3.3.151 2022-08-19
3.3.152 2022-08-16
• T4592 (bug): macsec: can not create two interfaces using the same source-interface
• T4584 (bug): hostap: create custom package build
• T4537 (bug): MACsec not working with cipher gcm-aes-256
3.3.153 2022-08-15
• T4565 (bug): vlan aware bridge not working with - Kernel: T3318: update Linux
Kernel to v5.4.205 #249
• T4206 (bug): Policy Based Routing with DHCP Interface Issue
• T2763 (feature): New SNMP resource request - SNMP over TCP
3.3.154 2022-08-14
• T4579 (bug): bridge: can not delete member interface CLI option when VLAN is
enabled
• T4421 (default): Add support for floating point numbers in the numeric validator
• T4415 (bug): Include license/copyright files in the image but remove user
documentation from /usr/share/doc to reduce its size
• T4313 (bug): "generate public-key-command" throws unhandled exceptions when it
cannot retrieve the key
• T4082 (bug): Add op mode command to restart ldpd
• T3714 (bug): Some sysctl custom parameters disappear after reboot
3.3.155 2022-08-11
• T4476 (default): Next steps after installation is not communicated properly to new
users
3.3.156 2022-08-02
3.3.157 2022-07-30
• T4575 (feature): vyos.utill add new wrapper "rc_cmd" to get the return code and
output
• T4532 (bug): Flow-accounting IPv6 server/receiver bug
3.3.158 2022-07-27
• T4571 (bug): Sflow with vrf configured does not use vrf to validate agent-address IP
from vrf-configured interfaces
3.3.159 2022-07-18
• T4228 (bug): bond: OS error thrown when two bonds use the same member
• T4534 (bug): bond: bridge: error out if member interface is assigned to a VRF
instance
• T4525 (bug): Delete interface from VRF and add it to bonding error
• T4522 (feature): bond: add ability to specify mii monitor interval via CLI
• T4521 (bug): bond: ARP monitor interval is not configured despite set via CLI
3.3.160 2022-07-14
• T4491 (bug): Use empty string for internal name of root node of config_tree
3.3.161 2022-07-13
3.3.162 2022-07-12
3.3.163 2022-07-09
3.3.164 2022-07-07
• T4456 (bug): NTP client in VRF tries to bind to interfaces outside VRF, logs many
messages
• T4509 (feature): Feature Request: DNS64
3.3.165 2022-07-06
3.3.166 2022-07-05
• T4510 (bug): set system static-host-mapping doesn't allow IPv4 and IPv6 for same
name.
• T2654 (bug): Multiple names unable to be assigned to the same static mapping
• T2683 (default): no dual stack in system static-host-mapping host-name
3.3.167 2022-07-01
3.3.168 2022-06-20
3.3.169 2022-06-16
3.3.170 2022-06-15
3.3.171 2022-06-09
3.3.172 2022-06-08
3.3.173 2022-05-30
3.3.174 2022-05-27
• T4441 (bug): wwan: connection not possible after a change added after 1.3.1-S1
release
3.3.175 2022-05-26
3.3.176 2022-05-25
3.3.177 2022-05-19
• T4430 (bug): Show firewall output with visual shift default rule
3.3.178 2022-05-16
3.3.179 2022-05-12
3.3.180 2022-05-11
3.3.181 2022-05-10
• T1972 (feature): Allow setting interface name for virtual_ipaddress in VRRP VRID
3.3.182 2022-05-07
• T4361 (bug): `vyos.config.exists()` does not work for nodes with multiple values
• T4354 (bug): Slave interfaces fall out from bonding during configuration change
3.3.183 2022-05-03
3.3.184 2022-05-01
• T4369 (bug): OpenVPN: daemon not restarted on changes to "openvpn-option" CLI node
• T4363 (bug): salt-minion: default mine_interval option is not set
3.3.185 2022-04-29
3.3.186 2022-04-26
3.3.187 2022-04-19
• T4344 (bug): DHCP statistics not matching, conf-mode generates incorrect pool name
with dash
• T4268 (bug): Elevated LA while using VyOS monitoring feature
3.3.188 2022-04-08
• T4331 (bug): IPv6 link local addresses are not configured when an interface is in a
VRF
• T4339 (bug): wwan: tab-completion results in "No such file or directory" if there
is no WWAN interface
• T4338 (bug): wwan: changing interface description should not trigger reconnect
• T4324 (bug): wwan: check alive script should only be run via cron if a wwan
interface is configured at all
3.3.189 2022-04-07
3.3.190 2022-04-06
• T4308 (feature): Op-comm "Show log frr" to view specific protocol logs
3.3.191 2022-03-29
3.3.192 2022-03-24
• T4294 (bug): Adding a new openvpn-option does not restart the OpenVPN process
• T4230 (bug): OpenVPN server configuration deleted after reboot when using a VRRP
virtual-address
3.3.193 2022-03-21
3.3.194 2022-03-12
• T4296 (bug): Interface config injected by Cloud-Init may interfere with VyOS native
• T4002 (default): firewall group network-group long names restriction incorrect
behavior
3.3.195 2022-03-11
• T4297 (bug): Interface configuration saving fails for ice/iavf based interfaces
because they can't change speed/duplex settings
3.3.196 2022-03-05
3.3.197 2022-02-28
3.3.198 2022-02-24
3.3.199 2022-02-23
3.3.200 2022-02-21
3.3.201 2022-02-20
3.3.202 2022-02-19
3.3.203 2022-02-17
• T4241 (bug): ocserv openconnect looks broken in recent bulds of 1.3 Equuleus
• T4255 (bug): Unexpected print of dict bridge on delete
• T4240 (bug): Cannot add wlan0 to bridge via configure
• T4154 (bug): Error add second gre tunnel with the same source interface
3.3.204 2022-02-16
3.3.205 2022-02-15
3.3.206 2022-02-13
3.3.207 2022-02-11
3.3.208 2022-02-10
3.3.209 2022-02-08
3.3.210 2022-02-07
• T4233 (bug): ssh: sync regex for allow/deny usernames to "system login"
• T4087 (feature): IPsec IKE-group proposals limit of 10 pieces
3.3.211 2022-02-05
• T4226 (bug): VRRP transition-script does not work for groups name which contains
-(minus) sign
3.3.212 2022-02-04
3.3.213 2022-02-03
• T3643 (bug): show vpn ipsec sa doesn't show tunnels in "down" state
3.3.214 2022-02-01
3.3.215 2022-01-28
• T4184 (bug): NTP allow-clients address doesn't work it allows to use ntp server for
all addresses
3.3.216 2022-01-24
3.3.217 2022-01-17
• T3164 (bug): console-server ssh does not work with RADIUS PAM auth
3.3.218 2022-01-15
3.3.219 2022-01-12
3.3.220 2022-01-10
• T3299 (bug): Allow the web proxy service to listen on all IP addresses
• T3115 (feature): Add support for firewall on L3 VIF bridge interface
3.3.221 2022-01-09
• T3822 (bug): OpenVPN processes do not have permission to read key files generated
with `run generate openvpn key`
• T4142 (bug): Input ifbX interfaces not displayed in op-mode
• T3914 (bug): VRRP rfc3768-compatibility doesn't work with unicast peers
3.3.222 2022-01-07
3.3.223 2022-01-06
3.3.224 2022-01-03
3.3.225 2021-12-31
• T4081 (bug): VRRP health-check script stops working when setting up a sync group
3.3.226 2021-12-29
• T2922 (bug): The `vpn ipsec logging log-modes` miss the IPSec daemons state check
• T2695 (bug): Flow-accounting bug with subinterfaces
• T2400 (default): OpenVPN: dont restart server if no need
• T4086 (default): system login banner is not removed on deletion.
3.3.227 2021-12-28
• T3380 (bug): "show vpn ike sa" does not display IPv6 peers
• T2933 (feature): VRRP add option virtual_ipaddress_excluded
3.3.228 2021-12-27
3.3.229 2021-12-26
• T4104 (bug): RAID1: "add raid md0 member sda1" does not restore boot sector
3.3.230 2021-12-25
3.3.231 2021-12-24
3.3.232 2021-12-23
3.3.233 2021-12-22
3.3.234 2021-12-21
• T4053 (bug): VRRP impossible to set scripts out of the /config directory
• T4013 (bug): Add pkg cloudwatch for AWS images
• T3913 (bug): VRF traffic fails after upgrade from 1.3.0-RC6 to 1.3.0-EPA1/2
3.3.235 2021-12-20
3.3.236 2021-12-19
3.3.237 2021-12-17
3.3.238 2021-12-16
3.3.239 2021-12-15
• T4077 (bug): op-mode: bfd: drop "show protocols bfd" in favour of "show bfd"
• T4073 (bug): "show protocols bfd peer <>" shows incorrect peer information.
3.3.240 2021-12-14
3.3.241 2021-12-12
• T4036 (bug): VXLAN incorrect raiseError if set multicast network instead of singe
address
3.3.242 2021-12-10
• T4068 (feature): Python: ConfigError should insert line breaks into the error
message
3.3.243 2021-12-09
3.3.244 2021-12-08
3.3.245 2021-12-07
3.3.246 2021-12-06
3.3.247 2021-12-05
3.3.248 2021-12-04
3.3.249 2021-12-02
3.3.250 2021-12-01
• T3695 (bug): OpenConnect reports commit success when ocserv fails to start due to
SSL cert/key file issues
3.3.251 2021-11-30
3.3.252 2021-11-29
3.3.253 2021-11-28
3.3.254 2021-11-26
3.3.255 2021-11-25
• T4005 (feature): Feature Request: IPsec IKEv1 + IKEv2 for one peer
3.3.256 2021-11-24
3.3.257 2021-11-23
• T3990 (bug): WATCHFRR: crashlog and per-thread log buffering unavailable (due to
files left behind in /var/tmp/frr/ after reboot)
3.3.258 2021-11-20
• T4004 (bug): IPsec ike-group parameters are not saved correctly (after reboot)
3.3.259 2021-11-19
• T4003 (bug): API for "show interfaces ethernet" does not include the interface
description
• T4011 (bug): ethernet: deleting interface should place interface in admin down
state
3.3.260 2021-11-18
3.3.261 2021-11-17
3.3.262 2021-11-15
3.3.263 2021-11-14
3.3.264 2021-11-11
• T1349 (bug): L2TP remote-access vpn terminated and not showing as connected
• T1058 (default): hw-id is ignored when naming interfaces
• T914 (feature): Extend list_interfaces.py to support multiple interface types
• T688 (enhancment): Move component versions used for config migration purposes into
vyos-1x
3.3.265 2021-11-10
3.3.266 2021-11-09
3.3.267 2021-11-07
3.3.268 2021-11-06
3.3.269 2021-11-05
3.3.270 2021-11-04
• T3964 (bug): SSTP: local-user static-ip CLI node accepts invalid IPv4 addresses
3.3.271 2021-11-03
3.3.272 2021-11-01
3.3.273 2021-10-31
3.3.274 2021-10-29
3.3.275 2021-10-28
• T3941 (bug): "show vpn ipsec sa" shows established time of parent SA not child SA's
3.3.276 2021-10-27
• T3944 (bug): VRRP fails over when adding new group to master
3.3.277 2021-10-25
3.3.278 2021-10-22
3.3.279 2021-10-21
• T3920 (bug): dhclient exit hook script 01-vyos-cleanup causes too many arguments
error
• T3926 (bug): strip-private does not sanitize "cisco-authentication" from NHRP
configuration
• T3925 (feature): Tunnel: dhcp-interface not implemented - use source-interface
instead
• T3927 (feature): Kernel: Enable kernel support for HW offload of the TLS protocol
3.3.280 2021-10-20
3.3.281 2021-10-19
• T3396 (bug): syslog can't be configured with an ipv6 literal destination in 1.2.x
• T690 (feature): Allow OpenVPN servers to push routes with custom metric values
3.3.282 2021-10-17
3.3.283 2021-10-16
• T3879 (bug): GPG key verification fails when upgrading from a 1.3 beta version
• T3851 (bug): Missing ospf and rip options for bridge vifs
3.3.284 2021-10-13
3.3.285 2021-10-11
• T2607 (feature): Support for pppoe-server radius mode auth and config radius
accouting port
3.3.286 2021-10-10
• T3750 (bug): pdns-recursor 4.4 issue with dont-query and private DNS servers
• T3885 (default): dhcpv6-pd: randomly generated DUID is not persisted
• T3899 (enhancment): Add support for hd44780 LCD displays
3.3.287 2021-10-09
• T3894 (bug): Tunnel Commit Failed if system does not have `eth0`
3.3.288 2021-10-08
3.3.289 2021-10-04
• T3888 (bug): Incorrect warning when poweroff command executed from configure mode.
• T3890 (feature): dhcp(v6): provide op-mode commands to retrieve both server and
client logfiles
• T3889 (feature): Migrate to journalctl when reading daemon logs
3.3.290 2021-10-03
3.3.291 2021-10-02
3.3.292 2021-10-01
• T3877 (bug): VRRP always enabled rfc3768-compatibility even when not specified
3.3.293 2021-09-30
3.3.294 2021-09-27
3.3.295 2021-09-26
• T3860 (bug): Error on pppoe, tunnel and wireguard interfaces for IPv6 EUI64
addresses
• T3857 (feature): reboot: send wall message to all users for information
• T3867 (bug): vxlan: multicast group address is not validated
• T3859 (bug): Add "log-adjacency-changes" to ospfv3 process
3.3.296 2021-09-23
• T3850 (bug): Dots are no longer allowed in SSH public key names
3.3.297 2021-09-21
3.3.298 2021-09-19
3.3.299 2021-09-11
• T3402 (feature): Add VyOS programming library for operational level commands
3.3.300 2021-09-10
• T3802 (bug): Commit fails if ethernet interface doesn't support flow control
• T3819 (bug): Upgrade Salt Stack 3002.3 -> 3003 release train
• T3421 (bug): MTR/Traceroute broken in 1.3-beta
• T3820 (feature): PowerDNS recursor - update from 4.3 -> 4.4 to sync with current
• T1770 (bug): webproxy breaks commit and http access on routed client
• T915 (feature): MPLS Support
3.3.301 2021-09-09
3.3.302 2021-09-07
3.3.303 2021-09-06
• T3806 (bug): Don't set link local ipv6 address if MTU less then 1280
• T3803 (default): Add source-address option to the ping CLI
• T3431 (bug): Show version all bug
• T3362 (bug): 1.3 - RC1 ifb redirect failing to commit
• T3291 (bug): Fault on setting offload RPS with single-core CPU
• T2920 (bug): Commit crash when adding the second mGRE tunnel with the same key
• T2895 (bug): VPN IPsec "leftsubnet" declared 2 times
• T2019 (bug): LLDP wrong config generation for interface 'all'
3.3.304 2021-09-05
• T3804 (feature): cli: Migrate and merge "system name-servers-dhcp" into "system
name-server"
3.3.305 2021-09-04
3.3.306 2021-09-03
• T3788 (bug): Keys are not allowed with ipip and sit tunnels
• T3683 (bug): VXLAN not accept ipv6 and source-interface options and mtu bug
• T3634 (feature): Add op command option for ping for do not fragment bit to be set
3.3.307 2021-09-02
• T3792 (bug): login: A hypen present in a username from "system login user" is
replaced by an underscore
• T3790 (bug): Does not possible to configure PPTP static ip-address to users
3.3.308 2021-09-01
3.3.309 2021-08-31
• T3789 (feature): Add custom validator for base64 encoded CLI data
• T3782 (default): Ingress Shaping with IFB No Longer Functional with 1.3
3.3.310 2021-08-30
3.3.311 2021-08-29
3.3.312 2021-08-27
• T3182 (bug): Main blocker Task for FRR 7.4/7.5 series update
• T2108 (default): Use minisign/signify instead of GPG for release signing
3.3.313 2021-08-26
3.3.314 2021-08-25
• T3773 (bug): Delete the "show system integrity" command (to prepare for a
re-implementation)
• T1514 (default): Add ability to restart frr processes
3.3.315 2021-08-24
• T3772 (bug): VRRP virtual interfaces are not shown in show interfaces
3.3.316 2021-08-23
• T2555 (bug): XML op-mode generation scripts silently discard XML nodes
3.3.317 2021-08-21
3.3.318 2021-08-20
• T1950 (default): Store VyOS configuration syntax version data in JSON file
3.3.319 2021-08-19
• T2759 (bug): validate-value prints error messages from validators that fail even if
overall validation succeeds
• T3234 (bug): multi_to_list fails in certain cases, with root cause an element
redundancy in XML interface-definitions
• T3732 (feature): override-default helper should support adding defaultValues to
default less nodes
• T1962 (default): Add syntax version to schema
3.3.320 2021-08-17
3.3.321 2021-08-16
3.3.322 2021-08-15
3.3.323 2021-08-14
3.3.324 2021-08-13
3.3.325 2021-08-12
3.3.326 2021-08-10
3.3.327 2021-08-09
3.3.328 2021-08-08
3.3.329 2021-08-07
3.3.330 2021-08-06
• T1153 (bug): VyOS 1.2.0RC10, RAID-1, fresh install, unable to save config
3.3.331 2021-08-05
3.3.332 2021-08-04
3.3.333 2021-08-02
• T2623 (bug): Creating sit tunnel fails with “Can not set “local” for tunnel sit tun1
at tunnel creation”
• T2161 (default): snmpd cannot start if ipv6 disabled
• T3601 (default): Error in ssh keys for vmware cloud-init if ssh keys is left empty.
3.3.334 2021-08-01
3.3.335 2021-07-31
3.3.336 2021-07-30
3.3.337 2021-07-29
3.3.338 2021-07-23
• T3699 (bug): login: verify selected "system login user" name is not already used by
the base system.
3.3.339 2021-07-21
3.3.340 2021-07-20
3.3.341 2021-07-13
• T3679 (default): Point the unexpected exception message link to the new rolling
release location
3.3.342 2021-07-11
• T3665 (bug): Missing VRF support for VxLAN but already documented
3.3.343 2021-07-06
3.3.344 2021-07-01
3.3.345 2021-06-29
3.3.346 2021-06-25
• T3650 (bug): OpenVPN: Upgrade package to 2.5.1 before releasing VyOS 1.3.0
• T3649 (feature): Add bonding additional hash-policy
3.3.347 2021-06-24
• T2722 (bug): get_config_dict() and key_mangling=('-', '_') will alter CLI data for
tagNodes
3.3.348 2021-06-22
3.3.349 2021-06-20
3.3.350 2021-06-19
3.3.351 2021-06-17
3.3.352 2021-06-16
3.3.353 2021-06-13
• T3620 (feature): Rename WWAN interface from wirelessmodem to wwan to use QMI
interface
• T3622 (feature): WWAN: add support for APN authentication
• T3621 (bug): PPPoE interface does not validate if password is supplied when username
is set
3.3.354 2021-06-10
3.3.355 2021-06-09
3.3.356 2021-06-08
3.3.357 2021-06-07
3.3.358 2021-06-04
3.3.359 2021-06-01
• T406 (bug): VPN configuration error: IPv6 over IPv4 IPsec is not supported when
using IPv6 ONLY tunnel.
3.3.360 2021-05-30
• T1866 (bug): Commit archive over SFTP doesn't work with non-standard ports
• T3589 (feature): op-mode: support clearing out logfiles from CLI
• T3508 (bug): Check if there's enough drive space for an upgrade before downloading
an image
• T1506 (enhancment): commit-archive scp/sftp public key authentication
3.3.361 2021-05-29
3.3.362 2021-05-28
3.3.363 2021-05-27
• T2629 (bug): VXLAN interfaces don't actually allow you to configure most settings
• T2617 (feature): Rewrite vyatta-op-quagga "show" to XML
• T2512 (feature): vyatta-op-quagga [show ip] to XML format
• T1905 (default): Update to Keepalived 2.0.19
• T2669 (bug): DHCP-server overlapping ranges.
3.3.364 2021-05-26
• T3558 (default): autocomplete options for dhcp-interface is not showing for the
static route command
• T3540 (bug): Keepalived memory utilisation issue when constantly getting its state
in JSON format
• T2807 (feature): IPv6 Link-Local Address - Automatically generation/configuration on
GRE Interfaces
3.3.365 2021-05-24
3.3.366 2021-05-23
3.3.367 2021-05-20
3.3.368 2021-05-19
3.3.369 2021-05-18
3.3.370 2021-05-15
3.3.371 2021-05-14
• T3346 (bug): nat 4-to-5 migration script fails when a 'source' or 'destination' node
exists but there are no rules
• T3248 (default): Deal with VRRP mode-force command that exists in 1.2 but not in 1.3
• T3426 (default): add support for script arguments to vyos-configd
3.3.372 2021-05-13
3.3.373 2021-05-12
• T3302 (default): Make vyos-configd relay stdout from scripts to the user's console
3.3.374 2021-05-11
3.3.375 2021-05-10
3.3.376 2021-05-08
3.3.377 2021-05-07
3.3.378 2021-05-06
3.3.379 2021-05-01
3.3.380 2021-04-30
3.3.381 2021-04-29
3.3.382 2021-04-27
3.3.383 2021-04-25
• T3468 (bug): Tunnel interfaces aren't suggested as being available for bridging
(regression)
• T1802 (feature): Wireguard QR code in cli for mobile devices
3.3.384 2021-04-23
3.3.385 2021-04-18
3.3.386 2021-04-15
3.3.387 2021-04-14
3.3.388 2021-04-12
3.3.389 2021-04-05
3.3.390 2021-04-04
3.3.391 2021-03-31
3.3.392 2021-03-25
3.3.393 2021-03-22
3.3.394 2021-03-21
• T3416 (bug): NTP: when running inside a VRF op-mode commands do not work
3.3.395 2021-03-20
• T3392 (bug): vrrp over dhcp default route bug (unexpected vrf)
• T3373 (feature): Upgrade to SaltStack version 3002.5
• T3329 (default): "system conntrack ignore" rules can no longer be created due to an
iptables syntax change
• T3300 (feature): Add DHCP default route distance
• T3306 (feature): Extend set route-map aggregator as to 4 Bytes
3.3.396 2021-03-18
3.3.397 2021-03-17
• T3413 (bug): Configuring invalid IPv6 EUI64 address results in "OSError: illegal IP
address string passed to inet_pton"
3.3.398 2021-03-14
3.3.399 2021-03-13
3.3.400 2021-03-11
• T3399 (bug): RPKI: dashes in hostnames are replaced with underscores when rendering
the FRR config
• T3305 (bug): Ingress qdisc does not work anymore in 1.3-rolling-202101 snapshot
• T2927 (bug): isc-dhcpd release and expiry events never execute
• T899 (bug): Tunnels cannot be moved from one bridge to another
• T786 (feature): new style xml and conf-mode scripts: posibillity to add tagNode
value as parameter to conf-script
3.3.401 2021-03-09
3.3.402 2021-03-08
3.3.403 2021-03-07
3.3.404 2021-03-05
3.3.405 2021-03-04
3.3.406 2021-03-03
• T2966 (feature): tunnel: add new encapsulation types ip6tnl and ip6gretap
3.3.407 2021-03-01
3.3.408 2021-02-28
3.3.409 2021-02-27
• T2291 (bug): Bad hostnames in /etc/hosts with static-mapping in dhcp server config
• T3364 (feature): tunnel: cleanup/rename CLI nodes
• T3368 (feature): macsec: add support for gcm-aes-256 cipher
• T3366 (bug): tunnel: can not change local / remote ip address for gre-bridge tunnel
• T3173 (feature): Need 'nopmtudisc' option for tunnel interface
3.3.410 2021-02-26
3.3.411 2021-02-24
3.3.412 2021-02-21
3.3.413 2021-02-19
3.3.414 2021-02-18
• T3259 (default): many dnat rules makes the vyos http api crash, even showConfig op
timeouts
3.3.415 2021-02-17
• T3047 (bug): OSPF : virtual-link and passive-interface default parameters does not
work together
• T3312 (feature): SolarFlare NICs support
3.3.416 2021-02-16
3.3.417 2021-02-14
• T2152 (bug): ddclient has bug which prevents use_web from being used
• T3308 (feature): BGP: add gracefull shutdown support
3.3.418 2021-02-13
• T3028 (feature): Create a default user when metadata is not available (for
Cloud-init builds)
• T2867 (feature): Cleanup DataSourceOVF.py in the Cloud-init
• T2726 (feature): Allow to use all supported SSH key types in Cloud-init
• T2403 (feature): Full support for networking config in Cloud-init
• T2387 (feature): Create XML scheme for [conf_mode] BGP
3.3.419 2021-02-11
3.3.420 2021-02-08
3.3.421 2021-02-07
• T3293 (bug): RPKI migration script errors out after CLI rewrite
3.3.422 2021-02-06
3.3.423 2021-02-05
3.3.424 2021-02-03
• T3239 (default): XML: override 'defaultValue' for mtu of certain interfaces; remove
workarounds
• T2910 (feature): XML: generator should support override of variables
• T2873 (bug): "show nat destination translation address" doesn't filter at all
3.3.425 2021-02-02
• T3018 (bug): Unclear behaviour when configuring vif and vif-s interfaces
• T3255 (default): Rewrite protocol RPKI to new XML/Python style
3.3.426 2021-02-01
3.3.427 2021-01-31
3.3.428 2021-01-30
3.3.429 2021-01-29
• T3262 (bug): DHCPv6 client runs when dhcpv6-options is configured without requesting
an address or PD
• T3261 (bug): Does not possible to disable pppoe client interface.
3.3.430 2021-01-27
3.3.431 2021-01-26
• T3251 (bug): PPPoE client trying to authorize with the wrong username
• T2859 (bug): show nat source translation - Errors out
3.3.432 2021-01-25
3.3.433 2021-01-24
3.3.434 2021-01-18
• T2761 (feature): Extend "show vrrp" op-mode command with router priority
• T2679 (feature): VRRP with BFD Failure Detection
• T3212 (bug): SSH: configuration directory is not always created on boot
• T3231 (bug): "system option ctrl-alt-delete" has no effect
3.3.435 2021-01-17
3.3.436 2021-01-16
3.3.437 2021-01-15
3.3.438 2021-01-14
• T3218 (feature): Replace Intel out-of-tree drivers with Linux Kernel stock drivers.
3.3.439 2021-01-13
3.3.440 2021-01-12
3.3.441 2021-01-11
3.3.442 2021-01-10
3.3.443 2021-01-09
3.3.444 2021-01-07
• T3192 (feature): login: radius: add support for IPv6 RADIUS servers
3.3.445 2021-01-05
3.3.446 2021-01-04
3.3.447 2021-01-03
3.3.448 2021-01-02
3.3.449 2021-01-01
• T3171 (feature): Add CLI option to enable RPS (Receive Packet Steering)
3.3.450 2020-12-31
3.3.451 2020-12-29
3.3.452 2020-12-28
3.3.453 2020-12-27
• T3150 (bug): When configuring QoS, the setting procedure of port mirroring is wrong
3.3.454 2020-12-23
3.3.455 2020-12-22
• T3142 (bug): OpenVPN op-command completion fails due to missing status file
• T2940 (feature): Update FRR to 7.4
• T2573 (bug): BFD op-mode commands are broken
• T2495 (feature): Add xml for ISIS [conf_mode]
• T1316 (feature): Support for IS-IS
3.3.456 2020-12-21
3.3.457 2020-12-20
3.3.458 2020-12-17
3.3.459 2020-12-14
3.3.460 2020-12-13
• T3114 (bug): When the bridge member is a non-ethernet interface, setting VLAN-aware
bridge parameters fails
3.3.461 2020-12-11
3.3.462 2020-12-10
3.3.463 2020-12-09
3.3.464 2020-12-08
• T2562 (bug): VyOS can't be used as a DHCP server for a DHCP relay
3.3.465 2020-12-07
3.3.466 2020-12-05
3.3.467 2020-12-04
3.3.468 2020-12-03
3.3.469 2020-12-01
3.3.470 2020-11-30
3.3.471 2020-11-29
3.3.472 2020-11-28
3.3.473 2020-11-27
3.3.474 2020-11-24
3.3.475 2020-11-23
3.3.476 2020-11-21
• T3079 (bug): Fix the problem that VLAN 1 will be deleted in VLAN-aware bridge
• T3060 (bug): OpenVPN virtual interface not coming up after upgrade
3.3.477 2020-11-20
• T3078 (feature): CLI cleanup: rename "system options" -> "system option"
• T2997 (feature): DHCP: disallow/do-not-request certain options when requesting IP
address from server
• T3077 (feature): WireGuard: automatically create link-local IPv6 adresses
• T2550 (default): OpenVPN: IPv4 not working in client mode
• T3072 (feature): Migrate tunnel interfaces to new get_config_dict() approach
• T3065 (feature): Add "interfaces wirelessmodem" IPv6 support
• T3048 (feature): Drop static smp-affinity for a more dynamic way using tuned
3.3.478 2020-11-19
• T3067 (bug): Wireless interface can no longer be added to the bridge after bridge
VLAN support
• T3075 (feature): Update Linux Kernel to v4.19.158
3.3.479 2020-11-16
3.3.480 2020-11-15
3.3.481 2020-11-14
3.3.482 2020-11-13
3.3.483 2020-11-12
3.3.484 2020-11-10
3.3.485 2020-11-08
3.3.486 2020-11-07
• T2914 (bug): OpenVPN: Fix for IPv4 remote-host hostname in client mode:
• T2653 (feature): "set interfaces" Python handler code improvements - next iteration
• T311 (feature): DHCP: set client-hostname via CLI
3.3.487 2020-11-06
• T3051 (bug): OpenVPN: multiple client routes do not work in server mode
• T3046 (bug): openvpn directory is not auto-created
• T3052 (feature): Update Linux firmware files to 20201022 version
• T2731 (bug): "show interfaces" returns invalid state when link is down
3.3.488 2020-11-05
3.3.489 2020-11-03
3.3.490 2020-11-02
3.3.491 2020-11-01
3.3.492 2020-10-30
• T2790 (feature): Add ability to set ipv6 protocol route-map for OSPFv3
• T3033 (feature): Update Linux Kernel to v4.19.154
• T2969 (bug): OpenVPN: command_set on interface is not applied, if interface doesn't
come up in commit
3.3.493 2020-10-28
• T2631 (default): l2tp, sstp, pptp add option to disable radius accounting
• T2630 (feature): Allow Interface MTU over 9000
• T3027 (bug): Unable to update system Signature check FAILED
• T2995 (bug): Enhancements/bugfixes for vyos_dict_search()
• T2968 (feature): Add support for Intel Atom C2000 series QAT
3.3.494 2020-10-27
• T1721 (bug): Recursive Next Hop not updated for static routes
3.3.495 2020-10-24
• T3007 (default): HTTP-API should use config load script, not backend config load
• T3009 (bug): vpn l2tp remoteaccess require option broken
• T3010 (bug): ttl option of gre-bridge
• T3005 (bug): Intel: update out-of-tree drivers, i40e driver warning
• T3004 (feature): ConfigSession should (optionally) use config load script
• T2723 (feature): Support tcptraceroute
3.3.496 2020-10-22
3.3.497 2020-10-21
3.3.498 2020-10-20
• T2987 (bug): VxLAN not working properly after upgrading to latest October build and
with a new installation
• T2989 (default): MPLS documentation expansion
3.3.499 2020-10-19
• T1588 (bug): VRRP failed to start if any of its interaces not exist
• T1385 (feature): Allow bonding interfaces to have pseudo-ethernet interfaces
• T3000 (bug): Mismatch between "prefix-length" and "preference" in dhcp6-server
syntax
• T2992 (feature): Automatically verify sha256 checksum on ISO download
• T752 (feature): Add an option to disable IPv4 forwarding on specific interface only
3.3.500 2020-10-18
3.3.501 2020-10-17
3.3.502 2020-10-13
• T2976 (bug): Client IP pool does not work for PPPoE local users
3.3.503 2020-10-12
3.3.504 2020-10-06
3.3.505 2020-10-05
• T2963 (bug): Wireless: WIFI is not password protected when security wpa mode is not
defined but passphrase is
3.3.506 2020-10-04
• T2953 (feature): Accel-PPP services CLI config cleanup (SSTP, L2TP, PPPoE, IPoE)
• T2829 (bug): PPPoE server: mppe setting is implemented as node instead of leafNode
• T2960 (feature): sstp: migrate to get_config_dict()
3.3.507 2020-10-03
3.3.508 2020-10-02
3.3.509 2020-10-01
3.3.510 2020-09-30
3.3.511 2020-09-29
3.3.512 2020-09-27
• T2930 (feature): Support configuration of MAC address for VXLAN and GENEVE tunnel
3.3.513 2020-09-26
• T2856 (bug): equuleus: `show version all` throws broken pipe exception on abort
• T2929 (bug): Upgrading from 1.2 (crux) to 1.3 rolling causes vyos.configtree.
ConfigTreeError for RADIUS settings
• T2928 (bug): MTU less then 1280 bytes and IPv6 will raise FileNotFoundError
• T2926 (bug): snmp.py missing an import
• T2912 (feature): When setting MTU check for hardware maximum supported MTU size
3.3.514 2020-09-25
3.3.515 2020-09-24
3.3.516 2020-09-23
3.3.517 2020-09-20
3.3.518 2020-09-19
• T2894 (bug): bond: lacp: member interfaces get removed once bond interface has
vlans configured
• T2901 (feature): Update Linux Kernel to v4.19.146
• T2900 (bug): DNS forwarding: invalid warning is shown for "system name-server" or
"system name-servers-dhcp" even if present
3.3.519 2020-09-18
• T945 (bug): Unable to change configuration after changing it from script (vbash +
script-template)
3.3.520 2020-09-16
3.3.521 2020-09-15
• T2515 (bug): Ethernet interface is automatically disabled when removing it from bond
3.3.522 2020-09-14
• T2872 (bug): "Show log" for nat and openvpn got intermixed
• T2301 (bug): Cannot delete PBR
• T2880 (feature): Update Linux Kernel to v4.19.145
• T2879 (feature): Cleanup 4.19.144 kernel configuration
3.3.523 2020-09-13
3.3.524 2020-09-12
3.3.525 2020-09-10
3.3.526 2020-09-09
• T2728 (bug): Protocol option ignored for IPSec peers in transport mode
• T1934 (default): Change default hostname when deploy from OVA without params.
• T1953 (bug): DDNS service name validation rejects valid service names
3.3.527 2020-09-07
3.3.528 2020-09-06
3.3.529 2020-09-02
3.3.530 2020-08-31
3.3.531 2020-08-30
3.3.532 2020-08-29
3.3.533 2020-08-28
3.3.534 2020-08-27
3.3.535 2020-08-26
3.3.536 2020-08-25
3.3.537 2020-08-24
3.3.538 2020-08-23
3.3.539 2020-08-22
3.3.540 2020-08-20
• T2209 (bug): Documentation has reference to the old 'user x level admin' option
• T1665 (default): prefix-list and prefix-list6 rules incorrectly accept a host
address where prefix is required
• T2815 (default): Move certbot config directory under /config/auth
3.3.541 2020-08-19
• T2794 (bug): op-mode: lldp: "show lldp neighbors" IndexError: list index out of
range
• T2791 (feature): "monitor traceroute" has no explicit IPv4/IPv6 support
• T1515 (bug): FRR ospf6d crashes when performing: "show ipv6 ospfv3 database"
3.3.542 2020-08-16
3.3.543 2020-08-15
3.3.544 2020-08-14
3.3.545 2020-08-12
3.3.546 2020-08-11
• T2779 (bug): LLDP: "show lldp neighbors interface" does not yield any result
• T2379 (bug): DHCPv6 address for interface deletion triggers a script error
• T2784 (default): Remove unused arg from host_name.py functions verify and get_config
3.3.547 2020-08-10
3.3.548 2020-08-08
• T2716 (bug): Shaper-HFSC shapes but does not control latency correctly
• T2497 (default): Cache config string during commit
• T2501 (bug): Cannot recover from failed boot config load
• T1974 (feature): Allow route-map to set administrative distance
• T1949 (bug): Multihop IPv6 BFD is unconfigurable
3.3.549 2020-08-04
3.3.550 2020-08-03
3.3.551 2020-08-02
3.3.552 2020-08-01
3.3.553 2020-07-30
3.3.554 2020-07-29
• T2743 (feature): WireGuard: move key migration from config script to migration
script
• T2742 (feature): mDNS repeater: migrate to get_config_dict()
3.3.555 2020-07-28
3.3.556 2020-07-27
3.3.557 2020-07-26
3.3.558 2020-07-25
3.3.559 2020-07-24
3.3.560 2020-07-23
• T2673 (bug): After the bridge is configured with Mac, bridge is automatically
disabled
• T2626 (bug): Changing pseudo-ethernet mode, throws CLI error
• T2608 (bug): delete pseudo-ethernet failed (another error type)
• T2527 (bug): bonding: the last slave interface is not deleted
• T2358 (bug): ip6ip6 bridge conf_mode errors
• T2346 (bug): Setting hostname yields temporary file error
• T2330 (bug): Vpn op-mode syntax
• T2188 (default): NTP op-mode commands don't work
3.3.561 2020-07-22
3.3.562 2020-07-20
• T2709 (bug): Destination NAT translation port without address fails to commit
• T2519 (bug): Broadcast address does not add automatically
3.3.563 2020-07-19
• T2708 (bug): "show flow-accounting" should not display script's "usage" help
• T2592 (default): dhcp-relay discarding packets on valid interfaces
• T2712 (feature): udp-broadcast-relay: serivce no longer starts
• T2706 (feature): Support NDP protocol monitoring
3.3.564 2020-07-18
3.3.565 2020-07-15
3.3.566 2020-07-12
3.3.567 2020-07-11
3.3.568 2020-07-08
3.3.569 2020-07-07
3.3.570 2020-07-06
3.3.571 2020-07-05
3.3.572 2020-07-04
• T2682 (bug): VRF aware services - connection no longer possible after system reboot
3.3.573 2020-07-03
3.3.574 2020-07-02
3.3.575 2020-07-01
• T2662 (default): get_config_dict includes node name as key only for tag and leaf
nodes
• T2667 (feature): get_config_dict: Use utility function for non-empty path argument
3.3.576 2020-06-28
• T2660 (bug): XML: Python default dictionary does not obey underscore (_) when flat
is False
3.3.577 2020-06-27
• T2656 (bug): XML: Python default dictionary returns wrong dictionary level(s)
3.3.578 2020-06-26
3.3.579 2020-06-25
• T2487 (bug): VRRP does not display info when group disabled
• T2329 (bug): Show remote config openvpn
• T2165 (bug): When trying to add route to ripng it complains that ip address should
be IPv4 format
• T2159 (default): webproxy log read from wrong file
• T2101 (feature): Fix VXLAN config option parsing
• T2062 (bug): Wrong dhcp-server static route subnet bytes
• T1986 (bug): Python configuration manipulation library leaks open files
• T1762 (bug): VLAN interface configuration fails after internal representation of
edit level was switched from a string to a list
• T1538 (bug): Update conntrack-sync packages to fix VRRP issues
• T1808 (feature): add package nftables
3.3.580 2020-06-24
3.3.581 2020-06-23
• T2632 (bug): WireGuard: Cannot use only one preshared-key for one peer
• T1829 (bug): Install Image script does not respect size of partition greater than 2G
but less than disk size
• T2635 (feature): SSH: migrate to get_config_dict()
3.3.582 2020-06-22
• T2486 (bug): DNS records set via 'system static-host-mapping' return NXDOMAIN from
'service dns forwarding' after a request to a forwarded zone
• T2463 (bug): DHCP-received nameserver not added to vyos-hostsd
• T2534 (bug): pdns-recursor override.conf error
• T2054 (bug): Changing "system name-server" doesn't update dns forwarding config,
neither does "restart dns forwarding"
• T2225 (default): PIM/IGMP documentation
3.3.583 2020-06-21
• T2624 (feature): Serial Console: fix migration script for configured powersave and
no console
• T2610 (bug): default-lifetime is not reflected in the RA message
• T2299 (feature): login radius-server priority
• T1739 (bug): Serial interface seems not to be deleted properly
• T480 (bug): Error if no serial interface is present (/dev/ttyS0: not a tty)
3.3.584 2020-06-20
3.3.585 2020-06-19
3.3.586 2020-06-18
3.3.587 2020-06-17
3.3.588 2020-06-16
3.3.589 2020-06-15
3.3.590 2020-06-14
3.3.591 2020-06-11
• T2578 (bug): ipaddrcheck unaware of /31 host addresses - can no longer assign /31
mask to interface addresses
• T2571 (bug): NAT destination port with ! results in error
• T2570 (feature): Drop support for "system console device <device> modem"
• T2586 (bug): WWAN default route is not installed into VRF
• T2561 (feature): Drop support for "system console netconsole"
• T2569 (feature): Migrate "set system console" to XML and Python representation
3.3.592 2020-06-10
3.3.593 2020-06-08
• T2559 (feature): Add operational mode command to retrieve hardware sensor data
3.3.594 2020-06-07
• T2529 (feature): WWAN: migrate from ttyUSB device to new device in /dev/serial/
by-bus
• T2560 (feature): New op-mode command to display information about USB interfaces
3.3.595 2020-06-05
3.3.596 2020-06-04
3.3.597 2020-06-02
• T2129 (feature): XML schema: tagNode not allowed on first level in new XML op-mode
definition
• T2545 (feature): Show physical device offloading capabilities for specified ethernet
interface
• T2544 (feature): Enable Kernel KONFIG_KALLSYMS
• T2543 (feature): Kernel: always build perf binary but ship as additional deb
package to not bloat the image
• T1096 (bug): BGP process memory leak
3.3.598 2020-06-01
3.3.599 2020-05-31
3.3.600 2020-05-30
• T2388 (feature): template rendering should create folder and set permission
• T2531 (feature): Update Linux Kernel to v4.19.125
• T2530 (bug): Error creating VRF with a name of exactly 16 characters
3.3.601 2020-05-29
3.3.602 2020-05-28
• T1291 (default): Under certain conditions the VTI will stay forever down
3.3.603 2020-05-27
3.3.604 2020-05-26
3.3.605 2020-05-25
3.3.606 2020-05-22
3.3.607 2020-05-21
• T1876 (bug): IPSec VTI tunnels are deleted after rekey and dangling around as A/D
• T2488 (feature): Remove logfile for dialup interfaces like pppoe and wwan
• T2475 (bug): linting
• T1820 (bug): VRRP transition scripts for sync-groups are not supported in VyOS
(anymore)
• T2364 (default): Add CLI command for mroute
• T2023 (feature): Add support for 802.1ae MACsec
3.3.608 2020-05-20
• T2480 (bug): NAT: after rewrite commit tells that dnat IP address is not locally
connected
3.3.609 2020-05-19
3.3.610 2020-05-17
• T2471 (feature): PPPoE server: always add AdvAutonomousFlag when IPv6 is configured
• T2409 (default): At boot, effective config should not be equal to current config
3.3.611 2020-05-16
• T2466 (bug): live-build encounters apt dependency problem when building with local
packages
• T2470 (feature): Update to PowerDNS recursor 4.3
• T2469 (feature): Update Linux Kernel to v4.19.123
• T2198 (default): Rewrite NAT in new XML/Python style
3.3.612 2020-05-15
• T2449 (bug): 'ipv6 address autoconf' and 'address dhcpv6' don't work because
interfaces have accept_ra=1 (they should have accept_ra=2 when forwarding=1)
3.3.613 2020-05-14
3.3.614 2020-05-13
3.3.615 2020-05-12
3.3.616 2020-05-10
3.3.617 2020-05-09
• T2427 (default): Interface addressing broken since fix for T2372 was merged
• T2438 (default): isc-dhcp-server(6).service reports startup success immediately even
if dhcpd fails to start up
• T2367 (default): Flush addresses from bridge members
3.3.618 2020-05-08
3.3.619 2020-05-06
• T2402 (bug): Live ISO should warn when configuring that changes won't persist
3.3.620 2020-05-05
• T1899 (bug): Unionfs metadata folder is copied to the active configuration directory
3.3.621 2020-05-04
3.3.622 2020-05-03
3.3.623 2020-05-02
3.3.624 2020-05-01
3.3.625 2020-04-29
• T2399 (bug): op-mode "dhcp client leases" does not return leases
• T2398 (bug): op-mode "dhcp client leases interface" completion helper misses
interfaces
• T2394 (feature): dhcpv6 client does not start
• T2393 (feature): dhclient: migrate from SysVinit to systemd
• T2268 (bug): DHCPv6 is broken
3.3.626 2020-04-28
3.3.627 2020-04-27
3.3.628 2020-04-26
3.3.629 2020-04-25
3.3.630 2020-04-24
• T2375 (feature): WireGuard: throw exception if address and port are not given as
both are mandatory
• T2348 (bug): On IPv6 address distribution and DHCPv6 bugs
3.3.631 2020-04-23
• T2369 (feature): VRF: can not leak interface route from default VRf to any other VRF
• T2368 (bug): VRF: missing completion helper when leaking to default table
• T2374 (bug): Tunnel interface can not be disabled
• T2362 (default): IPv6 link-local addresses missing due to EUI64 address code,
causing router-advert not to work
• T2345 (default): IPv6 router-advert not working
3.3.632 2020-04-22
3.3.633 2020-04-21
3.3.634 2020-04-20
3.3.635 2020-04-19
3.3.636 2020-04-18
• T2318 (bug): dns-forwarding migration script breaks with invalid interface name
• T2319 (feature): Update Linux Kernel to v4.19.116
• T2314 (feature): Cleanup PPPoE server implementation and CLI commands
• T2313 (bug): Accel-PPP / PPPoEserver raises "Floating point exception" when not all
limits are defined
• T2312 (feature): Use LED modules to enable more visible feedback on VyOS hardware
chassis
• T2306 (feature): Add new cipher suites to the WiFi configuration
• T2286 (default): IPoE server vulnerability
• T2224 (feature): Update Linux Kernel to v4.19.114
• T2110 (feature): RADIUS: supply include file for radius config to have a uniform CLI
• T2324 (feature): Cleanup IPoE server implementation and CLI commands
3.3.637 2020-04-17
3.3.638 2020-04-16
3.3.639 2020-04-15
3.3.640 2020-04-14
• T2213 (bug): vyos-1x: WiFi mode ieee80211ac should also activate ieee80211n
3.3.641 2020-04-13
• T2283 (default): openvpn not starting: ccd path in template not moved to /run/
openvpn/ccd
• T2236 (bug): DMVPN broken after tunnel rewrite to XML/Python
• T2284 (default): Upgrade ddclient to 3.9.1 which also brings systemd files
• T2282 (feature): Clarify hw-id in ethernet and wireless interface nodes
• T611 (feature): Static route syntax should reflect `ip` command routing
capabilities, if possible.
3.3.642 2020-04-12
3.3.643 2020-04-11
3.3.644 2020-04-10
3.3.645 2020-04-09
3.3.646 2020-04-08
3.3.647 2020-04-05
• T2212 (bug): vyos-1x: WiFi card antenna count not set accordingly
• T2230 (feature): Split out inlined Jina2 template to data/templates folder
• T2206 (feature): Split WireGuard endpoint into proper host and port nodes
3.3.648 2020-04-04
• T2158 (bug): Commit fails if ethernet interface doesn't support flow control (pause)
• T2221 (bug): Ability to remove a VRF that has a next-hop-vrf as target
• T2211 (bug): vyos-1x: VHT channel width not set accordingly
• T2208 (bug): vyos-1x: commit on interfaces wireless wlanX capabilities vht
link-adaptation (both|unsolicited) fails
• T2183 (bug): A number of bugs with wireguard script due to interface rearrangement
• T2104 (default): ifconfig.py size
• T2028 (feature): Convert "interfaces tunnel" to new XML/Python representation
• T2219 (bug): VRF default route of PPPoE and WWAN interfaces do not get added into
proper routing table
• T2222 (default): openvpn: requires "multihome" option to listen on all addresses
with udp protocol
3.3.649 2020-04-02
• T2072 (bug): Shell autocomplete of option (config node) with quoted value doesn't
work
• T1823 (feature): l2tpv3 interface migration fails
• T2202 (feature): Update PowerDNS recursor to 4.2 series
• T2200 (feature): Add VRF support on wirelessmodem interfaces
3.3.650 2020-03-31
3.3.651 2020-03-30
3.3.652 2020-03-29
• T2178 (bug): VRF interface don't get removed when VRF is deleted
• T2170 (feature): Add ability to create static route from default to VRF
• T1831 (feature): Denest IPv6 router-advert from Interfaces to general service
3.3.653 2020-03-28
3.3.654 2020-03-27
3.3.655 2020-03-26
3.3.656 2020-03-25
• T2148 (default): openvpn: setting "server client" config without "server client ip"
results in ValueError: '' does not appear to be an IPv4 or IPv6 address
• T2146 (default): openvpn: "delete server client" doesn't delete the corresponding
ccd configs
3.3.657 2020-03-24
3.3.658 2020-03-22
3.3.659 2020-03-21
• T2142 (bug): vyos-build: Add required packages and step to build-GCE-image script
• T1870 (feature): Extend Pipeline scripts to support PullRequests
3.3.660 2020-03-20
3.3.661 2020-03-19
3.3.662 2020-03-17
3.3.663 2020-03-16
3.3.664 2020-03-15
3.3.665 2020-03-14
3.3.666 2020-03-13
• T1622 (default): Add failsafe and back trace to boot config loader
3.3.667 2020-03-11
• T1961 (bug): VXLAN - fails to commit due to non-existent variable, broken MTU
• T2084 (default): conntrack-tools package build error for current/equuleus
3.3.668 2020-03-10
3.3.669 2020-03-09
3.3.670 2020-03-08
• T1954 (bug): Having `system login radius` configured causes exponentially long boot
times
• T1760 (bug): RADIUS shared secret is not redacted from "show configuration" op mode
command
3.3.671 2020-03-07
• T2107 (bug): Wireless interfaces do not work in station mode without security
3.3.672 2020-03-05
3.3.673 2020-03-04
• T2098 (bug): Wrong call to cli-shell-api in generated op-mode templates for path
completion helper
3.3.674 2020-03-03
3.3.675 2020-03-01
3.3.676 2020-02-29
3.3.677 2020-02-28
3.3.678 2020-02-27
3.3.679 2020-02-25
3.3.680 2020-02-23
3.3.681 2020-02-22
3.3.682 2020-02-20
3.3.683 2020-02-18
3.3.684 2020-02-17
3.3.685 2020-02-16
3.3.686 2020-02-15
• T2042 (bug): Error on reboot after deleting "service snmp" and not "service lldp
snmp enable"
• T2041 (bug): Adding non existent bond interface raises exception
3.3.687 2020-02-14
3.3.688 2020-02-13
3.3.689 2020-02-10
3.3.690 2020-02-09
• T2022 (bug): When RADIUS config is active, local logins won't work
• T2020 (default): Unable to log in after upgrade to 1.3-rolling-202002080217
• T1931 (bug): Enabling SNMP commit error
3.3.691 2020-02-05
3.3.692 2020-02-04
3.3.693 2020-02-02
3.3.694 2020-02-01
3.3.695 2020-01-31
3.3.696 2020-01-30
• T1994 (default): lldpd not bound to specified interfaces - Fix jinja template
• T1896 (enhancment): Remove LLDP-MED civic_based location information
• T1724 (feature): wireguard - add endpoint check in verify()
3.3.697 2020-01-29
3.3.698 2020-01-26
3.3.699 2020-01-24
3.3.700 2020-01-23
3.3.701 2020-01-21
• T1784 (bug): DMVPN with IPSec does not work in HUB mode
• T1977 (bug): webproxy error on fresh install
3.3.702 2020-01-18
3.3.703 2020-01-16
• T1880 (default): "A stop job is running for live-tools - System Support Scripts"
hangs, times out when shutting down equuleus live iso
3.3.704 2020-01-15
3.3.705 2020-01-09
3.3.706 2020-01-08
3.3.707 2020-01-03
3.3.708 2020-01-01
• T1779 (bug): Tunnel interfaces aren't suggested as being available for bridging
3.3.709 2019-12-31
• T1654 (bug): sFlow: multiple "sflow server" not work, and "disable-imt" could break
configuration
• T1923 (feature): Migrate L2TPv3 interface to XML/Python
3.3.710 2019-12-30
• T1920 (bug): beep: Error: Running under sudo, which is not supported for security
reasons.
• T1918 (bug): l2tp / ipsec config broken in latest daily
• T1897 (bug): IPSec - 1.2 to 1.3 migration failed
• T1921 (bug): snmp: VyOS options no longer recognized
• T1922 (feature): Add VXLAN IPv6 support
• T1919 (feature): Migrate "system options" to XML/Python representation
3.3.711 2019-12-28
3.3.712 2019-12-27
3.3.713 2019-12-26
3.3.714 2019-12-23
3.3.715 2019-12-22
3.3.716 2019-12-20
3.3.717 2019-12-19
• T1873 (default): DHCP server fails to start due to a change in isc-dhcp-server init
scripts
3.3.718 2019-12-18
3.3.719 2019-12-17
3.3.720 2019-12-13
3.3.721 2019-12-10
3.3.722 2019-12-08
3.3.723 2019-12-07
3.3.724 2019-12-06
3.3.725 2019-12-05
3.3.726 2019-12-04
3.3.727 2019-12-03
3.3.728 2019-12-02
3.3.729 2019-11-25
3.3.730 2019-11-24
3.3.731 2019-11-23
3.3.732 2019-11-21
3.3.733 2019-11-14
• T1710 (default): [equuleus] buster: add patch to fix live-build missing key error
• T1804 (default): Add python3-psutil to docker image
• T1736 (default): Decide on best practice for patching live-team packages for VyOS
build system
• T1424 (default): Rewrite the config load script
3.3.734 2019-11-11
3.3.735 2019-11-10
3.3.736 2019-11-08
• T1789 (bug): ddclient not working with generated RFC2136 / nsupdate config
3.3.737 2019-11-03
3.3.738 2019-11-02
3.3.739 2019-10-22
3.3.740 2019-10-21
3.3.741 2019-10-19
3.3.742 2019-10-18
3.3.743 2019-10-11
3.3.744 2019-10-09
3.3.745 2019-10-08
3.3.746 2019-10-06
3.3.747 2019-10-03
• T1689 (feature): "reset openvpn" op-mode command should terminate and restart
OpenVPN process
3.3.748 2019-10-01
3.3.749 2019-09-30
3.3.750 2019-09-28
3.3.751 2019-09-27
• T1681 (feature): cleanup wireguard code since tagnodes are now visible
• T1695 (bug): Syntax error in interface-dummy.py
3.3.752 2019-09-26
3.3.753 2019-09-25
3.3.754 2019-09-23
• T1679 (bug): during bootup: invalid literal for int() with base 10
• T1680 (feature): DHCP client does not release IP address on exit/deletion
3.3.755 2019-09-21
• T1676 (default): [equuleus] buster: update GRUB boot parameters during upgrade
• T1637 (feature): Rewrite ethernet interface in new style XML syntax
• T1675 (feature): OpenVPN - Specify minimum TLS version
3.3.756 2019-09-20
• T1602 (default): equuleus: buster: add live build apt options for choosing vyos
packages
3.3.757 2019-09-19
• T1666 (feature): Deleting a bond will place member interfaces into A/D state
3.3.758 2019-09-17
3.3.759 2019-09-16
3.3.760 2019-09-15
3.3.761 2019-09-13
3.3.762 2019-09-12
3.3.763 2019-09-10
3.3.764 2019-09-09
3.3.765 2019-09-07
3.3.766 2019-09-06
3.3.767 2019-09-04
3.3.768 2019-09-02
• T1621 (default): Rewrite the rest of trivial vyatta-op commands to new syntax
3.3.769 2019-08-31
• T1456 (bug): Port group cannot be configured if the same port is configured as
standalone and inside a range
3.3.770 2019-08-28
• T1615 (feature): After migration to pyroute2 the address DHCP statement is no longer
covered
3.3.771 2019-08-27
3.3.772 2019-08-26
• T1591 (bug): OpenVPN "run show openvpn client status" does not work
• T1608 (feature): bridge: Bridge adding non existing interfaces is allowed but does
not work
• T1548 (feature): Rewrite OpenVPN interface/op-commands in new style XML/Python
• T1607 (default): Convert 'reset conntrack' and 'reset ip[v6] cache' operations from
vyatta-op to new syntax
3.3.773 2019-08-25
3.3.774 2019-08-23
• T1606 (bug): Rolling release no longer boots after adding hostname daemon
3.3.775 2019-08-21
• T1601 (feature): Rewrite loopback interface type with new style XML/Python interface
• T1596 (default): Convert 'telnet' and 'traceroute' vyatta-op commands to new syntax
3.3.776 2019-08-20
3.3.777 2019-08-19
• T1580 (feature): Rewrite dummy interface type with new style XML/Python interface
• T1590 (default): Convert 'show system' operations from vyatta-op to python/xml
syntax
3.3.778 2019-08-17
3.3.779 2019-08-15
• T1584 (default): equuleus: buster: add consistent grub options for predictable
interface names
3.3.780 2019-08-13
3.3.781 2019-08-09
3.3.782 2019-08-05
• T1562 (feature): Change version scheme on current branch used for rolling releases
3.3.783 2019-08-04
• T1561 (bug): VyOS rolling ISO cluttered with vyatta-ravpn Git Repo
3.3.784 2019-08-02
3.3.785 2019-08-01
3.3.786 2019-07-31
3.3.787 2019-07-29
3.3.788 2019-07-28
3.3.789 2019-07-23
3.3.790 2019-07-22
3.3.791 2019-07-21
3.3.792 2019-07-18
3.3.793 2019-07-08
3.3.794 2019-07-03
• T1502 (feature): Add build sanity checking tools to the dev builds
3.3.795 2019-07-02
• T1099 (default): Openvpn: use config files instead of one long command.
• T1495 (feature): accel-ppp: IPoE implement IPv6 PD
3.3.796 2019-07-01
3.3.797 2019-06-24
3.3.798 2019-06-23
3.3.799 2019-06-22
3.3.800 2019-06-20
3.3.801 2019-06-19
3.3.802 2019-06-18
3.3.803 2019-06-17
• T1408 (feature): pppoe-server - implement local-ipv6 for pure IPv6 based deployments
3.3.804 2019-06-12
3.3.805 2019-06-05
• T1426 (default): Update the script that checks conntrack hash-size on reboot
3.3.806 2019-06-03
• T1423 (default): When merging remote config files, create known_hosts file if not
present.
3.3.807 2019-05-28
3.3.808 2019-05-26
3.3.809 2019-05-24
3.3.810 2019-05-23
3.3.811 2019-05-22
3.3.812 2019-05-21
3.3.813 2019-05-16
3.3.814 2019-05-06
3.3.815 2019-05-04
3.3.816 2019-04-29
3.3.817 2019-04-21
3.3.818 2019-04-20
3.3.819 2019-04-19
• T1325 (default): GRE tunnel to Cisco router fails in 1.2.0 - works in 1.1.8
3.3.820 2019-04-16
• T1184 (feature): wireguard - extend documentation with the show interface wireguard
commands
3.3.821 2019-04-15
3.3.822 2019-04-05
• T1324 (feature): update documtation for 'set system login user level'
3.3.823 2019-04-04
• T1323 (feature): migrate operator accounts to admin accounts and remove the option
to setup an operator account
3.3.824 2019-03-20
3.3.825 2019-03-12
3.3.826 2019-02-22
3.3.827 2019-02-21
3.3.828 2019-02-10
3.3.829 2019-02-09
3.4 1.2.6-S1
VyOS 1.2.6 release was found to be suspectible to CVE-2020-10995. It’s a low- impact vulnerability in the PowerDNS
recursor that allows an attacker to cause performance degradation via a specially crafted authoritative DNS server reply.
• T2899 remote syslog server migration error on update
3.5 1.2.6
3.6 1.2.5
3.7 1.2.4
• T1421 OpenVPN client push-route stopped working, needs added quotes to fix
• T1430 Add options for custom DHCP client-id and hostname
• T1447 Python subprocess called without import in host_name.py
• T1470 improve output of “show dhcpv6 server leases”
• T1485 Enable ‘AdvIntervalOpt’ option in for radvd.conf
• T1496 Separate rolling release and LTS kernel builds
• T1560 “set load-balancing wan rule 0” causes segfault and prevent load balancing from starting
• T1568 strip-private command improvement for additional masking o IPv6 and MAC address
• T1578 completion offers “show table”, but show table does not exist
• T1593 Support ip6gre
• T1597 /usr/sbin/rsyslogd after deleting “system syslog”
• T1638 vyos-hostsd not setting system domain name
• T1678 hostfile-update missing line feed
• T1694 NTPd: Do not listen on all interfaces by default
• T1701 Delete domain-name and domain-search won’t work
• T1705 High CPU usage by bgpd when snmp is active
• T1707 DHCP static mapping and exclude address not working
• T1708 Update Rolling Release Kernel to 4.19.76
• T1709 Update WireGuard to 0.0.20190913
• T1716 Update Intel NIC drivers to recent versions
• T1726 Update Linux Firmware binaries to a more recen version 2019-03-14 -> 2019-10-07
• T1728 Update Linux Kernel to 4.19.79
• T1737 SNMP tab completion missing
• T1738 Copy SNMP configuration from node to node raises exception
• T1740 Broken OSPFv2 virtual-link authentication
• T1742 NHRP unable to commit.
• T1745 dhcp-server commit fails with “DHCP range stop address must be greater or equal to the range start
address y!” when static mapping has same IP as range stop
• T1749 numeric validator doesn’t support multiple ranges
• T1769 Remove complex SNMPv3 Transport Security Model (TSM)
• T1772 <regex> constraints in XML are partially broken
• T1778 Kilobits/Megabits difference in configuration Vyos/FRR
• T1780 Adding ipsec ike closeaction
• T1786 disable-dhcp-nameservers is missed in current host_name.p implementation
• T1788 Intel QAT (QuickAssist Technology ) implementation
• T1792 Update WireGuard to Debian release 0.0.20191012-1
3.8 1.2.3
• HTTP API
• T1524 “set service dns forwarding allow-from <IPv4 net|IPv6 net>” option for limiting queries to specific client
networks
• T1503 Functions for checking if a commit is in progress
• T1543 “set system contig-mangement commit-archive source-address” option
• T1554 Intel NIC drivers now support receive side scaling and multiqueue
• T1209 OSPF max-metric values over 100 no longer causes commit errors
• T1333 Fixes issue with DNS forwarding not performing recursive lookups on domain specific forwarders
• T1362 Special characters in VRRP passwords are handled correctly
• T1377 BGP weight is applied properly
• T1420 Fixed permission for log files
• T1425 Wireguard interfaces now support /31 addresses
• T1428 Wireguard correctly handles firewall marks
• T1439 DHCPv6 static mappings now work correctly
• T1450 Flood ping commands now works correctly
• T1460 Op mode “show firewall” commands now support counters longer than 8 digits (T1460)
• T1465 Fixed priority inversion in VTI commands
• T1468 Fixed remote-as check in the BGP route-reflector-client option
• T1472 It’s now possible to re-create VRRP groups with RFC compatibility mode enabled
• T1527 Fixed a typo in DHCPv6 server help strings
• T1529 Unnumbered BGP peers now support VLAN interfaces
• T1530 Fixed “set system syslog global archive file” command
• T1531 Multiple fixes in cluster configuration scripts
• T1537 Fixed missing help text for “service dns”
• T1541 Fixed input validation in DHCPv6 relay options
• T1551 It’s now possible to create a QinQ interface and a firewall assigned to it in one commit
• T1559 URL filtering now uses correct rule database path and works again
• T1579 “show log vpn ipsec” command works again
• T1576 “show arp interface <intf>” command works again
• T1605 Fixed regression in L2TP/IPsec server
• T1613 Netflow/sFlow captures IPv6 traffic correctly
• T1616 “renew dhcpv6” command now works from op mode
• T1642 BGP remove-private-as option iBGP vs eBGP check works correctly now
• T1540, T1360, T1264, T1623 Multiple improvements in name servers and hosts configuration handling
3.8.3 Internals
/etc/resolv.conf and /etc/hosts files are now managed by the vyos-hostsd service that listens on a ZMQ socket
for update messages.
3.9 1.2.2
• Linux kernel 4.19.54, including a fix for the TCP SACK vulnerability
• T1371 VRRP health-check scripts now can use arguments
• T1497 DNS server addresses coming from a DHCP server are now correctly propagated to resolv.conf
• T1469 Domain-specific name servers in DNS forwarding are now used for recursive queries
• T1433 run show dhcpv6 server leases now display leases correctly
• T1461 Deleting firewall options node no longer causes errors
• T1458 Correct hostname is sent to remote syslog again
• T1438 Board serial number from DMI is correctly displayed in show version
• T1358, T1355, T1294 Multiple corrections in remote syslog config
• T1255 Fixed missing newline in /etc/hosts
• T1174 system domain-name is correctly included in /etc/resolv.conf
• T1465 Fixed priority inversion in interfaces vti vtiX ip settings
• T1446 Fixed errors when installing with RAID1 on UEFI machines
• T1387 Fixed an error on disabling an interfaces that has no address
• T1367 Fixed deleting VLAN interface with non-default MTU
• T1505 vyos.config return_effective_values() function now correctly returns a list rather than a string
3.10 1.2.1
• Package updates: kernel 4.19.32, open-vm-tools 10.3, latest Intel NIC drivers
• T1326 The kernel now includes drivers for various USB serial adapters, which allows people to add a serial
console to a machine without onboard RS232, or connect to something else from the router
• The collection of network card firmware is now much more extensive
• T1271 VRRP now correctly uses a virtual rather than physical MAC addresses in the RFC-compliant mode
• T1330 DHCP WPAD URL option works correctly again
• T1312 Many to many NAT rules now can use source/destination and translation networks of non-matching size.
If 1:1 network bits translation is desired, it’s now users responsibility to check if prefix length matches.
• T1290 IPv6 network prefix translation is fixed
• T1308 Non-alphanumeric characters such as > can now be safely used in PPPoE passwords
• T1305 show | commands no longer fails when a config section ends with a leaf node such as timezone in show
system | commands
• T1235 show | commands correctly works in config mode now
• T1298 VTI is now compatible with the DHCP-interface IPsec option
• T1277 show dhcp server statistics command was broken in latest Crux
• T1261 An issue with TFTP server refusing to listen on addresses other than loopback was fixed
• T1224 Template issue that might cause UDP broadcast relay fail to start is fixed
• T1067 VXLAN value validation is improved
• T1211 Blank hostnames in DHCP updates no longer can crash DNS forwarding
• T1322 Correct configuration is now generated for DHCPv6 relays with more than one upstream interface
• T1234 relay-agents-packets option works correctly now
• T1231 Dynamic DNS data is now cleaned on configuration change
• T1282 Remote Syslog can now use a fully qualified domain name
• T1279 ACPI power off works again
• T1247 Negation in WAN load balancing rules works again
• T1218 FRR staticd now starts on boot correctly
• T1296 The installer now correctly detects SD card devices
• T1225 Wireguard peers can be disabled now
• T1217 The issue with Wireguard interfaces impossible to delete is fixed
• T1160 Unintended IPv6 access is fixed in SNMP configuration
• T1060 It’s now possible to exclude hosts from the transparent web proxy
• T484 An issue with rules impossible to delete from the zone-based firewall is fixed
FOUR
4.1 Installation
VyOS installation requires a downloaded VyOS .iso file. That file is a live install image that lets you boot a live VyOS.
From the live system, you can proceed to a permanent installation on a hard drive or any other type of storage.
290
VyOS Documentation, Release 1.5.x (circinus)
The minimum system requirements are 1024 MiB RAM and 2 GiB storage. Depending on your use, you might need
additional RAM and CPU resources e.g. when having multiple BGP full tables in your system.
4.1.2 Download
Registered Subscribers
Registered subscribers can log into https://support.vyos.io/ to access a variety of different downloads via the “Down-
loads” link. These downloads include LTS (Long-Term Support), the associated hot-fix releases, early public access
releases, pre-built VM images, as well as device specific installation ISOs.
Non-subscribers can always get the LTS release by building it from source. Instructions can be found in the Build VyOS
section of this manual. VyOS source code repository is available for everyone at https://github.com/vyos/vyos-build.
Rolling Release
Note: Rolling releases contain all the latest enhancements and fixes. This means that there will be new bugs of course.
If you think you hit a bug please follow the guide at Bug Report/Issue. We depend on your feedback to improve VyOS!
The following link will always fetch the most recent VyOS build for AMD64 systems from the current branch: https:
//downloads.vyos.io/rolling/current/amd64/vyos-rolling-latest.iso
Download Verification
LTS images are signed by the VyOS lead package-maintainer private key. With the official public key, the authenticity
of the package can be verified. GPG (GNU Privacy Guard) is used for verification.
Note: This subsection only applies to LTS images, for Rolling images please jump to Live installation.
First, install GPG or another OpenPGP implementation. On most GNU+Linux distributions it is installed by default as
package managers use it to verify package signatures. If not pre-installed, it will need to be downloaded and installed.
The official VyOS public key can be retrieved in a number of ways. Skip to GPG verification if the key is already
present.
It can be retrieved directly from a key server:
gpg --recv-keys FD220285A0FE6D7E
Or it can be accessed via a web browser:
https://pgp.mit.edu/pks/lookup?op=get&search=0xFD220285A0FE6D7E
Or from the following block:
mQINBFXKsiIBEACyid9PR/v56pSRG8VgQyRwvzoI7rLErZ8BCQA2WFxA6+zNy+6G
+0E/6XAOzE+VHli+wtJpiVJwAh+wWuqzOmv9css2fdJxpMW87pJAS2i3EVVVf6ab
wU848JYLGzc9y7gZrnT1m2fNh4MXkZBNDp780WpOZx8roZq5X+j+Y5hk5KcLiBn/
lh9Zoh8yzrWDSXQsz0BGoAbVnLUEWyo0tcRcHuC0eLx6oNG/IHvd/+kxWB1uULHU
SlB/6vcx56lLqgzywkmhP01050ZDyTqrFRIfrvw6gLQaWlgR3lB93txvF/sz87Il
VblV7e6HEyVUQxedDS8ikOyzdb5r9a6Zt/j8ZPSntFNM6OcKAI7U1nDD3FVOhlVn
7lhUiNc+/qjC+pR9CrZjr/BTWE7Zpi6/kzeH4eAkfjyALj18oC5udJDjXE5daTL3
k9difHf74VkZm29Cy9M3zPckOZpsGiBl8YQsf+RXSBMDVYRKZ1BNNLDofm4ZGijK
mriXcaY+VIeVB26J8m8y0zN4/ZdioJXRcy72c1KusRt8e/TsqtC9UFK05YpzRm5R
/nwxDFYb7EdY/vHUFOmfwXLaRvyZtRJ9LwvRUAqgRbbRZg3ET/tn6JZk8hqx3e1M
IxuskOB19t5vWyAo/TLGIFw44SErrq9jnpqgclTSRgFjcjHEm061r4vjoQARAQAB
tDZWeU9TIE1haW50YWluZXJzIChWeU9TIFJlbGVhc2UpIDxtYWludGFpbmVyc0B2
eW9zLm5ldD6JAjgEEwECACIFAlXKsiICGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4B
AheAAAoJEP0iAoWg/m1+xbgP+QEDYZi5dA4IPY+vU1L95Bavju2m2o35TSUDPg5B
jfAGuhbsNUceU+l/yUlxjpKEmvshyW3GHR5QzUaKGup/ZDBo1CBxZNhpSlFida2E
KAYTx4vHk3MRXcntiAj/hIJwRtzCUp5UQIqHoU8dmHoHOkKEP+zhJuR6E2s+WwDr
nTwE6eRa0g/AHY+chj2Je6flpPm2CKoTfUE7a2yBBU3wPq3rGtsQgVxPAxHRZz7A
w4AjH3NM1Uo3etuiDnGkJAuoKKb1J4X3w2QlbwlR4cODLKhJXHIufwaGtRwEin9S
1l2bL8V3gy2Hv3D2t9TQZuR5NUHsibJRXLSa8WnSCcc6Bij5aqfdpYB+YvKH/rIm
GvYPmLZDfKGkx0JE4/qtfFjiPJ5VE7BxNyliEw/rnQsxWAGPqLlL61SD8w5jGkw3
CinwO3sccTVcPz9b6A1RsbBVhTJJX5lcPn1lkOEVwQ7l8bRhOKCMe0P53qEDcLCd
KcXNnAFbVes9u+kfUQ4oxS0G2JS9ISVNmune+uv+JR7KqSdOuRYlyXA9uTjgWz4y
Cs7RS+CpkJFqrqOtS1rmuDW9Ea4PA8ygGlisM5d/AlVkniHz/2JYtgetiLCj9mfE
MzQpgnldNSPumKqJ3wwmCNisE+lXQ5UXCaoaeqF/qX1ykybQn41LQ+0xT5Uvy7sL
9IwGuQINBFXKsiIBEACg2mP3QYkXdgWTK5JyTGyttE6bDC9uqsK8dc1J66Tjd5Ly
Be0amO+88GHXa0o5Smwk2QNoxsRR41G/D/eAeGsuOEYnePROEr3tcLnDjo4KLgQ+
H69zRPn77sdP3A34Jgp+QIzByJWM7Cnim31quQP3qal2QdpGJcT/jDJWdticN76a
Biaz+HN13LyvZM+DWhUDttbjAJc+TEwF9YzIrU+3AzkTRDWkRh4kNIQxjlpNzvho
9V75riVqg2vtgPwttPEhOLb0oMzy4ADdfezrfVvvMb4M4kY9npu4MlSkNTM97F/I
QKy90JuSUIjE05AO+PDXJF4Fd5dcpmukLV/2nV0WM2LAERpJUuAgkZN6pNUFVISR
+nSfgR7wvqeDY9NigHrJqJbSEgaBUs6RTk5hait2wnNKLJajlu3aQ2/QfRT/kG3h
ClKUz3Ju7NCURmFE6mfsdsVrlIsEjHr/dPbXRswXgC9FLlXpWgAEDYi9Wdxxz8o9
JDWrVYdKRGG+OpLFh8AP6QL3YnZF+p1oxGUQ5ugXauAJ9YS55pbzaUFP8oOO2P1Q
BeYnKRs1GcMI8KWtE/fze9C9gZ7Dqju7ZFEyllM4v3lzjhT8muMSAhw41J22mSx6
VRkQVRIAvPDFES45IbB6EEGhDDg4pD2az8Q7i7Uc6/olEmpVONSOZEEPsQe/2wAR
(continues on next page)
Store the key in a new text file and import it into GPG via: gpg --import file_with_the_public_key
The import can be verified with:
$ gpg --list-keys
...
pub rsa4096 2015-08-12 [SC]
0694A9230F5139BF834BA458FD220285A0FE6D7E
uid [ unknown] VyOS Maintainers (VyOS Release) <[email protected]>
sub rsa4096 2015-08-12 [E]
GPG verification
With the public key imported, the signature for the desired image needs to be downloaded.
Note: The signature can be downloaded by appending .asc to the URL of the downloaded VyOS image. That small
.asc file is the signature for the associated image.
Primary key fingerprint: 0694 A923 0F51 39BF 834B A458 FD22 0285 A0FE 6D7E
Minisign verification
Currently we are using GPG for release signing (pretty much like everyone else).
Popularity of GPG for release signing comes from the fact that many people already had it installed for email encryp-
tion/signing. Inside a VyOS image, signature checking is the only reason to have it installed. However, it still comes
with all the features no one needs, such as support for multiple outdated cipher suits and ability to embed a photo in
the key file. More importantly, web of trust, the basic premise of PGP, is never used in release signing context. Once
you have a knowingly authentic image, authenticity of upgrades is checked using a key that comes in the image, and to
get their first image people never rely on keyservers either.
Another point is that we are using RSA now, which requires absurdly large keys to be secure.
In 2015, OpenBSD introduced signify. An alternative implementation of the same protocol is minisign, which is also
available for Windows and macOS, and in most GNU/Linux distros it’s in the repositories now.
Its installed size (complete with libsodium) is less than that of GPG binary alone (not including libgcrypt and some
other libs, which I think we only use for GPG). Since it uses elliptic curves, it gets away with much smaller keys, and
it doesn’t include as much metadata to begin with.
Another issue of GPG is that it creates a /root/.gnupg directory just for release checking. The dir is small so the fact
that it’s never used again is an aesthetic problem, but we’ve had that process fail in the past. But, small key size of the
Ed25519 algorithm allows passing public keys in command line arguments, so verification process can be completely
stateless:
T2108 switched the validation system to prefer minisign over GPG keys.
To verify a VyOS image starting off with VyOS 1.3.0-rc6 you can run:
Note: A permanent VyOS installation always requires to go first through a live installation.
VyOS, as other GNU+Linux distributions, can be tested without installing it in your hard drive. With your downloaded
VyOS .iso file you can create a bootable USB drive that will let you boot into a fully functional VyOS system.
Once you have tested it, you can either decide to begin a Permanent installation in your hard drive or power your system
off, remove the USB drive, and leave everything as it was.
If you have a GNU+Linux system, you can create your VyOS bootable USB stick with with the dd command:
1. Open your terminal emulator.
2. Find out the device name of your USB drive (you can use the lsblk command)
3. Unmount the USB drive. Replace X in the example below with the letter of your device and keep the
asterisk (wildcard) to unmount all partitions.
$ umount /dev/sdX*
4. Write the image (your VyOS .iso file) to the USB drive. Note that here you want to use the device
name (e.g. /dev/sdb), not the partition name (e.g. /dev/sdb1).
Warning: This will destroy all data on the USB drive!
5. Wait until you get the outcome (bytes copied). Be patient, in some computers it might take more than
one minute.
6. Once dd has finished, pull the USB drive out and plug it into the powered-off computer where you
want to install (or test) VyOS.
7. Power the computer on, making sure it boots from the USB drive (you might need to select booting
device or change booting settings).
8. Once VyOS is completely loaded, enter the default credentials (login: vyos, password: vyos).
If you find difficulties with this method, prefer to use a GUI program, or have a different operating system, there are
other programs you can use to create a bootable USB drive, like balenaEtcher (for GNU/Linux, macOS and Windows),
Rufus (for Windows) and many others. You can follow their instructions to create a bootable USB drive from an .iso
file.
Hint: The default username and password for the live system is vyos.
Unlike general purpose Linux distributions, VyOS uses “image installation” that mimics the user experience of tradi-
tional hardware routers and allows keeping multiple VyOS versions installed simultaneously. This makes it possible to
switch to a previous version if something breaks or miss-behaves after an image upgrade.
Every version is contained in its own squashfs image that is mounted in a union filesystem together with a directory for
mutable data such as configurations, keys, or custom scripts.
Note: Older versions (prior to VyOS 1.1) used to support non-image installation (install system command).
Support for this has been removed from VyOS 1.2 and newer releases. Older releases can still be upgraded via the
general add system image <image_path> upgrade command (consult Image Management for further information).
Which drive should GRUB modify the boot partition on? [sda]:
Setting up grub: OK
Done!
3. After the installation is completed, remove the live USB stick or CD.
4. Reboot the system.
vyos@vyos:~$ reboot
Proceed with reboot? (Yes/No) [No] Yes
VyOS can also be installed through PXE. This is a more complex installation method that allows deploying VyOS
through the network.
Requirements
• Clients (where VyOS is to be installed) with a PXE-enabled NIC
• DHCP Server
• TFTP Server
• Webserver (HTTP) - optional, but we will use it to speed up installation
• VyOS ISO image to be installed (do not use images prior to VyOS 1.2.3)
• Files pxelinux.0 and ldlinux.c32 from the Syslinux distribution
Configuration
Step 1: DHCP
Step 2: TFTP
LABEL VyOS123
KERNEL vmlinuz
APPEND initrd=initrd.img-4.19.54-amd64-vyos boot=live nopersistence noautologin␣
˓→nonetworking fetch=http://address:8000/filesystem.squashfs
Step 3: HTTP
We also need to provide the filesystem.squashfs file. That is a heavy file and TFTP is slow, so you could send it through
HTTP to speed up the transfer. That is how it is done in our example, you can find that in the configuration file above.
First run a web server - you can use a simple one like Python’s SimpleHTTPServer and start serving the filesys-
tem.squashfs file. The file can be found inside the /live directory of the extracted contents of the ISO file.
Second, edit the configuration file of the Step 2: TFTP so that it shows the correct URL at fetch=http://
<address_of_your_HTTP_server>/filesystem.squashfs.
Note: Do not change the name of the filesystem.squashfs file. If you are working with different versions, you can
create different directories instead.
And third, restart the TFTP service. If you are using VyOS as your TFTP Server, you can restart the service with sudo
service tftpd-hpa restart.
Note: Make sure the available directories and files in both TFTP and HTTP server have the right permissions to be
accessed from the booting clients.
Client Boot
Finally, turn on your PXE-enabled client or clients. They will automatically get an IP address from the DHCP server
and start booting into VyOS live from the files automatically taken from the TFTP and HTTP servers.
Once finished you will be able to proceed with the install image command as in a regular VyOS installation.
GRUB attempts to redirect all output to a serial port for ease of installation on headless hosts. This appears to cause
an hard lockup on some hardware that lacks a serial port, with the result being a black screen after selecting the Live
system option from the installation image.
The workaround is to type e when the boot menu appears and edit the GRUB boot options. Specifically, remove the:
console=ttyS0,115200
option, and type CTRL-X to boot.
Installation can then continue as outlined above.
Libvirt is an open-source API, daemon and management tool for managing platform virtualization. There are several
ways to deploy VyOS on libvirt kvm. Use Virt-manager and native CLI. In an example we will be use use 4 gigabytes
of memory, 2 cores CPU and default network virbr0.
CLI
Create VM name vyos_r1. You must specify the path to the ISO image, the disk qcow2 will be created automatically.
The default network is the virtual network (type Virtio) created by the hypervisor with NAT.
$ virt-install -n vyos_r1 \
--ram 4096 \
--vcpus 2 \
--cdrom /var/lib/libvirt/images/vyos.iso \
--os-variant debian10 \
--network network=default \
--graphics vnc \
--hvm \
--virt-type kvm \
--disk path=/var/lib/libvirt/images/vyos_r1.qcow2,bus=virtio,size=8 \
--noautoconsole
After installation - exit from the console using the key combination Ctrl + ] and reboot the system.
The convenience of using KVM (Kernel-based Virtual Machine) images is that they don’t need to be installed. Down-
load predefined VyOS.qcow2 image for KVM
$ virt-install -n vyos_r2 \
--ram 4096 \
--vcpus 2 \
--os-variant debian10 \
--network network=default \
--graphics vnc \
--hvm \
--virt-type kvm \
--disk path=/var/lib/libvirt/images/vyos_kvm.qcow2,bus=virtio \
--import \
--noautoconsole
vyos@vyos:~$
Stayed in this stage. This is because the KVM console is chosen as the default boot option.
Open a secondary/parallel session and use this command to reboot the VM:
Then go to the first session where you opened the console. Select VyOS 1.4.x for QEMU (Serial console) and
press Enter
The system is fully operational.
Virt-manager
The virt-manager application is a desktop user interface for managing virtual machines through libvirt. On the linux
open VMM (Virtual Machine Manager).
3. Choose path to iso vyos.iso. Operating System can be any Debian based.
4. Choose Memory and CPU
5. Disk size
6. Name of VM and network selection
7. Then you will be taken to the console.
3. Choose the path to the image vyos_kvm.qcow2 that was previously downloaded . Operation System can be any
Debian based.
4. Choose Memory and CPU
5. Name of VM and network selection
6. Then you will be taken to the console.
Proxmox is an open-source platform for virtualization. Please visit https://vyos.io to see how to get a qcow2 image that
can be imported into Proxmox.
3. Optionally, the user can attach a CDROM with an ISO as a cloud-init data source. The below command assumes
the ISO has been uploaded to the local storage pool with the name seed.iso.
4. Start the virtual machine in the proxmox GUI or CLI using qm start 200.
1. Download the rolling release iso from https://vyos.net/get/nightly-builds/. Non-subscribers can always get the
LTS release by building it from source. Instructions can be found in the Build VyOS section of this manual.
VyOS source code repository is available https://github.com/vyos/vyos-build.
2. Prepare VM for installation from ISO media. The commands below assume that your iso is available in a storage
pool ‘local’, that you want it to have a VM ID ‘200’ and want to create a new disk on storage pool ‘local-lvm’ of
size 15GB.
qm create 200 --name vyos --memory 2048 --net0 virtio,bridge=vmbr0 --ide2 media=cdrom,
˓→file=local:iso/live-image-amd64.hybrid.iso --virtio0 local-lvm:15
3. Start the VM using the command qm start 200 or using the start button located in the proxmox GUI.
4. Using the proxmox webGUI, open the virtual console for your newly created vm. Login username/password is
vyos/vyos.
5. Once booted into the live system, type install image into the command line and follow the prompts to install
VyOS to the virtual drive.
6. After installation has completed, remove the installation iso using the GUI or qm set 200 --ide2 none.
7. Reboot the virtual machine using the GUI or qm reboot 200.
Visit https://www.proxmox.com/en/ for more information about the download and installation of this hypervisor.
.ova files are available for supporting users, and a VyOS can also be stood up using a generic Linux instance, and
attaching the bootable ISO file and installing from the ISO using the normal process around install image.
Note: There have been previous documented issues with GRE/IPSEC tunneling using the E1000 adapter on the VyOS
guest, and use of the VMXNET3 has been advised.
When the underlying ESXi host is approaching ~92% memory utilisation it will start the balloon process in a ‘soft’
state to start reclaiming memory from guest operating systems. This causes an artificial pressure using the vmmemctl
driver on memory usage on the virtual guest. As VyOS by default does not have a swap file, this vmmemctl pressure is
unable to force processes to move in memory data to the paging file, and blindly consumes memory forcing the virtual
guest into a low memory state with no way to escape. The balloon can expand to 65% of guest allocated memory,
so a VyOS guest running >35% of memory usage, can encounter an out of memory situation, and trigger the kernel
oom_kill process. At this point a weighted lottery favouring memory hungry processes will be run with the unlucky
winner being terminated by the kernel.
It is advised that VyOS routers are configured in a resource group with adequate memory reservations so that ballooning
is not inflicted on virtual VyOS guests.
References
https://muralidba.blogspot.com/2018/03/how-does-linux-out-of-memory-oom-killer.html
Sometimes you may want to test VyOS in a lab environment. GNS3 is a network emulation software you might use for
it.
This guide will provide the necessary steps for installing and setting up VyOS on GNS3.
Requirements
VM setup
First, a virtual machine (VM) for the VyOS installation must be created in GNS3.
Go to the GNS3 File menu, click New template and choose select Manually create a new Template.
Note: You probably will want to accept to copy the .iso file to your default image directory when you are asked.
In the Network tab, set 0 as the number of adapters, set the Name format to eth{0} and the Type to Paravirtualized
Network I/O (virtio-net-pci).
In the Advanced tab, unmark the checkbox Use as a linked base VM and click OK, which will save and close the
QEMU VM template configuration window.
At the general Preferences window, click OK to save and close.
VyOS installation
VyOS VM configuration
To turn the template into a working VyOS machine, further steps are necessary as outlined below:
General settings tab: Set the boot priority to HDD
CD/DVD tab: Unmount the installation image file by clearing the Image entry field.
Set the number of required network adapters, for example 4.
Advanced settings tab: Mark the checkbox Use as a linked base VM and click OK to save the changes.
The VyOS VM is now ready to be deployed.
4.2.5 EVE-NG
References
https://www.eve-ng.net/
Docker is an open-source project for deploying applications as standardized units called containers. Deploying VyOS
in a container provides a simple and lightweight mechanism for both testing and packet routing for container workloads.
VyOS requires an IPv6-enabled docker network. Currently linux distributions do not enable docker IPv6 support by
default. You can enable IPv6 support in two ways.
Edit /etc/docker/daemon.json to set the ipv6 key to true and to specify the fixed-cidr-v6 to your desired IPv6
subnet.
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8::/64"
}
Download the ISO on which you want to base the container. In this example, the name of the ISO is vyos-1.
4-rolling-202308240020-amd64.iso. If you created a custom IPv6-enabled network, the docker run command
below will require that this network be included as the --net parameter to docker run.
˓→202308240020-amd64.iso
$ mkdir rootfs
(continues on next page)
You can execute docker stop vyos when you are finished with the container.
Deploy VM
4. Configure instance for your requirements. Select number of instances / network / subnet
5. Additional storage. You can remove additional storage /dev/sdb. First root device will be /dev/xvda. You
can skip this step.
6. Configure Security Group. It’s recommended that you configure ssh access only from certain address sources.
Or permit any (by default).
7. Select SSH key pair and click Launch Instances
8. Find out your public IP address.
9. Connect to the instance by SSH key.
To use Amazon CloudWatch Agent, configure it within the Amazon SSM Parameter Store. If you don’t have a config-
uration yet, do CloudWatch SSM Configuration creation.
1. Create an IAM (Identity and Access Management) role for the EC2 (Elastic Compute Cloud) instance to access
CloudWatch service, and name it CloudWatchAgentServerRole. The role should contain two default policies:
CloudWatchAgentServerPolicy and AmazonSSMManagedInstanceCore.
2. Attach the created role to your VyOS EC2 instance.
3. Ensure that amazon-cloudwatch-agent package is installed.
Note: The amazon-cloudwatch-agent package is normally included in VyOS 1.3.3+ and 1.4+
3. Retrieve an existing CloudWatch Agent configuration from the SSM (Systems Manager) Parameter Store.
Note: The VyOS platform-specific scripts feature is under development. Thus, this step should be re-
peated manually after changing system image (Update VyOS)
Creating the Amazon Cloudwatch Agent Configuration in Amazon SSM Parameter Store.
1. Create an IAM role for your EC2 instance to access the CloudWatch service. Name it CloudWatchAgentAdmin-
Role. The role should contain at two default policies: CloudWatchAgentAdminPolicy and AmazonSSMMan-
agedInstanceCore.
Note: CloudWatchAgentServerRole is too permissive and should be used for single configuration cre-
ation and deployment. That’s why after completion of step #3 highly recommended to replace instance
CloudWatchAgentAdminRole role with CloudWatchAgentServerRole.
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-
˓→wizard
3. When prompted, answer “yes” to the question “Do you want to store the config in the SSM parameter store?”.
References
• https://console.aws.amazon.com/
• https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-iam-roles-for-cloudwatch-agent.
html
• https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance-fleet.
html
4.3.2 Azure
Deploy VM
Add interface
If instance was deployed with one eth0 WAN interface and want to add new one. To add new interface an example eth1
LAN you need shutdown the instance. Attach the interface in the Azure portal and then start the instance.
Note: Azure does not allow you attach interface when the instance in the Running state.
Absorbing Routes
If using as a router, you will want your LAN interface to absorb some or all of the traffic from your VNET by using a
route table applied to the subnet.
1. Create a route table and browse to Configuration
2. Add one or more routes for networks you want to pass through the VyOS VM. Next hop type Virtual Appliance
with the Next Hop Address of the VyOS LAN interface.
Note: If you want to create a new default route for VMs on the subnet, use Address Prefix 0.0.0.0/0 Also note that
if you want to use this as a typical edge device, you’ll want masquerade NAT for the WAN interface.
Serial Console
Azure has a way to access the serial console of a VM, but this needs to be configured on the VyOS. It’s there by default,
but keep it in mind if you are replacing config.boot and rebooting: set system console device ttyS0 speed
'9600'
References
https://azure.microsoft.com
Deploy VM
Note: In name “vyos@mypc” The first value must be “vyos”. Because default user is vyos and google api uses this
option.
2. Open GCP console and navigate to the menu Metadata. Choose SSH Keys and click edit.
Click Add item and paste your public ssh key. Click Save.
References
https://console.cloud.google.com/
4.3.4 Oracle
References
https://www.oracle.com/cloud/
I opted to get one of the new Intel Atom C3000 CPUs to spawn VyOS on it. Running VyOS on an UEFI only device
is supported as of VyOS release 1.2.
Shopping Cart
Optional (10GE)
If you want to get additional ethernet ports or even 10GE connectivity the following optional parts will be required:
• 1x Supermicro RSC-RR1U-E8 (Riser Card)
• 1x Supermicro MCP-120-00063-0N (Riser Card Bracket)
Latest VyOS rolling releases boot without any problem on this board. You also receive a nice IPMI interface realized
with an ASPEED AST2400 BMC (no information about OpenBMC so far on this motherboard).
Pictures
As this platform seems to be quite common in terms of noise, cost, power and performance it makes sense to write a
small installation manual.
This guide was developed using an APU4C4 board with the following specs:
• AMD Embedded G series GX-412TC, 1 GHz quad Jaguar core with 64 bit and AES-NI support, 32K data +
32K instruction cache per core, shared 2MB L2 cache.
• 4 GB DDR3-1333 DRAM, with optional ECC support
• About 6 to 10W of 12V DC power depending on CPU load
• 2 miniPCI express (one with SIM socket for 3G modem).
• 4 Gigabit Ethernet channels using Intel i211AT NICs
The board can be powered via 12V from the front or via a 5V onboard connector.
Shopping Cart
Extension Modules
WiFi
Refer to WLAN/WIFI - Wireless LAN for additional information, below listed modules have been tested successfully
on this Hardware platform:
• Compex WLE900VX mini-PCIe WiFi module, only supported in mPCIe slot 1.
• Intel Corporation AX200 mini-PCIe WiFi module, only supported in mPCIe slot 1. (see Intel AX200)
WWAN
Refer to WWAN - Wireless Wide-Area-Network for additional information, below listed modules have been tested suc-
cessfully on this Hardware platform using VyOS 1.3 (equuleus):
• Sierra Wireless AirPrime MC7304 miniPCIe card (LTE)
• Sierra Wireless AirPrime MC7430 miniPCIe card (LTE)
• Sierra Wireless AirPrime MC7455 miniPCIe card (LTE)
• Sierra Wireless AirPrime MC7710 miniPCIe card (LTE)
• Huawei ME909u-521 miniPCIe card (LTE)
Depending on the VyOS versions you intend to install there is a difference in the serial port settings (T1327).
Create a bootable USB pendrive using e.g. Rufus on a Windows machine.
Connect serial port to a PC through null modem cable (RXD / TXD crossed over). Set terminal emulator to 115200
8N1.
PC Engines apu4
coreboot build 20171130
BIOS version v4.6.4
4080 MB ECC DRAM
SeaBIOS (version rel-1.11.0.1-0-g90da88d)
Now boot from the USB MSC Drive Generic Flash Disk 8.07 media by pressing 2, the VyOS boot menu will
appear, just wait 10 seconds or press Enter to continue.
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x VyOS - Boot Menu x
tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu
x Live (amd64-vyos) x
x Live (amd64-vyos failsafe) x
x x
mqqqqqqPress ENAutomatic boot in 10 seconds...nu entryqqqqqqqj
The image will be loaded and the last lines you will get will be:
Loading /live/vmlinuz... ok
Loading /live/initrd.img...
The Kernel will now spin up using a different console setting. Set terminal emulator to 9600 8N1 and after a while
your console will show:
Loading /live/vmlinuz... ok
Loading /live/initrd.img...
Welcome to VyOS - vyos ttyS0
vyos login:
You can now proceed with a regular image installation as described in Installation.
As the APU board itself still used a serial setting of 115200 8N1 it is strongly recommended that you change the VyOS
serial interface settings after your first successful boot.
Use the following command to adjust the Serial Console settings:
Note: Once you commit the above changes access to the serial interface is lost until you set your terminal emulator to
115200 8N1 again.
Installing the rolling release on an APU2 board does not require any change on the serial console from your host side
as T1327 was successfully implemented.
Simply proceed with a regular image installation as described in Installation.
Pictures
Note: Both device types operate without any moving parts and emit zero noise.
Rack Mount
The install on this Q355G4 box is pretty much plug and play. The port numbering the OS does might differ from the
labels on the outside, but the UEFI firmware has a port blink test built in with MAC addresses so you can very quickly
identify which is which. MAC labels are on the inside as well, and this test can be done from VyOS or plain Linux too.
Default settings in the UEFI will make it boot, but depending on your installation wishes (i.e. storage type, boot type,
console type) you might want to adjust them. This Qotom company seems to be the real OEM/ODM for many other
relabelling companies like Protectli.
Hardware
There are a number of other options, but they all seem to be close to Intel reference designs, with added features like
more serial ports, more network interfaces and the likes. Because they don’t deviate too much from standard designs
all the hardware is well-supported by mainline. It accepts one LPDDR3 SO-DIMM, but chances are that if you need
more than that, you’ll also want something even beefier than an i5. There are options for antenna holes, and SIM slots,
so you could in theory add an LTE/Cell modem (not tested so far).
The chassis is a U-shaped alu extrusion with removable I/O plates and removable bottom plate. Cooling is completely
passive with a heatsink on the SoC with internal and external fins, a flat interface surface, thermal pad on top of that,
which then directly attaches to the chassis, which has fins as well. It comes with mounting hardware and rubber feet,
so you could place it like a desktop model or mount it on a VESA mount, or even wall mount it with the provided
mounting plate. The closing plate doubles as internal 2.5” mounting place for an HDD or SSD, and comes supplied
with a small SATA cable and SATA power cable.
Power supply is a 12VDC barrel jack, and included switching power supply, which is why SATA power regulation is
on-board. Internally it has a NUC-board-style on-board 12V input header as well, the molex locking style.
There are WDT options and auto-boot on power enable, which is great for remote setups. Firmware is reasonably
secure (no backdoors found, BootGuard is enabled in enforcement mode, which is good but also means no coreboot
option), yet has most options available to configure (so it’s not locked out like most firmwares are).
An external RS232 serial port is available, internally a GPIO header as well. It does have Realtek based audio on board
for some reason, but you can disable that. Booting works on both USB2 and USB3 ports. Switching between serial
BIOS mode and HDMI BIOS mode depends on what is connected at startup; it goes into serial mode if you disconnect
HDMI and plug in serial, in all other cases it’s HDMI mode.
4.4.4 Partaker i5
I believe this is actually the same hardware as the Protectli. I purchased it in June 2018. It came pre-loaded with
pfSense.
Manufacturer product page.
Installation
This microbox network appliance was build to create OpenVPN bridges. It can saturate a 100Mbps link. It is a small
(serial console only) PC with 6 Gb LAN
You may have to add your own RAM and HDD/SSD. There is no VGA connector. But Acrosser provides a DB25
adapter for the VGA header on the motherboard (not used).
BIOS Settings:
First thing you want to do is getting a more user friendly console to configure BIOS. Default VT100 brings a lot of
issues. Configure VT100+ instead.
For practical issues change speed from 115200 to 9600. 9600 is the default speed at which both linux kernel and VyOS
will reconfigure the serial port when loading.
Connect to serial (115200bps). Power on the appliance and press Del in the console when requested to enter BIOS
settings.
Advanced > Serial Port Console Redirection > Console Redirection Settings:
• Terminal Type : VT100+
• Bits per second : 9600
Save, reboot and change serial speed to 9600 on your client.
Some options have to be changed for VyOS to boot correctly. With XHCI enabled the installer can’t access the USB
key. Enable EHCI instead.
Reboot into BIOS, Chipset > South Bridge > USB Configuration:
• Disable XHCI
• Enable USB 2.0 (EHCI) Support
Install VyOS:
Create a VyOS bootable USB key. I used the 64-bit ISO (VyOS 1.1.7) and LinuxLive USB Creator.
I’m not sure if it helps the process but I changed default option to live-serial (line “default xxxx”) on the USB key under
syslinux/syslinux.cfg.
I connected the key to one black USB port on the back and powered on. The first VyOS screen has some readability
issues. Press Enter to continue.
Then VyOS should boot and you can perform the install image
New system images can be added using the add system image command. The command will extract the chosen
image and will prompt you to use the current system configuration and SSH security keys, allowing for the new image
to boot using the current configuration.
add system image <url | path> | [latest] [vrf name] [username user [password pass]]
Use this command to install a new system image. You can reach the image from the web (http://, https://)
or from your local system, e.g. /tmp/vyos-1.2.3-amd64.iso.
The add system image command also supports installing new versions of VyOS through an optional given VRF.
Also if URL in question requires authentication, you can specify an optional username and password via the
commandline which will be passed as “Basic-Auth” to the server.
If there is not enough free disk space available, the installation will be canceled. To delete images use the delete
system image command.
VyOS configuration is associated to each image, and each image has a unique copy of its configuration. This is
different than a traditional network router where the configuration is shared across all images.
Note: If you have any personal files, like some scripts you created, and you don’t want them to be lost during the
upgrade, make sure those files are stored in /config as this directory is always copied to newer installed images.
You can access files from a previous installation and copy them to your current image if they were located in the /config
directory. This can be done using the copy command. So, for instance, in order to copy /config/config.boot from
VyOS 1.2.1 image, you would use the following command:
4.5.1 Example
You can use latest option. It loads the latest available Rolling release.
Note: To use the latest option the “system update-check url” must be configured.
Hint: The most up-do-date Rolling Release for AMD64 can be accessed using the following URL:
https://vyos.net/get/nightly-builds/
After reboot you might want to verify the version you are running with the show version command.
The VyOS image-based installation is implemented by creating a directory for each image on the storage device selected
during the install process.
The directory structure of the boot device:
/
/boot
/boot/grub
/boot/1.2.0-rolling+201810021347
The image directory contains the system kernel, a compressed image of the root filesystem for the OS, and a directory
for persistent storage, such as configuration. On boot, the system will extract the OS image into memory and mount
the appropriate live-rw sub-directories to provide persistent storage system configuration.
This process allows for a system to always boot to a known working state, as the OS image is fixed and non-persistent.
It also allows for multiple releases of VyOS to be installed on the same storage device. The image can be selected
manually at boot if needed, but the system will otherwise boot the image configured to be the default.
show system image
List all available system images which can be booted on the current system.
show version
Show current system image version.
Architecture: x86_64
Boot via: installed image
System type: bare metal
If you need to rollback to a previous image, you can easily do so. First check the available images through the show
system image command and then select your image with the following command:
set system image default-boot [image-name]
Select the default boot image which will be started on the next boot of the system.
Then reboot the system.
Note: VyOS automatically associates the configuration to the image, so you don’t need to worry about that. Each
image has a unique copy of its configuration.
If you have access to the console, there is a another way to select your booting image: reboot and use the GRUB menu
at startup.
VyOS 1.x line aims to preserve backward compatibility and provide a safe upgrade path for existing Vyatta Core users.
You may think of VyOS 1.0.0 as VC7.0.
Note: Also, in Vyatta Core 6.5 remote access VPN interfaces have been renamed from pppX to l2tpX and pptpX. If
you are using zone based firewalling in Vyatta Core pre-6.5 versions, make sure to change interface names in rules for
remote access VPN.
You just use add system image, as if it was a new VC release (see Update VyOS for additional information). The
only thing you want to do is to verify the new images digital signature. You will have to add the public key manually
once as it is not shipped the first time.
For completion the key below corresponds to the key listed in the URL above.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.12 (GNU/Linux)
mQINBFIIUZwBEADGl+wkZpYytQxd6LnjDZZScziBKYJbjInetYeS0SUrgpqnPkzL
2CiGfPczLwpYY0zWxpUhTvqjFsE5yDpgs0sPXIgUTFE1qfZQE+WD1I1EUM6sp/38
2xKQ9QaNc8oHuYINLYYmNYra6ZjIGtQP9WOX//IDYB3fhdwlmiW2z0hux2OnPWdh
hPZAmSrx5AiXFEEREJ1cAQyvYk7hgIRvM/rdQMUm+u4/z+S4mxCHE10KzlqOGhRv
hA8WQxHCVusMFGwXoKHxYf9OQpV7lsfOCODfXOMP/L9kHQ5/gBsLL5hHst+o/3VG
ec0QuVrVkBBehgrqhfJW2noq+9gTooURGImQHEOyE0xpJdFrrgk5Ii9RqQwdVRzI
ZPbqbo8uuldZIRJRGnfx+vAR9812yo38NVZ/X0P/hkkrx+UeGVgpC/ao5XLRiOzL
7ZBMWLA6FVmZ7mkpqdzuMXX5548ApACm6EKErULIhTYDGDzFxA3cf6gr5VVi4usD
wglVs+FHuiLehmuuPTMoVcT2R6+Ht44hG3BmQmKzh/SSEa1g9gKgrhZrMdIyK4hu
GvMqLw9z9BgJbWB3BgXOUdlkXLDwBvVpEcWsPJgxSjAvjAbLLE4YkKAdYU8bQ0Pd
JuN485tcXxgQCadFZB0gcipQAvVf4b810HrY88g6FldfauHxiACOlXscZwARAQAB
tDBTTzMgR3JvdXAgTWFpbnRhaW5lcnMgPG1haW50YWluZXJzQHNvM2dyb3VwLm5l
dD6JAjgEEwECACIFAlIIUZwCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ
ELdE4lqkQubp8GsQAKntoRFG6bWX/4WPw7Vo7kIF5kWcmv3lVb0AQkacscWope7T
Iq0VcgpAycJue2bSS9LAsvNtpVkQmFawbwFjqB3CC5NbPNQ4Kf+gswKa+yaHwejo
7dkslAwxgXHe5g76DG7CVLMsMg6zVDFYuzeksPywls/OJBIpkuGqeXy9tAHjQzjA
SlZV3Gsx7azESjiVQ73EUBt2OXkwN4TN9TEHAnVsrNIXHwFl1VfFsSG1Q6uZDtkk
CB4DZJKN4RzCY2QSwMAqRRC2OXdwk5IAk8wwCGoFpp0UV6CO9YCeOaqJderEcBA4
MGHqdiPDIbH5wvckjZzFznU/Paz3MwPwBdtN+WSKvwf+JItSiUqm8Dy2Pl/1cnux
1g1I4WQlXUVaS/MDusqL7tbS8k5A5a2+YVMxShWH9BhXZwNXzEihl4sm8Hrg5SvZ
givJj2y93WoL69Wq0/86wkkH2xcrz4gsiUcQf5YXU/RHXOLnPR29/pg8TS0L7sST
dv0X23C2IpfqYoqN7YZ3K0Wczhi0yLPCrc27IczuHgjt/8ICda11xhB1t/pUbvnX
oksehaLp8O3uU8GyAsTfUgpijZFc/3jIadOl0L9NGUbYYgPzFeaZTa/njeEbz3wX
PZMn278sbL9UhupI5Hx7eREbKzV4VPVKz81ndKNMXyuJHXv2R0xou3nvuo1WuQIN
BFIIUZwBEADAhoYPDCSogG41Naq+wFkG+IPszqe0dW/UWg0xrZDT0UblwDSd4OGY
7FATMIhjOUyFxk6+XKA5CDCWP8Npkl0modTL59uVWNxU1vUKincc/j4ipHQeAhE6
fvZkrprvADD8TYIGesl/3EGNc7bzc5ZqX71hKPHG+autRtgFSOR2PSXD9MlJXIBb
RzHAXxlh72zvsGadcxLJm4pSWXitkR/5Wc3e0IippKdzGwZnCDpNmcBGtSTFgixP
JqyRZFVCPWs7jr/oQeZnq65wJp1KD2HvhhKHJfsPrnNjLSm1SQVh8hXzE9odcv6N
mJB7tNXywuROBt6a01ojBa9J3zuMYQj3iQl2MhxtHylKVBjr7NjZ4evZbLsRMxY1
hYk7sl+ZxCPFeOZ9D2ppU/CUDXCS095I1x+s+VuiUNf/3yd8ahCWDXVp9nsXyYjm
2pHIxb2F6r8Vd4AjlD2MQwszECS88INF3l/9ksIHEMKuuW+JAC9FiZ7k4IGcIltv
If/V2TgE6t6qoWIlmLhMTjOyJpwnokY1nIuXHH7yp+HsuqnYnf/dgLnt4czPLeHO
+TdIDHhUym0AKlCcbdgn0C6EJVTnA8BFgFjiIOMAeT0rhATg0W/cND8KQcX4V9wM
nHSEsgSEuP9H+67xuRx5Imuh5ntecrcuCYSNuOneUXWPThDKQPO9lQARAQABiQIf
BBgBAgAJBQJSCFGcAhsMAAoJELdE4lqkQubpc+0P/0IzUx8nTpF0/ii2TA0YCOgj
(continues on next page)
Would you like to save the SSH host keys from your
current configuration? (Yes/No) [Yes]: [return]
Copying SSH keys...
Setting up grub configuration...
Done.
Note: Future releases of VyOS will break the direct upgrade path from Vyatta core. Please upgrade through an
intermediate VyOS version e.g. VyOS 1.2. After this you can continue upgrading to newer releases once you bootet
into VyOS 1.2 once.
FIVE
QUICK START
This chapter will guide you on how to get up to speed quickly using your new VyOS system. It will show you a very
basic configuration example that will provide a NAT gateway for a device with two network interfaces (eth0 and eth1).
By default, VyOS is in operational mode, and the command prompt displays a $. To configure VyOS, you will need to
enter configuration mode, resulting in the command prompt displaying a #, as demonstrated below:
vyos@vyos$ configure
vyos@vyos#
After every configuration change, you need to apply the changes by using the following command:
commit
Once your configuration works as expected, you can save it permanently by using the following command:
save
• Your outside/WAN interface will be eth0. It will receive its interface address via DHCP.
• Your internal/LAN interface will be eth1. It will use a static IP address of 192.168.0.1/24.
After switching to Configuration Mode issue the following commands:
371
VyOS Documentation, Release 1.5.x (circinus)
After switching to Configuration Mode issue the following commands, and your system will listen on every interface
for incoming SSH connections. You might want to check the SSH chapter on how to listen on specific addresses only.
The following settings will configure DHCP and DNS services on your internal/LAN network, where VyOS will act
as the default gateway and DNS server.
• The default gateway and DNS recursor address will be 192.168.0.1/24
• The address range 192.168.0.2/24 - 192.168.0.8/24 will be reserved for static assignments
• DHCP clients will be assigned IP addresses within the range of 192.168.0.9 - 192.168.0.254 and have a
domain name of internal-network
• DHCP leases will hold for one day (86400 seconds)
• VyOS will serve as a full DNS recursor, replacing the need to utilize Google, Cloudflare, or other public DNS
servers (which is good for privacy)
• Only hosts from your internal/LAN network can use the DNS recursor
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 range 0 stop '192.
˓→168.0.254'
5.6 NAT
The following settings will configure SNAT rules for our internal/LAN network, allowing hosts to communicate through
the outside/WAN network via IP masquerade.
5.7 Firewall
A new firewall structure—which uses the nftables backend, rather than iptables—is available on all installations
starting from VyOS 1.4-rolling-202308040557. The firewall supports creation of distinct, interlinked chains for
each Netfilter hook and allows for more granular control over the packet filtering process.
The firewall begins with the base filter tables you define for each of the forward, input, and output Netfiter
hooks. Each of these tables is populated with rules that are processed in order and can jump to other chains for more
granular filtering.
To make firewall configuration easier, we can create groups of interfaces, networks, addresses, ports, and domains that
describe different parts of our network. We can then use them for filtering within our firewall rulesets, allowing for
more concise and readable configuration.
In this case, we will create two interface groups — a WAN group for our interfaces connected to the public internet
and a LAN group for the interfaces connected to our internal network. Additionally, we will create a network group,
NET-INSIDE-v4, that contains our internal subnet.
With the new firewall structure, we have have a lot of flexibility in how we group and order our rules, as shown by the
three alternative approaches below.
Using options defined in set firewall global-options state-policy, state policy rules that applies for both
IPv4 and IPv6 are created. These global state policies also applies for all traffic that passes through the router (transit)
and for traffic originated/destinated to/from the router itself, and will be evaluated before any other rule defined in the
firewall.
Most installations would choose this option, and will contain:
We can create a common chain for stateful connection filtering of multiple interfaces (or multiple netfilter hooks on
one interface). Those individual chains can then jump to the common chain for stateful connection filtering, returning
to the original chain for further rule processing if no action is taken on the packet.
The chain we will create is called CONN_FILTER and has three rules:
• A default action of return, which returns the packet back to the original chain if no action is taken.
• A rule to accept packets from established and related connections.
• A rule to drop packets from invalid connections.
Then, we can jump to the common chain from both the forward and input hooks as the first filtering rule in the
respective chains:
Alternatively, you can take the more traditional stateful connection filtering approach by creating rules on each base
hook’s chain:
Now that we have configured stateful connection filtering to allow traffic from established and related connections, we
can block all other incoming traffic addressed to our local network.
Create a new chain (OUTSIDE-IN) which will drop all traffic that is not explicitly allowed at some point in the chain.
Then, we can jump to that chain from the forward hook when traffic is coming from the WAN interface group and is
addressed to our local network.
We should also block all traffic destinated to the router itself that isn’t explicitly allowed at some point in the chain for
the input hook. As we’ve already configured stateful packet filtering above, we only need to set the default action to
drop:
We can now configure access to the router itself, allowing SSH access from the inside/LAN network and rate limiting
SSH access from the outside/WAN network.
First, create a new dedicated chain (VyOS_MANAGEMENT) for management access, which returns to the parent chain if
no action is taken. Add a rule to accept traffic from the LAN interface group:
Configure a rule on the input hook filter to jump to the VyOS_MANAGEMENT chain when new connections are addressed
to port 22 (SSH) on the router itself:
Finally, configure the VyOS_MANAGEMENT chain to accept connection from the LAN interface group while limiting
requests coming from the WAN interface group to 4 per minute:
Here we’re allowing the router to respond to pings. Then, we can allow access to the DNS recursor we configured
earlier, accepting traffic bound for port 53 from all hosts on the NET-INSIDE-v4 network:
Finally, we can now configure access to the services running on this router, allowing all connections coming from
localhost:
vyos@vyos# commit
vyos@vyos# save
Saving configuration to '/config/config.boot'...
Done
vyos@vyos# exit
vyos@vyos$
5.8 Hardening
Especially if you are allowing SSH remote access from the outside/WAN interface, there are a few additional configu-
ration steps that should be taken.
Replace the default vyos system user:
Finally, try and SSH into the VyOS install as your new user. Once you have confirmed that your new user can access
your router without a password, delete the original vyos user and completely disable password authentication for SSH:
As above, commit your changes, save the configuration, and exit configuration mode:
vyos@vyos# commit
vyos@vyos# save
Saving configuration to '/config/config.boot'...
Done
vyos@vyos# exit
vyos@vyos$
You now should have a simple yet secure and functioning router to experiment with further. Enjoy!
SIX
The VyOS CLI (Command-Line Interface) comprises an operational and a configuration mode.
Operational mode allows for commands to perform operational system tasks and view system and service status, while
configuration mode allows for the modification of system configuration.
The CLI provides a built-in help system. In the CLI the ? key may be used to display available commands. The TAB
key can be used to auto-complete commands and will present the help system upon a conflict or unknown value.
For example typing sh followed by the TAB key will complete to show. Pressing TAB a second time will display the
possible sub-commands of the show command.
vyos@vyos:~$ s[tab]
set show
378
VyOS Documentation, Release 1.5.x (circinus)
You can scroll up with the keys [Shift]+[PageUp] and scroll down with [Shift]+[PageDown].
When the output of a command results in more lines than can be displayed on the terminal screen the output is paginated
as indicated by a : prompt.
When viewing in page mode the following commands are available:
• q key can be used to cancel output
• space will scroll down one page
• b will scroll back one page
• return will scroll down one line
• up-arrow and down-arrow will scroll up or down one line at a time respectively
• left-arrow and right-arrow can be used to scroll left or right in the event that the output has lines
which exceed the terminal size.
vyos@vyos:~$ configure
[edit]
vyos@vyos:~#
vyos@vyos:~# exit
exit
vyos@vyos:~$
See the configuration section of this document for more information on configuration mode.
SEVEN
CONFIGURATION OVERVIEW
VyOS makes use of a unified configuration file for the entire system’s configuration: /config/config.boot. This
allows easy template creation, backup, and replication of system configuration. A system can thus also be easily cloned
by simply copying the required configuration files.
7.1 Terminology
show configuration
View the current active configuration, also known as the running configuration, from the operational mode.
380
VyOS Documentation, Release 1.5.x (circinus)
By default, the configuration is displayed in a hierarchy like the above example, this is only one of the possible ways to
display the configuration. When the configuration is generated and the device is configured, changes are added through
a collection of set and delete commands.
show configuration commands
Get a collection of all the set commands required which led to the running configuration.
Both these show commands should be executed when in operational mode, they do not work directly in configuration
mode. There is a special way on how to Access opmode from config mode.
Hint: Use the show configuration commands | strip-private command when you want to hide private data.
You may want to do so if you want to share your configuration on the forum.
{
"interfaces": {
"ethernet": {
"eth0": {
"address": [
"192.0.2.11/24",
"192.0.2.35/24"
],
"hw-id": "52:54:00:48:a0:c6"
},
"eth1": {
"address": [
"203.0.113.1/24"
],
"hw-id": "52:54:00:fc:50:0b"
}
},
"loopback": {
"lo": {}
(continues on next page)
When entering the configuration mode you are navigating inside a tree structure, to enter configuration mode enter the
command configure when in operational mode.
vyos@vyos$ configure
[edit]
vyos@vyos#
All commands executed here are relative to the configuration level you have entered. You can do everything from the
top level, but commands will be quite lengthy when manually typing them.
The current hierarchy level can be changed by the edit command.
[edit]
vyos@vyos# edit interfaces ethernet eth0
You are now in a sublevel relative to interfaces ethernet eth0, all commands executed from this point on are
relative to this sublevel. Use either the top or exit command to go back to the top of the hierarchy. You can also use
the up command to move only one level up at a time.
show
The show command within configuration mode will show the working configuration indicating line changes with + for
additions, > for replacements and - for deletions.
Example:
vyos@vyos:~$ configure
[edit]
vyos@vyos# show interfaces
ethernet eth0 {
description MY_OLD_DESCRIPTION
disable
hw-id 00:53:dd:44:3b:03
}
loopback lo {
}
[edit]
vyos@vyos# set interfaces ethernet eth0 address dhcp
[edit]
vyos@vyos# set interfaces ethernet eth0 description MY_NEW_DESCRIPTION
[edit]
vyos@vyos# delete interfaces ethernet eth0 disable
[edit]
vyos@vyos# show interfaces
ethernet eth0 {
+ address dhcp
> description MY_NEW_DESCRIPTION
- disable
hw-id 00:53:dd:44:3b:03
}
loopback lo {
}
It is also possible to display all set commands within configuration mode using show | commands
These commands are also relative to the level you are inside and only relevant configuration blocks will be displayed
when entering a sub-level.
Exiting from the configuration mode is done via the exit command from the top level, executing exit from within a
sub-level takes you back to the top level.
The configuration can be edited by the use of set and delete commands from within configuration mode.
set
Use this command to set the value of a parameter or to create a new element.
Configuration commands are flattened from the tree into ‘one-liner’ commands shown in show configuration
commands from operation mode. Commands are relative to the level where they are executed and all redundant in-
formation from the current level is removed from the command entered.
[edit]
vyos@vyos# set interface ethernet eth0 address 192.0.2.100/24
These two commands above are essentially the same, just executed from different levels in the hierarchy.
delete
To delete a configuration entry use the delete command, this also deletes all sub-levels under the current level
you’ve specified in the delete command. Deleting an entry will also result in the element reverting back to its
default value if one exists.
commit
Any change you do on the configuration, will not take effect until committed using the commit command in
configuration mode.
vyos@vyos# commit
[edit]
vyos@vyos# exit
Warning: configuration changes have not been saved.
vyos@vyos:~$
Hint: You can specify a commit message with commit comment <message>.
save
Use this command to preserve configuration changes upon reboot. By default it is stored at /config/config.boot.
In the case you want to store the configuration file somewhere else, you can add a local path, a SCP address, a
FTP address or a TFTP address.
vyos@vyos# save
Saving configuration to '/config/config.boot'...
Done
exit [discard]
Configuration mode can not be exited while uncommitted changes exist. To exit configuration mode without
applying changes, the exit discard command must be used.
All changes in the working config will thus be lost.
vyos@vyos# exit
Cannot exit: configuration modified.
Use 'exit discard' to discard the changes and exit.
[edit]
vyos@vyos# exit discard
commit-confirm <minutes>
Use this command to temporarily commit your changes and set the number of minutes available for validation.
confirm must be entered within those minutes, otherwise the system will reboot into the previous configuration.
The default value is 10 minutes.
What if you are doing something dangerous? Suppose you want to setup a firewall, and you are not sure
there are no mistakes that will lock you out of your system. You can use confirmed commit. If you issue the
commit-confirm command, your changes will be committed, and if you don’t issue the confirm command in
10 minutes, your system will reboot into previous config revision.
Note: A reboot because you did not enter confirm will not take you necessarily to the saved configuration,
but to the point before the unfortunate commit.
copy
Copy a configuration element.
You can copy and remove configuration subtrees. Suppose you set up a firewall ruleset FromWorld with one rule
that allows traffic from specific subnet. Now you want to setup a similar rule, but for different subnet. Change
your edit level to firewall name FromWorld and use copy rule 10 to rule 20, then modify rule 20.
rename
Rename a configuration element.
You can also rename config subtrees:
Note that show command respects your edit level and from this level you can view the modified firewall ruleset
with just show with no parameters.
vyos@router# show
default-action drop
rule 5 {
action accept
source {
address 203.0.113.0/24
}
}
rule 20 {
action accept
source {
address 198.51.100.0/24
}
}
Example:
Note: An important thing to note is that since the comment is added on top of the section, it will not appear
if the show <section> command is used. With the above example, the show firewall command would return
starting after the firewall { line, hiding the comment.
When inside configuration mode you are not directly able to execute operational commands.
run
Access to these commands are possible through the use of the run [command] command. From this command
you will have access to everything accessible from operational mode.
Command completion and syntax help with ? and [tab] will also work.
[edit]
vyos@vyos# run show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 0.0.0.0/0 u/u
VyOS comes with an integrated versioning system for the system configuration. It automatically maintains a backup
of every previous configuration which has been committed to the system. The configurations are versioned locally for
rollback but they can also be stored on a remote host for archiving/backup reasons.
Local Archive
Revisions are stored on disk. You can view, compare and rollback them to any previous revisions if something goes
wrong.
show system commit
View all existing revisions on the local system.
Compare configurations
The command compare allows you to compare different type of configurations. It also lets you compare different
revisions through the compare N M command, where N and M are revision numbers. The output will describe
how the configuration N is when compared to M indicating with a plus sign (+) the additional parts N has when
compared to M, and indicating with a minus sign (-) the lacking parts N misses when compared to M.
vyos@vyos# compare 0 6
[edit interfaces]
+dummy dum1 {
+ address 10.189.0.1/31
+}
[edit interfaces ethernet eth0]
+vif 99 {
(continues on next page)
This means four commits ago we did set system ipv6 disable-forwarding.
Rollback Changes
You can rollback configuration changes using the rollback command. This will apply the selected revision and trigger
a system reboot.
rollback <N>
Rollback to revision N (currently requires reboot)
vyos@vyos# compare 1
[edit system]
>host-name vyos-1
[edit]
vyos@vyos# rollback 1
Proceed with reboot? [confirm][y]
Broadcast message from root@vyos-1 (pts/0) (Tue Dec 17 21:07:45 2013):
The system is going down for reboot NOW!
Remote Archive
VyOS can upload the configuration to a remote location after each call to commit. You will have to set the commit-
archive location. TFTP, FTP, SCP and SFTP servers are supported. Every time a commit is successful the config.
boot file will be copied to the defined destination(s). The filename used on the remote host will be config.
boot-hostname.YYYYMMDD_HHMMSS.
set system config-management commit-archive location <URI>
Specify remote location of commit archive as any of the below URI (Uniform Resource Identifier)
• http://<user>:<passwd>@<host>:/<dir>
• https://<user>:<passwd>@<host>:/<dir>
• ftp://<user>:<passwd>@<host>/<dir>
• sftp://<user>:<passwd>@<host>/<dir>
• scp://<user>:<passwd>@<host>:/<dir>
• tftp://<host>/<dir>
• git+https://<user>:<passwd>@<host>/<path>
Since username and password are part of the URI, they need to be properly url encoded if containing special
characters.
Note: When using Git as destination for the commit archive the source-address CLI option has no effect.
Note: You may find VyOS not allowing the secure connection because it cannot verify the legitimacy of the
remote server. You can use the workaround below to quickly add the remote host’s SSH fingerprint to your
~/.ssh/known_hosts file:
You can use the save and load commands if you want to manually manage specific configuration files.
When using the save command, you can add a specific location where to store your configuration file. And, when
needed it, you will be able to load it with the load command:
load <URI>
Use this command to load a configuration which will replace the running configuration. Define the
location of the configuration file to be loaded. You can use a path to a local file, an SCP address, an
SFTP address, an FTP address, an HTTP address, an HTTPS address or a TFTP address.
vyos@vyos# load
Possible completions:
<Enter> Load from system config file
<file> Load from file on local machine
scp://<user>:<passwd>@<host>:/<file> Load from file on remote machine
sftp://<user>:<passwd>@<host>/<file> Load from file on remote machine
ftp://<user>:<passwd>@<host>/<file> Load from file on remote machine
http://<host>/<file> Load from file on remote machine
https://<host>/<file> Load from file on remote machine
tftp://<host>/<file> Load from file on remote machine
Restore Default
In the case you want to completely delete your configuration and restore the default one, you can enter the following
command in configuration mode:
load /opt/vyatta/etc/config.boot.default
You will be asked if you want to continue. If you accept, you will have to use commit if you want to make the changes
active.
Then you may want to save in order to delete the saved configuration too.
Note: If you are remotely connected, you will lose your connection. You may want to copy first the config, edit it to
ensure connectivity, and load the edited config.
EIGHT
CONFIGURATION GUIDE
8.1 Container
8.1.1 Configuration
If a registry is not specified, Docker.io will be used as the container registry unless an alternative registry is
specified using set container registry <name> or the registry is included in the image name
394
VyOS Documentation, Release 1.5.x (circinus)
Allow host networking in a container. The network stack of the container is not isolated from the host and will
use the host IP.
The command translates to “–net host” when the container is created.
Note: The first IP in the container network is reserved by the engine and cannot be used
Container Networks
Container Registry
For the sake of demonstration, example #1 in the official documentation to the declarative VyOS CLI
syntax.
8.2 Firewall
As VyOS is based on Linux it leverages its firewall. The Netfilter project created iptables and its successor nftables for
the Linux kernel to work directly on packet data flows. This now extends the concept of zone-based security to allow
for manipulating the data at multiple stages once accepted by the network interface and the driver before being handed
off to the destination (e.g., a web server OR another device).
A simplified traffic flow diagram, based on Netfilter packet flow, is shown next, in order to have a full view and under-
standing of how packets are processed, and what possible paths traffic can take.
The main points regarding this packet flow and terminology used in VyOS firewall are covered below:
• Bridge Port?: choose appropriate path based on whether interface where the packet was received is part of a
bridge, or not.
If the interface where the packet was received isn’t part of a bridge, then packet is processed at the IP Layer:
• Prerouting: All packets that are received by the router are processed in this stage, regardless of the destination of
the packet. Starting from vyos-1.5-rolling-202406120020, a new section was added to the firewall configuration.
There are several actions that can be done in this stage, and currently these actions are also defined in different
parts of the VyOS configuration. Order is important, and the relevant configuration that acts in this stage are:
– Firewall prerouting: rules defined under set firewall [ipv4 | ipv6] prerouting raw.... All
rules defined in this section are processed before connection tracking subsystem.
– Conntrack Ignore: rules defined under set system conntrack ignore [ipv4 | ipv6] ....
Starting from vyos-1.5-rolling-202406120020, configuration done in this section can be done in firewall
[ipv4 | ipv6] prerouting .... For compatibility reasons, this feature is still present, but it will be
removed in the future.
– Policy Route: rules defined under set policy [route | route6] ....
– Destination NAT: rules defined under set [nat | nat66] destination....
• Destination is the router?: choose an appropriate path based on destination IP address. Transit forward contin-
ues to forward, while traffic where the destination IP address is configured on the router continues to input.
• Input: stage where traffic destined for the router itself can be filtered and controlled. This is where all rules for
securing the router should take place. This includes ipv4 and ipv6 filtering rules, defined in:
– set firewall ipv4 input filter ....
– set firewall ipv6 input filter ....
• Forward: stage where transit traffic can be filtered and controlled. This includes ipv4 and ipv6 filtering rules,
defined in:
– set firewall ipv4 forward filter ....
– set firewall ipv6 forward filter ....
• Output: stage where traffic that originates from the router itself can be filtered and controlled. Bear in mind that
this traffic can be a new connection originated by a internal process running on the VyOS router such as NTP,
or a response to traffic received externally through input (for example response to an ssh login attempt to the
router). This includes ipv4 and ipv6 rules, and two different sections are present:
– Output Prerouting: set firewall [ipv4 | ipv6] output filter .... As described in Prerout-
ing, rules defined in this section are processed before connection tracking subsystem.
– Output Filter: set firewall [ipv4 | ipv6] output filter ....
• Postrouting: as in Prerouting, several actions defined in different parts of VyOS configuration are performed
in this stage. This includes:
– Source NAT: rules defined under set [nat | nat66] destination....
If the interface where the packet was received is part of a bridge, then the packet is processed at the Bridge Layer,
which contains a basic setup for bridge filtering:
• Forward (Bridge): stage where traffic that is trespassing through the bridge is filtered and controlled:
– set firewall bridge forward filter ....
The main structure of the VyOS firewall CLI is shown next:
- set firewall
* bridge
- forward
+ filter
* flowtable
- custom_flow_table
+ ...
(continues on next page)
Please, refer to appropriate section for more information about firewall configuration:
Overview
Some firewall settings are global and have an affect on the whole system. In this section there’s useful information
about these global-options that can be configured using vyos cli.
Configuration commands covered in this section:
set firewall global-options ...
Configuration
Note: firewall global-options all-ping affects only to LOCAL and it always behaves in the most restrictive
way
When the command above is set, VyOS will answer every ICMP echo request addressed to itself, but that will
only happen if no other rule is applied dropping or rejecting local echo requests. In case of conflict, VyOS will
not answer ICMP echo requests.
When the command above is set, VyOS will answer no ICMP echo request addressed to itself at all, no matter
where it comes from or whether more specific rules are being applied to accept them.
set firewall global-options broadcast-ping [enable | disable]
This setting enables or disables the response to icmp broadcast messages. The following system parameter will
be altered:
• net.ipv4.icmp_echo_ignore_broadcasts
set firewall global-options ip-src-route [enable | disable]
set firewall global-options ipv6-src-route [enable | disable]
This setting handles if VyOS accepts packets with a source route option. The following system parameters will
be altered:
• net.ipv4.conf.all.accept_source_route
• net.ipv6.conf.all.accept_source_route
set firewall global-options receive-redirects [enable | disable]
set firewall global-options ipv6-receive-redirects [enable | disable]
Enable or disable ICMPv4 or ICMPv6 redirect messages being accepted by VyOS. The following system pa-
rameters will be altered:
• net.ipv4.conf.all.accept_redirects
• net.ipv6.conf.all.accept_redirects
set firewall global-options send-redirects [enable | disable]
Enable or disable ICMPv4 redirect messages being sent by VyOS The following system parameter will be
altered:
• net.ipv4.conf.all.send_redirects
set firewall global-options log-martians [enable | disable]
Enable or disable the logging of martian IPv4 packets. The following system parameter will be altered:
• net.ipv4.conf.all.log_martians
set firewall global-options source-validation [strict | loose | disable]
Set the IPv4 source validation mode. The following system parameter will be altered:
• net.ipv4.conf.all.rp_filter
set firewall global-options syn-cookies [enable | disable]
Enable or disable if VyOS uses IPv4 TCP SYN Cookies. The following system parameter will be altered:
• net.ipv4.tcp_syncookies
set firewall global-options twa-hazards-protection [enable | disable]
Enable or Disable VyOS to be RFC 1337 conformant. The following system parameter will be altered:
• net.ipv4.tcp_rfc1337
set firewall global-options state-policy established action [accept | drop | reject]
set firewall global-options state-policy established log
set firewall global-options state-policy established log-level [emerg | alert | crit |
err | warn | notice | info | debug]
Set the global setting for an established connection.
set firewall global-options state-policy invalid action [accept | drop | reject]
set firewall global-options state-policy invalid log
set firewall global-options state-policy invalid log-level [emerg | alert | crit | err |
warn | notice | info | debug]
Set the global setting for invalid packets.
set firewall global-options state-policy related action [accept | drop | reject]
set firewall global-options state-policy related log
set firewall global-options state-policy related log-level [emerg | alert | crit | err |
warn | notice | info | debug]
Set the global setting for related connections.
VyOS supports setting timeouts for connections according to the connection type. You can set timeout values for
generic connections, for ICMP connections, UDP connections, or for TCP connections in a number of different states.
set firewall global-options timeout icmp <1-21474836>
Configuration
Firewall groups represent collections of IP addresses, networks, ports, mac addresses, domains or interfaces. Once
created, a group can be referenced by firewall, nat and policy route rules as either a source or destination matcher,
and/or as inbound/outbound in the case of interface group.
Address Groups
Network Groups
While network groups accept IP networks in CIDR notation, specific IP addresses can be added as a 32-bit prefix. If
you foresee the need to add a mix of addresses and networks, then a network group is recommended.
set firewall group network-group <name> network <CIDR>
set firewall group ipv6-network-group <name> network <CIDR>
Define a IPv4 or IPv6 Network group.
Interface Groups
Port Groups
A port group represents only port numbers, not the protocol. Port groups can be referenced for either TCP or UDP.
It is recommended that TCP and UDP groups are created separately to avoid accidentally filtering unnecessary ports.
Ranges of ports can be specified by using -.
set firewall group port-group <name> port [portname | portnumber | startport-endport]
Define a port group. A port name can be any name defined in /etc/services. e.g.: http
MAC Groups
Domain Groups
Dynamic Groups
Firewall dynamic groups are different from all the groups defined previously because, not only they can be used as
source/destination in firewall rules, but members of these groups are not defined statically using vyos configuration.
Instead, members of these groups are added dynamically using firewall rules.
Dynamic address group is supported by both IPv4 and IPv6 families. Commands used to define dynamic IPv4|IPv6
address groups are:
set firewall group dynamic-group address-group <name>
set firewall group dynamic-group ipv6-address-group <name>
Add description to firewall groups:
set firewall group dynamic-group address-group <name> description <text>
set firewall group dynamic-group ipv6-address-group <name> description <text>
Once dynamic firewall groups are defined, they should be used in firewall rules in order to dynamically add elements
to it.
Commands used for this task are:
• Add destination IP address of the connection to a dynamic address group:
set firewall ipv4 [forward | input | output] filter rule <1-999999> add-address-to-group
destination-address address-group <name>
set firewall ipv4 name <name> rule <1-999999> add-address-to-group destination-address
address-group <name>
set firewall ipv6 [forward | input | output] filter rule <1-999999> add-address-to-group
destination-address address-group <name>
set firewall ipv6 name <name> rule <1-999999> add-address-to-group destination-address
address-group <name>
• Add source IP address of the connection to a dynamic address group:
set firewall ipv4 [forward | input | output] filter rule <1-999999> add-address-to-group
source-address address-group <name>
set firewall ipv4 name <name> rule <1-999999> add-address-to-group source-address
address-group <name>
set firewall ipv6 [forward | input | output] filter rule <1-999999> add-address-to-group
source-address address-group <name>
set firewall ipv6 name <name> rule <1-999999> add-address-to-group source-address
address-group <name>
Also, specific timeouts can be defined per rule. In case rule gets a hit, a source or destinatination address will be added
to the group, and this element will remain in the group until the timeout expires. If no timeout is defined, then the
element will remain in the group until next reboot, or until a new commit that changes firewall configuration is done.
set firewall ipv4 [forward | input | output] filter rule <1-999999> add-address-to-group
[destination-address | source-address] timeout <timeout>
set firewall ipv4 name <name> rule <1-999999> add-address-to-group [destination-address |
source-address] timeout <timeout>
set firewall ipv6 [forward | input | output] filter rule <1-999999> add-address-to-group
[destination-address | source-address] timeout <timeout>
set firewall ipv6 name <name> rule <1-999999> add-address-to-group [destination-address |
source-address] timeout <timeout>
Timeout can be defined using seconds, minutes, hours or days:
As any other firewall group, dynamic firewall groups can be used in firewall rules as matching options. For example:
Examples
General example
As said before, once firewall groups are created, they can be referenced either in firewall, nat, nat66 and/or policy-route
rules.
Here is an example were multiple groups are created:
Using dynamic firewall groups, we can secure access to the router, or any other device if needed, by using the technique
of port knocking.
A 4 step port knocking example is shown next:
With this configuration, in order to get ssh access to the router, the user needs to:
1. Generate a new TCP connection with destination port 9990. As shown next, a new entry was added to dynamic
firewall group PN_01
2. Generate a new TCP connection with destination port 9991. As shown next, a new entry was added to dynamic
firewall group PN_02
3. Generate a new TCP connection with destination port 9992. As shown next, a new entry was added to dynamic
firewall group ALLOWED
4. Now the user can connect through ssh to the router (assuming ssh is configured).
Operation-mode
Overview
In this section there’s useful information on all firewall configuration that can be done regarding bridges, and appropriate
op-mode commands. Configuration commands covered in this section:
set firewall bridge ...
From the main structure defined in Firewall Overview in this section you can find detailed information only for the next
part of the general structure:
- set firewall
* bridge
- forward
+ filter
- name
+ custom_name
Traffic which is received by the router on an interface which is member of a bridge is processed on the Bridge Layer.
A simplified packet flow diagram for this layer is shown next:
For traffic that needs to be forwarded internally by the bridge, base chain is is forward, and it’s base command for
filtering is set firewall bridge forward filter ..., which happens in stage 4, highlighted with red color.
Custom bridge firewall chains can be created with the command set firewall bridge name <name> .... In
order to use such custom chain, a rule with action jump, and the appropriate target should be defined in a base chain.
Note: Layer 3 bridge: When an IP address is assigned to the bridge interface, and if traffic is sent to the router to
this IP (for example using such IP as default gateway), then rules defined for bridge firewall won’t match, and firewall
analysis continues at IP layer.
Bridge Rules
For firewall filtering, firewall rules need to be created. Each rule is numbered, has an action to apply if the rule is
matched, and the ability to specify multiple matching criteria. Data packets go through the rules from 1 - 999999, so
order is crucial. At the first match the action of the rule will be executed.
Actions
If a rule is defined, then an action must be defined for it. This tells the firewall what to do if all matching criterea in the
rule are met.
In firewall bridge rules, the action can be:
• accept: accept the packet.
• continue: continue parsing next rule.
• drop: drop the packet.
• jump: jump to another custom chain.
• return: Return from the current chain and continue at the next rule of the last chain.
• queue: Enqueue packet to userspace.
set firewall bridge forward filter rule <1-999999> action [accept | continue | drop |
jump | queue | return]
set firewall bridge name <name> rule <1-999999> action [accept | continue | drop | jump |
queue | return]
This required setting defines the action of the current rule. If action is set to jump, then jump-target is also
needed.
set firewall bridge forward filter rule <1-999999> jump-target <text>
set firewall bridge name <name> rule <1-999999> jump-target <text>
set firewall bridge forward filter rule <1-999999> queue <0-65535>
set firewall bridge name <name> rule <1-999999> queue <0-65535>
To be used only when action is set to queue. Use this command to specify the queue target to use. Queue range
is also supported.
set firewall bridge forward filter rule <1-999999> queue-options bypass
set firewall bridge name <name> rule <1-999999> queue-options bypass
To be used only when action is set to queue. Use this command to let packet go through firewall when no
userspace software is connected to the queue.
set firewall bridge forward filter rule <1-999999> queue-options fanout
set firewall bridge name <name> rule <1-999999> queue-options fanout
To be used only when action is set to queue. Use this command to distribute packets between several queues.
Also, default-action is an action that takes place whenever a packet does not match any rule in its’ chain. For base
chains, possible options for default-action are accept or drop.
set firewall bridge forward filter default-action [accept | drop]
set firewall bridge name <name> default-action [accept | continue | drop | jump | queue |
return]
This sets the default action of the rule-set if a packet does not match any of the rules in that chain. If default-
action is set to jump, then default-jump-target is also needed. Note that for base chains, default action can
only be set to accept or drop, while on custom chains more actions are available.
set firewall bridge name <name> default-jump-target <text>
To be used only when default-action is set to jump. Use this command to specify jump target for default
rule.
Note: Important note about default-actions: If the default action for any base chain is not defined, then the default
action is set to accept for that chain. For custom chains, if the default action is not defined, then the default-action is
set to drop.
Firewall Logs
Logging can be enable for every single firewall rule. If enabled, other log options can be defined.
set firewall bridge forward filter rule <1-999999> log
set firewall bridge name <name> rule <1-999999> log
Enable logging for the matched packet. If this configuration command is not present, then the log is not enabled.
set firewall bridge forward filter default-log
set firewall bridge name <name> default-log
Use this command to enable the logging of the default action on the specified chain.
set firewall bridge forward filter rule <1-999999> log-options level [emerg | alert |
crit | err | warn | notice | info | debug]
set firewall bridge name <name> rule <1-999999> log-options level [emerg | alert | crit |
err | warn | notice | info | debug]
Define log-level. Only applicable if rule log is enabled.
set firewall bridge forward filter rule <1-999999> log-options group <0-65535>
set firewall bridge name <name> rule <1-999999> log-options group <0-65535>
Define the log group to send messages to. Only applicable if rule log is enabled.
set firewall bridge forward filter rule <1-999999> log-options snapshot-length <0-9000>
set firewall bridge name <name> rule <1-999999> log-options snapshot-length <0-9000>
Define length of packet payload to include in netlink message. Only applicable if rule log is enabled and the log
group is defined.
set firewall bridge forward filter rule <1-999999> log-options queue-threshold <0-65535>
set firewall bridge name <name> rule <1-999999> log-options queue-threshold <0-65535>
Define the number of packets to queue inside the kernel before sending them to userspace. Only applicable if
rule log is enabled and the log group is defined.
Firewall Description
For reference, a description can be defined for every defined custom chain.
set firewall bridge name <name> description <text>
Provide a rule-set description to a custom firewall chain.
Rule Status
When defining a rule, it is enabled by default. In some cases, it is useful to just disable the rule, rather than removing
it.
set firewall bridge forward filter rule <1-999999> disable
set firewall bridge name <name> rule <1-999999> disable
Command for disabling a rule but keep it in the configuration.
Matching criteria
There are a lot of matching criteria against which the packet can be tested.
set firewall bridge forward filter rule <1-999999> destination mac-address <mac-address>
set firewall bridge name <name> rule <1-999999> destination mac-address <mac-address>
set firewall bridge forward filter rule <1-999999> source mac-address <mac-address>
set firewall bridge name <name> rule <1-999999> source mac-address <mac-address>
Match criteria based on source and/or destination mac-address.
set firewall bridge forward filter rule <1-999999> inbound-interface name <iface>
set firewall bridge name <name> rule <1-999999> inbound-interface name <iface>
Match based on inbound interface. Wildcard * can be used. For example: eth2*. Prepending character ! for
inverted matching criteria is also supported. For example !eth2
set firewall bridge forward filter rule <1-999999> inbound-interface group <iface_group>
set firewall bridge name <name> rule <1-999999> inbound-interface group <iface_group>
Match based on inbound interface group. Prepending character ! for inverted matching criteria is also supported.
For example !IFACE_GROUP
set firewall bridge forward filter rule <1-999999> outbound-interface name <iface>
set firewall bridge name <name> rule <1-999999> outbound-interface name <iface>
Match based on outbound interface. Wildcard * can be used. For example: eth2*. Prepending character ! for
inverted matching criteria is also supported. For example !eth2
set firewall bridge forward filter rule <1-999999> outbound-interface group <iface_group>
set firewall bridge name <name> rule <1-999999> outbound-interface group <iface_group>
Match based on outbound interface group. Prepending character ! for inverted matching criteria is also sup-
ported. For example !IFACE_GROUP
set firewall bridge forward filter rule <1-999999> vlan id <0-4096>
set firewall bridge name <name> rule <1-999999> vlan id <0-4096>
Operation-mode Firewall
Rule-set overview
In this section you can find all useful firewall op-mode commands.
General commands for firewall configuration, counter and statistics:
show firewall
show firewall summary
show firewall statistics
And, to print only bridge firewall information:
show firewall bridge
show firewall bridge forward filter
show firewall bridge forward filter rule <rule>
show firewall bridge name <name>
show firewall bridge name <name> rule <rule>
Example
Configuration example:
---------------------------------
bridge Firewall "forward filter"
---------------------------------
bridge Firewall "name TEST"
vyos@BRI:~$
vyos@BRI:~$ show firewall bridge name TEST
Ruleset Information
---------------------------------
bridge Firewall "name TEST"
vyos@BRI:~$
Inspect logs:
˓→11.11.102
˓→11.11.102
˓→11.11.102
...
vyos@BRI:~$ show log firewall bridge forward filter
Dec 05 14:42:22 kernel: [bri-FWD-filter-default-D]IN=eth2 OUT=eth1␣
˓→MAC=33:33:00:00:00:16:50:00:00:06:00:00:86:dd␣
˓→SRC=0000:0000:0000:0000:0000:0000:0000:0000␣
˓→SRC=0000:0000:0000:0000:0000:0000:0000:0000␣
Overview
In this section there’s useful information on all firewall configuration that can be done regarding IPv4, and appropriate
op-mode commands. Configuration commands covered in this section:
set firewall ipv4 ...
From the main structure defined in Firewall Overview in this section you can find detailed information only for the next
part of the general structure:
- set firewall
* ipv4
- forward
+ filter
- input
+ filter
- output
+ filter
+ raw
- prerouting
+ raw
- name
+ custom_name
First, all traffic is received by the router, and it is processed in the prerouting section.
This stage includes:
• Firewall Prerouting: commands found under set firewall ipv4 prerouting raw ...
• Conntrack Ignore: set system conntrack ignore ipv4...
• Policy Route: commands found under set policy route ...
• Destination NAT : commands found under set nat destination ...
For transit traffic, which is received by the router and forwarded, the base chain is forward. A simplified packet flow
diagram for transit traffic is shown next:
The base firewall chain to configure filtering rules for transit traffic is set firewall ipv4 forward filter ...,
which happens in stage 5, highlighted in the color red.
For traffic towards the router itself, the base chain is input, while traffic originated by the router has the base chain
output. A new simplified packet flow diagram is shown next, which shows the path for traffic destined to the router
itself, and traffic generated by the router (starting from circle number 6):
The base chain for traffic towards the router is set firewall ipv4 input filter ...
And the base chain for traffic generated by the router is set firewall ipv4 output ..., where two sub-chains are
available: filter and raw:
• Output Prerouting: set firewall ipv4 output raw .... As described in Prerouting, rules defined in
this section are processed before connection tracking subsystem.
• Output Filter: set firewall ipv4 output filter .... Rules defined in this section are processed after
connection tracking subsystem.
Note: Important note about default-actions: If a default action for any base chain is not defined, then the default
action is set to accept for that chain. For custom chains, if the default action is not defined, then the default-action is
set to drop
Custom firewall chains can be created, with commands set firewall ipv4 name <name> .... In order to use
such custom chain, a rule with action jump, and the appropriate target should be defined in a base chain.
For firewall filtering, firewall rules need to be created. Each rule is numbered, has an action to apply if the rule is
matched, and the ability to specify multiple matching criteria. Data packets go through the rules from 1 - 999999, so
order is crucial. At the first match the action of the rule will be executed.
Actions
If a rule is defined, then an action must be defined for it. This tells the firewall what to do if all of the criteria defined
for that rule match.
The action can be :
• accept: accept the packet.
• continue: continue parsing next rule.
• drop: drop the packet.
Note: Important note about default-actions: If the default action for any base chain is not defined, then the default
action is set to accept for that chain. For custom chains if a default action is not defined then the default-action is set
to drop.
Firewall Logs
Logging can be enable for every single firewall rule. If enabled, other log options can be defined.
set firewall ipv4 forward filter rule <1-999999> log
set firewall ipv4 input filter rule <1-999999> log
set firewall ipv4 output filter rule <1-999999> log
set firewall ipv4 name <name> rule <1-999999> log
Enable logging for the matched packet. If this configuration command is not present, then the log is not enabled.
set firewall ipv4 forward filter default-log
set firewall ipv4 input filter default-log
set firewall ipv4 output filter default-log
set firewall ipv4 name <name> default-log
Use this command to enable the logging of the default action on the specified chain.
set firewall ipv4 forward filter rule <1-999999> log-options level [emerg | alert | crit
| err | warn | notice | info | debug]
set firewall ipv4 input filter rule <1-999999> log-options level [emerg | alert | crit |
err | warn | notice | info | debug]
set firewall ipv4 output filter rule <1-999999> log-options level [emerg | alert | crit |
err | warn | notice | info | debug]
set firewall ipv4 name <name> rule <1-999999> log-options level [emerg | alert | crit |
err | warn | notice | info | debug]
Define log-level. Only applicable if rule log is enabled.
set firewall ipv4 forward filter rule <1-999999> log-options group <0-65535>
set firewall ipv4 input filter rule <1-999999> log-options group <0-65535>
set firewall ipv4 output filter rule <1-999999> log-options group <0-65535>
set firewall ipv4 name <name> rule <1-999999> log-options group <0-65535>
Define the log group to send messages to. Only applicable if rule log is enabled.
set firewall ipv4 forward filter rule <1-999999> log-options snapshot-length <0-9000>
set firewall ipv4 input filter rule <1-999999> log-options snapshot-length <0-9000>
set firewall ipv4 output filter rule <1-999999> log-options snapshot-length <0-9000>
set firewall ipv4 name <name> rule <1-999999> log-options snapshot-length <0-9000>
Define the length of packet payload to include in a netlink message. Only applicable if rule log is enabled and
log group is defined.
set firewall ipv4 forward filter rule <1-999999> log-options queue-threshold <0-65535>
set firewall ipv4 input filter rule <1-999999> log-options queue-threshold <0-65535>
set firewall ipv4 output filter rule <1-999999> log-options queue-threshold <0-65535>
set firewall ipv4 name <name> rule <1-999999> log-options queue-threshold <0-65535>
Define the number of packets to queue inside the kernel before sending them to userspace. Only applicable if
rule log is enabled and log group is defined.
Firewall Description
For reference, a description can be defined for every single rule, and for every defined custom chain.
set firewall ipv4 name <name> description <text>
Provide a rule-set description to a custom firewall chain.
set firewall ipv4 forward filter rule <1-999999> description <text>
set firewall ipv4 input filter rule <1-999999> description <text>
set firewall ipv4 output filter rule <1-999999> description <text>
set firewall ipv4 name <name> rule <1-999999> description <text>
Provide a description for each rule.
Rule Status
When defining a rule, it is enabled by default. In some cases, it is useful to just disable the rule, rather than removing
it.
set firewall ipv4 forward filter rule <1-999999> disable
set firewall ipv4 input filter rule <1-999999> disable
set firewall ipv4 output filter rule <1-999999> disable
set firewall ipv4 name <name> rule <1-999999> disable
Command for disabling a rule but keep it in the configuration.
Matching criteria
There are a lot of matching criteria against which the packet can be tested.
set firewall ipv4 forward filter rule <1-999999> connection-status nat [destination |
source]
set firewall ipv4 input filter rule <1-999999> connection-status nat [destination |
source]
set firewall ipv4 output filter rule <1-999999> connection-status nat [destination |
source]
set firewall ipv4 name <name> rule <1-999999> connection-status nat [destination |
source]
Match based on nat connection status.
set firewall ipv4 forward filter rule <1-999999> connection-mark <1-2147483647>
set firewall ipv4 input filter rule <1-999999> connection-mark <1-2147483647>
set firewall ipv4 output filter rule <1-999999> connection-mark <1-2147483647>
set firewall ipv4 name <name> rule <1-999999> connection-mark <1-2147483647>
Match based on connection mark.
set firewall ipv4 forward filter rule <1-999999> conntrack-helper <module>
set firewall ipv4 input filter rule <1-999999> conntrack-helper <module>
set firewall ipv4 output filter rule <1-999999> conntrack-helper <module>
set firewall ipv4 name <name> rule <1-999999> conntrack-helper <module>
Match based on connection tracking protocol helper module to secure use of that helper module. See below for
possible completions <module>.
Possible completions:
ftp Related traffic from FTP helper
h323 Related traffic from H.323 helper
pptp Related traffic from PPTP helper
nfs Related traffic from NFS helper
sip Related traffic from SIP helper
tftp Related traffic from TFTP helper
sqlnet Related traffic from SQLNet helper
set firewall ipv4 forward filter rule <1-999999> source address [address | addressrange |
CIDR]
set firewall ipv4 input filter rule <1-999999> source address [address | addressrange |
CIDR]
set firewall ipv4 output filter rule <1-999999> source address [address | addressrange |
CIDR]
set firewall ipv4 name <name> rule <1-999999> source address [address | addressrange |
CIDR]
set firewall ipv4 forward filter rule <1-999999> destination address [address |
addressrange | CIDR]
set firewall ipv4 input filter rule <1-999999> destination address [address |
addressrange | CIDR]
set firewall ipv4 output filter rule <1-999999> destination address [address |
addressrange | CIDR]
set firewall ipv4 name <name> rule <1-999999> destination address [address | addressrange
| CIDR]
Match criteria based on source and/or destination address. This is similar to the network groups part, but here
you are able to negate the matching addresses.
set firewall ipv4 forward filter rule <1-999999> source address-mask [address]
set firewall ipv4 input filter rule <1-999999> source address-mask [address]
set firewall ipv4 output filter rule <1-999999> source address-mask [address]
set firewall ipv4 name <name> rule <1-999999> source address-mask [address]
set firewall ipv4 forward filter rule <1-999999> destination address-mask [address]
set firewall ipv4 input filter rule <1-999999> destination address-mask [address]
set firewall ipv4 output filter rule <1-999999> destination address-mask [address]
set firewall ipv4 name <name> rule <1-999999> destination address-mask [address]
An arbitrary netmask can be applied to mask addresses to only match against a specific portion.
This functions for both individual addresses and address groups.
# Match any IPv4 address with `11` as the 2nd octet and `13` as the forth octet
set firewall ipv4 name FOO rule 100 destination address 0.11.0.13
set firewall ipv4 name FOO rule 100 destination address-mask 0.255.0.255
set firewall ipv4 forward filter rule <1-999999> source fqdn <fqdn>
set firewall ipv4 input filter rule <1-999999> source fqdn <fqdn>
set firewall ipv4 output filter rule <1-999999> source fqdn <fqdn>
set firewall ipv4 name <name> rule <1-999999> source fqdn <fqdn>
set firewall ipv4 forward filter rule <1-999999> destination fqdn <fqdn>
set firewall ipv4 input filter rule <1-999999> destination fqdn <fqdn>
set firewall ipv4 output filter rule <1-999999> destination fqdn <fqdn>
set firewall ipv4 name <name> rule <1-999999> destination fqdn <fqdn>
Specify a Fully Qualified Domain Name as source/destination to match. Ensure that the router is able to resolve
this dns query.
set firewall ipv4 forward filter rule <1-999999> source geoip country-code <country>
set firewall ipv4 input filter rule <1-999999> source geoip country-code <country>
set firewall ipv4 output filter rule <1-999999> source geoip country-code <country>
set firewall ipv4 name <name> rule <1-999999> source geoip country-code <country>
set firewall ipv4 forward filter rule <1-999999> destination geoip country-code <country>
set firewall ipv4 input filter rule <1-999999> destination geoip country-code <country>
set firewall ipv4 output filter rule <1-999999> destination geoip country-code <country>
set firewall ipv4 name <name> rule <1-999999> destination geoip country-code <country>
set firewall ipv4 forward filter rule <1-999999> source geoip inverse-match
set firewall ipv4 input filter rule <1-999999> source geoip inverse-match
set firewall ipv4 output filter rule <1-999999> source geoip inverse-match
set firewall ipv4 name <name> rule <1-999999> source geoip inverse-match
set firewall ipv4 forward filter rule <1-999999> destination geoip inverse-match
set firewall ipv4 input filter rule <1-999999> destination geoip inverse-match
set firewall ipv4 output filter rule <1-999999> destination geoip inverse-match
set firewall ipv4 name <name> rule <1-999999> destination geoip inverse-match
Match IP addresses based on its geolocation. More info: geoip matching. Use inverse-match to match anything
except the given country-codes.
Data is provided by DB-IP.com under CC-BY-4.0 license. Attribution required, permits redistribution so we can include
a database in images(~3MB compressed). Includes cron script (manually callable by op-mode update geoip) to keep
database and rules updated.
set firewall ipv4 forward filter rule <1-999999> source mac-address <mac-address>
set firewall ipv4 input filter rule <1-999999> source mac-address <mac-address>
set firewall ipv4 output filter rule <1-999999> source mac-address <mac-address>
set firewall ipv4 name <name> rule <1-999999> source mac-address <mac-address>
You can only specify a source mac-address to match.
set firewall ipv4 input filter rule 100 source mac-address 00:53:00:11:22:33
set firewall ipv4 input filter rule 101 source mac-address !00:53:00:aa:12:34
set firewall ipv4 forward filter rule <1-999999> source port [1-65535 | portname |
start-end]
set firewall ipv4 input filter rule <1-999999> source port [1-65535 | portname |
start-end]
set firewall ipv4 output filter rule <1-999999> source port [1-65535 | portname |
start-end]
set firewall ipv4 name <name> rule <1-999999> source port [1-65535 | portname |
start-end]
set firewall ipv4 forward filter rule <1-999999> destination port [1-65535 | portname |
start-end]
set firewall ipv4 input filter rule <1-999999> destination port [1-65535 | portname |
start-end]
set firewall ipv4 output filter rule <1-999999> destination port [1-65535 | portname |
start-end]
set firewall ipv4 name <name> rule <1-999999> destination port [1-65535 | portname |
start-end]
Multiple source ports can be specified as a comma-separated list. The whole list can also be “negated” using !.
For example:
set firewall ipv4 forward filter rule <1-999999> source group address-group <name | !
name>
set firewall ipv4 input filter rule <1-999999> source group address-group <name | !name>
set firewall ipv4 output filter rule <1-999999> source group address-group <name | !name>
set firewall ipv4 name <name> rule <1-999999> source group address-group <name | !name>
set firewall ipv4 forward filter rule <1-999999> destination group address-group <name |
!name>
set firewall ipv4 input filter rule <1-999999> destination group address-group <name |
!name>
set firewall ipv4 output filter rule <1-999999> destination group address-group <name |
!name>
set firewall ipv4 name <name> rule <1-999999> destination group address-group <name |
!name>
Use a specific address-group. Prepending the character ! to invert the criteria to match is also supported.
set firewall ipv4 forward filter rule <1-999999> source group dynamic-address-group <name
| !name>
set firewall ipv4 input filter rule <1-999999> source group dynamic-address-group <name |
!name>
set firewall ipv4 output filter rule <1-999999> source group dynamic-address-group <name
| !name>
set firewall ipv4 name <name> rule <1-999999> source group dynamic-address-group <name |
!name>
set firewall ipv4 forward filter rule <1-999999> destination group dynamic-address-group
<name | !name>
set firewall ipv4 input filter rule <1-999999> destination group dynamic-address-group
<name | !name>
set firewall ipv4 output filter rule <1-999999> destination group dynamic-address-group
<name | !name>
set firewall ipv4 name <name> rule <1-999999> destination group dynamic-address-group
<name | !name>
Use a specific dynamic-address-group. Prepending the character ! to invert the criteria to match is also sup-
ported.
set firewall ipv4 forward filter rule <1-999999> source group network-group <name | !
name>
set firewall ipv4 input filter rule <1-999999> source group network-group <name | !name>
set firewall ipv4 output filter rule <1-999999> source group network-group <name | !name>
set firewall ipv4 name <name> rule <1-999999> source group network-group <name | !name>
set firewall ipv4 forward filter rule <1-999999> destination group network-group <name |
!name>
set firewall ipv4 input filter rule <1-999999> destination group network-group <name |
!name>
set firewall ipv4 output filter rule <1-999999> destination group network-group <name |
!name>
set firewall ipv4 name <name> rule <1-999999> destination group network-group <name |
!name>
Use a specific network-group. Prepending the character ! to invert the criteria to match is also supported.
set firewall ipv4 forward filter rule <1-999999> source group port-group <name | !name>
set firewall ipv4 input filter rule <1-999999> source group port-group <name | !name>
set firewall ipv4 output filter rule <1-999999> source group port-group <name | !name>
set firewall ipv4 name <name> rule <1-999999> source group port-group <name | !name>
set firewall ipv4 forward filter rule <1-999999> destination group port-group <name |
!name>
set firewall ipv4 input filter rule <1-999999> destination group port-group <name | !
name>
set firewall ipv4 output filter rule <1-999999> destination group port-group <name | !
name>
set firewall ipv4 name <name> rule <1-999999> destination group port-group <name | !name>
Use a specific port-group. Prepending the character ! to invert the criteria to match is also supported.
set firewall ipv4 forward filter rule <1-999999> source group domain-group <name | !name>
set firewall ipv4 input filter rule <1-999999> source group domain-group <name | !name>
set firewall ipv4 output filter rule <1-999999> source group domain-group <name | !name>
set firewall ipv4 name <name> rule <1-999999> source group domain-group <name | !name>
set firewall ipv4 forward filter rule <1-999999> destination group domain-group <name |
!name>
set firewall ipv4 input filter rule <1-999999> destination group domain-group <name |
!name>
set firewall ipv4 output filter rule <1-999999> destination group domain-group <name |
!name>
set firewall ipv4 name <name> rule <1-999999> destination group domain-group <name | !
name>
Use a specific domain-group. Prepending the character ! to invert the criteria to match is also supported.
set firewall ipv4 forward filter rule <1-999999> source group mac-group <name | !name>
set firewall ipv4 input filter rule <1-999999> source group mac-group <name | !name>
set firewall ipv4 output filter rule <1-999999> source group mac-group <name | !name>
set firewall ipv4 name <name> rule <1-999999> source group mac-group <name | !name>
set firewall ipv4 forward filter rule <1-999999> destination group mac-group <name | !
name>
set firewall ipv4 input filter rule <1-999999> destination group mac-group <name | !name>
set firewall ipv4 output filter rule <1-999999> destination group mac-group <name | !
name>
set firewall ipv4 name <name> rule <1-999999> destination group mac-group <name | !name>
Use a specific mac-group. Prepending the character ! to invert the criteria to match is also supported.
set firewall ipv4 forward filter rule <1-999999> dscp [0-63 | start-end]
set firewall ipv4 input filter rule <1-999999> dscp [0-63 | start-end]
set firewall ipv4 output filter rule <1-999999> dscp [0-63 | start-end]
set firewall ipv4 name <name> rule <1-999999> dscp [0-63 | start-end]
set firewall ipv4 forward filter rule <1-999999> dscp-exclude [0-63 | start-end]
set firewall ipv4 input filter rule <1-999999> dscp-exclude [0-63 | start-end]
set firewall ipv4 output filter rule <1-999999> dscp-exclude [0-63 | start-end]
set firewall ipv4 name <name> rule <1-999999> dscp-exclude [0-63 | start-end]
Match based on dscp value.
set firewall ipv4 forward filter rule <1-999999> fragment [match-frag | match-non-frag]
set firewall ipv4 input filter rule <1-999999> fragment [match-frag | match-non-frag]
set firewall ipv4 output filter rule <1-999999> fragment [match-frag | match-non-frag]
set firewall ipv4 name <name> rule <1-999999> fragment [match-frag | match-non-frag]
Match based on fragmentation.
set firewall ipv4 forward filter rule <1-999999> icmp [code | type] <0-255>
set firewall ipv4 input filter rule <1-999999> icmp [code | type] <0-255>
set firewall ipv4 output filter rule <1-999999> icmp [code | type] <0-255>
set firewall ipv4 name <name> rule <1-999999> icmp [code | type] <0-255>
Match based on icmp code and type.
set firewall ipv4 forward filter rule <1-999999> icmp type-name <text>
set firewall ipv4 input filter rule <1-999999> icmp type-name <text>
set firewall ipv4 output filter rule <1-999999> icmp type-name <text>
set firewall ipv4 name <name> rule <1-999999> icmp type-name <text>
Match based on icmp type-name. Use tab for information about what type-name criteria are supported.
set firewall ipv4 forward filter rule <1-999999> inbound-interface name <iface>
set firewall ipv4 input filter rule <1-999999> inbound-interface name <iface>
set firewall ipv4 name <name> rule <1-999999> inbound-interface name <iface>
Match based on inbound interface. Wildcard * can be used. For example: eth2*. Prepending the character !
to invert the criteria to match is also supported. For example !eth2
Note: If an interface is attached to a non-default vrf, when using inbound-interface, the vrf name must be used. For
example set firewall ipv4 forward filter rule 10 inbound-interface name MGMT
set firewall ipv4 forward filter rule <1-999999> inbound-interface group <iface_group>
set firewall ipv4 input filter rule <1-999999> inbound-interface group <iface_group>
set firewall ipv4 name <name> rule <1-999999> inbound-interface group <iface_group>
Match based on the inbound interface group. Prepending the character ! to invert the criteria to match is also
supported. For example !IFACE_GROUP
set firewall ipv4 forward filter rule <1-999999> outbound-interface name <iface>
set firewall ipv4 output filter rule <1-999999> outbound-interface name <iface>
set firewall ipv4 name <name> rule <1-999999> outbound-interface name <iface>
Match based on outbound interface. Wildcard * can be used. For example: eth2*. Prepending the character !
to invert the criteria to match is also supported. For example !eth2
Note: If an interface is attached to a non-default vrf, when using outbound-interface, the real interface name must
be used. For example set firewall ipv4 forward filter rule 10 outbound-interface name eth0
set firewall ipv4 forward filter rule <1-999999> outbound-interface group <iface_group>
set firewall ipv4 output filter rule <1-999999> outbound-interface group <iface_group>
set firewall ipv4 name <name> rule <1-999999> outbound-interface group <iface_group>
Match based on outbound interface group. Prepending the character ! to invert the criteria to match is also
supported. For example !IFACE_GROUP
set firewall ipv4 forward filter rule <1-999999> ipsec [match-ipsec | match-none]
set firewall ipv4 input filter rule <1-999999> ipsec [match-ipsec | match-none]
set firewall ipv4 output filter rule <1-999999> ipsec [match-ipsec | match-none]
set firewall ipv4 name <name> rule <1-999999> ipsec [match-ipsec | match-none]
Match based on ipsec.
set firewall ipv4 forward filter rule <1-999999> limit burst <0-4294967295>
set firewall ipv4 input filter rule <1-999999> limit burst <0-4294967295>
set firewall ipv4 output filter rule <1-999999> limit burst <0-4294967295>
set firewall ipv4 name <name> rule <1-999999> limit burst <0-4294967295>
Match based on the maximum number of packets to allow in excess of rate.
set firewall ipv4 forward filter rule <1-999999> limit rate <text>
set firewall ipv4 input filter rule <1-999999> limit rate <text>
set firewall ipv4 output filter rule <1-999999> limit rate <text>
set firewall ipv4 name <name> rule <1-999999> limit rate <text>
Match based on the maximum average rate, specified as integer/unit. For example 5/minutes
set firewall ipv4 forward filter rule <1-999999> packet-length <text>
set firewall ipv4 forward filter rule <1-999999> recent count <1-255>
set firewall ipv4 input filter rule <1-999999> recent count <1-255>
set firewall ipv4 output filter rule <1-999999> recent count <1-255>
set firewall ipv4 name <name> rule <1-999999> recent count <1-255>
set firewall ipv4 forward filter rule <1-999999> recent time [second | minute | hour]
set firewall ipv4 input filter rule <1-999999> recent time [second | minute | hour]
set firewall ipv4 output filter rule <1-999999> recent time [second | minute | hour]
set firewall ipv4 name <name> rule <1-999999> recent time [second | minute | hour]
Match based on recently seen sources.
set firewall ipv4 forward filter rule <1-999999> tcp flags [not] <text>
set firewall ipv4 input filter rule <1-999999> tcp flags [not] <text>
set firewall ipv4 output filter rule <1-999999> tcp flags [not] <text>
set firewall ipv4 name <name> rule <1-999999> tcp flags [not] <text>
Allowed values fpr TCP flags: ack, cwr, ecn, fin, psh, rst, syn and urg. Multiple values are supported, and
for inverted selection use not, as shown in the example.
set firewall ipv4 forward filter rule <1-999999> state [established | invalid | new |
related]
set firewall ipv4 input filter rule <1-999999> state [established | invalid | new |
related]
set firewall ipv4 output filter rule <1-999999> state [established | invalid | new |
related]
set firewall ipv4 name <name> rule <1-999999> state [established | invalid | new |
related]
Match against the state of a packet.
set firewall ipv4 forward filter rule <1-999999> time startdate <text>
set firewall ipv4 input filter rule <1-999999> time startdate <text>
set firewall ipv4 output filter rule <1-999999> time startdate <text>
set firewall ipv4 name <name> rule <1-999999> time startdate <text>
set firewall ipv4 forward filter rule <1-999999> time starttime <text>
set firewall ipv4 input filter rule <1-999999> time starttime <text>
set firewall ipv4 output filter rule <1-999999> time starttime <text>
set firewall ipv4 name <name> rule <1-999999> time starttime <text>
set firewall ipv4 forward filter rule <1-999999> time stopdate <text>
set firewall ipv4 input filter rule <1-999999> time stopdate <text>
set firewall ipv4 output filter rule <1-999999> time stopdate <text>
set firewall ipv4 name <name> rule <1-999999> time stopdate <text>
set firewall ipv4 forward filter rule <1-999999> time stoptime <text>
set firewall ipv4 input filter rule <1-999999> time stoptime <text>
set firewall ipv4 output filter rule <1-999999> time stoptime <text>
set firewall ipv4 name <name> rule <1-999999> time stoptime <text>
set firewall ipv4 forward filter rule <1-999999> time weekdays <text>
set firewall ipv4 input filter rule <1-999999> time weekdays <text>
set firewall ipv4 output filter rule <1-999999> time weekdays <text>
set firewall ipv4 name <name> rule <1-999999> time weekdays <text>
Time to match the defined rule.
set firewall ipv4 forward filter rule <1-999999> ttl <eq | gt | lt> <0-255>
set firewall ipv4 input filter rule <1-999999> ttl <eq | gt | lt> <0-255>
set firewall ipv4 output filter rule <1-999999> ttl <eq | gt | lt> <0-255>
set firewall ipv4 name <name> rule <1-999999> ttl <eq | gt | lt> <0-255>
Match the time to live parameter, where ‘eq’ stands for ‘equal’; ‘gt’ stands for ‘greater than’, and ‘lt’ stands for
‘less than’.
set firewall ipv4 forward filter rule <1-999999> recent count <1-255>
set firewall ipv4 input filter rule <1-999999> recent count <1-255>
set firewall ipv4 output filter rule <1-999999> recent count <1-255>
set firewall ipv4 name <name> rule <1-999999> recent count <1-255>
set firewall ipv4 forward filter rule <1-999999> recent time <second | minute | hour>
set firewall ipv4 input filter rule <1-999999> recent time <second | minute | hour>
set firewall ipv4 output filter rule <1-999999> recent time <second | minute | hour>
set firewall ipv4 name <name> rule <1-999999> recent time <second | minute | hour>
Match when ‘count’ amount of connections are seen within ‘time’. These matching criteria can be used to block
brute-force attempts.
Synproxy
Synproxy connections
set firewall ipv4 [input | forward] filter rule <1-999999> action synproxy
set firewall ipv4 [input | forward] filter rule <1-999999> protocol tcp
set firewall ipv4 [input | forward] filter rule <1-999999> synproxy tcp mss <501-65535>
Set the TCP-MSS (maximum segment size) for the connection
set firewall ipv4 [input | forward] filter rule <1-999999> synproxy tcp window-scale
<1-14>
Set the window scale factor for TCP window scaling
Example synproxy
Operation-mode Firewall
Rule-set overview
show firewall
This will show you a basic firewall overview, for all rule-sets, and not only for ipv4
---------------------------------
ipv4 Firewall "forward filter"
---------------------------------
ipv4 Firewall "input filter"
---------------------------------
ipv4 Firewall "name AUX"
---------------------------------
(continues on next page)
---------------------------------
ipv6 Firewall "input filter"
vyos@vyos:~$
IPv6 Ruleset:
IPv4 Ruleset:
Firewall Groups
---------------------------------
IPv4 Firewall "input filter"
---------------------------------
ipv4 Firewall "output filter"
vyos@vyos:~$
firewall {
group {
network-group BAD-NETWORKS {
network 198.51.100.0/24
network 203.0.113.0/24
}
network-group GOOD-NETWORKS {
network 192.0.2.0/24
}
port-group BAD-PORTS {
port 65535
}
}
ipv4 {
forward {
filter {
default-action accept
rule 5 {
action accept
source {
group {
network-group GOOD-NETWORKS
}
}
(continues on next page)
update geoip
Command used to update GeoIP database and firewall sets.
Overview
In this section there’s useful information on all firewall configuration that can be done regarding IPv6, and appropriate
op-mode commands. Configuration commands covered in this section:
set firewall ipv6 ...
From the main structure defined in Firewall Overview in this section you can find detailed information only for the next
part of the general structure:
- set firewall
* ipv6
- forward
+ filter
- input
+ filter
- output
+ filter
+ raw
- prerouting
+ raw
- name
+ custom_name
First, all traffic is received by the router, and it is processed in the prerouting section.
This stage includes:
• Firewall Prerouting: commands found under set firewall ipv6 prerouting raw ...
The base firewall chain to configure filtering rules for transit traffic is set firewall ipv6 forward filter ...,
which happens in stage 5, highlighted in the color red.
For traffic towards the router itself, the base chain is input, while traffic originated by the router has the base chain
output. A new simplified packet flow diagram is shown next, which shows the path for traffic destined to the router
itself, and traffic generated by the router (starting from circle number 6):
The base chain for traffic towards the router is set firewall ipv6 input filter ...
And the base chain for traffic generated by the router is set firewall ipv6 output ..., where two sub-chains are
available: filter and raw:
• Output Prerouting: set firewall ipv6 output raw .... As described in Prerouting, rules defined in
this section are processed before connection tracking subsystem.
• Output Filter: set firewall ipv6 output filter .... Rules defined in this section are processed after
connection tracking subsystem.
Note: Important note about default-actions: If a default action for any base chain is not defined, then the default
action is set to accept for that chain. For custom chains, if the default action is not defined, then the default-action is
set to drop
Custom firewall chains can be created, with commands set firewall ipv6 name <name> .... In order to use
such custom chain, a rule with action jump, and the appropriate target should be defined in a base chain.
For firewall filtering, firewall rules need to be created. Each rule is numbered, has an action to apply if the rule is
matched, and the ability to specify multiple matching criteria. Data packets go through the rules from 1 - 999999, so
order is crucial. At the first match the action of the rule will be executed.
Actions
If a rule is defined, then an action must be defined for it. This tells the firewall what to do if all of the criteria defined
for that rule match.
The action can be :
• accept: accept the packet.
• continue: continue parsing next rule.
• drop: drop the packet.
• reject: reject the packet.
• jump: jump to another custom chain.
• return: Return from the current chain and continue at the next rule of the last chain.
• queue: Enqueue packet to userspace.
• synproxy: synproxy the packet.
set firewall ipv6 forward filter rule <1-999999> action [accept | continue | drop | jump
| queue | reject | return | synproxy]
set firewall ipv6 input filter rule <1-999999> action [accept | continue | drop | jump |
queue | reject | return | synproxy]
set firewall ipv6 output filter rule <1-999999> action [accept | continue | drop | jump |
queue | reject | return]
set firewall ipv6 name <name> rule <1-999999> action [accept | continue | drop | jump |
queue | reject | return]
This required setting defines the action of the current rule. If the action is set to jump, then a jump-target is also
needed.
set firewall ipv6 forward filter rule <1-999999> jump-target <text>
set firewall ipv6 input filter rule <1-999999> jump-target <text>
set firewall ipv6 output filter rule <1-999999> jump-target <text>
set firewall ipv6 name <name> rule <1-999999> jump-target <text>
To be used only when action is set to jump. Use this command to specify the jump target.
set firewall ipv6 forward filter rule <1-999999> queue <0-65535>
Note: Important note about default-actions: If the default action for any base chain is not defined, then the default
action is set to accept for that chain. For custom chains if a default action is not defined then the default-action is set
to drop.
Firewall Logs
Logging can be enable for every single firewall rule. If enabled, other log options can be defined.
set firewall ipv6 forward filter rule <1-999999> log
set firewall ipv6 input filter rule <1-999999> log
set firewall ipv6 output filter rule <1-999999> log
set firewall ipv6 name <name> rule <1-999999> log
Enable logging for the matched packet. If this configuration command is not present, then the log is not enabled.
set firewall ipv6 forward filter default-log
set firewall ipv6 input filter default-log
set firewall ipv6 output filter default-log
set firewall ipv6 name <name> default-log
Use this command to enable the logging of the default action on the specified chain.
set firewall ipv6 forward filter rule <1-999999> log-options level [emerg | alert | crit
| err | warn | notice | info | debug]
set firewall ipv6 input filter rule <1-999999> log-options level [emerg | alert | crit |
err | warn | notice | info | debug]
set firewall ipv6 output filter rule <1-999999> log-options level [emerg | alert | crit |
err | warn | notice | info | debug]
set firewall ipv6 name <name> rule <1-999999> log-options level [emerg | alert | crit |
err | warn | notice | info | debug]
Define log-level. Only applicable if rule log is enabled.
set firewall ipv6 forward filter rule <1-999999> log-options group <0-65535>
set firewall ipv6 input filter rule <1-999999> log-options group <0-65535>
set firewall ipv6 output filter rule <1-999999> log-options group <0-65535>
set firewall ipv6 name <name> rule <1-999999> log-options group <0-65535>
Define the log group to send messages to. Only applicable if rule log is enabled.
set firewall ipv6 forward filter rule <1-999999> log-options snapshot-length <0-9000>
set firewall ipv6 input filter rule <1-999999> log-options snapshot-length <0-9000>
set firewall ipv6 output filter rule <1-999999> log-options snapshot-length <0-9000>
set firewall ipv6 name <name> rule <1-999999> log-options snapshot-length <0-9000>
Define the length of packet payload to include in a netlink message. Only applicable if rule log is enabled and
log group is defined.
set firewall ipv6 forward filter rule <1-999999> log-options queue-threshold <0-65535>
set firewall ipv6 input filter rule <1-999999> log-options queue-threshold <0-65535>
set firewall ipv6 output filter rule <1-999999> log-options queue-threshold <0-65535>
set firewall ipv6 name <name> rule <1-999999> log-options queue-threshold <0-65535>
Define the number of packets to queue inside the kernel before sending them to userspace. Only applicable if
rule log is enabled and log group is defined.
Firewall Description
For reference, a description can be defined for every single rule, and for every defined custom chain.
set firewall ipv6 name <name> description <text>
Provide a rule-set description to a custom firewall chain.
set firewall ipv6 forward filter rule <1-999999> description <text>
set firewall ipv6 input filter rule <1-999999> description <text>
set firewall ipv6 output filter rule <1-999999> description <text>
set firewall ipv6 name <name> rule <1-999999> description <text>
Provide a description for each rule.
Rule Status
When defining a rule, it is enabled by default. In some cases, it is useful to just disable the rule, rather than removing
it.
set firewall ipv6 forward filter rule <1-999999> disable
set firewall ipv6 input filter rule <1-999999> disable
set firewall ipv6 output filter rule <1-999999> disable
set firewall ipv6 name <name> rule <1-999999> disable
Command for disabling a rule but keep it in the configuration.
Matching criteria
There are a lot of matching criteria against which the packet can be tested.
set firewall ipv6 forward filter rule <1-999999> connection-status nat [destination |
source]
set firewall ipv6 input filter rule <1-999999> connection-status nat [destination |
source]
set firewall ipv6 output filter rule <1-999999> connection-status nat [destination |
source]
set firewall ipv6 name <name> rule <1-999999> connection-status nat [destination |
source]
Match based on nat connection status.
set firewall ipv6 forward filter rule <1-999999> connection-mark <1-2147483647>
set firewall ipv6 input filter rule <1-999999> connection-mark <1-2147483647>
set firewall ipv6 output filter rule <1-999999> connection-mark <1-2147483647>
set firewall ipv6 name <name> rule <1-999999> connection-mark <1-2147483647>
Match based on connection mark.
set firewall ipv6 forward filter rule <1-999999> source address [address | addressrange |
CIDR]
set firewall ipv6 input filter rule <1-999999> source address [address | addressrange |
CIDR]
set firewall ipv6 output filter rule <1-999999> source address [address | addressrange |
CIDR]
set firewall ipv6 name <name> rule <1-999999> source address [address | addressrange |
CIDR]
set firewall ipv6 forward filter rule <1-999999> destination address [address |
addressrange | CIDR]
set firewall ipv6 input filter rule <1-999999> destination address [address |
addressrange | CIDR]
set firewall ipv6 output filter rule <1-999999> destination address [address |
addressrange | CIDR]
set firewall ipv6 name <name> rule <1-999999> destination address [address | addressrange
| CIDR]
Match based on source and/or destination address. This is similar to the network groups part, but here you are
able to negate the matching addresses.
set firewall ipv6 name FOO rule 100 source address 2001:db8::202
set firewall ipv6 forward filter rule <1-999999> source address-mask [address]
set firewall ipv6 input filter rule <1-999999> source address-mask [address]
set firewall ipv6 output filter rule <1-999999> source address-mask [address]
set firewall ipv6 name <name> rule <1-999999> source address-mask [address]
set firewall ipv6 forward filter rule <1-999999> destination address-mask [address]
set firewall ipv6 input filter rule <1-999999> destination address-mask [address]
set firewall ipv6 output filter rule <1-999999> destination address-mask [address]
set firewall ipv6 name <name> rule <1-999999> destination address-mask [address]
An arbitrary netmask can be applied to mask addresses to only match against a specific portion. This is particu-
larly useful with IPv6 as rules will remain valid if the IPv6 prefix changes and the host portion of systems IPv6
address is static (for example, with SLAAC or tokenised IPv6 addresses)
This functions for both individual addresses and address groups.
# Address groups
set firewall group ipv6-address-group WEBSERVERS address ::1000
set firewall group ipv6-address-group WEBSERVERS address ::2000
set firewall ipv6 forward filter rule 200 source group address-group WEBSERVERS
set firewall ipv6 forward filter rule 200 source address-mask ::ffff:ffff:ffff:ffff
set firewall ipv6 forward filter rule <1-999999> source fqdn <fqdn>
set firewall ipv6 input filter rule <1-999999> source fqdn <fqdn>
set firewall ipv6 output filter rule <1-999999> source fqdn <fqdn>
set firewall ipv6 name <name> rule <1-999999> source fqdn <fqdn>
set firewall ipv6 forward filter rule <1-999999> destination fqdn <fqdn>
set firewall ipv6 input filter rule <1-999999> destination fqdn <fqdn>
set firewall ipv6 output filter rule <1-999999> destination fqdn <fqdn>
set firewall ipv6 name <name> rule <1-999999> destination fqdn <fqdn>
Specify a Fully Qualified Domain Name as source/destination to match. Ensure that the router is able to resolve
this dns query.
set firewall ipv6 forward filter rule <1-999999> source geoip country-code <country>
set firewall ipv6 input filter rule <1-999999> source geoip country-code <country>
set firewall ipv6 output filter rule <1-999999> source geoip country-code <country>
set firewall ipv6 name <name> rule <1-999999> source geoip country-code <country>
set firewall ipv6 forward filter rule <1-999999> destination geoip country-code <country>
set firewall ipv6 input filter rule <1-999999> destination geoip country-code <country>
set firewall ipv6 output filter rule <1-999999> destination geoip country-code <country>
set firewall ipv6 name <name> rule <1-999999> destination geoip country-code <country>
set firewall ipv6 forward filter rule <1-999999> source geoip inverse-match
set firewall ipv6 input filter rule <1-999999> source geoip inverse-match
set firewall ipv6 output filter rule <1-999999> source geoip inverse-match
set firewall ipv6 name <name> rule <1-999999> source geoip inverse-match
set firewall ipv6 forward filter rule <1-999999> destination geoip inverse-match
set firewall ipv6 input filter rule <1-999999> destination geoip inverse-match
set firewall ipv6 output filter rule <1-999999> destination geoip inverse-match
set firewall ipv6 name <name> rule <1-999999> destination geoip inverse-match
Match IP addresses based on its geolocation. More info: geoip matching. Use inverse-match to match anything
except the given country-codes.
Data is provided by DB-IP.com under CC-BY-4.0 license. Attribution required, permits redistribution so we can include
a database in images(~3MB compressed). Includes cron script (manually callable by op-mode update geoip) to keep
database and rules updated.
set firewall ipv6 forward filter rule <1-999999> source mac-address <mac-address>
set firewall ipv6 input filter rule <1-999999> source mac-address <mac-address>
set firewall ipv6 output filter rule <1-999999> source mac-address <mac-address>
set firewall ipv6 name <name> rule <1-999999> source mac-address <mac-address>
You can only specify a source mac-address to match.
set firewall ipv6 input filter rule 100 source mac-address 00:53:00:11:22:33
set firewall ipv6 input filter rule 101 source mac-address !00:53:00:aa:12:34
set firewall ipv6 forward filter rule <1-999999> source port [1-65535 | portname |
start-end]
set firewall ipv6 input filter rule <1-999999> source port [1-65535 | portname |
start-end]
set firewall ipv6 output filter rule <1-999999> source port [1-65535 | portname |
start-end]
set firewall ipv6 name <name> rule <1-999999> source port [1-65535 | portname |
start-end]
set firewall ipv6 forward filter rule <1-999999> destination port [1-65535 | portname |
start-end]
set firewall ipv6 input filter rule <1-999999> destination port [1-65535 | portname |
start-end]
set firewall ipv6 output filter rule <1-999999> destination port [1-65535 | portname |
start-end]
set firewall ipv6 name <name> rule <1-999999> destination port [1-65535 | portname |
start-end]
A port can be set by number or name as defined in /etc/services.
Multiple source ports can be specified as a comma-separated list. The whole list can also be “negated” using !.
For example:
set firewall ipv6 forward filter rule <1-999999> source group address-group <name | !
name>
set firewall ipv6 input filter rule <1-999999> source group address-group <name | !name>
set firewall ipv6 output filter rule <1-999999> source group address-group <name | !name>
set firewall ipv6 name <name> rule <1-999999> source group address-group <name | !name>
set firewall ipv6 forward filter rule <1-999999> destination group address-group <name |
!name>
set firewall ipv6 input filter rule <1-999999> destination group address-group <name |
!name>
set firewall ipv6 output filter rule <1-999999> destination group address-group <name |
!name>
set firewall ipv6 name <name> rule <1-999999> destination group address-group <name |
!name>
Use a specific address-group. Prepending the character ! to invert the criteria to match is also supported.
set firewall ipv6 forward filter rule <1-999999> source group dynamic-address-group <name
| !name>
set firewall ipv6 input filter rule <1-999999> source group dynamic-address-group <name |
!name>
set firewall ipv6 output filter rule <1-999999> source group dynamic-address-group <name
| !name>
set firewall ipv6 name <name> rule <1-999999> source group dynamic-address-group <name |
!name>
set firewall ipv6 forward filter rule <1-999999> destination group dynamic-address-group
<name | !name>
set firewall ipv6 input filter rule <1-999999> destination group dynamic-address-group
<name | !name>
set firewall ipv6 output filter rule <1-999999> destination group dynamic-address-group
<name | !name>
set firewall ipv6 name <name> rule <1-999999> destination group dynamic-address-group
<name | !name>
Use a specific dynamic-address-group. Prepending the character ! to invert the criteria to match is also sup-
ported.
set firewall ipv6 forward filter rule <1-999999> source group network-group <name | !
name>
set firewall ipv6 input filter rule <1-999999> source group network-group <name | !name>
set firewall ipv6 output filter rule <1-999999> source group network-group <name | !name>
set firewall ipv6 name <name> rule <1-999999> source group network-group <name | !name>
set firewall ipv6 forward filter rule <1-999999> destination group network-group <name |
!name>
set firewall ipv6 input filter rule <1-999999> destination group network-group <name |
!name>
set firewall ipv6 output filter rule <1-999999> destination group network-group <name |
!name>
set firewall ipv6 name <name> rule <1-999999> destination group network-group <name |
!name>
Use a specific network-group. Prepending the character ! to invert the criteria to match is also supported.
set firewall ipv6 forward filter rule <1-999999> source group port-group <name | !name>
set firewall ipv6 input filter rule <1-999999> source group port-group <name | !name>
set firewall ipv6 output filter rule <1-999999> source group port-group <name | !name>
set firewall ipv6 name <name> rule <1-999999> source group port-group <name | !name>
set firewall ipv6 forward filter rule <1-999999> destination group port-group <name |
!name>
set firewall ipv6 input filter rule <1-999999> destination group port-group <name | !
name>
set firewall ipv6 output filter rule <1-999999> destination group port-group <name | !
name>
set firewall ipv6 name <name> rule <1-999999> destination group port-group <name | !name>
Use a specific port-group. Prepending the character ! to invert the criteria to match is also supported.
set firewall ipv6 forward filter rule <1-999999> source group domain-group <name | !name>
set firewall ipv6 input filter rule <1-999999> source group domain-group <name | !name>
set firewall ipv6 output filter rule <1-999999> source group domain-group <name | !name>
set firewall ipv6 name <name> rule <1-999999> source group domain-group <name | !name>
set firewall ipv6 forward filter rule <1-999999> destination group domain-group <name |
!name>
set firewall ipv6 input filter rule <1-999999> destination group domain-group <name |
!name>
set firewall ipv6 output filter rule <1-999999> destination group domain-group <name |
!name>
set firewall ipv6 name <name> rule <1-999999> destination group domain-group <name | !
name>
Use a specific domain-group. Prepending the character ! to invert the criteria to match is also supported.
set firewall ipv6 forward filter rule <1-999999> source group mac-group <name | !name>
set firewall ipv6 input filter rule <1-999999> source group mac-group <name | !name>
set firewall ipv6 output filter rule <1-999999> source group mac-group <name | !name>
set firewall ipv6 name <name> rule <1-999999> source group mac-group <name | !name>
set firewall ipv6 forward filter rule <1-999999> destination group mac-group <name | !
name>
set firewall ipv6 input filter rule <1-999999> destination group mac-group <name | !name>
set firewall ipv6 output filter rule <1-999999> destination group mac-group <name | !
name>
set firewall ipv6 name <name> rule <1-999999> destination group mac-group <name | !name>
Use a specific mac-group. Prepending the character ! to invert the criteria to match is also supported.
set firewall ipv6 forward filter rule <1-999999> dscp [0-63 | start-end]
set firewall ipv6 input filter rule <1-999999> dscp [0-63 | start-end]
set firewall ipv6 output filter rule <1-999999> dscp [0-63 | start-end]
set firewall ipv6 name <name> rule <1-999999> dscp [0-63 | start-end]
set firewall ipv6 forward filter rule <1-999999> dscp-exclude [0-63 | start-end]
set firewall ipv6 input filter rule <1-999999> dscp-exclude [0-63 | start-end]
set firewall ipv6 output filter rule <1-999999> dscp-exclude [0-63 | start-end]
set firewall ipv6 name <name> rule <1-999999> dscp-exclude [0-63 | start-end]
Match based on dscp value.
set firewall ipv6 forward filter rule <1-999999> fragment [match-frag | match-non-frag]
set firewall ipv6 input filter rule <1-999999> fragment [match-frag | match-non-frag]
set firewall ipv6 output filter rule <1-999999> fragment [match-frag | match-non-frag]
set firewall ipv6 name <name> rule <1-999999> fragment [match-frag | match-non-frag]
Match based on fragmentation.
set firewall ipv6 forward filter rule <1-999999> icmpv6 [code | type] <0-255>
set firewall ipv6 input filter rule <1-999999> icmpv6 [code | type] <0-255>
set firewall ipv6 output filter rule <1-999999> icmpv6 [code | type] <0-255>
set firewall ipv6 name <name> rule <1-999999> icmpv6 [code | type] <0-255>
Match based on icmp|icmpv6 code and type.
set firewall ipv6 forward filter rule <1-999999> icmpv6 type-name <text>
set firewall ipv6 input filter rule <1-999999> icmpv6 type-name <text>
set firewall ipv6 output filter rule <1-999999> icmpv6 type-name <text>
set firewall ipv6 name <name> rule <1-999999> icmpv6 type-name <text>
Match based on icmpv6 type-name. Use tab for information about what type-name criteria are supported.
set firewall ipv6 forward filter rule <1-999999> inbound-interface name <iface>
set firewall ipv6 input filter rule <1-999999> inbound-interface name <iface>
set firewall ipv6 name <name> rule <1-999999> inbound-interface name <iface>
Match based on inbound interface. Wildcard * can be used. For example: eth2*. Prepending the character !
to invert the criteria to match is also supported. For example !eth2
Note: If an interface is attached to a non-default vrf, when using inbound-interface, the vrf name must be used. For
example set firewall ipv6 forward filter rule 10 inbound-interface name MGMT
set firewall ipv6 forward filter rule <1-999999> inbound-interface group <iface_group>
set firewall ipv6 input filter rule <1-999999> inbound-interface group <iface_group>
set firewall ipv6 name <name> rule <1-999999> inbound-interface group <iface_group>
Match based on the inbound interface group. Prepending the character ! to invert the criteria to match is also
supported. For example !IFACE_GROUP
set firewall ipv6 forward filter rule <1-999999> outbound-interface name <iface>
set firewall ipv6 output filter rule <1-999999> outbound-interface name <iface>
set firewall ipv6 name <name> rule <1-999999> outbound-interface name <iface>
Match based on outbound interface. Wildcard * can be used. For example: eth2*. Prepending the character !
to invert the criteria to match is also supported. For example !eth2
Note: If an interface is attached to a non-default vrf, when using outbound-interface, the real interface name must
be used. For example set firewall ipv6 forward filter rule 10 outbound-interface name eth0
set firewall ipv6 forward filter rule <1-999999> outbound-interface group <iface_group>
set firewall ipv6 output filter rule <1-999999> outbound-interface group <iface_group>
set firewall ipv6 name <name> rule <1-999999> outbound-interface group <iface_group>
Match based on outbound interface group. Prepending the character ! to invert the criteria to match is also
supported. For example !IFACE_GROUP
set firewall ipv6 forward filter rule <1-999999> ipsec [match-ipsec | match-none]
set firewall ipv6 input filter rule <1-999999> ipsec [match-ipsec | match-none]
set firewall ipv6 output filter rule <1-999999> ipsec [match-ipsec | match-none]
set firewall ipv6 name <name> rule <1-999999> ipsec [match-ipsec | match-none]
set firewall ipv6 forward filter rule <1-999999> recent count <1-255>
set firewall ipv6 input filter rule <1-999999> recent count <1-255>
set firewall ipv6 output filter rule <1-999999> recent count <1-255>
set firewall ipv6 name <name> rule <1-999999> recent count <1-255>
set firewall ipv6 forward filter rule <1-999999> recent time [second | minute | hour]
set firewall ipv6 input filter rule <1-999999> recent time [second | minute | hour]
set firewall ipv6 output filter rule <1-999999> recent time [second | minute | hour]
set firewall ipv6 name <name> rule <1-999999> recent time [second | minute | hour]
Match bases on recently seen sources.
set firewall ipv6 forward filter rule <1-999999> tcp flags [not] <text>
set firewall ipv6 input filter rule <1-999999> tcp flags [not] <text>
set firewall ipv6 output filter rule <1-999999> tcp flags [not] <text>
set firewall ipv6 name <name> rule <1-999999> tcp flags [not] <text>
Allowed values fpr TCP flags: ack, cwr, ecn, fin, psh, rst, syn and urg. Multiple values are supported, and
for inverted selection use not, as shown in the example.
set firewall ipv6 forward filter rule <1-999999> state [established | invalid | new |
related]
set firewall ipv6 input filter rule <1-999999> state [established | invalid | new |
related]
set firewall ipv6 output filter rule <1-999999> state [established | invalid | new |
related]
set firewall ipv6 name <name> rule <1-999999> state [established | invalid | new |
related]
Match against the state of a packet.
set firewall ipv6 forward filter rule <1-999999> time startdate <text>
set firewall ipv6 input filter rule <1-999999> time startdate <text>
set firewall ipv6 output filter rule <1-999999> time startdate <text>
set firewall ipv6 name <name> rule <1-999999> time startdate <text>
set firewall ipv6 forward filter rule <1-999999> time starttime <text>
set firewall ipv6 input filter rule <1-999999> time starttime <text>
set firewall ipv6 output filter rule <1-999999> time starttime <text>
set firewall ipv6 name <name> rule <1-999999> time starttime <text>
set firewall ipv6 forward filter rule <1-999999> time stopdate <text>
set firewall ipv6 input filter rule <1-999999> time stopdate <text>
set firewall ipv6 output filter rule <1-999999> time stopdate <text>
set firewall ipv6 name <name> rule <1-999999> time stopdate <text>
set firewall ipv6 forward filter rule <1-999999> time stoptime <text>
set firewall ipv6 input filter rule <1-999999> time stoptime <text>
set firewall ipv6 output filter rule <1-999999> time stoptime <text>
set firewall ipv6 name <name> rule <1-999999> time stoptime <text>
set firewall ipv6 forward filter rule <1-999999> time weekdays <text>
set firewall ipv6 input filter rule <1-999999> time weekdays <text>
set firewall ipv6 output filter rule <1-999999> time weekdays <text>
set firewall ipv6 name <name> rule <1-999999> time weekdays <text>
Time to match the defined rule.
set firewall ipv6 forward filter rule <1-999999> hop-limit <eq | gt | lt> <0-255>
set firewall ipv6 input filter rule <1-999999> hop-limit <eq | gt | lt> <0-255>
set firewall ipv6 output filter rule <1-999999> hop-limit <eq | gt | lt> <0-255>
set firewall ipv6 name <name> rule <1-999999> hop-limit <eq | gt | lt> <0-255>
Match the hop-limit parameter, where ‘eq’ stands for ‘equal’; ‘gt’ stands for ‘greater than’, and ‘lt’ stands for
‘less than’.
set firewall ipv6 forward filter rule <1-999999> recent count <1-255>
set firewall ipv6 input filter rule <1-999999> recent count <1-255>
set firewall ipv6 output filter rule <1-999999> recent count <1-255>
set firewall ipv6 name <name> rule <1-999999> recent count <1-255>
set firewall ipv6 forward filter rule <1-999999> recent time <second | minute | hour>
set firewall ipv6 input filter rule <1-999999> recent time <second | minute | hour>
set firewall ipv6 output filter rule <1-999999> recent time <second | minute | hour>
set firewall ipv6 name <name> rule <1-999999> recent time <second | minute | hour>
Match when ‘count’ amount of connections are seen within ‘time’. These matching criteria can be used to block
brute-force attempts.
Synproxy
Synproxy connections
set firewall ipv6 [input | forward] filter rule <1-999999> action synproxy
set firewall ipv6 [input | forward] filter rule <1-999999> protocol tcp
set firewall ipv6 [input | forward] filter rule <1-999999> synproxy tcp mss <501-65535>
Set the TCP-MSS (maximum segment size) for the connection
set firewall ipv6 [input | forward] filter rule <1-999999> synproxy tcp window-scale
<1-14>
Example synproxy
Operation-mode Firewall
Rule-set overview
show firewall
This will show you a basic firewall overview, for all rule-sets, and not only for ipv6
---------------------------------
IPv4 Firewall "forward filter"
---------------------------------
(continues on next page)
---------------------------------
IPv6 Firewall "forward filter"
---------------------------------
IPv6 Firewall "input filter"
---------------------------------
IPv6 Firewall "ipv6_name IPV6-VyOS_MANAGEMENT"
IPv6 Ruleset:
IPv4 Ruleset:
Firewall Groups
---------------------------------
ipv6 Firewall "input filter"
(continues on next page)
vyos@vyos:~$
firewall {
ipv6 {
input {
filter {
rule 10 {
action jump
inbound-interface {
name eth1
}
jump-target INP-ETH1
}
rule 20 {
action accept
inbound-interface {
name eth0
}
log
protocol ipv6-icmp
}
}
}
name INP-ETH1 {
default-action drop
default-log
rule 10 {
action accept
protocol tcp_udp
}
}
}
}
update geoip
Command used to update GeoIP database and firewall sets.
Overview
In this section there’s useful information on all firewall configuration that can be done regarding flowtables.
set firewall flowtables ...
From the main structure defined in Firewall Overview in this section you can find detailed information only for the next
part of the general structure:
- set firewall
* flowtable
- custom_flow_table
+ ...
Flowtables allow you to define a fastpath through the flowtable datapath. The flowtable supports for the layer 3 IPv4
and IPv6 and the layer 4 TCP and UDP protocols.
Once the first packet of the flow successfully goes through the IP forwarding path (black circles path), from the second
packet on, you might decide to offload the flow to the flowtable through your ruleset. The flowtable infrastructure
provides a rule action that allows you to specify when to add a flow to the flowtable (On forward filtering, red circle
number 6)
A packet that finds a matching entry in the flowtable (flowtable hit) is transmitted to the output netdevice, hence, packets
bypass the classic IP forwarding path and uses the Fast Path (orange circles path). The visible effect is that you do not
see these packets from any of the Netfilter hooks coming after ingress. In case that there is no matching entry in the
flowtable (flowtable miss), the packet follows the classic IP forwarding path.
Flowtable Configuration
Configuration Example
Commands
Explanation
Checks
It’s time to check the conntrack table, to see if any connections were accepted, and if it was properly offloaded
---------------------------------
ipv4 Firewall "forward filter"
vyos@FlowTables:~$
Note: For more information of Netfilter hooks and Linux networking packet flows can be found in Netfilter-Hooks
Overview
Note: Starting from VyOS 1.4-rolling-202308040557, a new firewall structure can be found on all VyOS installations.
The Zone based firewall was removed in that version, but re introduced in VyOS 1.4 and 1.5. All versions built after
2023-10-22 have this feature. Documentation for most of the new firewall CLI can be found in the firewall chapter. The
legacy firewall is still available for versions before 1.4-rolling-202308040557 and can be found in the legacy firewall
configuration chapter.
In this section there’s useful information on all firewall configuration that is needed for the zone-based firewall. Con-
figuration commands covered in this section:
set firewall zone ...
From the main structure defined in Firewall Overview in this section you can find detailed information only for the next
part of the general structure:
- set firewall
* zone
- custom_zone_name
+ ...
In zone-based policy, interfaces are assigned to zones, and inspection policy is applied to traffic moving between the
zones and acted on according to firewall rules. A zone is a group of interfaces that have similar functions or features. It
establishes the security borders of a network. A zone defines a boundary where traffic is subjected to policy restrictions
as it crosses to another region of a network.
Key Points:
• A zone must be configured before an interface is assigned to it and an interface can be assigned to only a single
zone.
• All traffic to and from an interface within a zone is permitted.
Note: In T2199 the syntax of the zone configuration was changed. The zone configuration moved from zone-policy
zone <name> to firewall zone <name>.
Configuration
As an alternative to applying policy to an interface directly, a zone-based firewall can be created to simplify configu-
ration when multiple interfaces belong to the same security zone. Instead of applying rule-sets to interfaces, they are
applied to source zone-destination zone pairs.
A basic introduction to zone-based firewalls can be found here, and an example at Zone-Policy example.
Define a Zone
Before you are able to apply a rule-set to a zone you have to create the zones first.
It helps to think of the syntax as: (see below). The ‘rule-set’ should be written from the perspective of: Source Zone-
to->*Destination Zone*
set firewall zone <Destination Zone> from <Source Zone> firewall name <rule-set>
set firewall zone <name> from <name> firewall name <rule-set>
set firewall zone <name> from <name> firewall ipv6-name <rule-set>
You apply a rule-set always to a zone from an other zone, it is recommended to create one rule-set for each zone
pair.
Operation-mode
With zone-based firewalls a new concept was implemented, in addition to the standard in and out traffic flows, a local
flow was added. This local flow was for traffic originating and destined to the router itself. Which means that additional
rules were required to secure the firewall itself from the network, in addition to the existing inbound and outbound rules
from the traditional concept above.
To configure VyOS with the zone-based firewall configuration
As the example image below shows, the device now needs rules to allow/block traffic to or from the services running
on the device that have open connections on that interface.
VRRP (Virtual Router Redundancy Protocol) provides active/backup redundancy for routers. Every VRRP router has
a physical IP/IPv6 address, and a virtual address. On startup, routers elect the master, and the router with the highest
priority becomes the master and assigns the virtual address to its interface. All routers with lower priorities become
backup routers. The master then starts sending keepalive packets to notify other routers that it’s available. If the master
fails and stops sending keepalive packets, the router with the next highest priority becomes the new master and takes
over the virtual address.
VRRP keepalive packets use multicast, and VRRP setups are limited to a single datalink layer segment. You can setup
multiple VRRP groups (also called virtual routers). Virtual routers are identified by a VRID (Virtual Router IDentifier).
If you setup multiple groups on the same interface, their VRIDs must be unique if they use the same address family,
but it’s possible (even if not recommended for readability reasons) to use duplicate VRIDs on different interfaces.
VRRP groups are created with the set high-availability vrrp group $GROUP_NAME commands. The required
parameters are interface, vrid, and address.
minimal config
You can verify your VRRP group status with the operational mode run show vrrp command:
The address parameter can be either an IPv4 or IPv6 address, but you can not mix IPv4 and IPv6 in the same group,
and will need to create groups with different VRIDs specially for IPv4 and IPv6. If you want to use IPv4 + IPv6 address
you can use option excluded-address
8.3.3 Address
The address can be configured either on the VRRP interface or on not VRRP interface.
A disabled group will be removed from the VRRP process and your router will not participate in VRRP for that VRID.
It will disappear from operational mode commands output, rather than enter the backup state.
Exclude IP addresses from VRRP packets. This option excluded-address is used when you want to set IPv4 +
IPv6 addresses on the same virtual interface or when used more than 20 IP addresses.
The priority must be an integer number from 1 to 255. Higher priority value increases router’s precedence in the master
elections.
In the following example, when VLAN9 transitions, VLAN20 will also transition:
vrrp {
group VLAN9 {
interface eth0.9
address 10.9.1.1/24
priority 200
vrid 9
}
group VLAN20 {
interface eth0.20
priority 200
address 10.20.20.1/24
vrid 20
}
sync-group MAIN {
(continues on next page)
Warning: All items in a sync group should be similarly configured. If one VRRP group is set to a different
preemption delay or priority, it would result in an endless transition loop.
8.3.8 Preemption
VRRP can use two modes: preemptive and non-preemptive. In the preemptive mode, if a router with a higher priority
fails and then comes back, routers with lower priority will give up their master status. In non-preemptive mode, the
newly elected master will keep the master status and the virtual address indefinitely.
By default VRRP uses preemption. You can disable it with the “no-preempt” option:
You can also configure the time interval for preemption with the “preempt-delay” option. For example, to set the higher
priority router to take over in 180 seconds, use:
8.3.9 Track
Track option to track non VRRP interface states. VRRP changes status to FAULT if one of the track interfaces in state
down.
By default VRRP uses multicast packets. If your network does not support multicast for whatever reason, you can make
VRRP use unicast communication instead.
8.3.11 rfc3768-compatibility
RFC 3768 defines a virtual MAC address to each VRRP virtual router. This virtual router MAC address will be used
as the source in all periodic VRRP messages sent by the active node. When the rfc3768-compatibility option is set, a
new VRRP interface is created, to which the MAC address and the virtual IP address is automatically assigned.
Verification
Warning: RFC 3768 creates a virtual interface. If you want to apply the destination NAT rule to the traffic sent
to the virtual MAC, set the created virtual interface as inbound-interface.
On most scenarios, there’s no need to change specific parameters, and using default configuration is enough. But there
are cases were extra configuration is needed.
set high-availability vrrp global-parameters startup_delay <1-600>
This option specifies a delay in seconds before vrrp instances start up after keepalived starts.
These configuration is not mandatory and in most cases there’s no need to configure it. But if necessary, Gratuitous
ARP can be configured in global-parameters and/or in group section.
set high-availability vrrp global-parameters garp interval <0.000-1000>
set high-availability vrrp group <name> garp interval <0.000-1000>
Set delay between gratuitous ARP messages sent on an interface.
0 if not defined.
set high-availability vrrp global-parameters garp master-delay <1-255>
set high-availability vrrp group <name> garp master-delay <1-255>
Set delay for second set of gratuitous ARPs after transition to MASTER.
5 if not defined.
set high-availability vrrp global-parameters garp master-refresh <1-600>
set high-availability vrrp group <name> garp master-refresh <1-600>
Set minimum time interval for refreshing gratuitous ARPs while MASTER.
0 if not defined, which means no refreshing.
8.3.14 Version
8.3.15 Scripting
VRRP functionality can be extended with scripts. VyOS supports two kinds of scripts: health check scripts and transi-
tion scripts. Health check scripts execute custom checks in addition to the master router reachability. Transition scripts
are executed when VRRP state changes from master to backup or fault and vice versa and can be used to enable or
disable certain services, for example.
This setup will make the VRRP process execute the /config/scripts/vrrp-check.sh script every 60 seconds,
and transition the group to the fault state if it fails (i.e. exits with non-zero status) three times:
When the vrrp group is a member of the sync group will use only the sync group health check script. This example
shows how to configure it for the sync group:
Transition scripts
Transition scripts can help you implement various fixups, such as starting and stopping services, or even modify-
ing the VyOS config on VRRP transition. This setup will make the VRRP process execute the /config/scripts/
vrrp-fail.sh with argument Foo when VRRP fails, and the /config/scripts/vrrp-master.sh when the router
becomes the master:
8.3.16 Virtual-server
Virtual Server allows to Load-balance traffic destination virtual-address:port between several real servers.
Algorithm
Forward method
• NAT
• direct
• tunnel
Health-check
Fwmark
Real server
Example
A firewall mark fwmark allows using multiple ports for high-availability virtual-server. It uses fwmark value.
In this example all traffic destined to ports “80, 2222, 8888” protocol TCP marks to fwmark “111” and balanced between
2 real servers. Port “0” is required if multiple ports are used.
8.4 Interfaces
The bonding interface provides a method for aggregating multiple network interfaces into a single logical “bonded”
interface, or LAG, or ether-channel, or port-channel. The behavior of the bonded interfaces depends upon the mode;
generally speaking, modes provide either hot standby or load balancing services. Additionally, link integrity monitoring
may be performed.
Configuration
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
set interfaces bonding bond0 description 'This is an awesome interface running on␣
˓→VyOS'
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces bonding <interface> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
by the complete host on Linux, not by particular interfaces. Only for more complex setups like load-balancing,
does this behaviour cause problems.
If not set (default) allows you to have multiple network interfaces on the same subnet, and have the ARPs for
each interface be answered based on whether or not the kernel would route a packet from the ARP’d IP out that
interface (therefore you must use source based routing for this to work).
In other words it allows control of which cards (usually 1) will respond to an arp request.
Example:
If configured, reply only if the target IP address is local address configured on the incoming interface.
If this option is unset (default), reply for any local target IP address, configured on any interface.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces bonding <interface> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
DHCP(v6)
set interfaces bonding <interface> dhcp-options client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
Member Interfaces
Bond options
Note: Not all transmit policies may be 802.3ad compliant, particularly in regards to the packet
misordering requirements of section 43.2.4 of the 802.3ad standard.
• active-backup - Active-backup policy: Only one slave in the bond is active. A different slave
becomes active if, and only if, the active slave fails. The bond’s MAC address is externally visible
on only one port (network adapter) to avoid confusing the switch.
When a failover occurs in active-backup mode, bonding will issue one or more gratuitous ARPs
on the newly active slave. One gratuitous ARP is issued for the bonding master interface and
each VLAN interfaces configured above it, provided that the interface has at least one IP address
configured. Gratuitous ARPs issued for VLAN interfaces are tagged with the appropriate VLAN
id.
This mode provides fault tolerance. The primary option, documented below, affects the behavior
of this mode.
• broadcast - Broadcast policy: transmits everything on all slave interfaces.
This mode provides fault tolerance.
• round-robin - Round-robin policy: Transmit packets in sequential order from the first available
slave through the last.
This mode provides load balancing and fault tolerance.
• transmit-load-balance - Adaptive transmit load balancing: channel bonding that does not
require any special switch support.
Incoming traffic is received by the current slave. If the receiving slave fails, another slave takes
over the MAC address of the failed receiving slave.
• adaptive-load-balance - Adaptive load balancing: includes transmit-load-balance plus re-
ceive load balancing for IPV4 traffic, and does not require any special switch support. The receive
load balancing is achieved by ARP negotiation. The bonding driver intercepts the ARP Replies
sent by the local system on their way out and overwrites the source hardware address with the
unique hardware address of one of the slaves in the bond such that different peers use different
hardware addresses for the server.
Receive traffic from connections created by the server is also balanced. When the local system
sends an ARP Request the bonding driver copies and saves the peer’s IP information from the
ARP packet. When the ARP Reply arrives from the peer, its hardware address is retrieved and the
bonding driver initiates an ARP reply to this peer assigning it to one of the slaves in the bond. A
problematic outcome of using ARP negotiation for balancing is that each time that an ARP request
is broadcast it uses the hardware address of the bond. Hence, peers learn the hardware address
of the bond and the balancing of receive traffic collapses to the current slave. This is handled by
sending updates (ARP Replies) to all the peers with their individually assigned hardware address
such that the traffic is redistributed. Receive traffic is also redistributed when a new slave is added
to the bond and when an inactive slave is re-activated. The receive load is distributed sequentially
(round robin) among the group of highest speed slaves in the bond.
When a link is reconnected or a new slave joins the bond the receive traffic is redistributed among
all active slaves in the bond by initiating ARP Replies with the selected MAC address to each of
the clients. The updelay parameter (detailed below) must be set to a value equal or greater than
the switch’s forwarding delay so that the ARP Replies sent to the peers will not be blocked by the
switch.
• xor-hash - XOR policy: Transmit based on the selected transmit hash policy. The default policy
is a simple [(source MAC address XOR’d with destination MAC address XOR packet type ID)
modulo slave count]. Alternate transmit policies may be selected via the hash-policy option,
described below.
This mode provides load balancing and fault tolerance.
set interfaces bonding <interface> min-links <0-16>
Specifies the minimum number of links that must be active before asserting carrier. It is similar to the Cisco
EtherChannel min-links feature. This allows setting the minimum number of member ports that must be up
(link-up state) before marking the bond device as up (carrier on). This is useful for situations where higher
level services such as clustering want to ensure a minimum number of low bandwidth links are active before
switchover.
This option only affects 802.3ad mode.
The default value is 0. This will cause the carrier to be asserted (for 802.3ad mode) whenever there is an active
aggregator, regardless of the number of available links in that aggregator.
Note: Because an aggregator cannot be active without at least one available link, setting this option to 0 or to
1 has the exact same effect.
• layer2 - Uses XOR of hardware MAC addresses and packet type ID field to generate the hash. The formula
is
This algorithm will place all traffic to a particular network peer on the same slave.
This algorithm is 802.3ad compliant.
• layer2+3 - This policy uses a combination of layer2 and layer3 protocol information to generate the hash.
Uses XOR of hardware MAC addresses and IP addresses to generate the hash. The formula is:
VLAN
IEEE 802.1q, often referred to as Dot1q, is the networking standard that supports virtual LANs (VLANs) on an IEEE
802.3 Ethernet network. The standard defines a system of VLAN tagging for Ethernet frames and the accompanying
procedures to be used by bridges and switches in handling such frames. The standard also contains provisions for a
quality-of-service prioritization scheme commonly known as IEEE 802.1p and defines the Generic Attribute Registra-
tion Protocol.
Portions of the network which are VLAN-aware (i.e., IEEE 802.1q conformant) can include VLAN tags. When a frame
enters the VLAN-aware portion of the network, a tag is added to represent the VLAN membership. Each frame must
be distinguishable as being within exactly one VLAN. A frame in the VLAN-aware portion of the network that does
not contain a VLAN tag is assumed to be flowing on the native VLAN.
The standard was developed by IEEE 802.1, a working group of the IEEE 802 standards committee, and continues
to be actively revised. One of the notable revisions is 802.1Q-2014 which incorporated IEEE 802.1aq (Shortest Path
Bridging) and much of the IEEE 802.1d standard.
802.1q VLAN interfaces are represented as virtual sub-interfaces in VyOS. The term used for this is vif.
set interfaces bonding <interface> vif <vlan-id>
Create a new VLAN interface on interface <interface> using the VLAN number provided via <vlan-id>.
You can create multiple VLAN interfaces on a physical interface. The VLAN ID range is from 0 to 4094.
set interfaces bonding <interface> vif <vlan-id> address <address | dhcp | dhcpv6>
Configure interface <interface> with one or more interface addresses.
• address can be specified multiple times as IPv4 and/or IPv6 address, e.g. 192.0.2.1/24 and/or
2001:db8::1/64
• dhcp interface address is received by DHCP from a DHCP server on this segment.
• dhcpv6 interface address is received by DHCPv6 from a DHCPv6 server on this segment.
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces bonding <interface> vif <vlan-id> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
Define behavior for gratuitous ARP frames whose IP is not already present in the ARP table. If configured
create new entries in the ARP table.
Both replies and requests type gratuitous arp will trigger the ARP table to be updated, if this setting is on.
If the ARP table already contains the IP address of the gratuitous arp frame, the arp table will be updated
regardless if this setting is on or off.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
set interfaces bonding <interface> vif <vlan-id> ipv6 address eui64 <prefix>
EUI-64 as specified in RFC 4291 allows a host to assign iteslf a unique 64-Bit IPv6 address.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces bonding <interface> vif <vlan-id> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
DHCP(v6)
set interfaces bonding <interface> vif <vlan-id> dhcp-options client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
The DHCP unique identifier (DUID) is used by a client to get an IP address from a DHCPv6 server. It has a
2-byte DUID type field, and a variable-length identifier field up to 128 bytes. Its actual length depends on its
type. The server compares the DUID with its database and delivers configuration data (address, lease times,
DNS servers, etc.) to the client.
It will be combined with the delegated prefix and the sla-id to form a complete interface address. The default is
to use the EUI-64 address of the interface.
Example: Delegate a /64 prefix to interface eth8 which will use a local address on this router of
<prefix>::ffff, as the address 65534 will correspond to ffff in hexadecimal notation.
set interfaces bonding bond0 vif 10 dhcpv6-options pd 0 interface eth8 address 65534
SPAN port mirroring can copy the inbound/outbound traffic of the interface to the specified interface, usually the
interface can be connected to some special equipment, such as a behavior control system, intrusion detection system or
traffic collector, and can copy all related traffic from this port. The benefit of mirroring the traffic is that the application
is isolated from the source traffic and so application processing does not affect the traffic or the system performance.
VyOS uses the mirror option to configure port mirroring. The configuration is divided into 2 different directions.
Destination ports should be configured for different traffic directions.
set interfaces bondinging <interface> mirror ingress <monitor-interface>
Configure port mirroring for interface inbound traffic and copy the traffic to monitor-interface
Example: Mirror the inbound traffic of bond1 port to eth3
EVPN Multihoming
All-Active Multihoming is used for redundancy and load sharing. Servers are attached to two or more PEs and the
links are bonded (link-aggregation). This group of server links is referred to as an ES (Ethernet Segment).
An Ethernet Segment can be configured by specifying a system-MAC and a local discriminator or a complete
ESINAME against the bond interface on the PE.
set interfaces bonding <interface> evpn es-id <<1-16777215|10-byte ID>
set interfaces bonding <interface> evpn es-sys-mac <xx:xx:xx:xx:xx:xx>
The sys-mac and local discriminator are used for generating a 10-byte, Type-3 Ethernet Segment ID. ESINAME
is a 10-byte, Type-0 Ethernet Segment ID - “00:AA:BB:CC:DD:EE:FF:GG:HH:II”.
Type-1 (EAD-per-ES and EAD-per-EVI) routes are used to advertise the locally attached ESs and to learn off
remote ESs in the network. Local Type-2/MAC-IP routes are also advertised with a destination ESI allowing
for MAC-IP syncing between Ethernet Segment peers. Reference: RFC 7432, RFC 8365
EVPN-MH is intended as a replacement for MLAG or Anycast VTEPs. In multihoming each PE has an unique
VTEP address which requires the introduction of a new dataplane construct, MAC-ECMP. Here a MAC/FDB
entry can point to a list of remote PEs/VTEPs.
set interfaces bonding <interface> evpn es-df-pref <1-65535>
Type-4 (ESR) routes are used for Designated Forwarder (DF) election. DFs forward BUM traffic received via
the overlay network. This implementation uses a preference based DF election specified by draft-ietf-bess-evpn-
pref-df.
The DF preference is configurable per-ES.
BUM traffic is rxed via the overlay by all PEs attached to a server but only the DF can forward the de-capsulated
traffic to the access port. To accommodate that non-DF filters are installed in the dataplane to drop the traffic.
Similarly traffic received from ES peers via the overlay cannot be forwarded to the server. This is split-horizon-
filtering with local bias.
set interfaces bonding <interface> evpn uplink
When all the underlay links go down the PE no longer has access to the VxLAN +overlay. To prevent blackholing
of traffic the server/ES links are protodowned on the PE.
A link can be setup for uplink tracking via the following example:
Example
The following configuration on VyOS applies to all following 3rd party vendors. It creates a bond with two links and
VLAN 10, 100 on the bonded interfaces with a per VIF IPv4 address.
Note: If you happen to run this in a virtual environment like by EVE-NG you need to ensure your VyOS NIC is set to
use the e1000 driver. Using the default virtio-net-pci or the vmxnet3 driver will not work. ICMP messages will
not be properly processed. They are visible on the virtual wire but will not make it fully up the networking stack.
You can check your NIC driver by issuing show interfaces ethernet eth0 physical | grep -i driver
Cisco Catalyst
interface GigabitEthernet1/0/23
description VyOS eth1
channel-group 1 mode active
!
interface GigabitEthernet1/0/24
description VyOS eth2
channel-group 1 mode active
!
A new interface becomes present Port-channel1, all configuration like allowed VLAN interfaces, STP will happen
here.
interface Port-channel1
description LACP Channel for VyOS
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,100
switchport mode trunk
spanning-tree portfast trunk
!
Juniper EX Switch
For a headstart you can use the below example on how to build a bond with two interfaces from VyOS to a Juniper EX
Switch system.
# Create aggregated ethernet device with 802.3ad LACP and port speeds of 10gbit/s
set interfaces ae0 aggregated-ether-options link-speed 10g
set interfaces ae0 aggregated-ether-options lacp active
# Create layer 2 on the aggregated ethernet device with trunking for our vlans
set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
# Add the two interfaces to the aggregated ethernet device, in this setup both
# ports are on the same switch (switch 0, module 1, port 0 and 1)
set interfaces xe-0/1/0 ether-options 802.3ad ae0
set interfaces xe-0/1/1 ether-options 802.3ad ae0
# But this can also be done with multiple switches in a stack, a virtual
# chassis on Juniper (switch 0 and switch 1, module 1, port 0 on both switches)
set interfaces xe-0/1/0 ether-options 802.3ad ae0
set interfaces xe-1/1/0 ether-options 802.3ad ae0
Aruba/HP
For a headstart you can use the below example on how to build a bond,port-channel with two interfaces from VyOS to
a Aruba/HP 2510G switch.
Arista EOS
When utilizing VyOS in an environment with Arista gear you can use this blue print as an initial setup to get an LACP
bond / port-channel operational between those two devices.
Lets assume the following topology:
R1
interfaces {
bonding bond10 {
hash-policy layer3+4
member {
interface eth1
interface eth2
}
(continues on next page)
R2
interfaces {
bonding bond10 {
hash-policy layer3+4
member {
interface eth1
interface eth2
}
mode 802.3ad
vif 100 {
address 192.0.2.2/30
address 2001:db8::2/64
}
}
SW1
!
vlan 100
name FOO
!
interface Port-Channel10
switchport trunk allowed vlan 100
switchport mode trunk
spanning-tree portfast
!
interface Port-Channel20
switchport mode trunk
no spanning-tree portfast auto
spanning-tree portfast network
!
interface Ethernet1
channel-group 10 mode active
!
interface Ethernet2
channel-group 10 mode active
!
interface Ethernet3
channel-group 20 mode active
!
interface Ethernet4
channel-group 20 mode active
!
SW2
!
vlan 100
name FOO
!
interface Port-Channel10
switchport trunk allowed vlan 100
switchport mode trunk
spanning-tree portfast
!
interface Port-Channel20
switchport mode trunk
no spanning-tree portfast auto
spanning-tree portfast network
!
interface Ethernet1
channel-group 10 mode active
!
interface Ethernet2
channel-group 10 mode active
!
interface Ethernet3
channel-group 20 mode active
!
interface Ethernet4
channel-group 20 mode active
!
Note: When using EVE-NG to lab this environment ensure you are using e1000 as the desired driver for your VyOS
network interfaces. When using the regular virtio network driver no LACP PDUs will be sent by VyOS thus the
port-channel will never become active!
Operation
802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
8.4.2 Bridge
A Bridge is a way to connect two Ethernet segments together in a protocol independent way. Packets are forwarded
based on Ethernet address, rather than IP address (like a router). Since forwarding is done at Layer 2, all protocols can
go transparently through a bridge. The Linux bridge code implements a subset of the ANSI/IEEE 802.1d standard.
Note: Spanning Tree Protocol is not enabled by default in VyOS. STP Parameter can be easily enabled if needed.
Configuration
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
set interfaces bridge br0 description 'This is an awesome interface running on VyOS'
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
If configured, try to avoid local addresses that are not in the target’s subnet for this interface. This mode is
useful when target hosts reachable via this interface require the source IP address in ARP requests to be part of
their logical network configured on the receiving interface. When we generate the request we will check all our
subnets that include the target IP and will preserve the source address if it is from such subnet. If there is no
such subnet we select source address according to the rules for level 2.
• loose: Each incoming packet’s source address is also tested against the FIB and if the source address is not
reachable via any interface the packet check will fail.
• disable: No source validation
set interfaces bridge <interface> ipv6 address autoconf
SLAAC RFC 4862. IPv6 hosts can configure themselves automatically when connected to an IPv6 network us-
ing the Neighbor Discovery Protocol via ICMPv6 router discovery messages. When first connected to a network,
a host sends a link-local router solicitation multicast request for its configuration parameters; routers respond to
such a request with a router advertisement packet that contains Internet Layer configuration parameters.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces bridge <interface> ipv6 accept-dad <1-3>
DHCP(v6)
set interfaces bridge <interface> dhcp-options client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
Member Interfaces
Bridge Options
STP Parameter
STP (Spanning Tree Protocol) is a network protocol that builds a loop-free logical topology for Ethernet networks. The
basic function of STP is to prevent bridge loops and the broadcast radiation that results from them. Spanning tree also
allows a network design to include backup links providing fault tolerance if an active link fails.
set interfaces bridge <interface> stp
Enable spanning tree protocol. STP is disabled by default.
set interfaces bridge <interface> forwarding-delay <delay>
Spanning Tree Protocol forwarding <delay> in seconds (default: 15).
The forwarding delay time is the time spent in each of the listening and learning states before the Forwarding
state is entered. This delay is so that when a new bridge comes onto a busy network it looks at some traffic
before participating.
set interfaces bridge <interface> hello-time <interval>
VLAN
VLAN Options
Note: It is not valid to use the vif 1 option for VLAN aware bridges because VLAN aware bridges assume that all
unlabeled packets belong to the default VLAN 1 member and that the VLAN ID of the bridge’s parent interface is
always 1
IEEE 802.1q, often referred to as Dot1q, is the networking standard that supports virtual LANs (VLANs) on an IEEE
802.3 Ethernet network. The standard defines a system of VLAN tagging for Ethernet frames and the accompanying
procedures to be used by bridges and switches in handling such frames. The standard also contains provisions for a
quality-of-service prioritization scheme commonly known as IEEE 802.1p and defines the Generic Attribute Registra-
tion Protocol.
Portions of the network which are VLAN-aware (i.e., IEEE 802.1q conformant) can include VLAN tags. When a frame
enters the VLAN-aware portion of the network, a tag is added to represent the VLAN membership. Each frame must
be distinguishable as being within exactly one VLAN. A frame in the VLAN-aware portion of the network that does
not contain a VLAN tag is assumed to be flowing on the native VLAN.
The standard was developed by IEEE 802.1, a working group of the IEEE 802 standards committee, and continues
to be actively revised. One of the notable revisions is 802.1Q-2014 which incorporated IEEE 802.1aq (Shortest Path
Bridging) and much of the IEEE 802.1d standard.
802.1q VLAN interfaces are represented as virtual sub-interfaces in VyOS. The term used for this is vif.
set interfaces bridge <interface> vif <vlan-id>
Create a new VLAN interface on interface <interface> using the VLAN number provided via <vlan-id>.
You can create multiple VLAN interfaces on a physical interface. The VLAN ID range is from 0 to 4094.
set interfaces bridge <interface> vif <vlan-id> address <address | dhcp | dhcpv6>
Configure interface <interface> with one or more interface addresses.
• address can be specified multiple times as IPv4 and/or IPv6 address, e.g. 192.0.2.1/24 and/or
2001:db8::1/64
• dhcp interface address is received by DHCP from a DHCP server on this segment.
• dhcpv6 interface address is received by DHCPv6 from a DHCPv6 server on this segment.
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
set interfaces bridge br0 vif 10 description 'This is an awesome interface running␣
˓→on VyOS'
Configure MTU on given <interface>. It is the size (in bytes) of the largest ethernet frame sent on this link.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces bridge <interface> vif <vlan-id> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
If this option is unset (default), incoming IP directed broadcast packets will not be forwarded.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
set interfaces bridge <interface> vif <vlan-id> ipv6 address eui64 <prefix>
EUI-64 as specified in RFC 4291 allows a host to assign iteslf a unique 64-Bit IPv6 address.
Example:
Configure interface-specific Host/Router behaviour. If set, the interface will switch to host mode and IPv6
forwarding will be disabled on this interface.
Example:
set interfaces bridge <interface> vif <vlan-id> ipv6 adjust-mss <mss | clamp-mss-to-pmtu>
As Internet wide PMTU discovery rarely works, we sometimes need to clamp our TCP MSS value to a specific
value. This is a field in the TCP options part of a SYN packet. By setting the MSS value, you are telling the
remote side unequivocally ‘do not try to send me packets bigger than this value’.
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces bridge <interface> vif <vlan-id> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
DHCP(v6)
set interfaces bridge <interface> vif <vlan-id> dhcp-options client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
Specify the interface address used locally on the interface where the prefix has been delegated to. ID must be a
decimal integer.
It will be combined with the delegated prefix and the sla-id to form a complete interface address. The default is
to use the EUI-64 address of the interface.
Example: Delegate a /64 prefix to interface eth8 which will use a local address on this router of
<prefix>::ffff, as the address 65534 will correspond to ffff in hexadecimal notation.
set interfaces bridge br0 vif 10 dhcpv6-options pd 0 interface eth8 address 65534
SPAN port mirroring can copy the inbound/outbound traffic of the interface to the specified interface, usually the
interface can be connected to some special equipment, such as a behavior control system, intrusion detection system or
traffic collector, and can copy all related traffic from this port. The benefit of mirroring the traffic is that the application
is isolated from the source traffic and so application processing does not affect the traffic or the system performance.
VyOS uses the mirror option to configure port mirroring. The configuration is divided into 2 different directions.
Destination ports should be configured for different traffic directions.
set interfaces bridge <interface> mirror ingress <monitor-interface>
Configure port mirroring for interface inbound traffic and copy the traffic to monitor-interface
Example: Mirror the inbound traffic of br1 port to eth3
Examples
show bridge
The show bridge operational command can be used to display configured bridges:
8.4.3 Dummy
The dummy interface is really a little exotic, but rather useful nevertheless. Dummy interfaces are much like the
Loopback interface, except you can have as many as you want.
Note: Dummy interfaces can be used as interfaces that always stay up (in the same fashion to loopbacks in Cisco IOS),
or for testing purposes.
Hint: On systems with multiple redundant uplinks and routes, it’s a good idea to use a dedicated address for man-
agement and dynamic routing protocols. However, assigning that address to a physical link is risky: if that link goes
down, that address will become inaccessible. A common solution is to assign the management address to a loopback
or a dummy interface and advertise that address via all physical links, so that it’s reachable through any of them. Since
in Linux-based systems, there can be only one loopback interface, it’s better to use a dummy interface for that purpose,
since they can be added, removed, and taken up and down independently.
Configuration
set interfaces dummy dum0 description 'This is an awesome interface running on VyOS'
Operation
8.4.4 Ethernet
This will be the most widely used interface on a router carrying traffic to the real world.
Configuration
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
set interfaces ethernet eth0 description 'This is an awesome interface running on␣
˓→VyOS'
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
If configured, try to avoid local addresses that are not in the target’s subnet for this interface. This mode is
useful when target hosts reachable via this interface require the source IP address in ARP requests to be part of
their logical network configured on the receiving interface. When we generate the request we will check all our
subnets that include the target IP and will preserve the source address if it is from such subnet. If there is no
such subnet we select source address according to the rules for level 2.
• loose: Each incoming packet’s source address is also tested against the FIB and if the source address is not
reachable via any interface the packet check will fail.
• disable: No source validation
set interfaces ethernet <interface> ipv6 address autoconf
SLAAC RFC 4862. IPv6 hosts can configure themselves automatically when connected to an IPv6 network us-
ing the Neighbor Discovery Protocol via ICMPv6 router discovery messages. When first connected to a network,
a host sends a link-local router solicitation multicast request for its configuration parameters; routers respond to
such a request with a router advertisement packet that contains Internet Layer configuration parameters.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces ethernet <interface> ipv6 accept-dad <1-3>
DHCP(v6)
set interfaces ethernet <interface> dhcp-options client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
Ethernet options
Offloading
set interfaces ethernet <interface> offload <gro | gso | lro | rps | sg | tso>
Enable different types of hardware offloading on the given NIC.
LRO (Large Receive Offload) is a technique designed to boost the efficiency of how your computer’s network
interface card (NIC) processes incoming network traffic. Typically, network data arrives in smaller chunks called
packets. Processing each packet individually consumes CPU (central processing unit) resources. Lots of small
packets can lead to a performance bottleneck. Instead of handing the CPU each packet as it comes in, LRO
instructs the NIC to combine multiple incoming packets into a single, larger packet. This larger packet is then
passed to the CPU for processing.
Note: Under some circumstances, LRO is known to modify the packet headers of forwarded traffic, which
breaks the end-to-end principle of computer networking. LRO is also only able to offload TCP segments en-
capsulated in IPv4 packets. Due to these limitations, it is recommended to use GRO (Generic Receive Offload)
where possible. More information on the limitations of LRO can be found here: https://lwn.net/Articles/358910/
GSO (Generic Segmentation Offload) is a pure software offload that is meant to deal with cases where device
drivers cannot perform the offloads described above. What occurs in GSO is that a given skbuff will have its data
broken out over multiple skbuffs that have been resized to match the MSS provided via skb_shinfo()->gso_size.
Before enabling any hardware segmentation offload a corresponding software offload is required in GSO. Other-
wise it becomes possible for a frame to be re-routed between devices and end up being unable to be transmitted.
GRO (Generic receive offload) is the complement to GSO. Ideally any frame assembled by GRO should be
segmented to create an identical sequence of frames using GSO, and any sequence of frames segmented by
GSO should be able to be reassembled back to the original by GRO. The only exception to this is IPv4 ID in the
case that the DF bit is set for a given IP header. If the value of the IPv4 ID is not sequentially incrementing it
will be altered so that it is when a frame assembled via GRO is segmented via GSO.
RPS (Receive Packet Steering) is logically a software implementation of RSS (Receive Side Scaling). Being
in software, it is necessarily called later in the datapath. Whereas RSS selects the queue and hence CPU that
will run the hardware interrupt handler, RPS selects the CPU to perform protocol processing above the interrupt
handler. This is accomplished by placing the packet on the desired CPU’s backlog queue and waking up the
CPU for processing. RPS has some advantages over RSS:
• it can be used with any NIC
• software filters can easily be added to hash over new protocols
• it does not increase hardware device interrupt rate, although it does introduce inter-processor interrupts
(IPIs)
Note: In order to use TSO/LRO with VMXNET3 adapters, the SG offloading option must also be enabled.
Authentication (EAPoL)
EAP (Extensible Authentication Protocol) over LAN (EAPoL) is a network port authentication protocol used in IEEE
802.1X (Port Based Network Access Control) developed to give a generic network sign-on to access network resources.
EAPoL comes with an identify option. We automatically use the interface MAC address as identity parameter.
set interfaces ethernet <interface> eapol ca-certificate <name>
Set the name of the SSL CA (Certificate Authority) PKI entry used for authentication of the remote side. If an
intermediate CA certificate is specified, then all parent CA certificates that exist in the PKI, such as the root CA
or additional intermediate CAs, will automatically be used during certificate validation to ensure that the full
chain of trust is available.
Example:
Set the name of the x509 client keypair used to authenticate against the 802.1x system. All parent CA certificates
of the client certificate, such as intermediate and root CAs, will be sent as part of the EAP-TLS handshake.
Example:
EVPN Multihoming
Uplink/Core tracking.
set interfaces ethernet <interface> evpn uplink
When all the underlay links go down the PE no longer has access to the VxLAN +overlay. To prevent blackholing
of traffic the server/ES links are protodowned on the PE.
A link can be setup for uplink tracking via the following example:
VLAN
IEEE 802.1q, often referred to as Dot1q, is the networking standard that supports virtual LANs (VLANs) on an IEEE
802.3 Ethernet network. The standard defines a system of VLAN tagging for Ethernet frames and the accompanying
procedures to be used by bridges and switches in handling such frames. The standard also contains provisions for a
quality-of-service prioritization scheme commonly known as IEEE 802.1p and defines the Generic Attribute Registra-
tion Protocol.
Portions of the network which are VLAN-aware (i.e., IEEE 802.1q conformant) can include VLAN tags. When a frame
enters the VLAN-aware portion of the network, a tag is added to represent the VLAN membership. Each frame must
be distinguishable as being within exactly one VLAN. A frame in the VLAN-aware portion of the network that does
not contain a VLAN tag is assumed to be flowing on the native VLAN.
The standard was developed by IEEE 802.1, a working group of the IEEE 802 standards committee, and continues
to be actively revised. One of the notable revisions is 802.1Q-2014 which incorporated IEEE 802.1aq (Shortest Path
Bridging) and much of the IEEE 802.1d standard.
802.1q VLAN interfaces are represented as virtual sub-interfaces in VyOS. The term used for this is vif.
set interfaces ethernet <interface> vif <vlan-id>
Create a new VLAN interface on interface <interface> using the VLAN number provided via <vlan-id>.
You can create multiple VLAN interfaces on a physical interface. The VLAN ID range is from 0 to 4094.
set interfaces ethernet <interface> vif <vlan-id> address <address | dhcp | dhcpv6>
Configure interface <interface> with one or more interface addresses.
• address can be specified multiple times as IPv4 and/or IPv6 address, e.g. 192.0.2.1/24 and/or
2001:db8::1/64
• dhcp interface address is received by DHCP from a DHCP server on this segment.
• dhcpv6 interface address is received by DHCPv6 from a DHCPv6 server on this segment.
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
Configure MTU on given <interface>. It is the size (in bytes) of the largest ethernet frame sent on this link.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces ethernet <interface> vif <vlan-id> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
If this option is unset (default), incoming IP directed broadcast packets will not be forwarded.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
set interfaces ethernet <interface> vif <vlan-id> ipv6 address eui64 <prefix>
EUI-64 as specified in RFC 4291 allows a host to assign iteslf a unique 64-Bit IPv6 address.
Example:
Configure interface-specific Host/Router behaviour. If set, the interface will switch to host mode and IPv6
forwarding will be disabled on this interface.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces ethernet <interface> vif <vlan-id> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
DHCP(v6)
set interfaces ethernet <interface> vif <vlan-id> dhcp-options client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
Example:
set interfaces ethernet eth0 vif 10 dhcpv6-options pd 0 interface eth8 address 65534
QinQ (802.1ad)
IEEE 802.1ad was an Ethernet networking standard informally known as QinQ as an amendment to IEEE standard
802.1q VLAN interfaces as described above. 802.1ad was incorporated into the base 802.1q standard in 2011. The
technique is also known as provider bridging, Stacked VLANs, or simply QinQ or Q-in-Q. “Q-in-Q” can for supported
devices apply to C-tag stacking on C-tag (Ethernet Type = 0x8100).
The original 802.1q specification allows a single Virtual Local Area Network (VLAN) header to be inserted into an
Ethernet frame. QinQ allows multiple VLAN tags to be inserted into a single frame, an essential capability for im-
plementing Metro Ethernet network topologies. Just as QinQ extends 802.1Q, QinQ itself is extended by other Metro
Ethernet protocols.
In a multiple VLAN header context, out of convenience the term “VLAN tag” or just “tag” for short is often used in
place of “802.1q VLAN header”. QinQ allows multiple VLAN tags in an Ethernet frame; together these tags constitute
a tag stack. When used in the context of an Ethernet frame, a QinQ frame is a frame that has 2 VLAN 802.1q headers
(double-tagged).
In VyOS the terms vif-s and vif-c stand for the ethertype tags that are used.
The inner tag is the tag which is closest to the payload portion of the frame. It is officially called C-TAG (customer tag,
with ethertype 0x8100). The outer tag is the one closer/closest to the Ethernet header, its name is S-TAG (service tag
with Ethernet Type = 0x88a8).
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> address <address |
dhcp | dhcpv6>
Configure interface <interface> with one or more interface addresses.
• address can be specified multiple times as IPv4 and/or IPv6 address, e.g. 192.0.2.1/24 and/or
2001:db8::1/64
• dhcp interface address is received by DHCP from a DHCP server on this segment.
• dhcpv6 interface address is received by DHCPv6 from a DHCPv6 server on this segment.
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
set interfaces ethernet eth0 vif-s 1000 vif-c 20 description 'This is an awesome␣
˓→interface running on VyOS'
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> mtu <mtu>
Configure MTU on given <interface>. It is the size (in bytes) of the largest ethernet frame sent on this link.
Example:
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> ip adjust-mss <mss |
clamp-mss-to-pmtu>
As Internet wide PMTU discovery rarely works, we sometimes need to clamp our TCP MSS value to a specific
value. This is a field in the TCP options part of a SYN packet. By setting the MSS value, you are telling the
remote side unequivocally ‘do not try to send me packets bigger than this value’.
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
If this option is unset (default), incoming IP directed broadcast packets will not be forwarded.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
set interfaces ethernet eth0 vif-s 1000 vif-c 20 ipv6 address autoconf
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> ipv6 address eui64
<prefix>
EUI-64 as specified in RFC 4291 allows a host to assign iteslf a unique 64-Bit IPv6 address.
Example:
set interfaces ethernet eth0 vif-s 1000 vif-c 20 ipv6 address eui64 2001:db8:beef::/
˓→64
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> ipv6 address
no-default-link-local
Do not assign a link-local IPv6 address to this interface.
Example:
set interfaces ethernet eth0 vif-s 1000 vif-c 20 ipv6 address no-default-link-local
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> ipv6 adjust-mss <mss
| clamp-mss-to-pmtu>
As Internet wide PMTU discovery rarely works, we sometimes need to clamp our TCP MSS value to a specific
value. This is a field in the TCP options part of a SYN packet. By setting the MSS value, you are telling the
remote side unequivocally ‘do not try to send me packets bigger than this value’.
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> vrf <vrf>
Place interface in given VRF instance.
See also:
There is an entire chapter about how to configure a VRF, please check this for additional information.
Example:
DHCP(v6)
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> dhcp-options
client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
set interfaces ethernet eth0 vif-s 1000 vif-c 20 dhcp-options client-id 'foo-bar'
set interfaces ethernet eth0 vif-s 1000 vif-c 20 dhcp-options host-name 'VyOS'
set interfaces ethernet eth0 vif-s 1000 vif-c 20 dhcp-options vendor-class-id 'VyOS'
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> dhcp-options reject
<address>
Reject DHCP leases from a given address or range. This is useful when a modem gives a local IP when first
starting.
set interfaces ethernet eth0 vif-s 1000 vif-c 20 dhcp-options reject 192.168.100.0/
˓→24
set interfaces ethernet eth0 vif-s 1000 vif-c 20 dhcp-options user-class VyOS
set interfaces ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> dhcpv6-options duid
<duid>
The DHCP unique identifier (DUID) is used by a client to get an IP address from a DHCPv6 server. It has a
2-byte DUID type field, and a variable-length identifier field up to 128 bytes. Its actual length depends on its
type. The server compares the DUID with its database and delivers configuration data (address, lease times,
DNS servers, etc.) to the client.
set interfaces ethernet eth0 vif-s 1000 vif-c 20 dhcpv6-options pd 0 interface eth8␣
˓→address 65534
set interfaces ethernet eth0 vif-s 1000 vif-c 20 dhcpv6-options pd 0 interface eth8␣
˓→sla-id 1
SPAN port mirroring can copy the inbound/outbound traffic of the interface to the specified interface, usually the
interface can be connected to some special equipment, such as a behavior control system, intrusion detection system or
traffic collector, and can copy all related traffic from this port. The benefit of mirroring the traffic is that the application
is isolated from the source traffic and so application processing does not affect the traffic or the system performance.
VyOS uses the mirror option to configure port mirroring. The configuration is divided into 2 different directions.
Destination ports should be configured for different traffic directions.
set interfaces ethernet <interface> mirror ingress <monitor-interface>
Configure port mirroring for interface inbound traffic and copy the traffic to monitor-interface
Example: Mirror the inbound traffic of eth1 port to eth3
Operation
8.4.5 GENEVE
GENEVE (Generic Network Virtualization Encapsulation) supports all of the capabilities of VXLAN (Virtual Ex-
tensible LAN), NVGRE (Network Virtualization using Generic Routing Encapsulation), and STT (Stateless Transport
Tunneling) and was designed to overcome their perceived limitations. Many believe GENEVE could eventually replace
these earlier formats entirely.
GENEVE is designed to support network virtualization use cases, where tunnels are typically established to act as a
backplane between the virtual switches residing in hypervisors, physical switches, or middleboxes or other appliances.
An arbitrary IP network can be used as an underlay through Clos networks - A technique for composing network
fabrics larger than a single switch while maintaining non-blocking bandwidth across connection points. ECMP is used
to divide traffic across the multiple links and switches that constitute the fabric. Sometimes termed “leaf and spine” or
“fat tree” topologies.
Geneve Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| Opt Len |O|C| Rsvd. | Protocol Type |
(continues on next page)
Configuration
set interfaces geneve gnv0 description 'This is an awesome interface running on VyOS
˓→'
As Internet wide PMTU discovery rarely works, we sometimes need to clamp our TCP MSS value to a specific
value. This is a field in the TCP options part of a SYN packet. By setting the MSS value, you are telling the
remote side unequivocally ‘do not try to send me packets bigger than this value’.
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces geneve <interface> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
Define behavior for gratuitous ARP frames whose IP is not already present in the ARP table. If configured
create new entries in the ARP table.
Both replies and requests type gratuitous arp will trigger the ARP table to be updated, if this setting is on.
If the ARP table already contains the IP address of the gratuitous arp frame, the arp table will be updated
regardless if this setting is on or off.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
As Internet wide PMTU discovery rarely works, we sometimes need to clamp our TCP MSS value to a specific
value. This is a field in the TCP options part of a SYN packet. By setting the MSS value, you are telling the
remote side unequivocally ‘do not try to send me packets bigger than this value’.
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces geneve <interface> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
GENEVE options
8.4.6 L2TPv3
Layer 2 Tunnelling Protocol Version 3 is an IETF standard related to L2TP that can be used as an alternative protocol
to MPLS for encapsulation of multiprotocol Layer 2 communications traffic over IP networks. Like L2TP, L2TPv3
provides a pseudo-wire service but is scaled to fit carrier requirements.
L2TPv3 can be regarded as being to MPLS what IP is to ATM: a simplified version of the same concept, with much
of the same benefit achieved at a fraction of the effort, at the cost of losing some technical features considered less
important in the market.
In the case of L2TPv3, the features lost are teletraffic engineering features considered important in MPLS. However,
there is no reason these features could not be re-engineered in or on top of L2TPv3 in later products.
The protocol overhead of L2TPv3 is also significantly bigger than MPLS.
L2TPv3 is described in RFC 3931.
Configuration
set interfaces l2tpv3 l2tpeth0 description 'This is an awesome interface running on␣
˓→VyOS'
Use this command to disable the generation of Ethernet flow control (pause frames).
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces l2tpv3 <interface> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
If set the kernel can respond to arp requests with addresses from other interfaces. This may seem wrong but
it usually makes sense, because it increases the chance of successful communication. IP addresses are owned
by the complete host on Linux, not by particular interfaces. Only for more complex setups like load-balancing,
does this behaviour cause problems.
If not set (default) allows you to have multiple network interfaces on the same subnet, and have the ARPs for
each interface be answered based on whether or not the kernel would route a packet from the ARP’d IP out that
interface (therefore you must use source based routing for this to work).
In other words it allows control of which cards (usually 1) will respond to an arp request.
Example:
Define different modes for sending replies in response to received ARP requests that resolve local target IP
addresses:
If configured, reply only if the target IP address is local address configured on the incoming interface.
If this option is unset (default), reply for any local target IP address, configured on any interface.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces l2tpv3 <interface> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
L2TPv3 options
Example
Over IP
Over UDP
This is the LAN extension use case. The eth0 port of the distant VPN peers will be directly connected like if there was
a switch between them.
IPSec:
Bridge:
L2TPv3:
8.4.7 Loopback
The loopback networking interface is a virtual network device implemented entirely in software. All traffic sent to it
“loops back” and just targets services on your local machine.
Note: There can only be one loopback lo interface on the system. If you need multiple interfaces, please use the
Dummy interface type.
Hint: A loopback interface is always up, thus it could be used for management traffic or as source/destination for
and IGP (Interior Gateway Protocol) like BGP so your internal BGP link is not dependent on physical link states and
multiple routes can be chosen to the destination. A Dummy Interface should always be preferred over a Loopback
interface.
Configuration
Operation
8.4.8 MACsec
MACsec is an IEEE standard (IEEE 802.1AE) for MAC security, introduced in 2006. It defines a way to establish a
protocol independent connection between two hosts with data confidentiality, authenticity and/or integrity, using GCM-
AES-128. MACsec operates on the Ethernet layer and as such is a layer 2 protocol, which means it’s designed to secure
traffic within a layer 2 network, including DHCP or ARP requests. It does not compete with other security solutions
such as IPsec (layer 3) or TLS (layer 4), as all those solutions are used for their own specific use cases.
Configuration
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
set interfaces macsec macsec0 description 'This is an awesome interface running on␣
˓→VyOS'
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces macsec <interface> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
If the ARP table already contains the IP address of the gratuitous arp frame, the arp table will be updated
regardless if this setting is on or off.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces macsec <interface> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
DHCP(v6)
set interfaces macsec <interface> dhcp-options client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
When no-release is specified, dhcp6c will send a release message on client exit to prevent losing an assigned
address or prefix.
Specify the identifier value of the site-level aggregator (SLA) on the interface. ID must be a decimal number
greater then 0 which fits in the length of SLA IDs (see below).
Example: If ID is 1 and the client is delegated an IPv6 prefix 2001:db8:ffff::/48, dhcp6c will combine the two
values into a single IPv6 prefix, 2001:db8:ffff:1::/64, and will configure the prefix on the specified interface.
MACsec options
Static Keys
Static SAK (Secure Authentication Key) mode can be configured manually on each device wishing to use MACsec.
Keys must be set statically on all devices for traffic to flow properly. Key rotation is dependent on the administrator
updating all keys manually across connected devices. Static SAK mode can not be used with MKA.
set interfaces macsec <interface> security static key <key>
Set the device’s transmit (TX) key. This key must be a hex string that is 16-bytes (GCM-AES-128) or 32-bytes
(GCM-AES-256).
set interfaces macsec <interface> security static peer <peer> mac <mac address>
Set the peer’s MAC address
set interfaces macsec <interface> security static peer <peer> key <key>
Set the peer’s key used to receive (RX) traffic
set interfaces macsec <interface> security static peer <peer> disable
Disable the peer configuration
Key Management
MKA (MACsec Key Agreement protocol) is used to synchronize keys between individual peers.
set interfaces macsec <interface> security mka cak <key>
IEEE 802.1X/MACsec pre-shared key mode. This allows configuring MACsec with a pre-shared key using a
CAK (MACsec connectivity association key) and CKN (MACsec connectivity association name) pair.
set interfaces macsec <interface> security mka ckn <key>
CKN key
Replay protection
Operation
Examples
R2
Pinging (IPv6) the other host and intercepting the traffic in eth1 will show you the content is encrypted.
0x0000: 2c00 0000 000a 0050 56bf efaa 0001 d9fb ,......PV.......
0x0010: 920a 8b8d 68ed 9609 29dd e767 25a4 4466 ....h...)..g%.Df
0x0020: 5293 487b 9990 8517 3b15 22c7 ea5c ac83 R.H{....;."..\..
0x0030: 4c6e 13cf 0743 f917 2c4e 694e 87d1 0f09 Ln...C..,NiN....
0x0040: 0f77 5d53 ed75 cfe1 54df 0e5a c766 93cb .w]S.u..T..Z.f..
0x0050: c4f2 6e23 f200 6dfe 3216 c858 dcaa a73b ..n#..m.2..X...;
0x0060: 4dd1 9358 d9e4 ed0e 072f 1acc 31c4 f669 M..X...../..1..i
0x0070: e93a 9f38 8a62 17c6 2857 6ac5 ec11 8b0e .:.8.b..(Wj.....
0x0080: 6b30 92a5 7ccc 720b k0..|.r.
Disabling the encryption on the link by removing security encrypt will show the unencrypted but authenticated
content.
0x0000: 2000 0000 0009 0050 56bf efaa 0001 86dd .......PV.......
0x0010: 6009 86f3 0040 3a40 2001 0db8 0000 0000 `....@:@........
0x0020: 0000 0000 0000 0001 2001 0db8 0000 0000 ................
0x0030: 0000 0000 0000 0002 8100 d977 0f30 0003 ...........w.0..
0x0040: 1ca0 c65e 0000 0000 8d93 0b00 0000 0000 ...^............
0x0050: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................
(continues on next page)
R1 Static Key
R2 Static Key
8.4.9 OpenVPN
Traditionally hardware routers implement IPsec exclusively due to relative ease of implementing it in hardware and
insufficient CPU power for doing encryption in software. Since VyOS is a software router, this is less of a concern.
OpenVPN has been widely used on the UNIX platform for a long time and is a popular option for remote access VPN,
though it’s also capable of site-to-site connections.
Advantages of OpenVPN are:
• It uses a single TCP or UDP connection and does not rely on packet source addresses, so it will work even through
a double NAT: perfect for public hotspots and such
• It’s easy to setup and offers very flexible split tunneling
• There’s a variety of client GUI frontends for any platform
Disadvantages are:
• It’s slower than IPsec due to higher protocol overhead and the fact it runs in user mode while IPsec, on Linux, is
in kernel mode
• None of the operating systems have client software installed by default
In the VyOS CLI, a key point often overlooked is that rather than being configured using the set vpn stanza, OpenVPN
is configured as a network interface using set interfaces openvpn.
Site-to-Site
OpenVPN is popular for client-server setups, but its site-to-site mode remains a relatively obscure feature, and many
router appliances still don’t support it. However, it’s very useful for quickly setting up tunnels between routers.
As of VyOS 1.4, OpenVPN site-to-site mode can use either pre-shared keys or x.509 certificates.
The pre-shared key mode is deprecated and will be removed from future OpenVPN versions, so VyOS will have to
remove support for that option as well. The reason is that using pre-shared keys is significantly less secure than using
TLS.
We’ll configure OpenVPN using self-signed certificates, and then discuss the legacy pre-shared key mode.
In both cases, we will use the following settings:
• The public IP address of the local side of the VPN will be 198.51.100.10.
• The public IP address of the remote side of the VPN will be 203.0.113.11.
• The tunnel will use 10.255.1.1 for the local IP and 10.255.1.2 for the remote.
• The local site will have a subnet of 10.0.0.0/16.
• The remote site will have a subnet of 10.1.0.0/16.
• The official port for OpenVPN is 1194, which we reserve for client VPN; we will use 1195 for site-to-site VPN.
• The persistent-tunnel directive will allow us to configure tunnel-related attributes, such as firewall policy
as we would on any normal network interface.
• If known, the IP of the remote router can be configured using the remote-host directive; if unknown, it can be
omitted. We will assume a dynamic IP for our remote router.
Setting up certificates
Setting up a full-blown PKI with a CA certificate would arguably defeat the purpose of site-to-site OpenVPN, since its
main goal is supposed to be configuration simplicity, compared to server setups that need to support multiple clients.
However, since VyOS 1.4, it is possible to verify self-signed certificates using certificate fingerprints.
On both sides, you need to generate a self-signed certificate, preferrably using the “ec” (elliptic curve) type. You can
generate them by executing command run generate pki certificate self-signed install <name> in the
configuration mode. Once the command is complete, it will add the certificate to the configuration session, to the pki
subtree. You can then review the proposed changes and commit them.
vyos@vyos# compare
[pki]
+ certificate openvpn-local {
+ certificate "MIICJTCCAcugAwIBAgIUMXLfRNJ5iOjk/ ␣
˓→uAZqUe4phW8MdgwCgYIKoZIzj0EAwIwVzELMAkGA1UEBhMCR0IxEzARBgNVBAgMClNvbWUtU3RhdGUxEjAQBgNVBAcMCVNvbWUtQ2l
˓→lw9Eq9Q89r247AJR6ec/GT26AIcVA1bsongV1YaWvRwzTPC/yi5pkzV/PcT/
˓→WU7JQIyMWo3UwczAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/
˓→wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDATAdBgNVHQ4EFgQUBrAxRdFppdG/
˓→UBRdo7qNyHutaTQwHwYDVR0jBBgwFoAUBrAxRdFppdG/
˓→UBRdo7qNyHutaTQwCgYIKoZIzj0EAwIDSAAwRQIhAI2+8C92z9wTcTWkQ/
˓→goRxs10EBC+h78O+vgo9k97z5iAiBSeqfaVr5taQTS31+McGTAK3cYWNTg0DlOBI8aKO2oRg=="
+ private {
+ key "MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgtOeEb0dMb5P/
˓→2Exi09WWvk6Cvz0oOBoDuP68ZimS2LShRANCAASp7D0vE3SKSAWAzr/lw9Eq9Q89r247AJR6ec/
˓→GT26AIcVA1bsongV1YaWvRwzTPC/yi5pkzV/PcT/WU7JQIyMW"
+ }
+ }
[edit]
vyos@vyos# commit
You do not need to copy the certificate to the other router. Instead, you need to retrieve its SHA-256 fingerprint.
OpenVPN only supports SHA-256 fingerprints at the moment, so you need to use the following command:
Note: certificate names don’t matter, we use ‘openvpn-local’ and ‘openvpn-remote’ but they can be arbitrary.
Repeat the procedure on the other router.
Setting up OpenVPN
Local Configuration:
set interfaces openvpn vtun1 tls peer-fingerprint <remote cert fingerprint> # The␣
˓→output of 'run show pki certificate <name> fingerprint sha256
on the␣
˓→remote rout
Remote Configuration:
set interfaces openvpn vtun1 tls peer-fingerprint <local cert fingerprint> # The␣
˓→output of 'run show pki certificate <name> fingerprint sha256
on the␣
˓→local router
Pre-shared keys
Until VyOS 1.4, the only option for site-to-site OpenVPN without PKI was to use pre-shared keys. That option is still
available but it is deprecated and will be removed in the future. However, if you need to set up a tunnel to an older
VyOS version or a system with older OpenVPN, you need to still need to know how to use it.
First, you need to generate a key by running run generate pki openvpn shared-secret install <name> from
configuration mode. You can use any name, we will use s2s.
˓→"
+ version "1"
+ }
[edit]
vyos@local# commit
[edit]
vyos@remote# set pki openvpn shared-secret s2s key <generated key string>
Then you need to set the key in your OpenVPN interface settings:
Firewall Exceptions
For the OpenVPN traffic to pass through the WAN interface, you must create a firewall exception.
You should also ensure that the OUTISDE_LOCAL firewall group is applied to the WAN interface and a direction
(local).
Static Routing:
Static routes can be configured referencing the tunnel interface; for example, the local router will use a network of
10.0.0.0/16, while the remote has a network of 10.1.0.0/16:
Local Configuration:
Remote Configuration:
The configurations above will default to using 256-bit AES in GCM mode for encryption (if both sides support NCP)
and SHA-1 for HMAC authentication. SHA-1 is considered weak, but other hashing algorithms are available, as are
encryption algorithms:
For Encryption:
This sets the cipher when NCP (Negotiable Crypto Parameters) is disabled or OpenVPN version < 2.4.0.
This sets the accepted ciphers to use when version => 2.4.0 and NCP is enabled (which is the default). Default NCP
cipher for versions >= 2.4.0 is aes256gcm. The first cipher in this list is what server pushes to clients.
For Hashing:
If you change the default encryption and hashing algorithms, be sure that the local and remote ends have matching
configurations, otherwise the tunnel will not come up.
Firewall policy can also be applied to the tunnel interface for local, in, and out directions and functions identically to
ethernet interfaces.
If you’re making use of multiple tunnels, OpenVPN must have a way to distinguish between different tunnels aside
from the pre-shared-key. This is done either by referencing IP addresses or port numbers. One option is to dedicate a
public IP to each tunnel. Another option is to dedicate a port number to each tunnel (e.g. 1195,1196,1197. . . ).
OpenVPN status can be verified using the show openvpn operational commands. See the built-in help for a complete
list of options.
Server
Multi-client server is the most popular OpenVPN mode on routers. It always uses x.509 authentication and therefore
requires a PKI setup. Refer this topic PKI to generate a CA certificate, a server certificate and key, a certificate revoca-
tion list, and a Diffie-Hellman key exchange parameters file. You do not need client certificates and keys for the server
setup.
In this example we will use the most complicated case: a setup where each client is a router that has its own subnet
(think HQ and branch offices), since simpler setups are subsets of it.
Suppose you want to use 10.23.1.0/24 network for client tunnel endpoints and all client subnets belong to 10.23.0.0/20.
All clients need access to the 192.168.0.0/16 network.
First we need to specify the basic settings. 1194/UDP is the default. The persistent-tunnel option is recommended,
as it prevents the TUN/TAP device from closing on connection resets or daemon reloads.
Note: Using openvpn-option -reneg-sec can be tricky. This option is used to renegotiate data channel after n seconds.
When used on both the server and client, the lower value will trigger the renegotiation. If you set it to 0 on one side of
the connection (to disable it), the chosen value on the other side will determine when the renegotiation will occur.
Then we need to generate, add and specify the names of the cryptographic materials. Each of the install commands
should be applied to the configuration and commited before using under the openvpn interface configuration.
run generate pki certificate sign ca-1 install srv-1 # Follow the␣
˓→instructions to generate server cert.
Now we need to specify the server network settings. In all cases we need to specify the subnet for client tunnel endpoints.
Since we want clients to access a specific network behind our router, we will use a push-route option for installing that
route on clients.
Since it’s a HQ with branch offices setup, we will want all clients to have fixed addresses and we will route traffic to
specific subnets through them. We need configuration for each client to achieve this.
Note: Clients are identified by the CN field of their x.509 certificates, in this example the CN is client0:
OpenVPN will not automatically create routes in the kernel for client subnets when they connect and will only use
client-subnet association internally, so we need to create a route to the 10.23.0.0/20 network ourselves:
Additionally, each client needs a copy of ca cert and its own client key and cert files. The files are plaintext so they may
be copied manually from the CLI. Client key and cert files should be signed with the proper ca cert and generated on
the server side.
HQ’s router requires the following steps to generate crypto materials for the Branch 1:
run generate pki certificate sign ca-1 install branch-1 # Follow the␣
˓→instructions to generate client
set pki certificate branch-1 private key 'generated_private_key' # Client cert key␣
˓→generated on HQ router
Client Authentication
LDAP
Enterprise installations usually ship a kind of directory service which is used to have a single password store for all
employees. VyOS and OpenVPN support using LDAP/AD as single user backend.
Authentication is done by using the openvpn-auth-ldap.so plugin which is shipped with every VyOS installation.
A dedicated configuration file is required. It is best practise to store it in /config to survive image updates
<LDAP>
# LDAP server URL
URL ldap://ldap.example.com
# Bind DN (If your LDAP server doesn't support anonymous binds)
BindDN cn=LDAPUser,dc=example,dc=com
# Bind Password password
Password S3cr3t
# Network timeout (in seconds)
Timeout 15
</LDAP>
<Authorization>
# Base DN
BaseDN "ou=people,dc=example,dc=com"
# User Search Filter
SearchFilter "(&(uid=%u)(objectClass=shadowAccount))"
# Require Group Membership - allow all users
RequireGroup false
</Authorization>
Active Directory
<LDAP>
# LDAP server URL
URL ldap://dc01.example.com
# Bind DN (If your LDAP server doesn’t support anonymous binds)
BindDN CN=LDAPUser,DC=example,DC=com
# Bind Password
Password mysecretpassword
# Network timeout (in seconds)
(continues on next page)
<Authorization>
# Base DN
BaseDN "DC=example,DC=com"
# User Search Filter, user must be a member of the VPN AD group
SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN,OU=Groups,DC=example,DC=com))"
# Require Group Membership
RequireGroup false # already handled by SearchFilter
<Group>
BaseDN "OU=Groups,DC=example,DC=com"
SearchFilter "(|(cn=VPN))"
MemberAttribute memberOf
</Group>
</Authorization>
If you only want to check if the user account is enabled and can authenticate (against the primary group) the following
snipped is sufficient:
<LDAP>
URL ldap://dc01.example.com
BindDN CN=SA_OPENVPN,OU=ServiceAccounts,DC=example,DC=com
Password ThisIsTopSecret
Timeout 15
TLSEnable no
FollowReferrals no
</LDAP>
<Authorization>
BaseDN "DC=example,DC=com"
SearchFilter "sAMAccountName=%u"
RequireGroup false
</Authorization>
A complete LDAP auth OpenVPN configuration could look like the following example:
Client
VyOS can not only act as an OpenVPN site-to-site or server for multiple clients but you can also configure any VyOS
OpenVPN interface as an OpenVPN client that connects to a VyOS OpenVPN server or any other OpenVPN server.
Given the following example we have one VyOS router acting as an OpenVPN server and another VyOS router acting
as an OpenVPN client. The server also pushes a static client IP address to the OpenVPN client. Remember, clients are
identified using their CN attribute in the SSL certificate.
Configuration
Server Side
Client Side
Options
We do not have CLI nodes for every single OpenVPN option. If an option is missing, a feature request should be opened
at Phabricator so all users can benefit from it (see Issues/Feature requests).
If you are a hacker or want to try on your own we support passing raw OpenVPN options to OpenVPN.
set interfaces openvpn vtun10 openvpn-option ‘persist-key’
Will add persist-key to the generated OpenVPN configuration. Please use this only as last resort - things might
break and OpenVPN won’t start if you pass invalid options/syntax.
set interfaces openvpn vtun10 openvpn-option ‘push keepalive 10 60’
Will add push "keepalive 1 10" to the generated OpenVPN config file.
set interfaces openvpn vtun10 openvpn-option ‘route-up "/config/auth/tun_up.sh
arg1"’
Will add route-up "/config/auth/tun_up.sh arg1" to the generated OpenVPN config file. The path and argu-
ments need to be single- or double-quoted.
Note: Sometimes option lines in the generated OpenVPN configuration require quotes. This is done through a hack
on our config generator. You can pass quotes using the " statement.
Multi-factor Authentication
VyOS supports multi-factor authentication (MFA) or two-factor authentication using Time-based One-Time Password
(TOTP). Compatible with Google Authenticator software token, other software tokens.
set interfaces openvpn <interface> server mfa totp challenge <enable | disable>
If set to enable, openvpn-otp will expect password as result of challenge/ response protocol.
set interfaces openvpn <interface> server mfa totp digits <1-65535>
Configure number of digits to use for totp hash (default: 6)
set interfaces openvpn <interface> server mfa totp drift <1-65535>
Configure time drift in seconds (default: 0)
set interfaces openvpn <interface> server mfa totp slop <1-65535>
Configure maximum allowed clock slop in seconds (default: 180)
set interfaces openvpn <interface> server mfa totp step <1-65535>
Configure step value for totp in seconds (default: 30)
Example
For every client in the openvpn server configuration a totp secret is created. To display the authentication information,
use the command:
show interfaces openvpn <interface> user <username> mfa <qrcode|secret|uri>
An example:
Use the QR code to add the user account in Google authenticator application and on client side, use the OTP number
as password.
OpenVPN Data Channel Offload (DCO) enables significant performance enhancement in encrypted OpenVPN data
processing. By minimizing context switching for each packet, DCO effectively reduces overhead. This optimization is
achieved by keeping most data handling tasks within the kernel, avoiding frequent switches between kernel and user
space for encryption and packet handling.
As a result, the processing of each packet becomes more efficient, potentially leveraging hardware encryption offloading
support available in the kernel.
Note: OpenVPN DCO is not a fully supported OpenVPN feature, and is currently considered experimental. Further-
more, there are certain OpenVPN features and use cases that remain incompatible with DCO. To get a comprehensive
understanding of the limitations associated with DCO, refer to the list of known limitations in the documentation.
https://community.openvpn.net/openvpn/wiki/DataChannelOffload/Features
DCO support is a per-tunnel option and it is not automatically enabled by default for new or upgraded tunnels. Existing
tunnels will continue to function as they have in the past.
DCO can be enabled for both new and existing tunnels. VyOS adds an option in each tunnel configuration where we can
enable this function. The current best practice is to create a new tunnel with DCO to minimize the chance of problems
with existing clients.
set interfaces openvpn <name> offload dco
Enable OpenVPN Data Channel Offload feature by loading the appropriate kernel module.
Disabled by default - no kernel module loaded.
Troubleshooting
Check status
Reset OpenVPN
8.4.10 WireGuard
WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. See https:
//www.wireguard.com for more information.
This diagram corresponds with the example site to site configuration below.
Keypairs
WireGuard requires the generation of a keypair, which includes a private key to decrypt incoming traffic, and a public
key for peer(s) to encrypt traffic.
Generate Keypair
Note: If this command is invoked from configure mode with the run prefix the key is automatically installed
to the appropriate interface:
vyos@vyos# compare
[edit interfaces]
+wireguard wg10 {
+ private-key CJweb8FC6BU3Loj4PC2pn5V82cDjIPs7G1saW0ZfLWc=
+}
Optional
vyos@vyos:~$ generate pki wireguard preshared-key install interface wg10 peer foo
"generate" CLI command executed from operational level.
Generated preshared-key is not stored to CLI, use configure mode commands to␣
˓→install key:
Note: If this command is invoked from configure mode with the run prefix the key is automatically installed
to the appropriate interface:
Interface configuration
The next step is to configure your local side as well as the policy based trusted destination addresses. If you only initiate
a connection, the listen port and address/port is optional; however, if you act like a server and endpoints initiate the
connections to your system, you need to define a port your clients can connect to, otherwise the port is randomly chosen
and may make connection difficult with firewall rules, since the port may be different each time the system is rebooted.
You will also need the public key of your peer as well as the network(s) you want to tunnel (allowed-ips) to configure
a WireGuard tunnel. The public key below is always the public key from your peer, not your local one.
local side - commands
• WireGuard interface itself uses address 10.1.0.1/30
• We only allow the 192.168.2.0/24 subnet to travel over the tunnel
• Our remote end of the tunnel for peer to-wg02 is reachable at 192.0.2.1 port 51820
• The remote peer to-wg02 uses XMrlPykaxhdAAiSjhtPlvi30NVkvLQliQuKP7AI7CyI= as its public key portion
• We listen on port 51820
• We route all traffic for the 192.168.2.0/24 network to interface wg01
The last step is to define an interface route for 192.168.2.0/24 to get through the WireGuard interface wg01. Multiple
IPs or networks can be defined and routed. The last check is allowed-ips which either prevents or allows the traffic.
Warning: You can not assign the same allowed-ips statement to multiple WireGuard peers. This a design decision.
For more information please check the WireGuard mailing list.
The command show interfaces wireguard wg01 public-key will then show the public key, which needs
to be shared with the peer.
set interfaces wireguard <interface> per-client-thread
Provides a per-device control to enable/disable the threaded mode for all the NAPI instances of the given network
device, without the need for a device up/down.
If CLI option is not specified, this feature is disabled.
Example:
Firewall Exceptions
For the WireGuard traffic to pass through the WAN interface, you must create a firewall exception.
You should also ensure that the OUTSIDE_LOCAL firewall group is applied to the WAN interface and a direction
(local).
Assure that your firewall rules allow the traffic, in which case you have a working VPN using WireGuard.
An additional layer of symmetric-key crypto can be used on top of the asymmetric crypto. This is optional.
Copy the key, as it is not stored on the local filesystem. Because it is a symmetric key, only you and your peer should
have knowledge of its content. Make sure you distribute the key in a safe manner,
With WireGuard, a Road Warrior VPN config is similar to a site-to-site VPN. It just lacks the address and port
statements.
In the following example, the IPs for the remote clients are defined in the peers. This allows the peers to interact with
one another. In comparison to the site-to-site example the persistent-keepalive flag is set to 15 seconds to assure
the connection is kept alive. This is mainly relevant if one of the peers is behind NAT and can’t be connected to if the
connection is lost. To be effective this value needs to be lower than the UDP timeout.
wireguard wg01 {
address 10.172.24.1/24
address 2001:db8:470:22::1/64
description RoadWarrior
peer MacBook {
allowed-ips 10.172.24.30/32
allowed-ips 2001:db8:470:22::30/128
persistent-keepalive 15
pubkey F5MbW7ye7DsoxdOaixjdrudshjjxN5UdNV+pGFHqehc=
}
peer iPhone {
allowed-ips 10.172.24.20/32
allowed-ips 2001:db8:470:22::20/128
persistent-keepalive 15
pubkey BknHcLFo8nOo8Dwq2CjaC/TedchKQ0ebxC7GYn7Al00=
}
port 2224
private-key OLTQY3HuK5qWDgVs6fJR093SwPgOmCKkDI1+vJLGoFU=
}
The following is the config for the iPhone peer above. It’s important to note that the AllowedIPs wildcard setting
directs all IPv4 and IPv6 traffic through the connection.
[Interface]
PrivateKey = ARAKLSDJsadlkfjasdfiowqeruriowqeuasdf=
Address = 10.172.24.20/24, 2001:db8:470:22::20/64
DNS = 10.0.0.53, 10.0.0.54
[Peer]
PublicKey = RIbtUTCfgzNjnLNPQ/ulkGnnB2vMWHm7l2H/xUfbyjc=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 192.0.2.1:2224
PersistentKeepalive = 25
However, split-tunneling can be achieved by specifying the remote subnets. This ensures that only traffic destined for
the remote site is sent over the tunnel. All other traffic is unaffected.
[Interface]
PrivateKey = 8Iasdfweirousd1EVGUk5XsT+wYFZ9mhPnQhmjzaJE6Go=
Address = 10.172.24.30/24, 2001:db8:470:22::30/64
[Peer]
PublicKey = RIbtUTCfgzNjnLNPQ/ulkGnnB2vMWHm7l2H/xUfbyjc=
AllowedIPs = 10.172.24.30/24, 2001:db8:470:22::/64
Endpoint = 192.0.2.1:2224
PersistentKeepalive = 25
Operational Commands
Status
Some users tend to connect their mobile devices using WireGuard to their VyOS router. To ease deployment one can
generate a “per mobile” configuration from the VyOS CLI.
Warning: From a security perspective, it is not recommended to let a third party create and share the private
key for a secured connection. You should create the private portion on your own and only hand out the public key.
Please keep this in mind when using this convenience feature.
8.4.11 PPPoE
PPPoE (Point-to-Point Protocol over Ethernet) is a network protocol for encapsulating PPP frames inside Ethernet
frames. It appeared in 1999, in the context of the boom of DSL as the solution for tunneling packets over the DSL
connection to the ISPs (Internet Service Providers) IP network, and from there to the rest of the Internet. A 2005
networking book noted that “Most DSL providers use PPPoE, which provides authentication, encryption, and com-
pression.” Typical use of PPPoE involves leveraging the PPP facilities for authenticating the user with a username and
password, predominately via the PAP protocol and less often via CHAP.
Operating Modes
VyOS supports setting up PPPoE in two different ways to a PPPoE internet connection. This is because most ISPs
provide a modem that is also a wireless router.
Home Users
In this method, the DSL Modem/Router connects to the ISP for you with your credentials preprogrammed into the
device. This gives you an RFC 1918 address, such as 192.168.1.0/24 by default.
For a simple home network using just the ISP’s equipment, this is usually desirable. But if you want to run VyOS as
your firewall and router, this will result in having a double NAT and firewall setup. This results in a few extra layers of
complexity, particularly if you use some NAT or tunnel features.
Business Users
In order to have full control and make use of multiple static public IP addresses, your VyOS will have to initiate the
PPPoE connection and control it. In order for this method to work, you will have to figure out how to make your DSL
Modem/Router switch into a Bridged Mode so it only acts as a DSL Transceiver device to connect between the Ethernet
link of your VyOS and the phone cable. Once your DSL Transceiver is in Bridge Mode, you should get no IP address
from it. Please make sure you connect to the Ethernet Port 1 if your DSL Transceiver has a switch, as some of them
only work this way.
Once you have an Ethernet device connected, i.e. eth0, then you can configure it to open the PPPoE session for you and
your DSL Transceiver (Modem/Router) just acts to translate your messages in a way that vDSL/aDSL understands.
Configuration
set interfaces pppoe pppoe0 description 'This is an awesome interface running on␣
˓→VyOS'
PPPoE options
Note: This command got added in VyOS 1.4 and inverts the logic from the old default-route CLI option.
Note: When using the IPv6 protocol, MRU must be at least 1280 bytes.
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces pppoe <interface> ip disable-forwarding
Configure interface-specific Host/Router behaviour. If set, the interface will switch to host mode and IPv6
forwarding will be disabled on this interface.
IPv6
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces pppoe <interface> ipv6 disable-forwarding
Configure interface-specific Host/Router behaviour. If set, the interface will switch to host mode and IPv6
forwarding will be disabled on this interface.
DHCPv6 Prefix Delegation (PD)
VyOS 1.3 (equuleus) supports DHCPv6-PD (RFC 3633). DHCPv6 Prefix Delegation is supported by most ISPs who
provide native IPv6 for consumers on fixed networks.
set interfaces pppoe <interface> dhcpv6-options pd <id> length <length>
Some ISPs by default only delegate a /64 prefix. To request for a specific prefix size use this option to request
for a bigger delegation for this pd <id>. This value is in the range from 32 - 64 so you could request up to a /32
prefix (if your ISP allows this) down to a /64 delegation.
The default value corresponds to 64.
To request a /56 prefix from your ISP use:
Specify the interface address used locally on the interface where the prefix has been delegated to. ID must be a
decimal integer.
It will be combined with the delegated prefix and the sla-id to form a complete interface address. The default is
to use the EUI-64 address of the interface.
Example: Delegate a /64 prefix to interface eth8 which will use a local address on this router of
<prefix>::ffff, as the address 65534 will correspond to ffff in hexadecimal notation.
set interfaces pppoe <interface> dhcpv6-options pd <id> interface <delegatee> sla-id <id>
Specify the identifier value of the site-level aggregator (SLA) on the interface. ID must be a decimal number
greater then 0 which fits in the length of SLA IDs (see below).
Example: If ID is 1 and the client is delegated an IPv6 prefix 2001:db8:ffff::/48, dhcp6c will combine the two
values into a single IPv6 prefix, 2001:db8:ffff:1::/64, and will configure the prefix on the specified interface.
Operation
link/ppp
inet 192.0.2.1 peer 192.0.2.255/32 scope global pppoe0
valid_lft forever preferred_lft forever
Connect/Disconnect
Example
Requirements:
• Your ISPs modem is connected to port eth0 of your VyOS box.
• No VLAN tagging required by your ISP.
• You need your PPPoE credentials from your DSL ISP in order to configure this. The usual username is in the
form of [email protected] but may vary depending on ISP.
• The largest MTU size you can use with DSL is 1492 due to PPPoE overhead. If you are switching from a DHCP
based ISP like cable then be aware that things like VPN links may need to have their MTU sizes adjusted to work
within this limit.
• With the name-server option set to none, VyOS will ignore the nameservers your ISP sends you and thus you
can fully rely on the ones you have configured statically.
Note: Syntax has changed from VyOS 1.2 (crux) and it will be automatically migrated during an upgrade.
Note: A default route is automatically installed once the interface is up. To change this behavior use the
no-default-route CLI option.
You should add a firewall to your configuration above as well by assigning it to the pppoe0 itself as shown here:
VLAN Example
Some recent ISPs require you to build the PPPoE connection through a VLAN interface. One of those ISPs is e.g.
Deutsche Telekom in Germany. VyOS can easily create a PPPoE session through an encapsulated VLAN interface.
The following configuration will run your PPPoE connection through VLAN7 which is the default VLAN for Deutsche
Telekom:
The following configuration will setup a PPPoE session source from eth1 and assign a /64 prefix out of a /56 delegation
(requested from the ISP) to eth0. The IPv6 address assigned to eth0 will be <prefix>::1/64. If you do not know the
prefix size delegated to you, start with sla-len 0.
In addition we setup IPv6 RA (Router Advertisements) to make the prefix known on the eth0 link.
Pseudo-Ethernet or MACVLAN interfaces can be seen as subinterfaces to regular ethernet interfaces. Each and every
subinterface is created a different media access control (MAC) address, for a single physical Ethernet port. Pseudo-
Ethernet interfaces have most of their application in virtualized environments,
By using Pseudo-Ethernet interfaces there will be less system overhead compared to running a traditional bridging
approach. Pseudo-Ethernet interfaces can also be used to workaround the general limit of 4096 virtual LANs (VLANs)
per physical Ethernet port, since that limit is with respect to a single MAC address.
Every Virtual Ethernet interfaces behaves like a real Ethernet interface. They can have IPv4/IPv6 addresses config-
ured, or can request addresses by DHCP/ DHCPv6 and are associated/mapped with a real ethernet port. This also
makes Pseudo-Ethernet interfaces interesting for testing purposes. A Pseudo-Ethernet device will inherit characteris-
tics (speed, duplex, . . . ) from its physical parent (the so called link) interface.
Once created in the system, Pseudo-Ethernet interfaces can be referenced in the exact same way as other Ethernet
interfaces. Notes about using Pseudo- Ethernet interfaces:
• Pseudo-Ethernet interfaces can not be reached from your internal host. This means that you can not try to ping
a Pseudo-Ethernet interface from the host system on which it is defined. The ping will be lost.
• Loopbacks occurs at the IP level the same way as for other interfaces, ethernet frames are not forwarded between
Pseudo-Ethernet interfaces.
• Pseudo-Ethernet interfaces may not work in environments which expect a NIC (Network Interface Card) to only
have a single address. This applies to: - VMware machines using default settings - Network switches with
security settings allowing only a single MAC address - xDSL modems that try to learn the MAC address of the
NIC
Configuration
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces pseudo-ethernet <interface> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
by the complete host on Linux, not by particular interfaces. Only for more complex setups like load-balancing,
does this behaviour cause problems.
If not set (default) allows you to have multiple network interfaces on the same subnet, and have the ARPs for
each interface be answered based on whether or not the kernel would route a packet from the ARP’d IP out that
interface (therefore you must use source based routing for this to work).
In other words it allows control of which cards (usually 1) will respond to an arp request.
Example:
If configured, reply only if the target IP address is local address configured on the incoming interface.
If this option is unset (default), reply for any local target IP address, configured on any interface.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces pseudo-ethernet <interface> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
DHCP(v6)
set interfaces pseudo-ethernet <interface> dhcp-options client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
VLAN
IEEE 802.1q, often referred to as Dot1q, is the networking standard that supports virtual LANs (VLANs) on an IEEE
802.3 Ethernet network. The standard defines a system of VLAN tagging for Ethernet frames and the accompanying
procedures to be used by bridges and switches in handling such frames. The standard also contains provisions for a
quality-of-service prioritization scheme commonly known as IEEE 802.1p and defines the Generic Attribute Registra-
tion Protocol.
Portions of the network which are VLAN-aware (i.e., IEEE 802.1q conformant) can include VLAN tags. When a frame
enters the VLAN-aware portion of the network, a tag is added to represent the VLAN membership. Each frame must
be distinguishable as being within exactly one VLAN. A frame in the VLAN-aware portion of the network that does
not contain a VLAN tag is assumed to be flowing on the native VLAN.
The standard was developed by IEEE 802.1, a working group of the IEEE 802 standards committee, and continues
to be actively revised. One of the notable revisions is 802.1Q-2014 which incorporated IEEE 802.1aq (Shortest Path
Bridging) and much of the IEEE 802.1d standard.
802.1q VLAN interfaces are represented as virtual sub-interfaces in VyOS. The term used for this is vif.
set interfaces pseudo-ethernet <interface> vif <vlan-id>
Create a new VLAN interface on interface <interface> using the VLAN number provided via <vlan-id>.
You can create multiple VLAN interfaces on a physical interface. The VLAN ID range is from 0 to 4094.
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces pseudo-ethernet <interface> vif <vlan-id> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
Enable policy for source validation by reversed path, as specified in RFC 3704. Current recommended practice
in RFC 3704 is to enable strict mode to prevent IP spoofing from DDos attacks. If using asymmetric routing or
other complicated routing, then loose mode is recommended.
• strict: Each incoming packet is tested against the FIB and if the interface is not the best reverse path the
packet check will fail. By default failed packets are discarded.
• loose: Each incoming packet’s source address is also tested against the FIB and if the source address is not
reachable via any interface the packet check will fail.
• disable: No source validation
set interfaces pseudo-ethernet <interface> vif <vlan-id> ipv6 address autoconf
SLAAC RFC 4862. IPv6 hosts can configure themselves automatically when connected to an IPv6 network us-
ing the Neighbor Discovery Protocol via ICMPv6 router discovery messages. When first connected to a network,
a host sends a link-local router solicitation multicast request for its configuration parameters; routers respond to
such a request with a router advertisement packet that contains Internet Layer configuration parameters.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
set interfaces pseudo-ethernet <interface> vif <vlan-id> ipv6 address eui64 <prefix>
EUI-64 as specified in RFC 4291 allows a host to assign iteslf a unique 64-Bit IPv6 address.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces pseudo-ethernet <interface> vif <vlan-id> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
DHCP(v6)
set interfaces pseudo-ethernet <interface> vif <vlan-id> dhcp-options client-id
<description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
Instead of sending the real system hostname to the DHCP server, overwrite the host-name with this given-value.
Example:
type. The server compares the DUID with its database and delivers configuration data (address, lease times,
DNS servers, etc.) to the client.
Example: Delegate a /64 prefix to interface eth8 which will use a local address on this router of
<prefix>::ffff, as the address 65534 will correspond to ffff in hexadecimal notation.
SSTP (Secure Socket Tunneling Protocol) is a form of VTP (Virtual Private Network) tunnel that provides a mechanism
to transport PPP traffic through an SSL/TLS channel. SSL/TLS provides transport-level security with key negotiation,
encryption and traffic integrity checking. The use of SSL/TLS over TCP port 443 (by default, port can be changed)
allows SSTP to pass through virtually all firewalls and proxy servers except for authenticated web proxies.
Note: VyOS also comes with a build in SSTP server, see SSTP Server.
Configuration
set interfaces sstpc sstpc0 description 'This is an awesome interface running on␣
˓→VyOS'
Note: This command got added in VyOS 1.4 and inverts the logic from the old default-route CLI option.
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
Operation
link/ppp
inet 192.0.2.5 peer 192.0.2.254/32 scope global sstpc10
valid_lft forever preferred_lft forever
inet6 fe80::fd53:c7ff:fe8b:144f/64 scope link
valid_lft forever preferred_lft forever
Connect/Disconnect
8.4.14 Tunnel
set interfaces tunnel tun0 description 'This is an awesome interface running on VyOS
˓→'
Use this command to direct an interface to not detect any physical state changes on a link, for example, when
the cable is unplugged.
Default is to detects physical link state changes.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces tunnel <interface> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
Configure interface-specific Host/Router behaviour. If set, the interface will switch to host mode and IPv6
forwarding will be disabled on this interface.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces tunnel <interface> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
IPIP
This is one of the simplest types of tunnels, as defined by RFC 2003. It takes an IPv4 packet and sends it as a payload
of another IPv4 packet. For this reason, there are no other configuration options for this kind of tunnel.
An example:
IP6IP6
This is the IPv6 counterpart of IPIP. I’m not aware of an RFC that defines this encapsulation specifically, but it’s a
natural specific case of IPv6 encapsulation mechanisms described in :rfc:2473`.
It’s not likely that anyone will need it any time soon, but it does exist.
An example:
IPIP6
In the future this is expected to be a very useful protocol (though there are other proposals).
As the name implies, it’s IPv4 encapsulated in IPv6, as simple as that.
An example:
6in4 (SIT)
6in4 uses tunneling to encapsulate IPv6 traffic over IPv4 links as defined in RFC 4213. The 6in4 traffic is sent over
IPv4 inside IPv4 packets whose IP headers have the IP protocol number set to 41. This protocol number is specifically
designated for IPv6 encapsulation, the IPv4 packet header is immediately followed by the IPv6 packet being carried.
The encapsulation overhead is the size of the IPv4 header of 20 bytes, therefore with an MTU of 1500 bytes, IPv6
packets of 1480 bytes can be sent without fragmentation. This tunneling technique is frequently used by IPv6 tunnel
brokers like Hurricane Electric.
An example:
A GRE tunnel operates at layer 3 of the OSI model and is represented by IP protocol 47. The main benefit of a GRE
tunnel is that you are able to carry multiple protocols inside the same tunnel. GRE also supports multicast traffic and
supports routing protocols that leverage multicast to form neighbor adjacencies.
A VyOS GRE tunnel can carry both IPv4 and IPv6 traffic and can also be created over either IPv4 (gre) or IPv6 (ip6gre).
Configuration
A basic configuration requires a tunnel source (source-address), a tunnel destination (remote), an encapsulation type
(gre), and an address (ipv4/ipv6). Below is a basic IPv4 only configuration example taken from a VyOS router and a
Cisco IOS router. The main difference between these two configurations is that VyOS requires you explicitly configure
the encapsulation type. The Cisco router defaults to GRE IP otherwise it would have to be configured as well.
VyOS Router:
interface Tunnel100
ip address 10.0.0.2 255.255.255.252
tunnel source 203.0.113.10
tunnel destination 198.51.100.2
Here is a second example of a dual-stack tunnel over IPv6 between a VyOS router and a Linux host using systemd-
networkd.
VyOS Router:
Linux systemd-networkd:
This requires two files, one to create the device (XXX.netdev) and one to configure the network on the device
(XXX.network)
# cat /etc/systemd/network/gre-example.netdev
[NetDev]
Name=gre-example
Kind=ip6gre
MTUBytes=14180
[Tunnel]
Remote=2001:db8:babe:face::3afe:3
# cat /etc/systemd/network/gre-example.network
[Match]
Name=gre-example
[Network]
Address=2001:db8:feed:beef::2/126
[Address]
Address=192.168.5.2/30
Tunnel keys
GRE is also the only classic protocol that allows creating multiple tunnels with the same source and destination due to
its support for tunnel keys. Despite its name, this feature has nothing to do with security: it’s simply an identifier that
allows routers to tell one tunnel from another.
An example:
GRETAP
While normal GRE is for layer 3, GRETAP is for layer 2. GRETAP can encapsulate Ethernet frames, thus it can be
bridged with other interfaces to create datalink layer segments that span multiple remote sites.
Troubleshooting
GRE is a well defined standard that is common in most networks. While not inherently difficult to configure there
are a couple of things to keep in mind to make sure the configuration performs as expected. A common cause for
GRE tunnels to fail to come up correctly include ACL or Firewall configurations that are discarding IP protocol 47 or
blocking your source/destination traffic.
1. Confirm IP connectivity between tunnel source-address and remote:
Note: There is also a GRE over IPv6 encapsulation available, it is called: ip6gre.
The veth devices are virtual Ethernet devices. They can act as tunnels between network namespaces to create a bridge
to a physical network device in another namespace or VRF, but can also be used as standalone network devices.
Note: veth interfaces need to be created in pairs - it’s called the peer name
Configuration
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
VLAN
IEEE 802.1q, often referred to as Dot1q, is the networking standard that supports virtual LANs (VLANs) on an IEEE
802.3 Ethernet network. The standard defines a system of VLAN tagging for Ethernet frames and the accompanying
procedures to be used by bridges and switches in handling such frames. The standard also contains provisions for a
quality-of-service prioritization scheme commonly known as IEEE 802.1p and defines the Generic Attribute Registra-
tion Protocol.
Portions of the network which are VLAN-aware (i.e., IEEE 802.1q conformant) can include VLAN tags. When a frame
enters the VLAN-aware portion of the network, a tag is added to represent the VLAN membership. Each frame must
be distinguishable as being within exactly one VLAN. A frame in the VLAN-aware portion of the network that does
not contain a VLAN tag is assumed to be flowing on the native VLAN.
The standard was developed by IEEE 802.1, a working group of the IEEE 802 standards committee, and continues
to be actively revised. One of the notable revisions is 802.1Q-2014 which incorporated IEEE 802.1aq (Shortest Path
Bridging) and much of the IEEE 802.1d standard.
802.1q VLAN interfaces are represented as virtual sub-interfaces in VyOS. The term used for this is vif.
set interfaces virtual-ethernet <interface> vif <vlan-id>
Create a new VLAN interface on interface <interface> using the VLAN number provided via <vlan-id>.
You can create multiple VLAN interfaces on a physical interface. The VLAN ID range is from 0 to 4094.
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
Set a human readable, descriptive alias for this connection. Alias is used by e.g. the show interfaces com-
mand or SNMP based monitoring tools.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces virtual-ethernet <interface> vif <vlan-id> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
If configured, try to avoid local addresses that are not in the target’s subnet for this interface. This mode is
useful when target hosts reachable via this interface require the source IP address in ARP requests to be part of
their logical network configured on the receiving interface. When we generate the request we will check all our
subnets that include the target IP and will preserve the source address if it is from such subnet. If there is no
such subnet we select source address according to the rules for level 2.
• loose: Each incoming packet’s source address is also tested against the FIB and if the source address is not
reachable via any interface the packet check will fail.
• disable: No source validation
set interfaces virtual-ethernet <interface> vif <vlan-id> ipv6 address autoconf
SLAAC RFC 4862. IPv6 hosts can configure themselves automatically when connected to an IPv6 network us-
ing the Neighbor Discovery Protocol via ICMPv6 router discovery messages. When first connected to a network,
a host sends a link-local router solicitation multicast request for its configuration parameters; routers respond to
such a request with a router advertisement packet that contains Internet Layer configuration parameters.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
set interfaces virtual-ethernet <interface> vif <vlan-id> ipv6 address eui64 <prefix>
EUI-64 as specified in RFC 4291 allows a host to assign iteslf a unique 64-Bit IPv6 address.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces virtual-ethernet <interface> vif <vlan-id> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
DHCP(v6)
set interfaces virtual-ethernet <interface> vif <vlan-id> dhcp-options client-id
<description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
This option is used by some DHCP clients to identify the vendor type and possibly the configuration of a DHCP
client. The information is a string of bytes whose contents are specific to the vendor and are not specified in a
standard.
The vendor-class-id option can be used to request a specific class of vendor options from the server.
Example:
When no-release is specified, dhcp6c will send a release message on client exit to prevent losing an assigned
address or prefix.
QinQ (802.1ad)
IEEE 802.1ad was an Ethernet networking standard informally known as QinQ as an amendment to IEEE standard
802.1q VLAN interfaces as described above. 802.1ad was incorporated into the base 802.1q standard in 2011. The
technique is also known as provider bridging, Stacked VLANs, or simply QinQ or Q-in-Q. “Q-in-Q” can for supported
devices apply to C-tag stacking on C-tag (Ethernet Type = 0x8100).
The original 802.1q specification allows a single Virtual Local Area Network (VLAN) header to be inserted into an
Ethernet frame. QinQ allows multiple VLAN tags to be inserted into a single frame, an essential capability for im-
plementing Metro Ethernet network topologies. Just as QinQ extends 802.1Q, QinQ itself is extended by other Metro
Ethernet protocols.
In a multiple VLAN header context, out of convenience the term “VLAN tag” or just “tag” for short is often used in
place of “802.1q VLAN header”. QinQ allows multiple VLAN tags in an Ethernet frame; together these tags constitute
a tag stack. When used in the context of an Ethernet frame, a QinQ frame is a frame that has 2 VLAN 802.1q headers
(double-tagged).
In VyOS the terms vif-s and vif-c stand for the ethertype tags that are used.
The inner tag is the tag which is closest to the payload portion of the frame. It is officially called C-TAG (customer tag,
with ethertype 0x8100). The outer tag is the one closer/closest to the Ethernet header, its name is S-TAG (service tag
with Ethernet Type = 0x88a8).
set interfaces virtual-ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> address
<address | dhcp | dhcpv6>
Configure interface <interface> with one or more interface addresses.
• address can be specified multiple times as IPv4 and/or IPv6 address, e.g. 192.0.2.1/24 and/or
2001:db8::1/64
• dhcp interface address is received by DHCP from a DHCP server on this segment.
• dhcpv6 interface address is received by DHCPv6 from a DHCPv6 server on this segment.
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
set interfaces virtual-ethernet veth0 vif-s 1000 vif-c 20 description 'This is an␣
˓→awesome interface running on VyOS'
set interfaces virtual-ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> mtu <mtu>
Configure MTU on given <interface>. It is the size (in bytes) of the largest ethernet frame sent on this link.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces virtual-ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> ip
arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
This is done to support (ethernet) switch features, like RFC 3069, where the individual ports are NOT allowed
to communicate with each other, but they are allowed to talk to the upstream router. As described in RFC 3069,
it is possible to allow these hosts to communicate through the upstream router by proxy_arp’ing.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
set interfaces virtual-ethernet veth0 vif-s 1000 vif-c 20 ipv6 address autoconf
set interfaces virtual-ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> ipv6 address
eui64 <prefix>
EUI-64 as specified in RFC 4291 allows a host to assign iteslf a unique 64-Bit IPv6 address.
Example:
set interfaces virtual-ethernet veth0 vif-s 1000 vif-c 20 ipv6 address eui64␣
˓→2001:db8:beef::/64
set interfaces virtual-ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> ipv6 address
no-default-link-local
set interfaces virtual-ethernet veth0 vif-s 1000 vif-c 20 ipv6 address no-default-
˓→link-local
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces virtual-ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> ipv6
accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
set interfaces virtual-ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> vrf <vrf>
DHCP(v6)
set interfaces virtual-ethernet <interface> vif-s <vlan-id> vif-c <vlan-id> dhcp-options
client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
Set the distance for the default gateway sent by the DHCP server.
Example:
set interfaces virtual-ethernet veth0 vif-s 1000 vif-c 20 dhcp-options reject 192.
˓→168.100.0/24
Example: If ID is 1 and the client is delegated an IPv6 prefix 2001:db8:ffff::/48, dhcp6c will combine the two
values into a single IPv6 prefix, 2001:db8:ffff:1::/64, and will configure the prefix on the specified interface.
Operation
Example
Interconnect the global VRF with vrf “red” using the veth10 <-> veth 11 pair
Results in:
Warning: When using site-to-site IPsec with VTI interfaces, be sure to disable route autoinstall
More details about the IPsec and VTI issue and option disable-route-autoinstall https://blog.vyos.io/
vyos-1-dot-2-0-development-news-in-july
The root cause of the problem is that for VTI tunnels to work, their traffic selectors have to be set to 0.0.0.0/0 for traffic
to match the tunnel, even though actual routing decision is made according to netfilter marks. Unless route insertion is
disabled entirely, StrongSWAN thus mistakenly inserts a default route through the VTI peer address, which makes all
traffic routed to nowhere.
8.4.17 VXLAN
VXLAN is a network virtualization technology that attempts to address the scalability problems associated with large
cloud computing deployments. It uses a VLAN-like encapsulation technique to encapsulate OSI layer 2 Ethernet frames
within layer 4 UDP datagrams, using 4789 as the default IANA-assigned destination UDP port number. VXLAN
endpoints, which terminate VXLAN tunnels and may be either virtual or physical switch ports, are known as VTEPs
(VXLAN tunnel endpoints).
VXLAN is an evolution of efforts to standardize an overlay encapsulation protocol. It increases the scalability up to
16 million logical networks and allows for layer 2 adjacency across IP networks. Multicast or unicast with head-end
replication (HER) is used to flood broadcast, unknown unicast, and multicast (BUM) traffic.
The VXLAN specification was originally created by VMware, Arista Networks and Cisco. Other backers of the
VXLAN technology include Huawei, Broadcom, Citrix, Pica8, Big Switch Networks, Cumulus Networks, Dell EMC,
Ericsson, Mellanox, FreeBSD, OpenBSD, Red Hat, Joyent, and Juniper Networks.
VXLAN was officially documented by the IETF in RFC 7348.
If configuring VXLAN in a VyOS virtual machine, ensure that MAC spoofing (Hyper-V) or Forged Transmits (ESX)
are permitted, otherwise forwarded frames may be blocked by the hypervisor.
Note: As VyOS is based on Linux and there was no official IANA port assigned for VXLAN, VyOS uses a default
port of 8472. You can change the port on a per VXLAN interface basis to get it working across multiple vendors.
Configuration
set interfaces vxlan vxlan0 description 'This is an awesome interface running on␣
˓→VyOS'
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
If configured, try to avoid local addresses that are not in the target’s subnet for this interface. This mode is
useful when target hosts reachable via this interface require the source IP address in ARP requests to be part of
their logical network configured on the receiving interface. When we generate the request we will check all our
subnets that include the target IP and will preserve the source address if it is from such subnet. If there is no
such subnet we select source address according to the rules for level 2.
• loose: Each incoming packet’s source address is also tested against the FIB and if the source address is not
reachable via any interface the packet check will fail.
• disable: No source validation
set interfaces vxlan <interface> ipv6 address autoconf
SLAAC RFC 4862. IPv6 hosts can configure themselves automatically when connected to an IPv6 network us-
ing the Neighbor Discovery Protocol via ICMPv6 router discovery messages. When first connected to a network,
a host sends a link-local router solicitation multicast request for its configuration parameters; routers respond to
such a request with a router advertisement packet that contains Internet Layer configuration parameters.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces vxlan <interface> ipv6 accept-dad <1-3>
Note: As VyOS is Linux based the default port used is not using 4789 as the default IANA-assigned destination
UDP port number. Instead VyOS uses the Linux default port of 8472.
In order to minimize the flooding of ARP and ND messages in the VXLAN network, EVPN includes provisions
RFC 7432#section-10 that allow participating VTEPs to suppress such messages in case they know the MAC-IP
binding and can reply on behalf of the remote host.
set interfaces vxlan <interface> parameters nolearning
Specifies if unknown source link layer addresses and IP addresses are entered into the VXLAN device forwarding
database.
set interfaces vxlan <interface> parameters vni-filter
Specifies whether the VXLAN device is capable of vni filtering.
Only works with a VXLAN device with external flag set.
Note: The device can only receive packets with VNIs configured in the VNI filtering table.
Unicast
Multicast
Multicast VXLAN
For optimal scalability, Multicast shouldn’t be used at all, but instead use BGP to signal all connected devices between
leaves. Unfortunately, VyOS does not yet support this.
FRR supports a new way of configuring VLAN-to-VNI mappings for EVPN-VXLAN, when working with the Linux
kernel. In this new way, the mapping of a VLAN to a VNI is configured against a container VXLAN interface which
is referred to as a SVD (Single VXLAN device).
Multiple VLAN to VNI mappings can be configured against the same SVD. This allows for a significant scaling of the
number of VNIs since a separate VXLAN interface is no longer required for each VNI.
set interfaces vxlan <interface> vlan-to-vni <vlan> vni <vni>
Maps the VNI to the specified VLAN id. The VLAN can then be consumed by a bridge.
Sample configuration of SVD with VLAN to VNI mappings is shown below.
Example
Spine1:
fa0/2 towards Leaf2, IP-address: 10.1.2.1/24
fa0/3 towards Leaf3, IP-address: 10.1.3.1/24
Leaf2:
Eth0 towards Spine1, IP-address: 10.1.2.2/24
Eth1 towards a vlan-aware switch
Leaf3:
Eth0 towards Spine1, IP-address 10.1.3.3/24
Eth1 towards a vlan-aware switch
Spine1 Configuration:
conf t
ip multicast-routing
!
interface fastethernet0/2
ip address 10.1.2.1 255.255.255.0
(continues on next page)
Multicast-routing is required for the leaves to forward traffic between each other in a more scalable way. This also
requires PIM to be enabled towards the leaves so that the Spine can learn what multicast groups each Leaf expects
traffic from.
Leaf2 configuration:
Leaf3 configuration:
As you can see, the Leaf2 and Leaf3 configurations are almost identical. There are lots of commands above, I’ll try to
go into more detail below. Command descriptions are placed under the command boxes:
This commands creates a bridge that is used to bind traffic on eth1 vlan 241 with the vxlan241-interface. The IP address
is not required. It may however be used as a default gateway for each Leaf which allows devices on the vlan to reach
other subnets. This requires that the subnets are redistributed by OSPF so that the Spine will learn how to reach it.
To do this you need to change the OSPF network from ‘10.0.0.0/8’ to ‘0.0.0.0/0’ to allow 172.16/12-networks to be
advertised.
Binds eth1.241 and vxlan241 to each other by making them both member interfaces of the same bridge.
The multicast-group used by all leaves for this vlan extension. Has to be the same on all leaves that has this interface.
Sets the interface to listen for multicast packets on. Could be a loopback, not yet tested.
Sets the unique id for this vxlan-interface. Not sure how it correlates with multicast-address.
The destination port used for creating a VXLAN interface in Linux defaults to its pre-standard value of 8472 to preserve
backward compatibility. A configuration directive to support a user-specified destination port to override that behavior
is available using the above command.
Unicast VXLAN
Alternatively to multicast, the remote IPv4 address of the VXLAN tunnel can be set directly. Let’s change the Multicast
example from above:
# leaf2
set interface vxlan vxlan241 remote 10.1.3.3
The default port udp is set to 8472. It can be changed with set interface vxlan <vxlanN> port <port>
The WLAN (Wireless LAN) interface provides 802.11 (a/b/g/n/ac) wireless support (commonly referred to as Wi-Fi)
by means of compatible hardware. If your hardware supports it, VyOS supports multiple logical wireless interfaces
per physical device.
There are three modes of operation for a wireless interface:
• WAP (Wireless Access-Point) mode provides network access to connecting stations if the physical hardware
supports acting as a WAP
• Station mode acts as a Wi-Fi client accessing the network through an available WAP
• Monitor mode lets the system passively monitor wireless traffic
If the system detects an unconfigured wireless device, it will be automatically added the configuration tree, specifying
any detected settings (for example, its MAC address) and configured to run in monitor mode.
Configuration
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
Set a human readable, descriptive alias for this connection. Alias is used by e.g. the show interfaces com-
mand or SNMP based monitoring tools.
Example:
set interfaces wireless wlan0 description 'This is an awesome interface running on␣
˓→VyOS'
As Internet wide PMTU discovery rarely works, we sometimes need to clamp our TCP MSS value to a specific
value. This is a field in the TCP options part of a SYN packet. By setting the MSS value, you are telling the
remote side unequivocally ‘do not try to send me packets bigger than this value’.
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces wireless <interface> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
Define behavior for gratuitous ARP frames whose IP is not already present in the ARP table. If configured
create new entries in the ARP table.
Both replies and requests type gratuitous arp will trigger the ARP table to be updated, if this setting is on.
If the ARP table already contains the IP address of the gratuitous arp frame, the arp table will be updated
regardless if this setting is on or off.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
As Internet wide PMTU discovery rarely works, we sometimes need to clamp our TCP MSS value to a specific
value. This is a field in the TCP options part of a SYN packet. By setting the MSS value, you are telling the
remote side unequivocally ‘do not try to send me packets bigger than this value’.
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces wireless <interface> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
DHCP(v6)
set interfaces wireless <interface> dhcp-options client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
Instead of sending the real system hostname to the DHCP server, overwrite the host-name with this given-value.
Example:
Wireless options
Maximum number of stations allowed in station table. New stations will be rejected after the station table is
full. IEEE 802.11 has a limit of 2007 different association IDs, so this number should not be larger than that.
This defaults to 2007.
set interfaces wireless <interface> mgmt-frame-protection
Management Frame Protection (MFP) according to IEEE 802.11w
PPDU
Note: There are limits on which channels can be used with HT40- and HT40+. Following table shows the
channels that may be available for HT40- and HT40+ use per IEEE 802.11n Annex J:
Depending on the location, not all of these channels may be available for use!
Note: 40 MHz channels may switch their primary and secondary channels if needed or creation of 40 MHz
channel maybe rejected based on overlapping BSSes. These changes are done automatically when hostapd is
setting up the 40 MHz channel.
The example creates a wireless station (commonly referred to as Wi-Fi client) that accesses the network through the
WAP defined in the above example. The default physical device (phy0) is used.
Resulting in
system {
wireless {
country-code de
}
}
interfaces {
wireless wlan0 {
address dhcp
security {
wpa {
passphrase "12345678"
}
}
ssid TEST
type station
}
Security
WPA (Wi-Fi Protected Access), WPA2 Enterprise and WPA3 Enterprise in combination with 802.1x based authenti-
cation can be used to authenticate users or computers in a domain.
The wireless client (supplicant) authenticates against the RADIUS server (authentication server) using an EAP method
configured on the RADIUS server. The WAP (also referred to as authenticator) role is to send all authentication
messages between the supplicant and the configured authentication server, thus the RADIUS server is responsible for
authenticating the users.
The WAP in this example has the following characteristics:
• IP address 192.168.2.1/24
• Network ID (SSID) Enterprise-TEST
• WPA passphrase 12345678
• Use 802.11n protocol
• Wireless channel 1
• RADIUS server at 192.168.3.10 with shared-secret VyOSPassword
Resulting in
system {
wireless {
country-code de
}
}
interfaces {
[...]
wireless wlan0 {
address 192.168.2.1/24
channel 1
mode n
security {
wpa {
cipher CCMP
mode wpa2
radius {
server 192.168.3.10 {
key 'VyOSPassword'
port 1812
}
(continues on next page)
VLAN
IEEE 802.1q, often referred to as Dot1q, is the networking standard that supports virtual LANs (VLANs) on an IEEE
802.3 Ethernet network. The standard defines a system of VLAN tagging for Ethernet frames and the accompanying
procedures to be used by bridges and switches in handling such frames. The standard also contains provisions for a
quality-of-service prioritization scheme commonly known as IEEE 802.1p and defines the Generic Attribute Registra-
tion Protocol.
Portions of the network which are VLAN-aware (i.e., IEEE 802.1q conformant) can include VLAN tags. When a frame
enters the VLAN-aware portion of the network, a tag is added to represent the VLAN membership. Each frame must
be distinguishable as being within exactly one VLAN. A frame in the VLAN-aware portion of the network that does
not contain a VLAN tag is assumed to be flowing on the native VLAN.
The standard was developed by IEEE 802.1, a working group of the IEEE 802 standards committee, and continues
to be actively revised. One of the notable revisions is 802.1Q-2014 which incorporated IEEE 802.1aq (Shortest Path
Bridging) and much of the IEEE 802.1d standard.
802.1q VLAN interfaces are represented as virtual sub-interfaces in VyOS. The term used for this is vif.
set interfaces wireless <interface> vif <vlan-id>
Create a new VLAN interface on interface <interface> using the VLAN number provided via <vlan-id>.
You can create multiple VLAN interfaces on a physical interface. The VLAN ID range is from 0 to 4094.
set interfaces wireless <interface> vif <vlan-id> address <address | dhcp | dhcpv6>
Configure interface <interface> with one or more interface addresses.
• address can be specified multiple times as IPv4 and/or IPv6 address, e.g. 192.0.2.1/24 and/or
2001:db8::1/64
• dhcp interface address is received by DHCP from a DHCP server on this segment.
• dhcpv6 interface address is received by DHCPv6 from a DHCPv6 server on this segment.
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces wireless <interface> vif <vlan-id> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
If the ARP table already contains the IP address of the gratuitous arp frame, the arp table will be updated
regardless if this setting is on or off.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
set interfaces wireless <interface> vif <vlan-id> ipv6 address eui64 <prefix>
EUI-64 as specified in RFC 4291 allows a host to assign iteslf a unique 64-Bit IPv6 address.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces wireless <interface> vif <vlan-id> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
DHCP(v6)
set interfaces wireless <interface> vif <vlan-id> dhcp-options client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
QinQ (802.1ad)
IEEE 802.1ad was an Ethernet networking standard informally known as QinQ as an amendment to IEEE standard
802.1q VLAN interfaces as described above. 802.1ad was incorporated into the base 802.1q standard in 2011. The
technique is also known as provider bridging, Stacked VLANs, or simply QinQ or Q-in-Q. “Q-in-Q” can for supported
devices apply to C-tag stacking on C-tag (Ethernet Type = 0x8100).
The original 802.1q specification allows a single Virtual Local Area Network (VLAN) header to be inserted into an
Ethernet frame. QinQ allows multiple VLAN tags to be inserted into a single frame, an essential capability for im-
plementing Metro Ethernet network topologies. Just as QinQ extends 802.1Q, QinQ itself is extended by other Metro
Ethernet protocols.
In a multiple VLAN header context, out of convenience the term “VLAN tag” or just “tag” for short is often used in
place of “802.1q VLAN header”. QinQ allows multiple VLAN tags in an Ethernet frame; together these tags constitute
a tag stack. When used in the context of an Ethernet frame, a QinQ frame is a frame that has 2 VLAN 802.1q headers
(double-tagged).
In VyOS the terms vif-s and vif-c stand for the ethertype tags that are used.
The inner tag is the tag which is closest to the payload portion of the frame. It is officially called C-TAG (customer tag,
with ethertype 0x8100). The outer tag is the one closer/closest to the Ethernet header, its name is S-TAG (service tag
with Ethernet Type = 0x88a8).
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> address <address |
dhcp | dhcpv6>
Configure interface <interface> with one or more interface addresses.
• address can be specified multiple times as IPv4 and/or IPv6 address, e.g. 192.0.2.1/24 and/or
2001:db8::1/64
• dhcp interface address is received by DHCP from a DHCP server on this segment.
• dhcpv6 interface address is received by DHCPv6 from a DHCPv6 server on this segment.
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
set interfaces wireless wlan0 vif-s 1000 vif-c 20 description 'This is an awesome␣
˓→interface running on VyOS'
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> mtu <mtu>
Configure MTU on given <interface>. It is the size (in bytes) of the largest ethernet frame sent on this link.
Example:
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> ip adjust-mss <mss |
clamp-mss-to-pmtu>
As Internet wide PMTU discovery rarely works, we sometimes need to clamp our TCP MSS value to a specific
value. This is a field in the TCP options part of a SYN packet. By setting the MSS value, you are telling the
remote side unequivocally ‘do not try to send me packets bigger than this value’.
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
If the ARP table already contains the IP address of the gratuitous arp frame, the arp table will be updated
regardless if this setting is on or off.
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
set interfaces wireless wlan0 vif-s 1000 vif-c 20 ipv6 address autoconf
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> ipv6 address eui64
<prefix>
EUI-64 as specified in RFC 4291 allows a host to assign iteslf a unique 64-Bit IPv6 address.
Example:
set interfaces wireless wlan0 vif-s 1000 vif-c 20 ipv6 address eui64␣
˓→2001:db8:beef::/64
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> ipv6 address
no-default-link-local
Do not assign a link-local IPv6 address to this interface.
Example:
set interfaces wireless wlan0 vif-s 1000 vif-c 20 ipv6 address no-default-link-local
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> ipv6 adjust-mss <mss
| clamp-mss-to-pmtu>
As Internet wide PMTU discovery rarely works, we sometimes need to clamp our TCP MSS value to a specific
value. This is a field in the TCP options part of a SYN packet. By setting the MSS value, you are telling the
remote side unequivocally ‘do not try to send me packets bigger than this value’.
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> vrf <vrf>
Place interface in given VRF instance.
See also:
There is an entire chapter about how to configure a VRF, please check this for additional information.
Example:
DHCP(v6)
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> dhcp-options
client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
set interfaces wireless wlan0 vif-s 1000 vif-c 20 dhcp-options client-id 'foo-bar'
set interfaces wireless wlan0 vif-s 1000 vif-c 20 dhcp-options host-name 'VyOS'
set interfaces wireless wlan0 vif-s 1000 vif-c 20 dhcp-options vendor-class-id 'VyOS
˓→'
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> dhcp-options reject
<address>
Reject DHCP leases from a given address or range. This is useful when a modem gives a local IP when first
starting.
• address can be specified multiple times, e.g. 192.168.100.1 and/or 192.168.100.0/24
Example:
set interfaces wireless wlan0 vif-s 1000 vif-c 20 dhcp-options reject 192.168.100.0/
˓→24
This option is used by some DHCP clients as a way for users to specify identifying information to the client.
This can be used in a similar way to the vendor-class-identifier option, but the value of the option is specified
by the user, not the vendor.
Example:
set interfaces wireless wlan0 vif-s 1000 vif-c 20 dhcp-options user-class VyOS
set interfaces wireless <interface> vif-s <vlan-id> vif-c <vlan-id> dhcpv6-options duid
<duid>
The DHCP unique identifier (DUID) is used by a client to get an IP address from a DHCPv6 server. It has a
2-byte DUID type field, and a variable-length identifier field up to 128 bytes. Its actual length depends on its
type. The server compares the DUID with its database and delivers configuration data (address, lease times,
DNS servers, etc.) to the client.
Some ISPs by default only delegate a /64 prefix. To request for a specific prefix size use this option to request
for a bigger delegation for this pd <id>. This value is in the range from 32 - 64 so you could request up to a /32
prefix (if your ISP allows this) down to a /64 delegation.
The default value corresponds to 64.
To request a /56 prefix from your ISP use:
Operation
Note: Scanning is not supported on all wireless drivers and wireless hardware. Refer to your driver and wireless
hardware documentation for further details.
Examples
The following example creates a WAP. When configuring multiple WAP interfaces, you must specify unique IP ad-
dresses, channels, Network IDs commonly referred to as SSID (Service Set Identifier), and MAC addresses.
The WAP in this example has the following characteristics:
• IP address 192.168.2.1/24
• Network ID (SSID) TEST
• WPA passphrase 12345678
• Use 802.11n protocol
• Wireless channel 1
Resulting in
system {
wireless {
country-code de
}
}
interfaces {
[...]
wireless wlan0 {
address 192.168.2.1/24
channel 1
mode n
security {
wpa {
cipher CCMP
mode wpa2
passphrase "12345678"
}
}
ssid "TEST"
type access-point
}
}
system {
[...]
wifi-regulatory-domain DE
}
To get it to work as an access point with this configuration you will need to set up a DHCP server to work with that
network. You can - of course - also bridge the Wireless interface with any configured bridge (Bridge) on the system.
Intel AX200
The Intel AX200 card does not work out of the box in AP mode, see https://unix.stackexchange.com/questions/598275/
intel-ax200-ap-mode. You can still put this card into AP mode using the following configuration:
The Wireless Wide-Area-Network interface provides access (through a wireless modem/wwan) to wireless networks
provided by various cellular providers.
VyOS uses the interfaces wwan subsystem for configuration.
Configuration
Note: When using DHCP to retrieve IPv4 address and if local customizations are needed, they should be
possible using the enter and exit hooks provided. The hook dirs are:
• /config/scripts/dhcp-client/pre-hooks.d/
• /config/scripts/dhcp-client/post-hooks.d/
Example:
set interfaces wwan wwan0 description 'This is an awesome interface running on VyOS'
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss <value>
Hint: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in 1452 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces wwan <interface> ip arp-cache-timeout
Once a neighbor has been found, the entry is considered to be valid for at least for this specific time. An entry’s
validity will be extended if it receives positive feedback from higher level protocols.
This defaults to 30 seconds.
Example:
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
Example:
Note: This command was introduced in VyOS 1.4 - it was previously called: set firewall options
interface <name> adjust-mss6 <value>
Hint: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in 1432 bytes on a 1492 byte MTU.
Instead of a numerical MSS value clamp-mss-to-pmtu can be used to automatically set the proper value.
set interfaces wwan <interface> ipv6 accept-dad <1-3>
Whether to accept DAD (Duplicate Address Detection).
• 0: Disable DAD
• 1: Enable DAD (default)
• 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
Example:
DHCP(v6)
set interfaces wwan <interface> dhcp-options client-id <description>
RFC 2131 states: The client MAY choose to explicitly provide the identifier through the ‘client identifier’
option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent
messages, and the server MUST use that identifier to identify the client.
Example:
This option is used by some DHCP clients as a way for users to specify identifying information to the client.
This can be used in a similar way to the vendor-class-identifier option, but the value of the option is specified
by the user, not the vendor.
Example:
set interfaces wwan <interface> dhcpv6-options pd <id> interface <delegatee> sla-id <id>
Specify the identifier value of the site-level aggregator (SLA) on the interface. ID must be a decimal number
greater then 0 which fits in the length of SLA IDs (see below).
Example: If ID is 1 and the client is delegated an IPv6 prefix 2001:db8:ffff::/48, dhcp6c will combine the two
values into a single IPv6 prefix, 2001:db8:ffff:1::/64, and will configure the prefix on the specified interface.
Operation
--------------------------------
Numbers | own: 4917xxxxxxxx
--------------------------------
Status | lock: sim-pin2
| unlock retries: sim-pin (3), sim-pin2 (3), sim-puk (10), sim-
˓→puk2 (10)
| state: connected
| power state: on
| access tech: lte
| signal quality: 63% (recent)
--------------------------------
Modes | supported: allowed: 2g; preferred: none
| allowed: 3g; preferred: none
| allowed: 4g; preferred: none
| allowed: 2g, 3g; preferred: 3g
| allowed: 2g, 3g; preferred: 2g
| allowed: 2g, 4g; preferred: 4g
| allowed: 2g, 4g; preferred: 2g
| allowed: 3g, 4g; preferred: 3g
| allowed: 3g, 4g; preferred: 4g
| allowed: 2g, 3g, 4g; preferred: 4g
| allowed: 2g, 3g, 4g; preferred: 3g
| allowed: 2g, 3g, 4g; preferred: 2g
| current: allowed: 2g, 3g, 4g; preferred: 2g
--------------------------------
Bands | supported: egsm, dcs, pcs, utran-1, utran-8, eutran-1,␣
˓→eutran-3,
Example
The following example is based on a Sierra Wireless MC7710 miniPCIe card (only the form factor in reality it runs
UBS) and Deutsche Telekom as ISP. The card is assembled into a PC Engines APU4.
Supported Modules
The following hardware modules have been tested successfully in an PC Engines APU4 board:
• Sierra Wireless AirPrime MC7304 miniPCIe card (LTE)
• Sierra Wireless AirPrime MC7430 miniPCIe card (LTE)
• Sierra Wireless AirPrime MC7455 miniPCIe card (LTE)
• Sierra Wireless AirPrime MC7710 miniPCIe card (LTE)
• Huawei ME909u-521 miniPCIe card (LTE)
• Huawei ME909s-120 miniPCIe card (LTE)
Firmware Update
All available WWAN cards have a built-in, reprogrammable firmware. Most vendors provide regular updates to
firmware used in the baseband chip.
As VyOS makes use of the QMI interface to connect to the WWAN modem cards, the firmware can be reprogrammed.
To update the firmware, VyOS also ships the qmi-firmware-update binary. To upgrade the firmware of an
e.g. Sierra Wireless MC7710 module to the firmware provided in the file 9999999_9999999_9200_03.05.14.
00_00_generic_000.000_001_SPKG_MC.cwe use the following command:
8.5 Load-balancing
Outbound traffic can be balanced between two or more outbound interfaces. If a path fails, traffic is balanced across
the remaining healthy paths, a recovered path is automatically added back to the routing table and used by the load
balancer. The load balancer automatically adds routes for each path to the routing table and balances traffic across the
configured interfaces, determined by interface health and weight.
In a minimal configuration, the following must be provided:
• an interface with a nexthop
• one rule with a LAN (inbound-interface) and the WAN (interface).
Let’s assume we have two DHCP WAN interfaces and one LAN (eth2):
Note: WAN Load Balacing should not be used when dynamic routing protocol is used/needed. This feature creates
customized routing tables and firewall rules, that makes it incompatible to use with routing protocols.
Balancing Rules
Interfaces, their weight and the type of traffic to be balanced are defined in numbered balancing rule sets. The rule sets
are executed in numerical order against outgoing packets. In case of a match the packet is sent through an interface
specified in the matching rule. If a packet doesn’t match any rule it is sent by using the system routing table. Rule
numbers can’t be changed.
Create a load balancing rule, it can be a number between 1 and 9999:
Interface weight
Let’s expand the example from above and add weight to the interfaces. The bandwidth from eth0 is larger than eth1.
Per default, outbound traffic is distributed randomly across available interfaces. Weights can be assigned to interfaces
to influence the balancing.
Rate limit
A packet rate limit can be set for a rule to apply the rule to traffic above or below a specified threshold. To configure
the rate limiting use:
• burst: Number of packets allowed to overshoot the limit within period. Default 5.
• period: Time window for rate calculation. Possible values: second (one second), minute (one minute), hour
(one hour). Default is second.
• rate: Number of packets. Default 5.
• threshold: below or above the specified rate limit.
Outgoing traffic is balanced in a flow-based manner. A connection tracking table is used to track flows by their source
address, destination address and port. Each flow is assigned to an interface according to the defined balancing rules
and subsequent packets are sent through the same interface. This has the advantage that packets always arrive in order
if links with different speeds are in use.
Packet-based balancing can lead to a better balance across interfaces when out of order packets are no issue. Per-packet-
based balancing can be set for a balancing rule with:
Exclude traffic
To exclude traffic from load balancing, traffic matching an exclude rule is not balanced but routed through the system
routing table instead:
Health checks
The health of interfaces and paths assigned to the load balancer is periodically checked by sending ICMP packets (ping)
to remote destinations, a TTL test or the execution of a user defined script. If an interface fails the health check it is
removed from the load balancer’s pool of interfaces. To enable health checking for an interface:
Specify nexthop on the path to the destination, ipv4-address can be set to dhcp
Set the number of health check failures before an interface is marked as unavailable, range for number is 1 to 10,
default 1. Or set the number of successful health checks before an interface is added back to the interface pool, range
for number is 1 to 10, default 1.
Each health check is configured in its own test, tests are numbered and processed in numeric order. For multi target
health checking multiple tests can be defined:
• resp-time: the maximum response time for ping in seconds. Range 1. . . 30, default 5
• target: the target to be sent ICMP packets to, address can be an IPv4 address or hostname
• test-script: A user defined script must return 0 to be considered successful and non-zero to fail. Scripts are
located in /config/scripts, for different locations the full path needs to be provided
• ttl-limit: For the UDP TTL limit test the hop count limit must be specified. The limit must be shorter than
the path length, an ICMP time expired message is needed to be returned for a successful test. default 1
• type: Specify the type of test. type can be ping, ttl or a user defined script
Per default, interfaces used in a load balancing pool replace the source IP of each outgoing packet with its own address
to ensure that replies arrive on the same interface. This works through automatically generated source NAT (SNAT)
rules, these rules are only applied to balanced traffic. In cases where this behaviour is not desired, the automatic
generation of SNAT rules can be disabled:
Sticky Connections
Inbound connections to a WAN interface can be improperly handled when the reply is sent back to the client.
Upon reception of an incoming packet, when a response is sent, it might be desired to ensure that it leaves from the
same interface as the inbound one. This can be achieved by enabling sticky connections in the load balancing:
Failover
In failover mode, one interface is set to be the primary interface and other interfaces are secondary or spare. Instead
of balancing traffic across all healthy interfaces, only the primary interface is used and in case of failure, a secondary
interface selected from the pool of available interfaces takes over. The primary interface is selected based on its weight
and health, others become secondary interfaces. Secondary interfaces to take over a failed primary interface are chosen
from the load balancer’s interface pool, depending on their weight and health. Interface roles can also be selected based
on rule order by including interfaces in balancing rules and ordering those rules accordingly. To put the load balancer
in failover mode, create a failover rule:
Because existing sessions do not automatically fail over to a new path, the session table can be flushed on each connec-
tion state change:
Warning: Flushing the session table will cause other connections to fall back from flow-based to packet-based
balancing until each flow is reestablished.
Script execution
A script can be run when an interface state change occurs. Scripts are run from /config/scripts, for a different location
specify the full path:
Warning: Blocking call with no timeout. System will become unresponsive if script does not return!
Show WAN load balancer information including test types and targets. A character at the start of each line depicts the
state of the test
• + successful
• - failed
• a blank indicates that no test has been carried out
Interface: eth1
Status: active
Last Status Change: Tue Jun 11 20:06:42 2019
+Test: ping Target:
Last Interface Success: 0s
Last Interface Failure: 6m26s
# Interface Failure(s): 0
Restart
restart wan-load-balance
8.5.2 Reverse-proxy
VyOS reverse-proxy is balancer and proxy server that provides high-availability, load balancing and proxying for TCP
(level 4) and HTTP-based (level 7) applications.
Configuration
Service configuration is responsible for binding to a specific port, while the backend configuration determines the type
of load balancing to be applied and specifies the real servers to be utilized.
Service
Rules
Rules allow to control and route incoming traffic to specific backend based on predefined conditions. Rules allow to
define matching criteria and perform action accordingly.
set load-balancing reverse-proxy service <name> rule <rule> domain-name <name>
Match domain name
set load-balancing reverse-proxy service <name> rule <rule> ssl <sni>
SSL match Server Name Indication (SNI) option:
• req-ssl-sni SSL Server Name Indication (SNI) request match
• ssl-fc-sni SSL frontend connection Server Name Indication match
• ssl-fc-sni-end SSL frontend match end of connection Server Name
Indication
set load-balancing reverse-proxy service <name> rule <rule> url-path <match> <url>
Allows to define URL path matching rules for a specific service.
With this command, you can specify how the URL path should be matched against incoming requests.
The available options for <match> are:
• begin Matches the beginning of the URL path
• end Matches the end of the URL path.
• exact Requires an exactly match of the URL path
set load-balancing reverse-proxy service <name> rule <rule> set backend <name>
Assign a specific backend to a rule
set load-balancing reverse-proxy service <name> rule <rule> redirect-location <url>
Redirect URL to a new location
Backend
Global
Global parameters
set load-balancing reverse-proxy global-parameters max-connections <num>
Limit maximum number of connections
set load-balancing reverse-proxy global-parameters ssl-bind-ciphers <ciphers>
Limit allowed cipher algorithms used during SSL/TLS handshake
set load-balancing reverse-proxy global-parameters tls-version-min <version>
Specify the minimum required TLS version 1.2 or 1.3
Health checks
HTTP checks
For web application providing information about their state HTTP health checks can be used to determine their avail-
ability.
set load-balancing reverse-proxy backend <name> http-check
Enables HTTP health checks using OPTION HTTP requests against ‘/’ and expecting a successful response
code in the 200-399 range.
set load-balancing reverse-proxy backend <name> http-check method <method>
Sets the HTTP method to be used, can be either: option, get, post, put
set load-balancing reverse-proxy backend <name> http-check uri <path>
Sets the endpoint to be used for health checks
set load-balancing reverse-proxy backend <name> http-check expect <condition>
TCP checks
Health checks can also be configured for TCP mode backends. You can configure protocol aware checks for a range of
Layer 7 protocols:
set load-balancing reverse-proxy backend <name> health-check <protocol>
Available health check protocols:
• ldap LDAP protocol check.
• redis Redis protocol check.
• mysql MySQL protocol check.
• pgsql PostgreSQL protocol check.
• smtp SMTP protocol check.
Note: If you specify a server to be checked but do not configure a protocol, a basic TCP health check will be attempted.
A server shall be deemed online if it responses to a connection attempt with a valid SYN/ACK packet.
The name of the service can be different, in this example it is only for convenience.
Examples
Level 4 balancing
This configuration enables the TCP reverse proxy for the “my-tcp-api” service. Incoming TCP connections on port 8888
will be load balanced across the backend servers (srv01 and srv02) using the round-robin load-balancing algorithm.
The following configuration demonstrates how to use VyOS to achieve load balancing based on the domain name.
The HTTP service listen on TCP port 80.
Rule 10 matches requests with the domain name node1.example.com forwards to the backend bk-api-01
Rule 20 matches requests with the domain name node2.example.com forwards to the backend bk-api-02
set load-balancing reverse-proxy service http description 'bind app listen on 443 port'
set load-balancing reverse-proxy service http mode 'tcp'
set load-balancing reverse-proxy service http port '80'
Terminate SSL
SSL Bridging
The following configuration terminates incoming HTTPS traffic on the router, then re-encrypts the traffic and sends
to the backend server via HTTPS. This is useful if encryption is required for both legs, but you do not want to install
publicly trusted certificates on each backend server.
Backend service certificates are checked against the certificate authority specified in the configuration, which could be
an internal CA.
The https service listens on port 443 with backend bk-bridge-ssl to handle HTTPS traffic. It uses certificate named
cert for SSL termination.
The bk-bridge-ssl backend connects to sr01 server on port 443 via HTTPS and checks backend server has a valid
certificate trusted by CA cacert
8.6 NAT
8.6.1 NAT44
NAT (Network Address Translation) is a common method of remapping one IP address space into another by modifying
network address information in the IP header of packets while they are in transit across a traffic routing device. The
technique was originally used as a shortcut to avoid the need to readdress every host when a network was moved. It has
become a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One
Internet-routable IP address of a NAT gateway can be used for an entire private network.
IP masquerading is a technique that hides an entire IP address space, usually consisting of private IP addresses, behind
a single IP address in another, usually public address space. The hidden addresses are changed into a single (public)
IP address as the source address of the outgoing IP packets so they appear as originating not from the hidden host but
from the routing device itself. Because of the popularity of this technique to conserve IPv4 address space, the term
NAT has become virtually synonymous with IP masquerading.
As network address translation modifies the IP address information in packets, NAT implementations may vary in their
specific behavior in various addressing cases and their effect on network traffic. The specifics of NAT behavior are not
commonly documented by vendors of equipment containing NAT implementations.
The computers on an internal network can use any of the addresses set aside by the IANA (Internet Assigned Numbers
Authority) for private addressing (see RFC 1918). These reserved IP addresses are not in use on the Internet, so an
external machine will not directly route to them. The following addresses are reserved for private use:
• 10.0.0.0 to 10.255.255.255 (CIDR: 10.0.0.0/8)
• 172.16.0.0 to 172.31.255.255 (CIDR: 172.16.0.0/12)
• 192.168.0.0 to 192.168.255.255 (CIDR: 192.168.0.0/16)
If an ISP deploys a CGN (Carrier-grade NAT), and uses RFC 1918 address space to number customer gateways, the
risk of address collision, and therefore routing failures, arises when the customer network already uses an RFC 1918
address space.
This prompted some ISPs to develop a policy within the ARIN (American Registry for Internet Numbers) to allocate
new private address space for CGNs, but ARIN deferred to the IETF before implementing the policy indicating that
the matter was not a typical allocation issue but a reservation of addresses for technical purposes (per RFC 2860).
IETF published RFC 6598, detailing a shared address space for use in ISP CGN deployments that can handle the same
network prefixes occurring both on inbound and outbound interfaces. ARIN returned address space to the IANA for
this allocation.
The allocated address block is 100.64.0.0/10.
Devices evaluating whether an IPv4 address is public must be updated to recognize the new address space. Allocating
more private IPv4 address space for NAT devices might prolong the transition to IPv6.
Overview
SNAT
SNAT (Source Network Address Translation) is the most common form of NAT and is typically referred to simply as
NAT. To be more correct, what most people refer to as NAT is actually the process of PAT (Port Address Translation),
or NAT overload. SNAT is typically used by internal users/private hosts to access the Internet - the source address is
translated and thus kept private.
DNAT
DNAT (Destination Network Address Translation) changes the destination address of packets passing through the
router, while SNAT changes the source address of packets. DNAT is typically used when an external (public) host
needs to initiate a session with an internal (private) host. A customer needs to access a private service behind the
routers public IP. A connection is established with the routers public IP address on a well known port and thus all traffic
for this port is rewritten to address the internal (private) host.
Bidirectional NAT
This is a common scenario where both SNAT and DNAT are configured at the same time. It’s commonly used when
internal (private) hosts need to establish a connection with external resources and external systems need to access
internal (private) resources.
There is a very nice picture/explanation in the Vyatta documentation which should be rewritten here.
NAT Ruleset
NAT is configured entirely on a series of so called rules. Rules are numbered and evaluated by the underlying OS in
numerical order! The rule numbers can be changes by utilizing the rename and copy commands.
Note: Changes to the NAT system only affect newly established connections. Already established connections are not
affected.
Hint: When designing your NAT ruleset leave some space between consecutive rules for later extension. Your ruleset
could start with numbers 10, 20, 30. You thus can later extend the ruleset and place new rules between existing ones.
Traffic Filters
Traffic Filters are used to control which packets will have the defined NAT rules applied. Five different filters can be
applied within a NAT rule.
• outbound-interface - applicable only to SNAT . It configures the interface which is used for the outside traffic
that this translation rule applies to. Interface groups, inverted selection and wildcard, are also supported.
Examples:
• inbound-interface - applicable only to DNAT . It configures the interface which is used for the inside traffic the
translation rule applies to. Interface groups, inverted selection and wildcard, are also supported.
Example:
• protocol - specify which types of protocols this translation rule applies to. Only packets matching the specified
protocol are NATed. By default this applies to all protocols.
Example:
– Set SNAT rule 20 to only NAT TCP and UDP packets
– Set DNAT rule 20 to only NAT UDP packets
• source - specifies which packets the NAT translation rule applies to based on the packets source IP address and/or
source port. Only matching packets are considered for NAT.
Example:
– Set SNAT rule 20 to only NAT packets arriving from the 192.0.2.0/24 network
– Set SNAT rule 30 to only NAT packets arriving from the 203.0.113.0/24 network with a source port of 80
and 443
• destination - specify which packets the translation will be applied to, only based on the destination address
and/or port number configured.
Note: If no destination is specified the rule will match on any destination address and port.
Example:
– Configure SNAT rule (40) to only NAT packets with a destination address of 192.0.2.1.
Address Conversion
Every NAT rule has a translation command defined. The address defined for the translation is the address used when
the address information in a packet is replaced.
Source Address
For SNAT rules the packets source address will be replaced with the address specified in the translation command. A
port translation can also be specified and is part of the translation address.
Note: The translation address must be set to one of the available addresses on the configured outbound-interface or it
must be set to masquerade which will use the primary IP address of the outbound-interface as its translation address.
Note: When using NAT for a large number of host systems it recommended that a minimum of 1 IP address is used to
NAT every 256 private host systems. This is due to the limit of 65,000 port numbers available for unique translations
and a reserving an average of 200-300 sessions per host system.
Example:
• Define a discrete source IP address of 100.64.0.1 for SNAT rule 20
• Use address masquerade (the interfaces primary address) on rule 30
• For a large amount of private machines behind the NAT your address pool might to be bigger. Use any address
in the range 100.64.0.10 - 100.64.0.20 on SNAT rule 40 when doing the translation
Destination Address
For DNAT rules the packets destination address will be replaced by the specified address in the translation address
command.
Example:
• DNAT rule 10 replaces the destination address of an inbound packet with 192.0.2.10
Also, in DNAT , redirection to localhost is supported. The redirect statement is a special form of dnat which always
translates the destination address to the local host’s one.
Example of redirection:
Advanced configuration can be used in order to apply source or destination NAT, and within a single rule, be able to
define multiple translated addresses, so NAT balances the translations among them.
NAT Load Balance uses an algorithm that generates a hash and based on it, then it applies corresponding translation.
This hash can be generated randomly, or can use data from the ip header: source-address, destination-address, source-
port and/or destination-port. By default, it will generate the hash randomly.
When defining the translated address, called backends, a weight must be configured. This lets the user define load
balance distribution according to their needs. Them sum of all the weights defined for the backends should be equal
to 100. In oder words, the weight defined for the backend is the percentage of the connections that will receive such
backend.
set nat [source | destination] rule <rule> load-balance hash [source-address |
destination-address | source-port | destination-port | random]
set nat [source | destination] rule <rule> load-balance backend <x.x.x.x> weight <1-100>
Configuration Examples
rule 100 {
outbound-interface {
name eth0
}
source {
address 192.168.0.0/24
}
translation {
address masquerade
}
}
In this example, we use masquerade as the translation address instead of an IP address. The masquerade target is
effectively an alias to say “use whatever IP address is on the outgoing interface”, rather than a statically configured IP
address. This is useful if you use DHCP for your outgoing interface and do not know what the external address will be.
When using NAT for a large number of host systems it recommended that a minimum of 1 IP address is used to NAT
every 256 host systems. This is due to the limit of 65,000 port numbers available for unique translations and a reserving
an average of 200-300 sessions per host system.
Example: For an ~8,000 host network a source NAT pool of 32 IP addresses is recommended.
A pool of addresses can be defined by using a hyphen between two IP addresses:
Linux netfilter will not NAT traffic marked as INVALID. This often confuses people into thinking that Linux (or
specifically VyOS) has a broken NAT implementation because non-NATed traffic is seen leaving an external interface.
This is actually working as intended, and a packet capture of the “leaky” traffic should reveal that the traffic is either an
additional TCP “RST”, “FIN,ACK”, or “RST,ACK” sent by client systems after Linux netfilter considers the connection
closed. The most common is the additional TCP RST some host implementations send after terminating a connection
(which is implementation-specific).
In other words, connection tracking has already observed the connection be closed and has transition the flow to IN-
VALID to prevent attacks from attempting to reuse the connection.
You can avoid the “leaky” behavior by using a firewall policy that drops “invalid” state packets.
Having control over the matching of INVALID state traffic, e.g. the ability to selectively log, is an important trou-
bleshooting tool for observing broken protocol behavior. For this reason, VyOS does not globally drop invalid state
traffic, instead allowing the operator to make the determination on how the traffic is handled.
A typical problem with using NAT and hosting public servers is the ability for internal systems to reach an internal
server using it’s external IP address. The solution to this is usually the use of split-DNS to correctly point host systems
to the internal address when requests are made internally. Because many smaller networks lack DNS infrastructure,
a work-around is commonly deployed to facilitate the traffic by NATing the request from internal hosts to the source
address of the internal interface on the firewall.
This technique is commonly referred to as NAT Reflection or Hairpin NAT.
Example:
• Redirect Microsoft RDP traffic from the outside (WAN, external) world via DNAT in rule 100 to the internal,
private host 192.0.2.40.
• Redirect Microsoft RDP traffic from the internal (LAN, private) network via DNAT in rule 110 to the internal,
private host 192.0.2.40. We also need a SNAT rule 110 for the reverse path of the traffic. The internal network
192.0.2.0/24 is reachable via interface eth0.10.
set nat destination rule 100 description 'Regular destination NAT from external'
set nat destination rule 100 destination port '3389'
set nat destination rule 100 inbound-interface name 'pppoe0'
set nat destination rule 100 protocol 'tcp'
set nat destination rule 100 translation address '192.0.2.40'
Destination NAT
DNAT is typically referred to as a Port Forward. When using VyOS as a NAT router and firewall, a common config-
uration task is to redirect incoming traffic to a system behind the firewall.
In this example, we will be using the example Quick Start configuration above as a starting point.
To setup a destination NAT rule we need to gather:
• The interface traffic will be coming in on;
• The protocol and port we wish to forward;
• The IP address of the internal system we wish to forward traffic to.
In our example, we will be forwarding web server traffic to an internal web server on 192.168.0.100. HTTP traffic
makes use of the TCP protocol on port 80. For other common port numbers, see: https://en.wikipedia.org/wiki/List_
of_TCP_and_UDP_port_numbers
Our configuration commands would be:
nat {
destination {
rule 10 {
description "Port Forward: HTTP to 192.168.0.100"
destination {
port 80
}
inbound-interface {
name eth0
}
protocol tcp
translation {
address 192.168.0.100
}
}
}
}
Note: If forwarding traffic to a different port than it is arriving on, you may also configure the translation port using
set nat destination rule [n] translation port.
This establishes our Port Forward rule, but if we created a firewall policy it will likely block the traffic.
It is important to note that when creating firewall rules, the DNAT translation occurs before traffic traverses the firewall.
In other words, the destination address has already been translated to 192.168.0.100.
So in our firewall ruleset, we want to allow traffic which previously matched a destination nat rule. In order to avoid
creating many rules, one for each destination nat rule, we can accept all ‘dnat’ connections with one simple rule, using
connection-status matcher:
ipv4 {
forward {
filter {
rule 10 {
action accept
(continues on next page)
1-to-1 NAT
Another term often used for DNAT is 1-to-1 NAT. For a 1-to-1 NAT configuration, both DNAT and SNAT are used to
NAT all traffic from an external IP address to an internal IP address and vice-versa.
Typically, a 1-to-1 NAT rule omits the destination port (all ports) and replaces the protocol with either all or ip.
Then a corresponding SNAT rule is created to NAT outgoing traffic for the internal IP to a reserved external IP. This
dedicates an external IP address to an internal IP address and is useful for protocols which don’t have the notion of
ports, such as GRE.
Here’s an extract of a simple 1-to-1 NAT configuration with one internal and one external interface:
Firewall rules are written as normal, using the internal IP address as the source of outbound rules and the destination
of inbound rules.
Some application service providers (ASPs) operate a VPN gateway to provide access to their internal resources, and
require that a connecting organisation translate all traffic to the service provider network to a source address provided
by the ASP.
Load Balance
Second scenario: apply source NAT for all outgoing connections from LAN 10.0.0.0/8, using 3 public addresses and
equal distribution. We will generate the hash randomly.
Example Network
Here’s one example of a network environment for an ASP. The ASP requests that all connections from this company
should come from 172.29.41.89 - an address that is assigned by the ASP and not in use at the customer site.
Configuration
Dummy interface
The dummy interface allows us to have an equivalent of the Cisco IOS Loopback interface - a router-internal interface
we can use for IP addresses the router must know about, but which are not actually assigned to a real network.
We only need a single step for this interface:
NAT Configuration
We’ll use the IKE and ESP groups created above for this VPN. Because we need access to 2 different subnets on the
far side, we will need two different tunnels. If you changed the names of the ESP group and IKE group in the previous
step, make sure you use the correct names here too.
If you’ve completed all the above steps you no doubt want to see if it’s all working.
Start by checking for IPSec SAs (Security Associations) with:
Peer ID / IP Local ID / IP
------------ -------------
198.51.100.243 203.0.113.46
Tunnel State Bytes Out/In Encrypt Hash NAT-T A-Time L-Time Proto
------ ----- ------------- ------- ---- ----- ------ ------ -----
0 up 0.0/0.0 aes256 sha256 no 1647 3600 all
1 up 0.0/0.0 aes256 sha256 no 865 3600 all
That looks good - we defined 2 tunnels and they’re both up and running.
8.6.2 NAT64
NAT64 (IPv6-to-IPv4 Prefix Translation) is a critical component in modern networking, facilitating communication
between IPv6 and IPv4 networks. This documentation outlines the setup, configuration, and usage of the NAT64 feature
in your project. Whether you are transitioning to IPv6 or need to seamlessly connect IPv4 and IPv6 devices. NAT64 is
a stateful translation mechanism that translates IPv6 addresses to IPv4 addresses and IPv4 addresses to IPv6 addresses.
NAT64 is used to enable IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP.
Overview
SNAT64
SNAT64 (IPv6-to-IPv4 Source Address Translation) is a stateful translation mechanism that translates IPv6 addresses
to IPv4 addresses.
64:ff9b::/96 is the well-known prefix for IPv4-embedded IPv6 addresses. The prefix is used to represent IPv4
addresses in an IPv6 address format. The IPv4 address is encoded in the low-order 32 bits of the IPv6 address. The
high-order 32 bits are set to the well-known prefix 64:ff9b::/96.
Configuration Examples
The following examples show how to configure NAT64 on a VyOS router. The 192.0.2.10 address is used as the IPv4
address for the translation pool.
NAT64 server configuration:
8.6.3 NAT66(NPTv6)
NPTv6 (IPv6-to-IPv6 Network Prefix Translation) is an address translation technology based on IPv6 networks, used
to convert an IPv6 address prefix in an IPv6 message into another IPv6 address prefix. We call this address translation
method NAT66. Devices that support the NAT66 function are called NAT66 devices, which can provide NAT66 source
and destination address translation functions.
Overview
SNAT66
SNPTv6 (Source IPv6-to-IPv6 Network Prefix Translation) The conversion function is mainly used in the following
scenarios:
• A single internal network and external network. Use the NAT66 device to connect a single internal network and
public network, and the hosts in the internal network use IPv6 address prefixes that only support routing within
the local range. When a host in the internal network accesses the external network, the source IPv6 address prefix
in the message will be converted into a global unicast IPv6 address prefix by the NAT66 device.
• Redundancy and load sharing. There are multiple NAT66 devices at the edge of an IPv6 network to another IPv6
network. The path through the NAT66 device to another IPv6 network forms an equivalent route, and traffic can
be load-shared on these NAT66 devices. In this case, you can configure the same source address translation rules
on these NAT66 devices, so that any NAT66 device can handle IPv6 traffic between different sites.
• Multi-homed. In a multi-homed network environment, the NAT66 device connects to an internal network and
simultaneously connects to different external networks. Address translation can be configured on each external
network side interface of the NAT66 device to convert the same internal network address into different external
network addresses, and realize the mapping of the same internal address to multiple external addresses.
DNAT66
The DNPTv6 (Destination IPv6-to-IPv6 Network Prefix Translation) destination address translation function is used
in scenarios where the server in the internal network provides services to the external network, such as providing Web
services or FTP services to the external network. By configuring the mapping relationship between the internal server
address and the external network address on the external network side interface of the NAT66 device, external network
users can access the internal network server through the designated external network address.
Prefix Conversion
Source Prefix
Every SNAT66 rule has a translation command defined. The prefix defined for the translation is the prefix used when
the address information in a packet is replaced.
The SNAT66 rule replaces the source address of the packet and calculates the converted address using the prefix spec-
ified in the rule.
Example:
• Convert the address prefix of a single fc01::/64 network to fc00::/64
• Output from eth0 network interface
Destination Prefix
For the DNAT66 rule, the destination address of the packet isreplaced by the address calculated from the specified
address or prefix in the translation address command
Example:
• Convert the address prefix of a single fc00::/64 network to fc01::/64
• Input from eth0 network interface
Configuration Examples
Use the following topology to build a nat66 based isolated network between internal and external networks (dynamic
prefix is not supported):
R1:
R2:
Use the following topology to translate internal user local addresses (fc::/7) to DHCPv6-PD provided prefixes from
an ISP connected to a VyOS HA pair.
Configure both routers (a and b) for DHCPv6-PD via dummy interface:
Configure the A-side router for NPTv6 using the prefixes above:
set nat66 source rule 10 description 'NPT to VLAN 10'
set nat66 source rule 10 outbound-interface name 'bond0.20'
set nat66 source rule 10 source prefix 'fd52:d62e:8011:a::/64'
set nat66 source rule 10 translation address '2001:db8:123:b008::/64'
set nat66 source rule 20 description 'NPT to VLAN 70'
set nat66 source rule 20 outbound-interface name 'bond0.20'
set nat66 source rule 20 source prefix 'fd52:d62e:8011:46::/64'
set nat66 source rule 20 translation address '2001:db8:123:b009::/64'
set nat66 source rule 30 description 'NPT to VLAN 200'
set nat66 source rule 30 outbound-interface name 'bond0.20'
set nat66 source rule 30 source prefix 'fd52:d62e:8011:c8::/64'
set nat66 source rule 30 translation address '2001:db8:123:b00a::/64'
set nat66 source rule 40 description 'NPT to VLAN 240'
set nat66 source rule 40 outbound-interface name 'bond0.20'
set nat66 source rule 40 source prefix 'fd52:d62e:8011:f0::/64'
set nat66 source rule 40 translation address '2001:db8:123:b00b::/64'
commit
Configure the B-side router for NPTv6 using the prefixes above:
8.6.4 CGNAT
CGNAT (Carrier-Grade Network Address Translation) , also known as Large-Scale NAT (LSN), is a type of network
address translation used by Internet Service Providers (ISPs) to enable multiple private IP addresses to share a single
public IP address. This technique helps to conserve the limited IPv4 address space. The 100.64.0.0/10 address block
is reserved for use in carrier-grade NAT
Overview
CGNAT works by placing a NAT device within the ISP’s network. This device translates private IP addresses from
customer networks to a limited pool of public IP addresses assigned to the ISP. This allows many customers to share a
smaller number of public IP addresses.
Not all RFC 6888 requirements are implemented in CGNAT.
Implemented the following RFC 6888 requirements:
• REQ 2: A CGN must have a default “IP address pooling” behavior of “Paired”. CGN must use the same external
IP address mapping for all sessions associated with the same internal IP address, be they TCP, UDP, ICMP,
something else, or a mix of different protocols.
• REQ 3: The CGN function should not have any limitations on the size or the contiguity of the external address
pool.
• REQ 4: A CGN must support limiting the number of external ports (or, equivalently, “identifiers” for ICMP) that
are assigned per subscriber
Advantages of CGNAT
• IPv4 Address Conservation: CGNAT helps mitigate the exhaustion of IPv4 addresses by allowing multiple
customers to share a single public IP address.
• Scalability: ISPs can support more customers without needing a proportional increase in public IP addresses.
• Cost-Effective: Reduces the cost associated with acquiring additional public IPv4 addresses.
Considerations
• Traceability Issues: Since multiple users share the same public IP address, tracking individual users for security
and legal purposes can be challenging.
• Performance Overheads: The translation process can introduce latency and potential performance bottlenecks,
especially under high load.
• Application Compatibility: Some applications and protocols may not work well with CGNAT due to their
reliance on unique public IP addresses.
• Port Allocation Limits: Each public IP address has a limited number of ports, which can be exhausted, affecting
the ability to establish new connections.
• Port Control Protocol: PCP is not implemented.
Port calculation
When implementing CGNAT, ensuring that there are enough ports allocated per subscriber is critical. Below is a
summary based on RFC 6888.
1. Total Ports Available:
• Total Ports: 65536 (0 to 65535)
• Reserved Ports: Assume 1024 ports are reserved for well-known services and administrative purposes.
• Usable Ports: 65536 - 1024 = 64512
2. Estimate Ports Needed per Subscriber:
• Example: A household might need 1000 ports to ensure smooth operation for multiple devices and appli-
cations.
3. Calculate the Number of Subscribers per Public IP:
• Usable Ports / Ports per Subscriber
• 64512 / 1000 64 subscribers per public IP
Configuration
Configuration Examples
Example of setting up a basic CGNAT configuration: In the following example, we define an external pool named ext-1
with one external IP address
Each subscriber will be allocated a maximum of 2000 ports from the external pool.
Operation commands
Further Reading
8.7 Policy
Policies are used for filtering and traffic management. With policies, network administrators could filter and treat traffic
according to their needs.
There could be a wide range of routing policies. Some examples are listed below:
• Filter traffic based on source/destination address.
• Set some metric to routes learned from a particular neighbor.
• Set some attributes (like AS PATH or Community value) to advertised routes to neighbors.
• Prefer a specific routing protocol routes over another routing protocol running on the same router.
Policies, in VyOS, are implemented using FRR filtering and route maps. Detailed information of FRR could be found
in http://docs.frrouting.org/
Filtering is used for both input and output of the routing information. Once filtering is defined, it can be applied in any
direction. VyOS makes filtering possible using acls and prefix lists.
Basic filtering can be done using access-list and access-list6.
Configuration
Access Lists
Prefix lists provides the most powerful prefix based filtering mechanism. In addition to access-list functionality, ip
prefix-list has prefix length range specification.
If no ip prefix list is specified, it acts as permit. If ip prefix list is defined, and no match is found, default deny is applied.
Prefix filtering can be done using prefix-list and prefix-list6.
Configuration
Prefix Lists
IPv4 route and IPv6 route policies are defined in this section. These route policies can then be associated to interfaces.
Rule-Sets
A rule-set is a named collection of rules that can be applied to an interface. Each rule is numbered, has an action to
apply if the rule is matched, and the ability to specify the criteria to match. Data packets go through the rules from 1 -
999999, at the first match the action of the rule will be executed.
set policy route <name> description <text>
set policy route6 <name> description <text>
Provide a rule-set description.
set policy route <name> default-log
set policy route6 <name> default-log
Option to log packets hitting default-action.
set policy route <name> rule <n> description <text>
set policy route6 <name> rule <n> description <text>
Provide a description for each rule.
set policy route <name> rule <n> log <enable|disable>
set policy route6 <name> rule <n> log <enable|disable>
Option to enable or disable log matching rule.
Matching criteria
There are a lot of matching criteria options available, both for policy route and policy route6. These options
are listed in this section.
set policy route <name> rule <n> connection-mark <1-2147483647>
set policy route6 <name> rule <n> connection-mark <1-2147483647>
Set match criteria based on connection mark.
set policy route <name> rule <n> source address <match_criteria>
set policy route <name> rule <n> destination address <match_criteria>
Match based on packet length criteria. Multiple values from 1 to 65535 and ranges are supported.
set policy route <name> rule <n> packet-type [broadcast | host | multicast | other]
set policy route6 <name> rule <n> packet-type [broadcast | host | multicast | other]
Match based on packet type criteria.
set policy route <name> rule <n> recent count <1-255>
set policy route6 <name> rule <n> recent count <1-255>
set policy route <name> rule <n> recent time <1-4294967295>
set policy route6 <name> rule <n> recent time <1-4294967295>
Set parameters for matching recently seen sources. This match could be used by seeting count (source address
seen more than <1-255> times) and/or time (source address seen in the last <0-4294967295> seconds).
set policy route <name> rule <n> state <established | invalid | new | related>
set policy route6 <name> rule <n> state <established | invalid | new | related>
Set match criteria based on session state.
set policy route <name> rule <n> tcp flags <text>
set policy route6 <name> rule <n> tcp flags <text>
Set match criteria based on tcp flags. Allowed values for TCP flags: SYN ACK FIN RST URG PSH
ALL. When specifying more than one flag, flags should be comma-separated. For example : value of
‘SYN,!ACK,!FIN,!RST’ will only match packets with the SYN flag set, and the ACK, FIN and RST flags unset.
set policy route <name> rule <n> time monthdays <text>
set policy route6 <name> rule <n> time monthdays <text>
set policy route <name> rule <n> time startdate <text>
set policy route6 <name> rule <n> time startdate <text>
set policy route <name> rule <n> time starttime <text>
set policy route6 <name> rule <n> time starttime <text>
set policy route <name> rule <n> time stopdate <text>
set policy route6 <name> rule <n> time stopdate <text>
set policy route <name> rule <n> time stoptime <text>
set policy route6 <name> rule <n> time stoptime <text>
set policy route <name> rule <n> time weekdays <text>
set policy route6 <name> rule <n> time weekdays <text>
set policy route <name> rule <n> time utc
set policy route6 <name> rule <n> time utc
Time to match the defined rule.
set policy route rule <n> ttl <eq | gt | lt> <0-255>
Match time to live parameter, where ‘eq’ stands for ‘equal’; ‘gt’ stands for ‘greater than’, and ‘lt’ stands for ‘less
than’.
set policy route6 rule <n> hop-limit <eq | gt | lt> <0-255>
Match hop-limit parameter, where ‘eq’ stands for ‘equal’; ‘gt’ stands for ‘greater than’, and ‘lt’ stands for ‘less
than’.
Actions
When mathcing all patterns defined in a rule, then different actions can be made. This includes droping the packet,
modifying certain data, or setting a different routing table.
set policy route <name> rule <n> action drop
set policy route6 <name> rule <n> action drop
Set rule action to drop.
set policy route <name> rule <n> set connection-mark <1-2147483647>
set policy route6 <name> rule <n> set connection-mark <1-2147483647>
Set a specific connection mark.
set policy route <name> rule <n> set dscp <0-63>
set policy route6 <name> rule <n> set dscp <0-63>
Set packet modifications: Packet Differentiated Services Codepoint (DSCP)
set policy route <name> rule <n> set mark <1-2147483647>
set policy route6 <name> rule <n> set mark <1-2147483647>
Set a specific packet mark.
set policy route <name> rule <n> set table <main | 1-200>
set policy route6 <name> rule <n> set table <main | 1-200>
Set the routing table to forward packet with.
set policy route <name> rule <n> set tcp-mss <500-1460>
set policy route6 <name> rule <n> set tcp-mss <500-1460>
Set packet modifications: Explicitly set TCP Maximum segment size value.
Route map is a powerfull command, that gives network administrators a very useful and flexible tool for traffic manip-
ulation.
Configuration
Route Map
set policy route-map <text> rule <1-65535> match ip route-source prefix-list <text>
IP route source of route to match, based on prefix-list.
set policy route-map <text> rule <1-65535> match ipv6 address access-list <text>
IPv6 address of route to match, based on IPv6 access-list.
set policy route-map <text> rule <1-65535> match ipv6 address prefix-list <text>
IPv6 address of route to match, based on IPv6 prefix-list.
set policy route-map <text> rule <1-65535> match ipv6 address prefix-len <0-128>
IPv6 address of route to match, based on specified prefix-length. Note that this can be used for kernel routes only.
Do not apply to the routes of dynamic routing protocols (e.g. BGP, RIP, OSFP), as this can lead to unexpected
results..
set policy route-map <text> rule <1-65535> match ipv6 nexthop <h:h:h:h:h:h:h:h>
Nexthop IPv6 address to match.
set policy route-map <text> rule <1-65535> match large-community large-community-list
<text>
Match BGP large communities.
set policy route-map <text> rule <1-65535> match local-preference <0-4294967295>
Match local preference.
set policy route-map <text> rule <1-65535> match metric <1-65535>
Match route metric.
set policy route-map <text> rule <1-65535> match origin <egp|igp|incomplete>
Boarder Gateway Protocol (BGP) origin code to match.
set policy route-map <text> rule <1-65535> match peer <x.x.x.x>
Peer IP address to match.
set policy route-map <text> rule <1-65535> match protocol <protocol>
Source protocol to match.
• babel - Babel routing protocol (Babel)
• bgp - Border Gateway Protocol (BGP)
• connected - Connected routes (directly attached subnet or host)
• isis - Intermediate System to Intermediate System (IS-IS)
• kernel - Kernel routes
• ospf - Open Shortest Path First (OSPFv2)
• ospfv3 - Open Shortest Path First (IPv6) (OSPFv3)
• rip - Routing Information Protocol (RIP)
• ripng - Routing Information Protocol next-generation (IPv6) (RIPng)
• static - Statically configured routes
• table - Non-main Kernel Routing Table
• vnc - Virtual Network Control (VNC)
Configuration
VyOS provides policies commands exclusively for BGP traffic filtering and manipulation: as-path-list is one of them.
Configuration
policy as-path-list
VyOS provides policies commands exclusively for BGP traffic filtering and manipulation: community-list is one of
them.
Configuration
policy community-list
VyOS provides policies commands exclusively for BGP traffic filtering and manipulation: extcommunity-list is one
of them.
Configuration
policy extcommunity-list
Regular expression to match against an extended community list, where text could be:
• <aa:nn:nn>: Extended community list regular expression.
• <rt aa:nn:nn>: Route Target regular expression.
• <soo aa:nn:nn>: Site of Origin regular expression.
VyOS provides policies commands exclusively for BGP traffic filtering and manipulation: large-community-list is
one of them.
Configuration
policy large-community-list
8.7.2 Examples
BGP Example
Policy definition:
# Create policy
set policy route-map setmet rule 2 action 'permit'
set policy route-map setmet rule 2 set as-path prepend '2 2 2'
Using ‘soft-reconfiguration’ we get the policy update without bouncing the neighbor.
Routes learned before routing policy applied:
Transparent Proxy
The following example will show how VyOS can be used to redirect web traffic to an external transparent proxy:
This creates a route policy called FILTER-WEB with one rule to set the routing table for matching traffic (TCP port
80) to table ID 100 instead of the default routing table.
To create routing table 100 and add a new default gateway to be used by traffic matching our route policy:
This can be confirmed using the show ip route table 100 operational command.
Finally, to apply the policy route to ingress traffic on our LAN interface, we use:
Multiple Uplinks
VyOS Policy-Based Routing (PBR) works by matching source IP address ranges and forwarding the traffic using dif-
ferent routing tables.
Routing tables that will be used in this example are:
• table 10 Routing table used for VLAN 10 (192.168.188.0/24)
• table 11 Routing table used for VLAN 11 (192.168.189.0/24)
• main Routing table used by VyOS and other interfaces not participating in PBR
OPTIONAL: Exclude Inter-VLAN traffic (between VLAN10 and VLAN11) from PBR
set policy route PBR rule 10 description 'VLAN10 <-> VLAN11 shortcut'
set policy route PBR rule 10 destination group network-group 'VLANS-GR'
set policy route PBR rule 10 set table 'main'
These commands allow the VLAN10 and VLAN11 hosts to communicate with each other using the main routing table.
Local route
The following example allows VyOS to use PBR (Policy-Based Routing) for traffic, which originated from the router
itself. That solution for multiple ISP’s and VyOS router will respond from the same interface that the packet was
received. Also, it used, if we want that one VPN tunnel to be through one provider, and the second through another.
• 203.0.113.254 IP addreess on VyOS eth1 from ISP1
• 192.168.2.254 IP addreess on VyOS eth2 from ISP2
• table 10 Routing table used for ISP1
• table 11 Routing table used for ISP2
This example shows how to target an MSS clamp (in our example to 1360 bytes) to a specific destination IP.
set policy route IP-MSS-CLAMP rule 10 description 'Clamp TCP session MSS to 1360 for 198.
˓→51.100.30'
To apply this policy to the correct interface, configure it on the interface the inbound local host will send through to
reach our destined target host (in our example eth1).
You can view that the policy is being correctly (or incorrectly) utilised with the following command:
8.8 PKI
VyOS 1.4 changed the way in how encryption keys or certificates are stored on the system. In the pre VyOS 1.4 era,
certificates got stored under /config and every service referenced a file. That made copying a running configuration
from system A to system B a bit harder, as you had to copy the files and their permissions by hand.
T3642 describes a new CLI subsystem that serves as a “certstore” to all services requiring any kind of encryption
key(s). In short, public and private certificates are now stored in PKCS#8 format in the regular VyOS CLI. Keys can
now be added, edited, and deleted using the regular set/edit/delete CLI commands.
VyOS not only can now manage certificates issued by 3rd party Certificate Authorities, it can also act as a CA on its
own. You can create your own root CA and sign keys with it by making use of some simple op-mode commands.
Don’t be afraid that you need to re-do your configuration. Key transformation is handled, as always, by our migration
scripts, so this will be a smooth transition for you!
VyOS now also has the ability to create CAs, keys, Diffie-Hellman and other keypairs from an easy to access operational
level command.
generate pki ca
Create a new CA and output the CAs public and private key on the console.
generate pki ca install <name>
Create a new CA and output the CAs public and private key on the console.
Note: In addition to the command above, the output is in a format which can be used to directly import the key
into the VyOS CLI by simply copy-pasting the output from op-mode into configuration mode.
name is used for the VyOS CLI command to identify this key. This key name is then used in the CLI configuration
to reference the key instance.
Note: In addition to the command above, the output is in a format which can be used to directly import the key
into the VyOS CLI by simply copy-pasting the output from op-mode into configuration mode.
name is used for the VyOS CLI command to identify this key. This key name is then used in the CLI configuration
to reference the key instance.
Certificates
Note: In addition to the command above, the output is in a format which can be used to directly import the key
into the VyOS CLI by simply copy-pasting the output from op-mode into configuration mode.
name is used for the VyOS CLI command to identify this key. This key name is then used in the CLI configuration
to reference the key instance.
Note: In addition to the command above, the output is in a format which can be used to directly import the key
into the VyOS CLI by simply copy-pasting the output from op-mode into configuration mode.
name is used for the VyOS CLI command to identify this key. This key name is then used in the CLI configuration
to reference the key instance.
Note: In addition to the command above, the output is in a format which can be used to directly import the key
into the VyOS CLI by simply copy-pasting the output from op-mode into configuration mode.
name is used for the VyOS CLI command to identify this key. This key name is then used in the CLI configuration
to reference the key instance.
Diffie-Hellman parameters
generate pki dh
Generate a new set of DH (Diffie-Hellman) parameters. The key size is requested by the CLI and defaults to
2048 bit.
The generated parameters are then output to the console.
generate pki dh install <name>
Generate a new set of DH parameters. The key size is requested by the CLI and defaults to 2048 bit.
Note: In addition to the command above, the output is in a format which can be used to directly import the key
into the VyOS CLI by simply copy-pasting the output from op-mode into configuration mode.
name is used for the VyOS CLI command to identify this key. This key name is then used in the CLI configuration
to reference the key instance.
OpenVPN
Note: In addition to the command above, the output is in a format which can be used to directly import the key
into the VyOS CLI by simply copy-pasting the output from op-mode into configuration mode.
name is used for the VyOS CLI command to identify this key. This key name is then used in the CLI configuration
to reference the key instance.
WireGuard
Note: In addition to the command above, the output is in a format which can be used to directly import the key
into the VyOS CLI by simply copy-pasting the output from op-mode into configuration mode.
interface is used for the VyOS CLI command to identify the WireGuard interface where this private key is
to be used.
Note: In addition to the command above, the output is in a format which can be used to directly import the key
into the VyOS CLI by simply copy-pasting the output from op-mode into configuration mode.
peer is used for the VyOS CLI command to identify the WireGuard peer where this secret is to be used.
CA (Certificate Authority)
Note: When loading the certificate you need to manually strip the -----BEGIN CERTIFICATE----- and
-----END CERTIFICATE----- tags. Also, the certificate/key needs to be presented in a single line without
line breaks (\n), this can be done using the following shell command:
$ tail -n +2 ca.pem | head -n -1 | tr -d '\n'
Note: When loading the certificate you need to manually strip the -----BEGIN KEY----- and -----END
KEY----- tags. Also, the certificate/key needs to be presented in a single line without line breaks (\n), this can
be done using the following shell command:
$ tail -n +2 ca.key | head -n -1 | tr -d '\n'
Server Certificate
After we have imported the CA certificate(s) we can now import and add certificates used by services on this router.
set pki certificate <name> certificate
Add public key portion for the certificate named name to the VyOS CLI.
Note: When loading the certificate you need to manually strip the -----BEGIN CERTIFICATE----- and
-----END CERTIFICATE----- tags. Also, the certificate/key needs to be presented in a single line without
line breaks (\n), this can be done using the following shell command:
$ tail -n +2 cert.pem | head -n -1 | tr -d '\n'
Note: When loading the certificate you need to manually strip the -----BEGIN KEY----- and -----END
KEY----- tags. Also, the certificate/key needs to be presented in a single line without line breaks (\n), this can
be done using the following shell command:
$ tail -n +2 cert.key | head -n -1 | tr -d '\n'
VyOS provides this utility to import existing certificates/key files directly into PKI from op-mode. Previous to VyOS
1.4, certificates were stored under the /config folder permanently and will be retained post upgrade.
import pki ca <name> file <Path to CA certificate file>
Import the public CA certificate from the defined file to VyOS CLI.
import pki ca <name> key-file <Path to private key file>
Import the CAs private key portion to the CLI. This should never leave the system as it is used to decrypt the
data. The key is required if you use VyOS as your certificate generator.
import pki certificate <name> file <path to certificate>
Import the certificate from the file to VyOS CLI.
import pki certificate <name> key-file <path to private key>
Import the private key of the certificate to the VyOS CLI. This should never leave the system as it is used to
decrypt the data.
import pki openvpn shared-secret <name> file <path to OpenVPN secret key>
Import the OpenVPN shared secret stored in file to the VyOS CLI.
ACME
The VyOS PKI subsystem can also be used to automatically retrieve Certificates using the ACME (Automatic Certificate
Management Environment) protocol.
set pki certificate <name> acme domain-name <name>
Domain names to apply, multiple domain-names can be specified.
This is a mandatory option
set pki certificate <name> acme email <address>
Email used for registration and recovery contact.
This is a mandatory option
set pki certificate <name> acme listen-address <address>
The address the server listens to during http-01 challenge
set pki certificate <name> acme rsa-key-size <2048 | 3072 | 4096>
Size of the RSA key.
This options defaults to 2048
set pki certificate <name> acme url <url>
ACME Directory Resource URI.
This defaults to https://acme-v02.api.letsencrypt.org/directory
Note: During initial deployment we recommend using the staging API of LetsEncrypt to prevent and black-
listing of your system. The API endpoint is https://acme-staging-v02.api.letsencrypt.org/directory
8.8.3 Operation
VyOS operational mode commands are not only available for generating keys but also to display them.
show pki ca
Show a list of installed CA certificates.
8.8.4 Examples
This configuration generates & installs into the VyOS PKI system a root certificate authority, alongside two interme-
diary certificate authorities for client & server certificates. These CAs are then used to generate a server certificate for
the router, and a client certificate for a user.
• vyos_root_ca is the root certificate authority.
• vyos_client_ca and vyos_server_ca are intermediary certificate authorities, which are signed by the root
CA.
• vyos_cert is a leaf server certificate used to identify the VyOS router, signed by the server intermediary CA.
• vyos_example_user is a leaf client certificate used to identify a user, signed by client intermediary CA.
First, we create the root certificate authority.
[edit]
vyos@vyos# run generate pki ca install vyos_root_ca
Enter private key type: [rsa, dsa, ec] (Default: rsa) rsa
Enter private key bits: (Default: 2048) 2048
Enter country code: (Default: GB) GB
Enter state: (Default: Some-State) Some-State
Enter locality: (Default: Some-City) Some-City
Enter organization name: (Default: VyOS) VyOS
Enter common name: (Default: vyos.io) VyOS Root CA
(continues on next page)
Secondly, we create the intermediary certificate authorities, which are used to sign the leaf certificates.
[edit]
vyos@vyos# run generate pki ca sign vyos_root_ca install vyos_server_ca
Do you already have a certificate request? [y/N] n
Enter private key type: [rsa, dsa, ec] (Default: rsa) rsa
Enter private key bits: (Default: 2048) 2048
Enter country code: (Default: GB) GB
Enter state: (Default: Some-State) Some-State
Enter locality: (Default: Some-City) Some-City
Enter organization name: (Default: VyOS) VyOS
Enter common name: (Default: vyos.io) VyOS Intermediary Server CA
Enter how many days certificate will be valid: (Default: 1825) 1095
Note: If you plan to use the generated key on this router, do not encrypt the private␣
˓→key.
[edit]
vyos@vyos# run generate pki ca sign vyos_root_ca install vyos_client_ca
Do you already have a certificate request? [y/N] n
Enter private key type: [rsa, dsa, ec] (Default: rsa) rsa
Enter private key bits: (Default: 2048) 2048
Enter country code: (Default: GB) GB
Enter state: (Default: Some-State) Some-State
Enter locality: (Default: Some-City) Some-City
Enter organization name: (Default: VyOS) VyOS
Enter common name: (Default: vyos.io) VyOS Intermediary Client CA
Enter how many days certificate will be valid: (Default: 1825) 1095
Note: If you plan to use the generated key on this router, do not encrypt the private␣
˓→key.
Lastly, we can create the leaf certificates that devices and users will utilise.
[edit]
vyos@vyos# run generate pki certificate sign vyos_server_ca install vyos_cert
Do you already have a certificate request? [y/N] n
Enter private key type: [rsa, dsa, ec] (Default: rsa) rsa
Enter private key bits: (Default: 2048) 2048
Enter country code: (Default: GB) GB
Enter state: (Default: Some-State) Some-State
Enter locality: (Default: Some-City) Some-City
Enter organization name: (Default: VyOS) VyOS
(continues on next page)
[edit]
vyos@vyos# run generate pki certificate sign vyos_client_ca install vyos_example_user
Do you already have a certificate request? [y/N] n
Enter private key type: [rsa, dsa, ec] (Default: rsa) rsa
Enter private key bits: (Default: 2048) 2048
Enter country code: (Default: GB) GB
Enter state: (Default: Some-State) Some-State
Enter locality: (Default: Some-City) Some-City
Enter organization name: (Default: VyOS) VyOS
Enter common name: (Default: vyos.io) Example User
Do you want to configure Subject Alternative Names? [y/N] y
Enter alternative names in a comma separate list, example: ipv4:1.1.1.1,ipv6:fe80::1,
˓→dns:vyos.net,rfc822:[email protected]
8.9 Protocols
8.9.1 Babel
Babel is a modern routing protocol designed to be robust and efficient both in ordinary wired networks and in wireless
mesh networks. By default, it uses hop-count on wired networks and a variant of ETX on wireless links, It can be
configured to take radio diversity into account and to automatically compute a link’s latency and include it in the
metric. It is defined in RFC 8966.
Babel a dual stack protocol. A single Babel instance is able to perform routing for both IPv4 and IPv6.
General Configuration
VyOS does not have a special command to start the Babel process. The Babel process starts when the first Babel
enabled interface is configured.
set protocols babel interface <interface>
This command specifies a Babel enabled interface by interface name. Both the sending and receiving of Babel
packets will be enabled on the interface specified in this command.
Optional Configuration
Note: If you enable this, you will probably want to set diversity-factor and channel below.
Interfaces Configuration
This command specifies the time in milliseconds between two scheduled hellos. On wired links, Babel notices
a link failure within two hello intervals; on wireless links, the link quality value is reestimated at every hello
interval. The default is 4000 ms.
set protocols babel interface <interface> update-interval <milliseconds>
This command specifies the time in milliseconds between two scheduled updates. Since Babel makes extensive
use of triggered updates, this can be set to fairly high values on links with little packet loss. The default is 20000
ms.
set protocols babel interface <interface> rxcost <1-65534>
This command specifies the base receive cost for this interface. For wireless interfaces, it specifies the multiplier
used for computing the ETX reception cost (default 256); for wired interfaces, it specifies the cost that will be
advertised to neighbours.
set protocols babel interface <interface> rtt-decay <1-256>
This command specifies the decay factor for the exponential moving average of RTT samples, in units of 1/256.
Higher values discard old samples faster. The default is 42.
set protocols babel interface <interface> rtt-min <milliseconds>
This command specifies the minimum RTT, in milliseconds, starting from which we increase the cost to a
neighbour. The additional cost is linear in (rtt - rtt-min). The default is 10 ms.
set protocols babel interface <interface> rtt-max <milliseconds>
This command specifies the maximum RTT, in milliseconds, above which we don’t increase the cost to a neigh-
bour. The default is 120 ms.
set protocols babel interface <interface> max-rtt-penalty <milliseconds>
This command specifies the maximum cost added to a neighbour because of RTT, i.e. when the RTT is higher
or equal than rtt-max. The default is 150. Setting it to 0 effectively disables the use of a RTT-based cost.
set protocols babel interface <interface> enable-timestamps
This command enables sending timestamps with each Hello and IHU message in order to compute RTT values.
It is recommended to enable timestamps on tunnel interfaces.
set protocols babel interface <interface> channel <1-254|interfering|noninterfering>
This command set the channel number that diversity routing uses for this interface (see diversity option above).
1-254 – interfaces with a channel number interfere with interfering interfaces and interfaces with the same
channel number. interfering – interfering interfaces are assumed to interfere with all other channels except
noninterfering channels. noninterfering – noninterfering interfaces are assumed to only interfere with them-
selves.
Redistribution Configuration
Configuration Example
Node 2:
8.9.2 BFD
BFD (Bidirectional Forwarding Detection) is described and extended by the following RFCs: RFC 5880, RFC 5881
and RFC 5883.
In the age of very fast networks, a second of unreachability may equal millions of lost packets. The idea behind BFD
is to detect very quickly when a peer is down and take action extremely fast.
BFD sends lots of small UDP packets very quickly to ensures that the peer is still alive.
This allows avoiding the timers defined in BGP and OSPF protocol to expires.
Configure BFD
Operational Commands
BFD Peers:
peer 198.51.100.33 vrf default interface eth4.100
ID: 4182341893
Remote ID: 12678929647
Status: up
Uptime: 1 month(s), 16 hour(s), 29 minute(s), 38 second(s)
Diagnostics: ok
Remote diagnostics: ok
Local timers:
Receive interval: 300ms
Transmission interval: 300ms
Echo transmission interval: 50ms
Remote timers:
Receive interval: 300ms
Transmission interval: 300ms
Echo transmission interval: 0ms
A monitored static route conditions the installation to the RIB on the BFD session running state: when BFD session is
up the route is installed to RIB, but when the BFD session is down it is removed from the RIB.
Configuration
set protocols static route <subnet> next-hop <address> bfd profile <profile>
Configure a static route for <subnet> using gateway <address> and use the gateway address as BFD peer desti-
nation address.
set protocols static route <subnet> next-hop <address> bfd multi-hop source <address>
profile <profile>
Configure a static route for <subnet> using gateway <address> , use source address to indentify the peer when
is multi-hop session and the gateway address as BFD peer destination address.
set protocols static route6 <subnet> next-hop <address> bfd profile <profile>
Configure a static route for <subnet> using gateway <address> and use the gateway address as BFD peer desti-
nation address.
set protocols static route6 <subnet> next-hop <address> bfd multi-hop source <address>
profile <profile>
Configure a static route for <subnet> using gateway <address> , use source address to indentify the peer when
is multi-hop session and the gateway address as BFD peer destination address.
Operational Commands
Next hops:
VRF default IPv4 Unicast:
10.10.13.3/32 peer 192.168.2.3 (status: installed)
172.16.10.3/32 peer 192.168.10.1 (status: uninstalled)
8.9.3 BGP
BGP (Border Gateway Protocol) is one of the Exterior Gateway Protocols and the de facto standard interdomain routing
protocol. The latest BGP version is 4. BGP-4 is described in RFC 1771 and updated by RFC 4271. RFC 2858 adds
multiprotocol support to BGP.
VyOS makes use of FRR (Free Range Routing) and we would like to thank them for their effort!
Basic Concepts
Autonomous Systems
Address Families
Multiprotocol extensions enable BGP to carry routing information for multiple network layer protocols. BGP supports
an Address Family Identifier (AFI) for IPv4 and IPv6.
Route Selection
The route selection process used by FRR’s BGP implementation uses the following decision criterion, starting at the
top of the list and going towards the bottom until one of the factors can be used.
1. Weight check
Prefer higher local weight routes to lower routes.
2. Local preference check
Prefer higher local preference routes to lower.
3. Local route check
Prefer local routes (statics, aggregates, redistributed) to received routes.
4. AS path length check
Prefer shortest hop-count AS_PATHs.
5. Origin check
Prefer the lowest origin type route. That is, prefer IGP origin routes to EGP, to Incomplete routes.
6. MED check
Where routes with a MED were received from the same AS, prefer the route with the lowest MED.
7. External check
Prefer the route received from an external, eBGP peer over routes received from other types of peers.
8. IGP cost check
Prefer the route with the lower IGP cost.
9. Multi-path check
If multi-pathing is enabled, then check whether the routes not yet distinguished in preference may be considered
equal. If bgp bestpath as-path multipath-relax is set, all such routes are considered equal, otherwise
routes received via iBGP with identical AS_PATHs or routes received from eBGP neighbours in the same AS
are considered equal.
10. Already-selected external check
Where both routes were received from eBGP peers, then prefer the route which is already selected. Note that this
check is not applied if bgp bestpath compare-routerid is configured. This check can prevent some cases
of oscillation.
11. Router-ID check
Prefer the route with the lowest router-ID. If the route has an ORIGINATOR_ID attribute, through iBGP reflec-
tion, then that router ID is used, otherwise the router-ID of the peer the route was received from is used.
12. Cluster-List length check
The route with the shortest cluster-list length is used. The cluster-list reflects the iBGP reflection path the route
has taken.
13. Peer address
Prefer the route received from the peer with the higher transport layer address, as a last-resort tie-breaker.
Capability Negotiation
When adding IPv6 routing information exchange feature to BGP. There were some proposals. IETF (Internet Engi-
neering Task Force) IDR (Inter Domain Routing) adopted a proposal called Multiprotocol Extension for BGP. The
specification is described in RFC 2283. The protocol does not define new protocols. It defines new attributes to ex-
isting BGP. When it is used exchanging IPv6 routing information it is called BGP-4+. When it is used for exchanging
multicast routing information it is called MBGP.
bgpd supports Multiprotocol Extension for BGP. So if a remote peer supports the protocol, bgpd can exchange IPv6
and/or multicast routing information.
Traditional BGP did not have the feature to detect a remote peer’s capabilities, e.g. whether it can handle prefix types
other than IPv4 unicast routes. This was a big problem using Multiprotocol Extension for BGP in an operational
network. RFC 2842 adopted a feature called Capability Negotiation. bgpd use this Capability Negotiation to detect
the remote peer’s capabilities. If a peer is only configured as an IPv4 unicast neighbor, bgpd does not send these
Capability Negotiation packets (at least not unless other optional BGP features require capability negotiation).
By default, FRR will bring up peering with minimal common capability for the both sides. For example, if the local
router has unicast and multicast capabilities and the remote router only has unicast capability the local router will
establish the connection with unicast only capability. When there are no common capabilities, FRR sends Unsupported
Capability error and then resets the connection.
Configuration
First of all you must configure BGP router with the ASN. The AS number is an identifier for the autonomous system.
The BGP protocol uses the AS number for detecting whether the BGP connection is internal or external. VyOS does
not have a special command to start the BGP process. The BGP process starts when the first neighbor is configured.
set protocols bgp system-as <asn>
Set local autonomous system number that this router represents. This is a mandatory option!
Peers Configuration
Defining Peers
Capability Negotiation
Peer Parameters
Note: Storage of route updates uses memory. If you enable soft reconfiguration inbound for multiple neighbors,
the amount of memory used can become significant.
Peer Groups
Peer groups are used to help improve scaling by generating the same update information to all members of a peer group.
Note that this means that the routes generated by a member of a peer group will be sent back to that originating peer
with the originator identifier attribute set to indicated the originating peer. All peers not associated with a specific peer
group are treated as belonging to a default peer group, and will share updates.
set protocols bgp peer-group <name>
This command defines a new peer group. You can specify to the group the same parameters that you can specify
for specific neighbors.
Note: If you apply a parameter to an individual neighbor IP address, you override the action defined for a peer
group that includes that IP address.
Note: By default, the BGP prefix is advertised even if it’s not present in the routing table. This behaviour
differs from the implementation of some vendors.
This command specifies an aggregate address and provides that longer-prefixes inside of the aggregate address
are suppressed before sending BGP updates out to peers.
set protocols bgp neighbor <address|interface> address-family <ipv4-unicast|ipv6-unicast>
unsuppress-map <name>
This command applies route-map to selectively unsuppress prefixes suppressed by summarisation.
Redistribution Configuration
General Configuration
Common parameters
This command disables route reflection between route reflector clients. By default, the clients of a
route reflector are not required to be fully meshed and the routes from a client are reflected to other
clients. However, if the clients are fully meshed, route reflection is not required. In this case, use the
no-client-to-client-reflection command to disable client-to-client reflection.
set protocols bgp parameters no-fast-external-failover
Disable immediate session reset if peer’s connected link goes down.
set protocols bgp listen range <prefix> peer-group <name>
This command is useful if one desires to loosen the requirement for BGP to have strictly defined neighbors.
Specifically what is allowed is for the local router to listen to a range of IPv4 or IPv6 addresses defined by a
prefix and to accept BGP open messages. When a TCP connection (and subsequently a BGP open message)
from within this range tries to connect the local router then the local router will respond and connect with the
parameters that are defined within the peer group. One must define a peer-group for each range that is listed. If
no peer-group is defined then an error will keep you from committing the configuration.
set protocols bgp listen limit <number>
This command goes hand in hand with the listen range command to limit the amount of BGP neighbors that are
allowed to connect to the local router. The limit range is 1 to 5000.
set protocols bgp parameters ebgp-requires-policy
This command changes the eBGP behavior of FRR. By default FRR enables RFC 8212 functionality which
affects how eBGP routes are advertised, namely no routes are advertised across eBGP sessions without some
sort of egress route-map/policy in place. In VyOS however we have this RFC functionality disabled by default
so that we can preserve backwards compatibility with older versions of VyOS. With this option one can enable
RFC 8212 functionality to operate.
set protocols bgp parameters labeled-unicast <explicit-null | ipv4-explicit-null |
ipv6-explicit-null>
By default, locally advertised prefixes use the implicit-null label to encode in the outgoing NLRI.
The following command uses the explicit-null label value for all the BGP instances.
Administrative Distance
Note: Routes with a distance of 255 are effectively disabled and not installed into the kernel.
Timers
Route Dampening
When a route fails, a routing update is sent to withdraw the route from the network’s routing tables. When the route is
re-enabled, the change in availability is also advertised. A route that continually fails and returns requires a great deal
of network traffic to update the network about the route’s status.
Route dampening wich described in RFC 2439 enables you to identify routes that repeatedly fail and return. If route
dampening is enabled, an unstable route accumulates penalties each time the route fails and returns. If the accumulated
penalties exceed a threshold, the route is no longer advertised. This is route suppression. Routes that have been
suppressed are re-entered into the routing table only when the amount of their penalty falls below a threshold.
A penalty of 1000 is assessed each time the route fails. When the penalties reach a predefined threshold (suppress-
value), the router stops advertising the route.
Once a route is assessed a penalty, the penalty is decreased by half each time a predefined amount of time elapses (half-
life-time). When the accumulated penalties fall below a predefined threshold (reuse-value), the route is unsuppressed
and added back into the BGP routing table.
No route is suppressed indefinitely. Maximum-suppress-time defines the maximum time a route can be suppressed
before it is re-advertised.
set protocols bgp parameters dampening half-life <minutes>
This command defines the amount of time in minutes after which a penalty is reduced by half. The timer range
is 10 to 45 minutes.
set protocols bgp parameters dampening re-use <seconds>
This command defines the accumulated penalty amount at which the route is re-advertised. The penalty range
is 1 to 20000.
set protocols bgp parameters dampening start-suppress-time <seconds>
This command defines the accumulated penalty amount at which the route is suppressed. The penalty range is
1 to 20000.
set protocols bgp parameters dampening max-suppress-time <seconds>
This command defines the maximum time in minutes that a route is suppressed. The timer range is 1 to 255
minutes.
In order to control and modify routing information that is exchanged between peers you can use route-map, filter-list,
prefix-list, distribute-list.
For inbound updates the order of preference is:
• route-map
• filter-list
• prefix-list, distribute-list
For outbound updates the order of preference is:
• prefix-list, distribute-list
• filter-list
• route-map
Note: The attributes prefix-list and distribute-list are mutually exclusive, and only one com-
mand (distribute-list or prefix-list) can be applied to each inbound or outbound direction for a particular
neighbor.
This command prevents from sending back prefixes learned from the neighbor.
BGP routers connected inside the same AS through BGP belong to an internal BGP session, or IBGP. In order to
prevent routing table loops, IBGP speaker does not advertise IBGP-learned routes to other IBGP speaker (Split Horizon
mechanism). As such, IBGP requires a full mesh of all peers. For large networks, this quickly becomes unscalable.
There are two ways that help us to mitigate the BGPs full-mesh requirement in a network:
• Using BGP route-reflectors
• Using BGP confederation
Introducing route reflectors removes the need for the full-mesh. When you configure a route reflector you have to tell
the router whether the other IBGP router is a client or non-client. A client is an IBGP router that the route reflector
will “reflect” routes to, the non-client is just a regular IBGP neighbor. Route reflectors mechanism is described in RFC
4456 and updated by RFC 7606.
set protocols bgp neighbor <address> address-family <ipv4-unicast|ipv6-unicast>
route-reflector-client
This command specifies the given neighbor as route reflector client.
set protocols bgp parameters cluster-id <id>
This command specifies cluster ID which identifies a collection of route reflectors and their clients, and is used
by route reflectors to avoid looping. By default cluster ID is set to the BGP router id value, but can be set to an
arbitrary 32-bit value.
Confederation Configuration
A BGP confederation divides our AS into sub-ASes to reduce the number of required IBGP peerings. Within a sub-AS
we still require full-mesh IBGP but between these sub-ASes we use something that looks like EBGP but behaves like
IBGP (called confederation BGP). Confederation mechanism is described in RFC 5065
set protocols bgp parameters confederation identifier <asn>
This command specifies a BGP confederation identifier. <asn> is the number of the autonomous system that
internally includes multiple sub-autonomous systems (a confederation).
set protocols bgp parameters confederation peers <nsubasn>
This command sets other confederations <nsubasn> as members of autonomous system specified by
confederation identifier <asn>.
Show
Reset
This command resets BGP connections to the specified peer group. With argument soft this command initiates
a soft reset. If you do not specify the in or out options, both inbound and outbound soft reconfiguration are
triggered.
Examples
IPv4 peering
Node 2:
Don’t forget, the CIDR declared in the network statement MUST exist in your routing table (dynamic or static), the
best way to make sure that is true is creating a static route:
Node 1:
Node 2:
IPv6 peering
Node 2:
Don’t forget, the CIDR declared in the network statement MUST exist in your routing table (dynamic or static), the
best way to make sure that is true is creating a static route:
Node 1:
Node 2:
Route Filtering
Node2:
We could expand on this and also deny link local and multicast in the rule 20 action deny.
8.9.4 Failover
Failover routes are manually configured routes, but they only install to the routing table if the health-check target is
alive. If the target is not alive the route is removed from the routing table until the target becomes available.
Failover Routes
set protocols failover route <subnet> next-hop <address> check target <target-address>
Configure next-hop <address> and <target-address> for an IPv4 static route. Specify the target IPv4 address
for health checking.
set protocols failover route <subnet> next-hop <address> check timeout <timeout>
Timeout in seconds between health target checks.
Range is 1 to 300, default is 10.
set protocols failover route <subnet> next-hop <address> check type <protocol>
Defines protocols for checking ARP, ICMP, TCP
Default is icmp.
set protocols failover route <subnet> next-hop <address> check policy <policy>
Example
One gateway:
set protocols failover route 203.0.113.1/32 next-hop 192.0.2.1 check target '192.0.2.1'
set protocols failover route 203.0.113.1/32 next-hop 192.0.2.1 check timeout '5'
set protocols failover route 203.0.113.1/32 next-hop 192.0.2.1 check type 'icmp'
set protocols failover route 203.0.113.1/32 next-hop 192.0.2.1 interface 'eth0'
set protocols failover route 203.0.113.1/32 next-hop 192.0.2.1 metric '10'
set protocols failover route 203.0.113.1/32 next-hop 192.0.2.1 check target '192.0.2.1'
set protocols failover route 203.0.113.1/32 next-hop 192.0.2.1 check timeout '5'
set protocols failover route 203.0.113.1/32 next-hop 192.0.2.1 check type 'icmp'
set protocols failover route 203.0.113.1/32 next-hop 192.0.2.1 interface 'eth0'
set protocols failover route 203.0.113.1/32 next-hop 192.0.2.1 metric '10'
set protocols failover route 203.0.113.1/32 next-hop 198.51.100.1 check target '198.51.
˓→100.99'
set protocols failover route 203.0.113.1/32 next-hop 198.51.100.1 check timeout '5'
set protocols failover route 203.0.113.1/32 next-hop 198.51.100.1 check type 'icmp'
set protocols failover route 203.0.113.1/32 next-hop 198.51.100.1 interface 'eth2'
set protocols failover route 203.0.113.1/32 next-hop 198.51.100.1 metric '20'
IGMP (Internet Group Management Protocol) proxy sends IGMP host messages on behalf of a connected client. The
configuration must define one, and only one upstream interface, and one or more downstream interfaces.
Configuration
Example
Interface eth1 LAN is behind NAT. In order to subscribe 10.0.0.0/23 subnet multicast which is in eth0 WAN we need
to configure igmp-proxy.
Operation
restart igmp-proxy
Restart the IGMP proxy process.
8.9.6 IS-IS
IS-IS (Intermediate System to Intermediate System) is a link-state interior gateway protocol (IGP) which is described
in ISO10589, RFC 1195, RFC 5308. IS-IS runs the Dijkstra shortest-path first (SPF) algorithm to create a database
of the network’s topology, and from that database to determine the best (that is, lowest cost) path to a destination. The
intermediate systems (the name for routers) exchange topology information with their directly connected neighbors.
IS-IS runs directly on the data link layer (Layer 2). IS-IS addresses are called NETs (Network Entity Titles) and can
be 8 to 20 bytes long, but are generally 10 bytes long. The tree database that is created with IS-IS is similar to the one
that is created with OSPF in that the paths chosen should be similar. Comparisons to OSPF are inevitable and often
are reasonable ones to make in regards to the way a network will respond with either IGP.
General
Configuration
Mandatory Settings
For IS-IS top operate correctly, one must do the equivalent of a Router ID in CLNS. This Router ID is called the NET
(Network Entity Title). This must be unique for each and every router that is operating in IS-IS. It also must not be
duplicated otherwise the same issues that occur within OSPF will occur within IS-IS when it comes to said duplication.
set protocols isis net <network-entity-title>
This command sets network entity title (NET) provided in ISO format.
Here is an example NET value:
49.0001.1921.6800.1002.00
listed here is 192.168.1.2, which if expanded will turn into 192.168.001.002. Then all one has to do
is move the dots to have four numbers instead of three. This gives us 1921.6800.1002.
• NET selector: 00 Must always be 00. This setting indicates “this system” or “local system.”
set protocols isis interface <interface>
This command enables IS-IS on this interface, and allows for adjacency to occur. Note that the name of IS-IS
instance must be the same as the one used to configure the IS-IS process.
This command will enable IGP-LDP synchronization globally for ISIS. This requires for LDP to be functional.
This is described in RFC 5443. By default all interfaces operational in IS-IS are enabled for synchronization.
Loopbacks are exempt.
set protocols isis ldp-sync holddown <seconds>
This command will change the hold down value globally for IGP-LDP synchronization during conver-
gence/interface flap events.
Interface Configuration
Route Redistribution
Timers
Examples
Enable IS-IS
Node 1:
Node 2:
Node 1:
Node 2:
Routes on Node 2:
Node 1:
This gives us IGP-LDP synchronization for all non-loopback interfaces with a holddown timer of zero seconds:
Node 1:
Node 2:
This gives us MPLS segment routing enabled and labels for far end loopbacks:
Here is the routing tables showing the MPLS segment routing label operations:
8.9.7 MPLS
MPLS (Multi-Protocol Label Switching) is a packet forwarding paradigm which differs from regular IP forwarding.
Instead of IP addresses being used to make the decision on finding the exit interface, a router will instead use an exact
match on a 32 bit/4 byte header called the MPLS label. This label is inserted between the ethernet (layer 2) header
and the IP (layer 3) header. One can statically or dynamically assign label allocations, but we will focus on dynamic
allocation of labels using some sort of label distribution protocol (such as the aptly named Label Distribution Protocol
/ LDP, Resource Reservation Protocol / RSVP, or Segment Routing through OSPF/ISIS). These protocols allow for
the creation of a unidirectional/unicast path called a labeled switched path (initialized as LSP) throughout the network
that operates very much like a tunnel through the network. An easy way of thinking about how an MPLS LSP actually
forwards traffic throughout a network is to think of a GRE tunnel. They are not the same in how they operate, but they
are the same in how they handle the tunneled packet. It would be good to think of MPLS as a tunneling technology
that can be used to transport many different types of packets, to aid in traffic engineering by allowing one to specify
paths throughout the network (using RSVP or SR), and to generally allow for easier intra/inter network transport of
data packets.
For more information on how MPLS label switching works, please go visit Wikipedia (MPLS).
Note: MPLS support in VyOS is not finished yet, and therefore its functionality is limited. Currently there is no support
for MPLS enabled VPN services such as L2VPNs and mVPNs. RSVP support is also not present as the underlying
routing stack (FRR) does not implement it. Currently VyOS implements LDP as described in RFC 5036; other LDP
standard are the following ones: RFC 6720, RFC 6667, RFC 5919, RFC 5561, RFC 7552, RFC 4447. Because MPLS
is already available (FRR also supports RFC 3031).
The MPLS architecture does not assume a single protocol to create MPLS paths. VyOS supports the Label Distribution
Protocol (LDP) as implemented by FRR, based on RFC 5036.
LDP (Label Distribution Protocol) is a TCP based MPLS signaling protocol that distributes labels creating MPLS label
switched paths in a dynamic manner. LDP is not a routing protocol, as it relies on other routing protocols for forwarding
decisions. LDP cannot bootstrap itself, and therefore relies on said routing protocols for communication with other
routers that use LDP.
In order to allow for LDP on the local router to exchange label advertisements with other routers, a TCP session will be
established between automatically discovered and statically assigned routers. LDP will try to establish a TCP session to
the transport address of other routers. Therefore for LDP to function properly please make sure the transport address
is shown in the routing table and reachable to traffic at all times.
It is highly recommended to use the same address for both the LDP router-id and the discovery transport address, but
for VyOS MPLS LDP to work both parameters must be explicitly set in the configuration.
Another thing to keep in mind with LDP is that much like BGP, it is a protocol that runs on top of TCP. It however does
not have an ability to do something like a refresh capability like BGPs route refresh capability. Therefore one might
have to reset the neighbor for a capability change or a configuration change to work.
Configuration Options
Use these commands if you would like to set the discovery hello and hold time parameters.
set protocols mpls ldp discovery session-ipv4-holdtime <seconds>
set protocols mpls ldp discovery session-ipv6-holdtime <seconds>
Use this command if you would like to set the TCP session hold time intervals.
set protocols mpls ldp import ipv4 import-filter filter-access-list <access list number>
set protocols mpls ldp import ipv6 import-filter filter-access-list6 <access list number>
Use these commands to control the importing of forwarding equivalence classes (FECs) for LDP from neighbors.
This would be useful for example on only accepting the labeled routes that are needed and not ones that are not
needed, such as accepting loopback interfaces and rejecting all others.
set protocols mpls ldp export ipv4 export-filter filter-access-list <access list number>
set protocols mpls ldp export ipv6 export-filter filter-access-list6 <access list number>
Use these commands to control the exporting of forwarding equivalence classes (FECs) for LDP to neighbors.
This would be useful for example on only announcing the labeled routes that are needed and not ones that are
not needed, such as announcing loopback interfaces and no others.
set protocols mpls ldp export ipv4 explicit-null
set protocols mpls ldp export ipv6 explicit-null
Use this command if you would like for the router to advertise FECs with a label of 0 for explicit null operations.
set protocols mpls ldp allocation ipv4 access-list <access list number>
set protocols mpls ldp allocation ipv6 access-list6 <access list number>
Use this command if you would like to control the local FEC allocations for LDP. A good example would be for
your local router to not allocate a label for everything. Just a label for what it’s useful. A good example would
be just a loopback label.
set protocols mpls ldp parameters cisco-interop-tlv
Use this command to use a Cisco non-compliant format to send and interpret the Dual-Stack capability TLV for
IPv6 LDP communications. This is related to RFC 7552.
set protocols mpls ldp parameters ordered-control
Use this command to use ordered label distribution control mode. FRR by default uses independent label dis-
tribution control mode for label distribution. This is related to RFC 5036.
set protocols mpls ldp parameters transport-prefer-ipv4
Use this command to prefer IPv4 for TCP peer transport connection for LDP when both an IPv4 and IPv6 LDP
address are configured on the same interface.
set protocols mpls ldp targeted-neighbor ipv4 enable
set protocols mpls ldp targeted-neighbor ipv6 enable
Use this command to enable targeted LDP sessions to the local router. The router will then respond to any
sessions that are trying to connect to it that are not a link local type of TCP connection.
set protocols mpls ldp targeted-neighbor ipv4 address <address>
set protocols mpls ldp targeted-neighbor ipv6 address <address>
Use this command to enable the local router to try and connect with a targeted LDP session to another router.
set protocols mpls ldp targeted-neighbor ipv4 hello-holdtime <seconds>
When LDP is working, you will be able to see label information in the outcome of show ip route. Besides that
information, there are also specific show commands for LDP:
Show
Reset
Segment Routing (SR) is a network architecture that is similar to source-routing . In this architecture, the ingress
router adds a list of segments, known as SIDs, to the packet as it enters the network. These segments represent different
portions of the network path that the packet will take.
The SR segments are portions of the network path taken by the packet, and are called SIDs. At each node, the first SID
of the list is read, executed as a forwarding function, and may be popped to let the next node read the next SID of the
list. The SID list completely determines the path where the packet is forwarded.
Segment Routing can be applied to an existing MPLS-based data plane and defines a control plane network architecture.
In MPLS networks, segments are encoded as MPLS labels and are added at the ingress router. These MPLS labels are
then exchanged and populated by Interior Gateway Protocols (IGPs) like IS-IS or OSPF which are running on most
ISPs.
Note: Segment routing defines a control plane network architecture and can be applied to an existing MPLS based
dataplane. In the MPLS networks, segments are encoded as MPLS labels and are imposed at the ingress router. MPLS
labels are exchanged and populated by IGPs like IS-IS.Segment Routing as per RFC8667 for MPLS dataplane. It
supports IPv4, IPv6 and ECMP and has been tested against Cisco & Juniper routers.however,this deployment is still
EXPERIMENTAL for FRR.
IS-IS SR Configuration
Segment routing (SR) is used by the IGP protocols to interconnect network devices, below configuration shows how to
enable SR on IS-IS:
OSPF SR Configuration
Segment routing (SR) is used by the IGP protocols to interconnect network devices, below configuration shows how to
enable SR on OSPF:
set protocols ospf parameters opaque-lsa
Enable the Opaque-LSA capability (rfc2370), necessary to transport label on IGP
set protocols ospf segment-routing global-block high-label-value <label-value>
Set the Segment Routing Global Block i.e. the label range used by MPLS to store label in the MPLS FIB for
Prefix SID. Note that the block size may not exceed 65535.
set protocols ospf segment-routing global-block low-label-value <label-value>
Set the Segment Routing Global Block i.e. the low label range used by MPLS to store label in the MPLS FIB
for Prefix SID. Note that the block size may not exceed 65535.
set protocols ospf segment-routing local-block high-label-value <label-value>
Set the Segment Routing Local Block i.e. the label range used by MPLS to store label in the MPLS FIB for Prefix
SID. Note that the block size may not exceed 65535.Segment Routing Local Block, The negative command
always unsets both.
set protocols ospf segment-routing local-block <low-label-value <label-value>
Set the Segment Routing Local Block i.e. the low label range used by MPLS to store label in the MPLS FIB
for Prefix SID. Note that the block size may not exceed 65535.Segment Routing Local Block, The negative
command always unsets both.
set protocols ospf segment-routing maximum-label-depth <1-16>
Set the Maximum Stack Depth supported by the router. The value depend of the MPLS dataplane.
set protocols ospf segment-routing prefix <address> index value <0-65535>
A segment ID that contains an IP address prefix calculated by an IGP in the service provider core network.
Prefix SIDs are globally unique, this value indentify it
set protocols ospf segment-routing prefix <address> index <no-php-flag | explicit-null|
n-flag-clear>
this option allows to configure prefix-sid on SR. The ‘no-php-flag’ means NO Penultimate Hop Popping that
allows SR node to request to its neighbor to not pop the label. The ‘explicit-null’ flag allows SR node to request
to its neighbor to send IP packet with the EXPLICIT-NULL label. The ‘n-flag-clear’ option can be used to
explicitly clear the Node flag that is set by default for Prefix-SIDs associated to loopback addresses. This option
is necessary to configure Anycast-SIDs.
Configuration Example
we described the configuration SR ISIS / SR OSPF using 2 connected with them to share label information.
Node 1:
Node 2:
This gives us MPLS segment routing enabled and labels for far end loopbacks:
Here is the routing tables showing the MPLS segment routing label operations:
Node 1
Node 2
This gives us MPLS segment routing enabled and labels for far end loopbacks:
Here is the routing tables showing the MPLS segment routing label operations:
Node-1@vyos:~$ show ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
O>* 10.1.1.1/32 [110/1] via 192.168.0.1, eth0, label IPv4 Explicit Null, weight 1,␣
˓→00:03:36
8.9.9 OSPF
OSPF (Open Shortest Path First) is a routing protocol for Internet Protocol (IP) networks. It uses a link state routing
(LSR) algorithm and falls into the group of interior gateway protocols (IGPs), operating within a single autonomous
system (AS). It is defined as OSPF Version 2 in RFC 2328 (1998) for IPv4. Updates for IPv6 are specified as OSPF
Version 3 in RFC 5340 (2008). OSPF supports the CIDR (Classless Inter-Domain Routing) addressing model.
OSPF is a widely used IGP in large enterprise networks.
OSPFv2 (IPv4)
Configuration
General
VyOS does not have a special command to start the OSPF process. The OSPF process starts when the first ospf enabled
interface is configured.
set protocols ospf area <number> network <A.B.C.D/M>
This command specifies the OSPF enabled interface(s). If the interface has an address from defined range then
the command enables OSPF on this interface so router can provide network information to the other ospf routers
via this interface.
This command is also used to enable the OSPF process. The area number can be specified in decimal notation
in the range from 0 to 4294967295. Or it can be specified in dotted decimal notation similar to ip address.
Prefix length in interface must be equal or bigger (i.e. smaller network) than prefix length in network state-
ment. For example statement above doesn’t enable ospf on interface with address 192.168.1.1/23, but it does on
interface with address 192.168.1.129/25.
In some cases it may be more convenient to enable OSPF on a per interface/subnet basis set protocols ospf
interface <interface> area <x.x.x.x | x>
set protocols ospf auto-cost reference-bandwidth <number>
This command sets the reference bandwidth for cost calculations, where bandwidth can be in range from 1 to
4294967, specified in Mbits/s. The default is 100Mbit/s (i.e. a link of bandwidth 100Mbit/s or higher will have
a cost of 1. Cost of lower bandwidth links will be scaled with reference to this cost).
set protocols ospf parameters router-id <rid>
This command sets the router-ID of the OSPF process. The router-ID may be an IP address of the router, but
need not be – it can be any arbitrary 32bit number. However it MUST be unique within the entire OSPF domain
to the OSPF speaker – bad things will happen if multiple OSPF speakers are configured with the same router-ID!
Optional
Note: Routes with a distance of 255 are effectively disabled and not installed into the kernel.
This command selects ABR model. OSPF router supports four ABR models:
cisco – a router will be considered as ABR if it has several configured links to the networks in different areas
one of which is a backbone area. Moreover, the link to the backbone area should be active (working). ibm –
identical to “cisco” model but in this case a backbone area link may not be active. standard – router has several
active links to different areas. shortcut – identical to “standard” but in this model a router is allowed to use a
connected areas topology without involving a backbone area for inter-area connections.
Detailed information about “cisco” and “ibm” models differences can be found in RFC 3509. A “shortcut”
model allows ABR to create routes between areas based on the topology of the areas connected to this router
but not using a backbone area in case if non-backbone route will be cheaper. For more information about
“shortcut” model, see ospf-shortcut-abr-02.txt
set protocols ospf parameters rfc1583-compatibility
RFC 2328, the successor to RFC 1583, suggests according to section G.2 (changes) in section 16.4.1 a change
to the path preference algorithm that prevents possible routing loops that were possible in the old version of
OSPFv2. More specifically it demands that inter-area paths and intra-area backbone path are now of equal
preference but still both preferred to external paths.
This command should NOT be set normally.
set protocols ospf interface <interface> passive [disable]
This command specifies interface as passive. Passive interface advertises its address, but does not run the OSPF
protocol (adjacencies are not formed and hello packets are not generated).
The optional disable option allows to exclude interface from passive state. This command is used if the command
passive-interface default was configured.
set protocols ospf passive-interface default
This command specifies all interfaces as passive by default. Because this command changes the configuration
logic to a default passive; therefore, interfaces where router adjacencies are expected need to be configured with
the passive-interface-exclude command.
set protocols ospf maximum-paths <1-64>
Use this command to control the maximum number of equal cost paths to reach a specific destination. The upper
limit may differ if you change the value of MULTIPATH_NUM during compilation. The default is MULTI-
PATH_NUM (64).
set protocols ospf refresh timers <seconds>
The router automatically updates link-state information with its neighbors. Only an obsolete information is
updated which age has exceeded a specific threshold. This parameter changes a threshold value, which by
default is 1800 seconds (half an hour). The value is applied to the whole OSPF router. The timer range is 10 to
1800.
set protocols ospf timers throttle spf <delay|initial-holdtime|max-holdtime> <seconds>
This command sets the initial delay, the initial-holdtime and the maximum-holdtime between when SPF is
calculated and the event which triggered the calculation. The times are specified in milliseconds and must be in
the range of 0 to 600000 milliseconds. delay sets the initial SPF schedule delay in milliseconds. The default
value is 200 ms. initial-holdtime sets the minimum hold time between two consecutive SPF calculations.
The default value is 1000 ms. max-holdtime sets the maximum wait time between two consecutive SPF
calculations. The default value is 10000 ms.
set protocols ospf ldp-sync
This command will enable IGP-LDP synchronization globally for OSPF. This requires for LDP to be functional.
This is described in RFC 5443. By default all interfaces operational in OSPF are enabled for synchronization.
Loopbacks are exempt.
Note: FRR offers only partial support for some of the routing protocol extensions that are used with MPLS-TE;
it does not support a complete RSVP-TE solution.
Area Configuration
Interface Configuration
This command allows to specify the distribution type for the network connected to this interface:
broadcast – broadcast IP addresses distribution. non-broadcast – address distribution in NBMA networks
topology. point-to-multipoint – address distribution in point-to-multipoint networks. point-to-point – address
distribution in point-to-point networks.
set protocols ospf interface <interface> priority <number>
This command sets Router Priority integer value. The router with the highest priority will be more eligible to
become Designated Router. Setting the value to 0, makes the router ineligible to become Designated Router.
The default value is 1. The interval range is 0 to 255.
set protocols ospf interface <interface> retransmit-interval <number>
This command sets number of seconds for RxmtInterval timer value. This value is used when retransmitting
Database Description and Link State Request packets if acknowledge was not received. The default value is 5
seconds. The interval range is 3 to 65535.
set protocols ospf interface <interface> transmit-delay <number>
This command sets number of seconds for InfTransDelay value. It allows to set and adjust for each interface the
delay interval before starting the synchronizing process of the router’s database with all neighbors. The default
value is 1 seconds. The interval range is 3 to 65535.
set protocols ospf interface <interface> ldp-sync disable
This command disables IGP-LDP sync for this specific interface.
set protocols ospf interface <interface> ldp-sync holddown <seconds>
This command will change the hold down value for IGP-LDP synchronization during convergence/interface flap
events, but for this interface only.
This feature summarises originated external LSAs (Type-5 and Type-7). Summary Route will be originated on-behalf
of all matched external LSAs.
set protocols ospf aggregation timer <seconds>
Configure aggregation delay timer interval.
Summarisation starts only after this delay timer expiry.
set protocols ospf summary-address x.x.x.x/y [tag (1-4294967295)]
This command enable/disables summarisation for the configured address range.
Tag is the optional parameter. If tag configured Summary route will be originated with the configured tag.
set protocols ospf summary-address x.x.x.x/y no-advertise
This command to ensure not advertise the summary lsa for the matched external LSAs.
Graceful Restart
OSPF routing devices normally discover their neighbors dynamically by listening to the broadcast or multicast hello
packets on the network. Because an NBMA network does not support broadcast (or multicast), the device cannot
discover its neighbors dynamically, so you must configure all the neighbors statically.
set protocols ospf neighbor <A.B.C.D>
This command specifies the IP address of the neighboring device.
set protocols ospf neighbor <A.B.C.D> poll-interval <seconds>
This command specifies the length of time, in seconds, before the routing device sends hello packets out of the
interface before it establishes adjacency with a neighbor. The range is 1 to 65535 seconds. The default value is
60 seconds.
set protocols ospf neighbor <A.B.C.D> priority <number>
This command specifies the router priority value of the nonbroadcast neighbor associated with the IP address
specified. The default is 0. This keyword does not apply to point-to-multipoint interfaces.
Redistribution Configuration
LS age: 1213
Options: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x3
Flags: 0x0
LS Type: router-LSA
Link State ID: 10.0.13.1
Advertising Router: 10.0.13.1
LS Seq Number: 80000009
Checksum: 0xd119
Length: 36
Number of Links: 1
Examples
Enable OSPF
Node 1
Node 2
Enable OSPF with route redistribution of the loopback and default originate:
Node 1
Node 2
Node 1:
This gives us IGP-LDP synchronization for all non-loopback interfaces with a holddown timer of zero seconds:
Node 1
Node 2
This gives us MPLS segment routing enabled and labels for far end loopbacks:
Here is the routing tables showing the MPLS segment routing label operations:
O>* 10.1.1.1/32 [110/1] via 192.168.0.1, eth0, label IPv4 Explicit Null, weight 1,␣
˓→00:03:36
OSPFv3 (IPv6)
Configuration
General
VyOS does not have a special command to start the OSPFv3 process. The OSPFv3 process starts when the first ospf
enabled interface is configured.
set protocols ospfv3 interface <interface> area <number>
This command specifies the OSPFv3 enabled interface. This command is also used to enable the OSPF process.
The area number can be specified in decimal notation in the range from 0 to 4294967295. Or it can be specified
in dotted decimal notation similar to ip address.
set protocols ospfv3 parameters router-id <rid>
This command sets the router-ID of the OSPFv3 process. The router-ID may be an IP address of the router,
but need not be – it can be any arbitrary 32bit number. However it MUST be unique within the entire OSPFv3
domain to the OSPFv3 speaker – bad things will happen if multiple OSPFv3 speakers are configured with the
same router-ID!
Optional
Area Configuration
Interface Configuration
Graceful Restart
Redistribution Configuration
Configuration Example
Node 2:
Note: You cannot easily redistribute IPv6 routes via OSPFv3 on a WireGuard interface link. This requires you to
configure link-local addresses manually on the WireGuard interfaces, see T1483.
Node 2
Status
When PIM receives a register packet the source of the packet will be compared to the prefix-list specified, and
if a permit is received normal processing continues. If a deny is returned for the source address of the register
packet a register stop message is sent to the source.
set protocols pim register-suppress-time <n>
Modify the time that pim will register suppress a FHR will send register notifications to the kernel.
set protocols pim rp <address> group <group>
In order to use PIM, it is necessary to configure a RP (Rendezvous Point) for join messages to be sent to.
Currently the only methodology to do this is via static rendezvous point commands.
All routers in the PIM network must agree on these values.
The first ip address is the RP’s address and the second value is the matching prefix of group ranges covered.
set protocols pim rp keep-alive-timer <n>
Modify the time out value for a S,G flow from 1-65535 seconds at RP. The normal keepalive period for the
KAT(S,G) defaults to 210 seconds. However, at the RP, the keepalive period must be at least the Regis-
ter_Suppression_Time, or the RP may time out the (S,G) state before the next Null-Register arrives. Thus,
the KAT(S,G) is set to max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is sent.
If choosing a value below 31 seconds be aware that some hardware platforms cannot see data flowing in better
than 30 second chunks.
See RFC 7761#section-4.1 for details.
set protocols pim no-v6-secondary
When sending PIM hello packets tell PIM to not send any v6 secondary addresses on the interface. This infor-
mation is used to allow PIM to use v6 nexthops in it’s decision for RPF lookup if this option is not set (default).
set protocols pim spt-switchover infinity-and-beyond [prefix-list <list>]
On the last hop router if it is desired to not switch over to the SPT tree configure this command.
Optional parameter prefix-list can be use to control which groups to switch or not switch. If a group is PERMIT
as per the prefix-list, then the SPT switchover does not happen for it and if it is DENY, then the SPT switchover
happens.
set protocols pim ssm prefix-list <list>
Specify a range of group addresses via a prefix-list that forces PIM to never do SSM over.
Example
Router 1
Router 3
Router 2
Basic commands
Tuning commands
Configuration Example
The following configuration explicitly joins multicast group ff15::1234 on interface eth1 and source-specific multicast
group ff15::5678 with source address 2001:db8::1 on interface eth1:
8.9.12 RIP
RIP (Routing Information Protocol) is a widely deployed interior gateway protocol. RIP was developed in the 1970s
at Xerox Labs as part of the XNS routing protocol. RIP is a distance-vector protocol and is based on the Bellman-
Ford algorithms. As a distance-vector protocol, RIP router send updates to its neighbors periodically, thus allowing the
convergence to a known topology. In each update, the distance to any given network will be broadcast to its neighboring
router.
Supported versions of RIP are:
• RIPv1 as described in RFC 1058
• RIPv2 as described in RFC 2453
General Configuration
Optional Configuration
Note: Routes with a distance of 255 are effectively disabled and not installed into the kernel.
Redistribution Configuration
Interfaces Configuration
show ip rip
This command displays RIP routes.
Configuration Example
Node 2:
8.9.13 RPKI
There are two types of Network Admins who deal with BGP, those who have created an international
incident and/or outage, and those who are lying
—tweet by EvilMog, 2020-02-21
RPKI (Resource Public Key Infrastructure) is a framework designed to secure the Internet routing infrastructure. It
associates BGP route announcements with the correct originating ASN which BGP routers can then use to check each
route against the corresponding ROA (Route Origin Authorisation) for validity. RPKI is described in RFC 6480.
A BGP-speaking router like VyOS can retrieve ROA information from RPKI “Relying Party software” (often just
called an “RPKI server” or “RPKI validator”) by using RTR (RPKI to Router) protocol. There are several open source
implementations to choose from, such as NLNetLabs’ Routinator (written in Rust), OpenBSD’s rpki-client (written in
C), and StayRTR (written in Go). The RTR protocol is described in RFC 8210.
Tip: If you are new to these routing security technologies then there is an excellent guide to RPKI by NLnet Labs
which will get you up to speed very quickly. Their documentation explains everything from what RPKI is to deploying
it in production. It also has some help and operational guidance including “What can I do about my route having an
Invalid state?”
Getting started
First you will need to deploy an RPKI validator for your routers to use. NLnet Labs provides a collection of software
you can compare and settle on one. Once your server is running you can start validating announcements.
Imported prefixes during the validation may have values:
valid
The prefix and ASN that originated it match a signed ROA. These are probably trustworthy route
announcements.
invalid
The prefix or prefix length and ASN that originated it doesn’t match any existing ROA. This could
be the result of a prefix hijack, or merely a misconfiguration, but should probably be treated as un-
trustworthy route announcements.
notfound
No ROA exists which covers that prefix. Unfortunately this is the case for about 40%-50% of the
prefixes which were announced to the DFZ (default-free zone) at the start of 2024.
Note: If you are responsible for the global addresses assigned to your network, please make sure that your prefixes
have ROAs associated with them to avoid being notfound by RPKI. For most ASNs this will involve publishing ROAs
via your RIR (Regional Internet Registry) (RIPE NCC, APNIC, ARIN, LACNIC, or AFRINIC), and is something you
are encouraged to do whenever you plan to announce addresses into the DFZ.
Particularly large networks may wish to run their own RPKI certificate authority and publication server instead of
publishing ROAs via their RIR. This is a subject far beyond the scope of VyOS’ documentation. Consider reading
about Krill if this is a rabbit hole you need or especially want to dive down.
Configuration
SSH
Connections to the RPKI caching server can not only be established by TCP using the RTR protocol but you can also
rely on a secure SSH session to the server. This provides transport integrity and confidentiality and it is a good idea
if your validation software supports it. To enable SSH, first you need to create an SSH client keypair using generate
ssh client-key /config/auth/id_rsa_rpki. Once your key is created you can setup the connection.
set protocols rpki cache <address> ssh username <user>
SSH username to establish an SSH connection to the cache server.
set protocols rpki cache <address> ssh private-key-file <filepath>
Local path that includes the private key file of the router.
set protocols rpki cache <address> ssh public-key-file <filepath>
Local path that includes the public key file of the router.
Note: When using SSH, private-key-file and public-key-file are mandatory options.
Example
We can build route-maps for import based on these states. Here is a simple RPKI configuration, where routinator is
the RPKI-validating “cache” server with ip 192.0.2.1:
Here is an example route-map to apply to routes learned at import. In this filter we reject prefixes with the state invalid,
and set a higher local-preference if the prefix is RPKI valid rather than merely notfound.
Once your routers are configured to reject RPKI-invalid prefixes, you can test whether the configuration is working
correctly using Cloudflare’s test website. Keep in mind that in order for this to work, you need to have no default routes
or anything else that would still send traffic to RPKI-invalid destinations.
8.9.14 Static
Static routes are manually configured routes, which, in general, cannot be updated dynamically from information VyOS
learns about the network topology from other routing protocols. However, if a link fails, the router will remove routes,
including static routes, from the RIPB (Routing Information Base) that used this interface to reach the next hop. In
general, static routes should only be used for very simple network topologies, or to override the behavior of a dynamic
routing protocol for a small number of routes. The collection of all routes the router has learned from its configuration
or from its dynamic routing protocols is stored in the RIB. Unicast routes are directly used to determine the forwarding
table used for unicast packet forwarding.
Static Routes
Note: Routes with a distance of 255 are effectively disabled and not installed into the kernel.
Note: Routes with a distance of 255 are effectively disabled and not installed into the kernel.
Interface Routes
Blackhole
TBD
Alternate routing tables are used with policy based routing by utilizing VRF.
8.9.15 ARP
ARP (Address Resolution Protocol) is a communication protocol used for discovering the link layer address, such as
a MAC address, associated with a given internet layer address, typically an IPv4 address. This mapping is a critical
function in the Internet protocol suite. ARP was defined in 1982 by RFC 826 which is Internet Standard STD 37.
In Internet Protocol Version 6 (IPv6) networks, the functionality of ARP is provided by the Neighbor Discovery Protocol
(NDP).
To manipulate or display ARP table entries, the following commands are implemented.
Configure
set protocols static arp interface <interface> address <host> mac <mac>
This will configure a static ARP entry always resolving <address> to <mac> for interface <interface>.
Example:
set protocols static arp interface eth0 address 192.0.2.1 mac 01:23:45:67:89:01
Operation
8.10 Service
Certain vendors use broadcasts to identify their equipment within one ethernet segment. Unfortunately if you split your
network with multiple VLANs you loose the ability of identifying your equipment.
This is where “UDP broadcast relay” comes into play! It will forward received broadcasts to other configured networks.
Every UDP port which will be forward requires one unique ID. Currently we support 99 IDs!
Configuration
Note: You can run the UDP broadcast relay service on multiple routers connected to a subnet. There is NO UDP
broadcast relay packet storm!
Example
To forward all broadcast packets received on UDP port 1900 on eth3, eth4 or eth5 to all other interfaces in this config-
uration.
Configuration synchronization (config sync) is a feature of VyOS that permits synchronization of the configuration of
one VyOS router to another in a network.
The main benefit to configuration synchronization is that it eliminates having to manually replicate configuration
changes made on the primary router to the secondary (replica) router.
The writing of the configuration to the secondary router is performed through the VyOS HTTP API. The user can
specify which portion(s) of the configuration will be synchronized and the mode to use - whether to replace or add.
To prevent issues with divergent configurations between the pair of routers, synchronization is strictly unidirectional
from primary to replica. Both routers should be online and run the same version of VyOS.
Configuration
Example
Known issues
Configuration resynchronization. With the current implementation of service config-sync, the secondary node must be
online.
One of the important features built on top of the Netfilter framework is connection tracking. Connection tracking allows
the kernel to keep track of all logical network connections or sessions, and thereby relate all of the packets which may
make up that connection. NAT relies on this information to translate all related packets in the same way, and iptables
can use this information to act as a stateful firewall.
The connection state however is completely independent of any upper-level state, such as TCP’s or SCTP’s state. Part
of the reason for this is that when merely forwarding packets, i.e. no local delivery, the TCP engine may not necessarily
be invoked at all. Even connectionless-mode transmissions such as UDP, IPsec (AH/ESP), GRE and other tunneling
protocols have, at least, a pseudo connection state. The heuristic for such protocols is often based upon a preset timeout
value for inactivity, after whose expiration a Netfilter connection is dropped.
Each Netfilter connection is uniquely identified by a (layer-3 protocol, source address, destination address, layer-4
protocol, layer-4 key) tuple. The layer-4 key depends on the transport protocol; for TCP/UDP it is the port numbers,
for tunnels it can be their tunnel ID, but otherwise is just zero, as if it were not part of the tuple. To be able to inspect
the TCP port in all cases, packets will be mandatorily defragmented.
It is possible to use either Multicast or Unicast to sync conntrack traffic. Most examples below show Multicast, but
unicast can be specified by using the “peer” keywork after the specified interface, as in the following example:
set service conntrack-sync interface eth0 peer 192.168.0.250
Configuration
Operation
Note: If the table is empty and you have a warning message, it means conntrack is not enabled. To enable con-
ntrack, just create a NAT or a firewall rule. set firewall state-policy established action accept
cache internal:
current active connections: 19606
connections created: 6298470 failed: 0
connections updated: 3786793 failed: 0
connections destroyed: 6278864 failed: 0
cache external:
current active connections: 15771
connections created: 1660193 failed: 0
connections updated: 77204 failed: 0
connections destroyed: 1644422 failed: 0
traffic processed:
0 Bytes 0 Pckts
message tracking:
0 Malformed msgs 263 Lost msgs
Example
On the active router, you should have information in the internal-cache of conntrack-sync. The same current active
connections number should be shown in the external-cache of the standby router
On active router run:
cache internal:
current active connections: 10
connections created: 8517 failed: 0
connections updated: 127 failed: 0
connections destroyed: 8507 failed: 0
cache external:
current active connections: 0
connections created: 0 failed: 0
connections updated: 0 failed: 0
connections destroyed: 0 failed: 0
traffic processed:
0 Bytes 0 Pckts
(continues on next page)
message tracking:
0 Malformed msgs 0 Lost msgs
cache internal:
current active connections: 0
connections created: 0 failed: 0
connections updated: 0 failed: 0
connections destroyed: 0 failed: 0
cache external:
current active connections: 10
connections created: 888 failed: 0
connections updated: 134 failed: 0
connections destroyed: 878 failed: 0
traffic processed:
0 Bytes 0 Pckts
message tracking:
0 Malformed msgs 0 Lost msgs
Starting of with VyOS 1.3 (equuleus) we added support for running VyOS as an Out-of-Band Management device
which provides remote access by means of SSH to directly attached serial interfaces.
Serial interfaces can be any interface which is directly connected to the CPU or chipset (mostly known as a ttyS interface
in Linux) or any other USB to serial converter (Prolific PL2303 or FTDI FT232/FT4232 based chips).
If you happened to use a Cisco NM-16A - Sixteen Port Async Network Module or NM-32A - Thirty-two Port Async
Network Module - this is your VyOS replacement.
For USB port information please refor to: USB.
Configuration
Between computers, the most common configuration used was “8N1”: eight bit characters, with one start bit, one stop
bit, and no parity bit. Thus 10 Baud times are used to send a single character, and so dividing the signalling bit-rate by
ten results in the overall transmission speed in characters per second. This is also the default setting if none of those
options are defined.
set service console-server device <device> data-bits [7 | 8]
Configure either seven or eight data bits. This defaults to eight data bits if left unconfigured.
set service console-server device <device> description <string>
A user friendly description identifying the connected peripheral.
set service console-server device <device> alias <string>
A user friendly alias for this connection. Can be used instead of the device name when connecting.
set service console-server device <device> parity [even | odd | none]
Set the parity option for the console. If unset this will default to none.
set service console-server device <device> stop-bits [1 | 2]
Configure either one or two stop bits. This defaults to one stop bits if left unconfigured.
set service console-server device <device> speed [ 300 | 1200 | 2400 | 4800 | 9600 |
19200 | 38400 | 57600 | 115200 ]
Note: USB to serial converters will handle most of their work in software so you should be carefull with the
selected baudrate as some times they can’t cope with the expected speed.
Remote Access
Each individual configured console-server device can be directly exposed to the outside world. A user can directly
connect via SSH to the configured port.
set service console-server device <device> ssh port <port>
Accept SSH connections for the given <device> on TCP port <port>. After successfull authentication the user
will be directly dropped to the connected serial device.
Hint: Multiple users can connect to the same serial device but only one is allowed to write to the console port.
Operation
vyos-r2 login:
Hint: Multiple users can connect to the same serial device but only one is allowed to write to the console port.
Hint: The sequence ^Ec? translates to: Ctrl+E c ?. To quit the session use: Ctrl+E c .
Hint: If alias is set, it can be used instead of the device when connecting.
If you want your router to forward DHCP requests to an external DHCP server you can configure the system to act as
a DHCP relay agent. The DHCP relay agent works with IPv4 and IPv6 addresses.
All interfaces used for the DHCP relay must be configured. This includes the uplink to the DHCP server.
IPv4 relay
Configuration
Options
Example
Also, for backwards compatibility this configuration, which uses generic interface definition, is still valid:
Operation
IPv6 relay
Configuration
Options
Example
commit
show service dhcpv6-relay
listen-interface eth1 {
}
upstream-interface eth2 {
address 2001:db8::4
}
Operation
VyOS uses Kea DHCP server for both IPv4 and IPv6 address assignment.
IPv4 server
The network topology is declared by shared-network-name and the subnet declarations. The DHCP service can serve
multiple shared networks, with each shared network having 1 or more subnets. Each subnet must be present on an
interface. A range can be declared inside a subnet to define a pool of dynamic addresses. Multiple ranges can be
defined and can contain holes. Static mappings can be set to assign “static” addresses to clients based on their MAC
address.
Configuration
High Availability
VyOS provides High Availability support for DHCP server. DHCP High Availability can act in two different modes:
• Active-active: both DHCP servers will respond to DHCP requests. If mode is not defined, this is the default
behavior.
• Active-passive: only primary server will respond to DHCP requests. If this server goes offline, then secondary
server will take place.
DHCP High Availability must be configured explicitly by the following statements on both servers:
set service dhcp-server high-availability mode [active-active | active-passive]
Define operation mode of High Availability feature. Default value if command is not specified is active-active
set service dhcp-server high-availability source-address <address>
Local IP <address> used when communicating to the HA peer.
set service dhcp-server high-availability remote <address>
Remote peer IP <address> of the second DHCP server in this HA cluster.
set service dhcp-server high-availability name <name>
A generic <name> referencing this sync service.
Note: In order for the primary and the secondary DHCP server to keep their lease tables in sync, they must be
able to reach each other on TCP port 647. If you have firewall rules in effect, adjust them accordingly.
Hint: The dialogue between HA partners is neither encrypted nor authenticated. Since most DHCP servers
exist within an organisation’s own secure Intranet, this would be an unnecessary overhead. However, if you have
DHCP HA peers whose communications traverse insecure networks, then we recommend that you consider the
use of VPN tunneling between them to ensure that the HA partnership is immune to disruption (accidental or
otherwise) via third parties.
Static mappings
You can specify a static DHCP assignment on a per host basis. You will need the MAC address of the station and your
desired IP address. The address must be inside the subnet definition but can be outside of the range statement.
set service dhcp-server shared-network-name <name> subnet <subnet> static-mapping
<description> mac <address>
Create a new DHCP static mapping named <description> which is valid for the host identified by its MAC
<address>.
set service dhcp-server shared-network-name <name> subnet <subnet> static-mapping
<description> duid <identifier>
Create a new DHCP static mapping named <description> which is valid for the host identified by its DHCP
unique identifier (DUID) <identifier>.
set service dhcp-server shared-network-name <name> subnet <subnet> static-mapping
<description> ip-address <address>
Static DHCP IP address assign to host identified by <description>. IP address must be inside the <sub-
net> which is defined but can be outside the dynamic range created with set service dhcp-server
shared-network-name <name> subnet <subnet> range <n>. If no ip-address is specified, an IP from
the dynamic pool is used.
This is useful, for example, in combination with hostfile update.
Example:
• IP address 192.168.1.100 shall be statically mapped to client named client1
Options
Example
High Availability
Primary
Secondary
Operation Mode
Hint: Static mappings aren’t shown. To show all states, use show dhcp server leases state all.
IPv6 server
VyOS also provides DHCPv6 server functionality which is described in this section.
Configuration
A NIS (Network Information Service) domain can be set to be used for DHCPv6 clients.
set service dhcpv6-server shared-network-name <name> subnet <prefix> option
nisplus-domain <domain-name>
The procedure to specify a NIS+ (Network Information Service Plus) domain is similar to the NIS domain one:
set service dhcpv6-server shared-network-name <name> subnet <prefix> option nis-server
<address>
Specify a NIS server address for DHCPv6 clients.
set service dhcpv6-server shared-network-name <name> subnet <prefix> option
nisplus-server <address>
Specify a NIS+ server address for DHCPv6 clients.
set service dhcpv6-server shared-network-name <name> subnet <prefix> option sip-server
<address | fqdn>
Specify a SIP (Session Initiation Protocol) server by IPv6 address of Fully Qualified Domain Name for all
DHCPv6 clients.
set service dhcpv6-server shared-network-name <name> subnet <prefix> option
sntp-server-address <address>
A SNTP server address can be specified for DHCPv6 clients.
Prefix Delegation
To hand out individual prefixes to your clients the following configuration is used:
set service dhcpv6-server shared-network-name <name> subnet <prefix> prefix-delegation
start <address> prefix-length <length>
Hand out prefixes of size <length> to clients in subnet <prefix> when they request for prefix delegation.
set service dhcpv6-server shared-network-name <name> subnet <prefix> prefix-delegation
start <address> stop <address>
Delegate prefixes from the range indicated by the start and stop qualifier.
Address pools
DHCPv6 address pools must be configured for the system to act as a DHCPv6 server. The following example describes
a common scenario.
Example:
• A shared network named NET1 serves subnet 2001:db8::/64
• It is connected to eth1
• DNS server is located at 2001:db8::ffff
• Address pool shall be 2001:db8::100 through 2001:db8::199.
• Lease time will be left at the default value which is 24 hours
Static mappings
In order to map specific IPv6 addresses to specific hosts static mappings can be created. The following example explains
the process.
Example:
• IPv6 address 2001:db8::101 shall be statically mapped
• IPv6 prefix 2001:db8:0:101::/64 shall be statically mapped
• Host specific mapping shall be named client1
Hint: The identifier is the device’s DUID: colon-separated hex list (as used by isc-dhcp option dhcpv6.client-id). If
the device already has a dynamic lease from the DHCPv6 server, its DUID can be found with show service dhcpv6
server leases. The DUID begins at the 5th octet (after the 4th colon) of IAID_DUID.
Operation Mode
Hint: Static mappings aren’t shown. To show all states, use show dhcp server leases state all.
Configuration
VyOS provides DNS infrastructure for small networks. It is designed to be lightweight and have a small footprint,
suitable for resource constrained routers and firewalls. For this we utilize PowerDNS recursor.
The VyOS DNS forwarder does not require an upstream DNS server. It can serve as a full recursive DNS server - but
it can also forward queries to configurable upstream DNS servers. By not configuring any upstream DNS servers you
also avoid being tracked by the provider of your upstream DNS server.
set service dns forwarding system
Forward incoming DNS queries to the DNS servers configured under the system name-server nodes.
set service dns forwarding dhcp <interface>
Interfaces whose DHCP client nameservers to forward requests to.
set service dns forwarding name-server <address> port <port>
Send all DNS queries to the IPv4/IPv6 DNS server specified under <address> on optional port specified under
<port>. The port defaults to 53. You can configure multiple nameservers here.
set service dns forwarding domain <domain-name> name-server <address>
Forward received queries for a particular domain (specified via domain-name) to a given nameserver. Multiple
nameservers can be specified. You can use this feature for a DNS split-horizon configuration.
the AD-bit in the response when the data is validated successfully, or send SERVFAIL when the validation
comes up bogus.
• log-fail In this mode, the recursor will attempt to validate all data it retrieves from authoritative servers,
regardless of the client’s DNSSEC desires, and will log the validation result. This mode can be used to
determine the extra load and amount of possibly bogus answers before turning on full-blown validation.
Responses to client queries are the same as with process.
• validate The highest mode of DNSSEC processing. In this mode, all queries will be validated and will be
answered with a SERVFAIL in case of bogus data, regardless of the client’s request.
Note: The popular Unix/Linux dig tool sets the AD-bit in the query. This might lead to unexpected query
results when testing. Set +noad on the dig command line when this is the case.
Note: The CD-bit is honored correctly for process and validate. For log-fail, failures will be logged too.
Authoritative zones
The VyOS DNS forwarder can also be configured to host authoritative records for a domain.
set service dns forwarding authoritative-domain <domain-name> disable
Disable hosting authoritative zone for <domain-name> without deleting from configuration.
set service dns forwarding authoritative-domain <domain-name> records <type> <name>
disable
Disable specific record without deleting it from configuration.
set service dns forwarding authoritative-domain <domain-name> records <type> <name> ttl
<seconds>
Set the TTL (Time-to-live) for the record in seconds. Default is 300 seconds.
Record types
Below are a list of record types available to be configured within VyOS. Some records support special <name> key-
words:
• @ Use @ as record name to set the record for the root domain.
• any Use any as record name to configure the record as a wildcard.
set service dns forwarding authoritative-domain <domain-name> records a <name> address
<x.x.x.x>
Set an A (Address) record. Supports @ and any keywords.
set service dns forwarding authoritative-domain <domain-name> records aaaa <name> address
<h:h:h:h:h:h:h:h>
Set an AAAA (IPv6 Address) record. Supports @ and any keywords.
set service dns forwarding authoritative-domain <domain-name> records cname <name> target
<target-domain-name>
Set an CNAME (Canonical name) record. Supports @ keyword.
set service dns forwarding authoritative-domain <domain-name> records naptr <name> rule
<rule-number> <option> <value>
Set an NAPTR (Naming authority pointer) record. Supports @ keyword. NAPTR records support the following
options:
• lookup-a A Flag.
• lookup-srv S flag.
• order Rule order. Requires <value>.
• preference Rule preference. Requires <value>. Defaults to 0 if not set.
• protocol-specific P flag.
• regexp Regular expression. Requires <value>.
• replacement Replacement DNS name.
• resolve-uri U flag.
• service Service type. Requires <value>.
Example
A VyOS router with two interfaces - eth0 (WAN) and eth1 (LAN) - is required to implement a split-horizon DNS
configuration for example.com.
In this scenario:
• All DNS requests for example.com must be forwarded to a DNS server at 192.0.2.254 and 2001:db8:cafe::1
• All other DNS requests will be forwarded to a different set of DNS servers at 192.0.2.1, 192.0.2.2, 2001:db8::1:ffff
and 2001:db8::2:ffff
• The VyOS DNS forwarder will only listen for requests on the eth1 (LAN) interface addresses - 192.168.1.254
for IPv4 and 2001:db8::ffff for IPv6
• The VyOS DNS forwarder will only accept lookup requests from the LAN subnets - 192.168.1.0/24 and
2001:db8::/64
• The VyOS DNS forwarder will pass reverse lookups for 10.in-addr.arpa, 168.192.in-addr.arpa, 16-31.172.in-
addr.arpa zones to upstream server.
Operation
VyOS is able to update a remote DNS record when an interface gets a new IP address. In order to do so, VyOS includes
ddclient, a Perl script written for this only one purpose.
ddclient uses two methods to update a DNS record. The first one will send updates directly to the DNS daemon, in
compliance with RFC 2136. The second one involves a third party service, like DynDNS.com or any other such service
provider. This method uses HTTP requests to transmit the new IP address. You can configure both in VyOS.
Configuration
Example
# Resulting config:
#
vyos@vyos# show service dns dynamic
name VyOS-DNS {
address {
interface eth0
}
description "RFC 2136 dynamic dns service"
host-name example.vyos.io
key /config/auth/my.key
protocol nsupdate
server ns1.vyos.io
ttl 300
zone vyos.io
}
Note: You can also keep different DNS zone updated. Just create a new config node: set service dns dynamic
interface <interface> rfc2136 <other-service-name>
VyOS is also able to use any service relying on protocols supported by ddclient.
To use such a service, one must define a login, password, one or multiple hostnames, protocol and server.
set service dns dynamic name <service-name> address interface <interface>
Create new dynamic DNS update configuration which will update the IP address assigned to <interface> on
the service you configured under <service-name>.
set service dns dynamic name <service-name> description <text>
Set description <text> for dynamic DNS service being configured.
set service dns dynamic name <service-name> host-name <hostname>
Setup the dynamic DNS hostname <hostname> associated with the DynDNS provider identified by <service-
name>.
set service dns dynamic name <service-name> username <username>
Configure <username> used when authenticating the update request for DynDNS service identified by
<service-name>.
set service dns dynamic name <service-name> password <password>
Configure <password> used when authenticating the update request for DynDNS service identified by <service-
name>.
set service dns dynamic name <service-name> protocol <protocol>
When a custom DynDNS provider is used, the protocol used for communicating to the provider must be spec-
ified under <protocol>. See the embedded completion helper when entering above command for available
protocols.
set service dns dynamic name <service-name> server <server>
When a custom DynDNS provider is used the <server> where update requests are being sent to must be spec-
ified.
set service dns dynamic name <service-name> ip-version ‘ipv6’
Allow explicit IPv6 address for the interface.
Example:
set service dns dynamic name dedyn description 'deSEC dynamic dns service'
set service dns dynamic name dedyn username 'myusername'
set service dns dynamic name dedyn password 'mypassword'
set service dns dynamic name dedyn host-name 'myhostname.dedyn.io'
set service dns dynamic name dedyn protocol 'dyndns2'
set service dns dynamic name dedyn server 'update.dedyn.io'
set service dns dynamic name dedyn address interface 'eth0'
Note: Multiple services can be used per interface. Just specify as many services per interface as you like!
set service dns dynamic name dedyn description 'deSEC ipv6 dynamic dns service'
set service dns dynamic name dedyn username 'myusername'
set service dns dynamic name dedyn password 'mypassword'
set service dns dynamic name dedyn host-name 'myhostname.dedyn.io'
set service dns dynamic name dedyn protocol 'dyndns2'
set service dns dynamic name dedyn ip-version 'ipv6'
set service dns dynamic name dedyn server 'update6.dedyn.io'
set service dns dynamic name dedyn address interface 'eth0'
By default, ddclient will update a dynamic dns record using the IP address directly attached to the interface. If your
VyOS instance is behind NAT, your record will be updated to point to your internal IP.
ddclient has another way to determine the WAN IP address. This is controlled by:
set service dns dynamic name <service-name> address web <url>
Use configured <url> to determine your IP address. ddclient will load <url> and tries to extract your IP address
from the response.
set service dns dynamic name <service-name> address web skip <pattern>
ddclient will skip any address located before the string set in <pattern>.
Event handler allows you to execute scripts when a string that matches a regex or a regex with a service name appears
in journald logs. You can pass variables, arguments, and a full matching string to the script.
Note: The regular expression matches if and only if the entire string matches the pattern.
Example
#!/usr/bin/env python3
#
# VyOS event-handler script example
from os import environ
import subprocess
from sys import exit
if __name__ == '__main__':
try:
# Run script actions and exit
process_event()
exit(0)
except Exception as err:
# Exit properly in case if something in the script goes wrong
print(f'Error running script: {err}')
exit(1)
VyOS provide an HTTP API. You can use it to execute op-mode commands, update VyOS, set or delete config.
Please take a look at the VyOS API page for an detailed how-to.
Configuration
API
GraphQL
Example Configuration
FastNetMon
FastNetMon is a high-performance DDoS detector/sensor built on top of multiple packet capture engines: NetFlow,
IPFIX, sFlow, AF_PACKET (port mirror). It can detect hosts in the deployed network sending or receiving large
volumes of traffic, packets/bytes/flows per second and perform a configurable action to handle that event, such as
calling a custom script.
VyOS includes the FastNetMon Community Edition.
Configuration
Example
A configuration example can be found in this section. In this simplified scenario, main things to be considered are:
• Network to be protected: 192.0.2.0/24 (public IPs use by customers)
• ban-time and threshold: these values are kept very low in order to easily identify and generate and attack.
• Direction: in and out. Protect public network from external attacks, and identify internal attacks towards internet.
• Interface eth0 used to connect to upstream.
Since we are analyzing attacks to and from our internal network, two types of attacks can be identified, and different
actions are needed:
• External attack: an attack from the internet towards an internal IP is identify. In this case, all connections towards
such IP will be blocked
• Internal attack: an attack from the internal network (generated by a customer) towards the internet is identify. In
this case, all connections from this particular IP/Customer will be blocked.
So, firewall configuration needed for this setup:
#!/bin/bash
VyOS utilizes accel-ppp to provide IPoE (Internet Protocol over Ethernet) server functionality. It can be used with
local authentication (mac-address) or a connected RADIUS server.
IPoE is a method of delivering an IP payload over an Ethernet-based access network or an access network using bridged
Ethernet over Asynchronous Transfer Mode (ATM) without using PPPoE. It directly encapsulates the IP datagrams in
Ethernet frames, using the standard RFC 894 encapsulation.
The use of IPoE addresses the disadvantage that PPP is unsuited for multicast delivery to multiple users. Typically, IPoE
uses Dynamic Host Configuration Protocol and Extensible Authentication Protocol to provide the same functionality
as PPPoE, but in a less robust manner.
Note: Please be aware, due to an upstream bug, config changes/commits will restart the ppp daemon and will reset
existing IPoE sessions, in order to become effective.
IPoE can be configured on different interfaces, it will depend on each specific situation which interface will provide
IPoE to clients. The client’s mac address and the incoming interface is being used as control parameter, to authenticate
a client.
The example configuration below will assign an IP to the client on the incoming interface eth1 with the client mac
address 00:50:79:66:68:00. Other DHCP discovery requests will be ignored, unless the client mac has been enabled in
the configuration.
To enable RADIUS based authentication, the authentication mode needs to be changed within the configuration. Pre-
vious settings like the local users, still exists within the configuration, however they are not used if the mode has been
changed from local to radius. Once changed back to local, it will use all local accounts again.
Note: Some RADIUS severs use an access control list which allows or denies queries, make sure to add your VyOS
router to the allowed client list.
If you are using OSPF as IGP, always the closest interface connected to the RADIUS server is used. With VyOS 1.2
you can bind all outgoing RADIUS requests to a single source IP e.g. the loopback interface.
set service ipoe-server authentication radius source-address <address>
Source IPv4 address used in all RADIUS server queires.
Note: The source-address must be configured on one of VyOS interface. Best practice would be a loopback or
dummy interface.
Note: If you set a custom RADIUS attribute you must define it on both dictionaries at RADIUS server and client.
If the RADIUS server sends the attribute Framed-IP-Address then this IP address will be allocated to the client and
the option default-pool within the CLI config is being ignored.
If the RADIUS server sends the attribute Framed-Pool, IP address will be allocated from a predefined IP pool whose
name equals the attribute value.
If the RADIUS server sends the attribute Stateful-IPv6-Address-Pool, IPv6 address will be allocated from a
predefined IPv6 pool prefix whose name equals the attribute value.
If the RADIUS server sends the attribute Delegated-IPv6-Prefix-Pool, IPv6 delegation pefix will be allocated
from a predefined IPv6 pool delegate whose name equals the attribute value.
User interface can be put to VRF context via RADIUS Access-Accept packet, or change it via RADIUS CoA.
Accel-VRF-Name is used from these purposes. It is custom ACCEL-PPP attribute. Define it in your RADIUS server.
IPv6
Scripting
Advanced Options
set service ipoe-server authentication interface <interface> mac <MAC> vlan <vlan-id>
VLAN monitor for automatic creation of VLAN interfaces for specific user on specific <interface>
set service ipoe-server authentication interface <interface> mac <MAC> rate-limit
download <bandwidth>
Download bandwidth limit in kbit/s for user on interface <interface>.
set service ipoe-server authentication interface <interface> mac <MAC> rate-limit upload
<bandwidth>
Upload bandwidth limit in kbit/s for for user on interface <interface>.
Monitoring
Toubleshooting
˓→ID 192.168.0.1> <Lease-Time 600> <T1 300> <T2 525> <Router 192.168.0.1> <Subnet 255.
˓→255.255.0>]
˓→Classless-Route,Domain-Name,MTU>]
˓→<Lease-Time 600> <T1 300> <T2 525> <Router 192.168.0.1> <Subnet 255.255.255.0>]
8.10.13 LLDP
LLDP (Link Layer Discovery Protocol) is a vendor-neutral link layer protocol in the Internet Protocol Suite used by
network devices for advertising their identity, capabilities, and neighbors on an IEEE 802 local area network, principally
wired Ethernet. The protocol is formally referred to by the IEEE as Station and Media Access Control Connectivity
Discovery specified in IEEE 802.1AB and IEEE 802.3-2012 section 6 clause 79.
LLDP performs functions similar to several proprietary protocols, such as CDP (Cisco Discovery Protocol), FDP
(Foundry Discovery Protocol), NDP (Nortel Discovery Protocol) and LLTD (Link Layer Topology Discovery).
Information gathered with LLDP is stored in the device as a MIB (Management Information Database) and can be
queried with SNMP (Simple Network Management Protocol) as specified in RFC 2922. The topology of an LLDP-
enabled network can be discovered by crawling the hosts and querying this database. Information that may be retrieved
include:
• System Name and Description
• Port name and description
• VLAN name
• IP management address
• System capabilities (switching, routing, etc.)
• MAC/PHY information
• MDI power
• Link aggregation
Configuration
Operation
Starting with VyOS 1.2 a mDNS (Multicast DNS) repeater functionality is provided. Additional information can be
obtained from https://en.wikipedia.org/wiki/Multicast_DNS.
Multicast DNS uses the reserved address 224.0.0.251, which is “administratively scoped” and does not leave the
subnet. mDNS repeater retransmits mDNS packets from one interface to other interfaces. This enables support for
devices using mDNS discovery (like network printers, Apple Airplay, Chromecast, various IP based home-automation
devices etc) across multiple VLANs.
Since the mDNS protocol sends the AA (Authoritative Answer) records in the packet itself, the repeater does not need
to forge the source address. Instead, the source address is of the interface that repeats the packet.
Configuration
Note: You can not run this in a VRRP setup, if multiple mDNS repeaters are launched in a subnet you will experience
the mDNS packet storm death!
Example
To listen on both eth0 and eth1 mDNS packets and also repeat packets received on eth0 to eth1 (and vice-versa) use the
following commands:
To allow only specific services, for example _airplay._tcp or _ipp._tcp, (instead of all services) to be re-
broadcasted, use the following command:
To allow listing additional custom domain, for example openthread.thread.home.arpa, so that it can reflected in
addition to the default local, use the following command:
Operation
8.10.15 Monitoring
Azure-data-explorer
Prometheus-client
Splunk
Telegraf
Monitoring functionality with telegraf and InfluxDB 2 is provided. Telegraf is the open source server agent to
help you collect metrics, events and logs from your routers.
set service monitoring telegraf influxdb authentication organization <organization>
Authentication organization name
set service monitoring telegraf influxdb authentication token <token>
Authentication token
set service monitoring telegraf bucket <bucket>
Remote InfluxDB bucket name
set service monitoring telegraf influxdb port <port>
Remote port
set service monitoring telegraf influxdb url <url>
Remote URL
Loki
Example
8.10.16 NTP
NTP (Network Time Protocol) is a networking protocol for clock synchronization between computer systems over
packet-switched, variable-latency data networks. In operation since before 1985, NTP is one of the oldest Internet
protocols in current use.
NTP is intended to synchronize all participating computers to within a few milliseconds of UTC (Coordinated Universal
Time). It uses the intersection algorithm, a modified version of Marzullo’s algorithm, to select accurate time servers
and is designed to mitigate the effects of variable network latency. NTP can usually maintain time to within tens of
milliseconds over the public Internet, and can achieve better than one millisecond accuracy in local area networks under
ideal conditions. Asymmetric routes and network congestion can cause errors of 100 ms or more.
The protocol is usually described in terms of a client-server model, but can as easily be used in peer-to-peer relationships
where both peers consider the other to be a potential time source. Implementations send and receive timestamps using
UDP (User Datagram Protocol) on port number 123.
NTP supplies a warning of any impending leap second adjustment, but no information about local time zones or daylight
saving time is transmitted.
The current protocol is version 4 (NTPv4), which is a proposed standard as documented in RFC 5905. It is backward
compatible with version 3, specified in RFC 1305.
Note: VyOS 1.4 uses chrony instead of ntpd (see T3008) which will no longer accept anonymous NTP requests as in
VyOS 1.3. All configurations will be migrated to keep the anonymous functionality. For new setups if you have clients
using your VyOS installation as NTP server, you must specify the allow-client directive.
Configuration
• nts enables Network Time Security (NTS) for the server as specified in RFC 8915
• pool mobilizes persistent client mode association with a number of remote servers.
• prefer marks the server as preferred. All other things being equal, this host will be chosen for synchro-
nization among a set of correctly operating hosts.
set service ntp listen-address <address>
NTP process will only listen on the specified IP address. You must specify the <address> and optionally the
permitted clients. Multiple listen addresses can be configured.
set service ntp allow-client address <address>
List of networks or client addresses permitted to contact this NTP server.
Multiple networks/client IP addresses can be configured.
set service ntp vrf <name>
Specify name of the VRF (Virtual Routing and Forwarding) instance.
set service ntp leap-second [ignore|smear|system|timezone]
Define how to handle leap-seconds.
• ignore: No correction is applied to the clock for the leap second. The clock will be corrected later in normal
operation when new measurements are made and the estimated offset includes the one second error.
• smear: When smearing a leap second, the leap status is suppressed on the server and the served time is
corrected slowly by slewing instead of stepping. The clients do not need any special configuration as they
do not know there is any leap second and they follow the server time which eventually brings them back to
UTC. Care must be taken to ensure they use only NTP servers which smear the leap second in exactly the
same way for synchronisation.
• system: When inserting a leap second, the kernel steps the system clock backwards by one second when the
clock gets to 00:00:00 UTC. When deleting a leap second, it steps forward by one second when the clock
gets to 23:59:59 UTC.
• timezone: This directive specifies a timezone in the system timezone database which chronyd can use to
determine when will the next leap second occur and what is the current offset between TAI and UTC. It
will periodically check if 23:59:59 and 23:59:60 are valid times in the timezone. This normally works with
the right/UTC timezone which is the default
VyOS utilizes accel-ppp to provide PPPoE server functionality. It can be used with local authentication or a connected
RADIUS server.
Note: Please be aware, due to an upstream bug, config changes/commits will restart the ppp daemon and will reset
existing PPPoE connections from connected users, in order to become effective.
To enable RADIUS based authentication, the authentication mode needs to be changed within the configuration. Pre-
vious settings like the local users, still exists within the configuration, however they are not used if the mode has been
changed from local to radius. Once changed back to local, it will use all local accounts again.
Note: Some RADIUS severs use an access control list which allows or denies queries, make sure to add your VyOS
router to the allowed client list.
If you are using OSPF as IGP, always the closest interface connected to the RADIUS server is used. With VyOS 1.2
you can bind all outgoing RADIUS requests to a single source IP e.g. the loopback interface.
set service pppoe-server authentication radius source-address <address>
Source IPv4 address used in all RADIUS server queires.
Note: The source-address must be configured on one of VyOS interface. Best practice would be a loopback or
dummy interface.
Value to send to RADIUS server in NAS-Identifier attribute and to be matched in DM/CoA requests.
set service pppoe-server authentication radius nas-ip-address <address>
Value to send to RADIUS server in NAS-IP-Address attribute and to be matched in DM/CoA requests. Also
DM/CoA server will bind to that address.
set service pppoe-server authentication radius source-address <address>
Source IPv4 address used in all RADIUS server queires.
set service pppoe-server authentication radius rate-limit attribute <attribute>
Specifies which RADIUS server attribute contains the rate limit information. The default attribute is
Filter-Id.
Note: If you set a custom RADIUS attribute you must define it on both dictionaries at RADIUS server and client.
If the RADIUS server sends the attribute Framed-IP-Address then this IP address will be allocated to the client and
the option default-pool within the CLI config is being ignored.
If the RADIUS server sends the attribute Framed-Pool, IP address will be allocated from a predefined IP pool whose
name equals the attribute value.
If the RADIUS server sends the attribute Stateful-IPv6-Address-Pool, IPv6 address will be allocated from a
predefined IPv6 pool prefix whose name equals the attribute value.
If the RADIUS server sends the attribute Delegated-IPv6-Prefix-Pool, IPv6 delegation pefix will be allocated
from a predefined IPv6 pool delegate whose name equals the attribute value.
User interface can be put to VRF context via RADIUS Access-Accept packet, or change it via RADIUS CoA.
Accel-VRF-Name is used from these purposes. It is custom ACCEL-PPP attribute. Define it in your RADIUS server.
If the RADIUS server uses the attribute NAS-Port-Id, ppp tunnels will be renamed.
Note: The value of the attribute NAS-Port-Id must be less than 16 characters, otherwise the interface won’t be
renamed.
Bandwidth Shaping
Bandwidth rate limits can be set for local users or RADIUS based attributes.
set service pppoe-server authentication local-users username foo rate-limit upload '10240
˓→'
Once the user is connected, the user session is using the set limits and can be displayed via show pppoe-server
sessions.
-------+----------+------------+-------------------+-------------+--------+----------+---
˓→-------+----------
The current attribute Filter-Id is being used as default and can be setup within RADIUS:
Filter-Id=2000/3000 (means 2000Kbit down-stream rate and 3000Kbit up-stream rate)
The command below enables it, assuming the RADIUS connection has been setup and is working.
set service pppoe-server authentication radius rate-limit enable
Use this command to enable bandwidth shaping via RADIUS.
Other attributes can be used, but they have to be in one of the dictionaries in /usr/share/accel-ppp/radius.
Load Balancing
In the example above, the first 499 sessions connect without delay. PADO packets will be delayed 50 ms for connection
from 500 to 999, this trick allows other PPPoE servers send PADO faster and clients will connect to other servers. Last
command says that this PPPoE server can serve only 3000 clients.
IPv6
Use this comand to set the IPv6 address pool from which an PPPoE client will get an IPv6 prefix of your defined
length (mask) to terminate the PPPoE endpoint at their side. The mask length can be set from 48 to 128 bit long,
the default value is 64.
set service pppoe-server client-ipv6-pool <IPv6-POOL-NAME> delegate <address>
delegation-prefix <number-of-bits>
Use this command to configure DHCPv6 Prefix Delegation (RFC3633) on PPPoE. You will have to set your
IPv6 pool and the length of the delegation prefix. From the defined IPv6 pool you will be handing out networks
of the defined length (delegation-prefix). The length of the delegation prefix can be set from 32 to 64 bit long.
set service pppoe-server default-ipv6-pool <IPv6-POOL-NAME>
Use this command to define default IPv6 address pool name.
Scripting
Advanced Options
Specifies timeout in seconds to wait for any peer activity. If this option specified it turns on adaptive lcp echo
functionality and “lcp-echo-failure” is not used. Default value is 0.
set service pppoe-server ppp-options min-mtu <number>
Defines minimum acceptable MTU. If client will try to negotiate less then specified MTU then it will be NAKed
or disconnected if rejects greater MTU. Default value is 100.
set service pppoe-server ppp-options mppe <require | prefer | deny>
Specifies MPPE (Microsoft Point-to-Point Encryption) negotiation preference.
• require - ask client for mppe, if it rejects drop connection
• prefer - ask client for mppe, if it rejects don’t fail. (Default value)
• deny - deny mppe
Default behavior - don’t ask client for mppe, but allow it if client wants. Please note that RADIUS may override
this option by MS-MPPE-Encryption-Policy attribute.
set service pppoe-server ppp-options mru <number>
Defines preferred MRU. By default is not defined.
Monitoring
-------+----------+------------+-------------------+-------------+--------+----------+---
˓→-------+----------
Examples
IPv4
The example below uses ACN as access-concentrator name, assigns an address from the pool 10.1.1.100-111, termi-
nates at the local endpoint 10.1.1.1 and serves requests only on eth1.
The client, once successfully authenticated, will receive an IPv4 and an IPv6 /64 address to terminate the PPPoE
endpoint on the client side and a /56 subnet for the clients internal use.
RAs (Router advertisements) are described in RFC 4861#section-4.6.2. They are part of what is known as SLAAC.
Supported interface types:
• bonding
• bridge
• ethernet
• geneve
• l2tpv3
• openvpn
• pseudo-ethernet
• tunnel
• vxlan
• wireguard
• wireless
• wwan
Configuration
Advertising a Prefix
Note: You can also opt for using ::/64 as prefix for your RAs. This will take the IPv6 GUA prefix assigned to
the interface, which comes in handy when using DHCPv6-PD.
Disabling Advertisements
Example
Your LAN connected on eth0 uses prefix 2001:db8:beef:2::/64 with the router beeing 2001:db8:beef:2::1
8.10.19 Salt-Minion
SaltStack is Python-based, open-source software for event-driven IT automation, remote task execution, and configura-
tion management. Supporting the “infrastructure as code” approach to data center system and network deployment and
management, configuration automation, SecOps orchestration, vulnerability remediation, and hybrid cloud control.
Requirements
To use the Salt-Minion, a running Salt-Master is required. You can find more in the Salt Project Documentation
Configuration
8.10.20 SNMP
SNMP is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks
and for modifying that information to change device behavior. Devices that typically support SNMP include cable
modems, routers, switches, servers, workstations, printers, and more.
SNMP is widely used in network management for network monitoring. SNMP exposes management data in the form
of variables on the managed systems organized in a management information base (MIB) which describe the system
status and configuration. These variables can then be remotely queried (and, in some circumstances, manipulated) by
managing applications.
Three significant versions of SNMP have been developed and deployed. SNMPv1 is the original version of the protocol.
More recent versions, SNMPv2c and SNMPv3, feature improvements in performance, flexibility and security.
SNMP is a component of the Internet Protocol Suite as defined by the Internet Engineering Task Force (IETF). It
consists of a set of standards for network management, including an application layer protocol, a database schema, and
a set of data objects.
In typical uses of SNMP, one or more administrative computers called managers have the task of monitoring or man-
aging a group of hosts or devices on a computer network. Each managed system executes a software component called
an agent which reports information via SNMP to the manager.
An SNMP-managed network consists of three key components:
• Managed devices
• Agent - software which runs on managed devices
• Network management station (NMS) - software which runs on the manager
A managed device is a network node that implements an SNMP interface that allows unidirectional (read-only) or bidi-
rectional (read and write) access to node-specific information. Managed devices exchange node-specific information
with the NMSs. Sometimes called network elements, the managed devices can be any type of device, including, but not
limited to, routers, access servers, switches, cable modems, bridges, hubs, IP telephones, IP video cameras, computer
hosts, and printers.
An agent is a network-management software module that resides on a managed device. An agent has local knowledge
of management information and translates that information to or from an SNMP-specific form.
A network management station executes applications that monitor and control managed devices. NMSs provide the
bulk of the processing and memory resources required for network management. One or more NMSs may exist on any
managed network.
VyOS itself supports SNMPv2 (version 2) and SNMPv3 (version 3) where the later is recommended because of im-
proved security (optional authentication and encryption).
SNMPv2
SNMPv2 is the original and most commonly used version. For authorizing clients, SNMP uses the concept of commu-
nities. Communities may have authorization set to read only (this is most common) or to read and write (this option is
not actively used in VyOS).
SNMP can work synchronously or asynchronously. In synchronous communication, the monitoring system queries the
router periodically. In asynchronous, the router sends notification to the “trap” (the monitoring host).
SNMPv2 does not support any authentication mechanisms, other than client source address, so you should specify
addresses of clients allowed to monitor the router. Note that SNMPv2 also supports no encryption and always sends
data in plain text.
Example
# Define a community
set service snmp community routers authorization ro
SNMPv3
SNMPv3 (version 3 of the SNMP protocol) introduced a whole slew of new security related features that have been
missing from the previous versions. Security was one of the biggest weakness of SNMP until v3. Authentication in
SNMP Versions 1 and 2 amounts to nothing more than a password (community string) sent in clear text between a
manager and agent. Each SNMPv3 message contains security parameters which are encoded as an octet string. The
meaning of these security parameters depends on the security model being used.
The security approach in SNMPv3 targets:
• Confidentiality – Encryption of packets to prevent snooping by an unauthorized source.
• Integrity – Message integrity to ensure that a packet has not been tampered while in transit including an optional
packet replay protection mechanism.
• Authentication – to verify that the message is from a valid source.
Example
After commit the plaintext passwords will be hashed and stored in your configuration. The resulting CLI config will
look like:
You can test the SNMPv3 functionality from any linux based system, just run the following command: snmpwalk -v
3 -u vyos -a SHA -A vyos12345678 -x AES -X vyos12345678 -l authPriv 192.0.2.1 .1
VyOS MIBs
All SNMP MIBs are located in each image of VyOS here: /usr/share/snmp/mibs/
You are be able to download the files using SCP, once the SSH service has been activated like so
SNMP Extensions
To extend SNMP agent functionality, custom scripts can be executed every time the agent is being called. This can be
achieved by using arbitrary extensioncommands. The first step is to create a functional script of course, then up-
load it to your VyOS instance via the command scp your_script.sh vyos@your_router:/config/user-data.
Once the script is uploaded, it needs to be configured via the command below.
The OID .1.3.6.1.4.1.8072.1.3.2.3.1.1.4.116.101.115.116, once called, will contain the output of the ex-
tension.
SolarWinds
If you happen to use SolarWinds Orion as NMS you can also use the Device Templates Management. A template for
VyOS can be easily imported.
Create a file named VyOS-1.3.6.1.4.1.44641.ConfigMgmt-Commands using the following content:
8.10.21 SSH
SSH (Secure Shell) is a cryptographic network protocol for operating network services securely over an unsecured
network. The standard TCP port for SSH is 22. The best known example application is for remote login to computer
systems by users.
SSH provides a secure channel over an unsecured network in a client-server architecture, connecting an SSH client
application with an SSH server. Common applications include remote command-line login and remote command
execution, but any network service can be secured with SSH. The protocol specification distinguishes between two
major versions, referred to as SSH-1 and SSH-2.
The most visible application of the protocol is for access to shell accounts on Unix-like operating systems, but it sees
some limited use on Windows as well. In 2015, Microsoft announced that they would include native support for SSH
in a future release.
SSH was designed as a replacement for Telnet and for unsecured remote shell protocols such as the Berkeley rlogin, rsh,
and rexec protocols. Those protocols send information, notably passwords, in plaintext, rendering them susceptible to
interception and disclosure using packet analysis. The encryption used by SSH is intended to provide confidentiality
and integrity of data over an unsecured network, such as the Internet.
Note: VyOS 1.1 supported login as user root. This has been removed due to tighter security in VyOS 1.2.
See also:
SSH Key Based Authentication
Configuration
Dynamic-protection
Protects host from brute-force attacks against SSH. Log messages are parsed, line-by-line, for recognized patterns. If
an attack, such as several login failures within a few seconds, is detected, the offending IP is blocked. Offenders are
unblocked after a set interval.
set service ssh dynamic-protection
Allow ssh dynamic-protection.
set service ssh dynamic-protection allow-from <address | prefix>
Whitelist of addresses and networks. Always allow inbound connections from these systems.
set service ssh dynamic-protection block-time <sec>
Block source IP in seconds. Subsequent blocks increase by a factor of 1.5 The default is 120.
set service ssh dynamic-protection detect-time <sec>
Remember source IP in seconds before reset their score. The default is 1800.
set service ssh dynamic-protection threshold <sec>
Block source IP when their cumulative attack score exceeds threshold. The default is 30.
Operation
restart ssh
Restart the SSH daemon process, the current session is not affected, only the background daemon is restarted.
generate ssh server-key
Re-generated the public/private keyportion which SSH uses to secure connections.
Note: Already learned known_hosts files of clients need an update as the public key will change.
set system login user alyssa authentication public-keys [email protected] type ssh-
˓→rsa
commit
(continues on next page)
TFTP (Trivial File Transfer Protocol) is a simple, lockstep file transfer protocol which allows a client to get a file from
or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a local area network.
TFTP has been used for this application because it is very simple to implement.
Configuration
Hint: Choose your directory location carefully or you will loose the content on image upgrades. Any directory
under /config is save at this will be migrated.
Configure the IPv4 or IPv6 listen address of the TFTP server. Multiple IPv4 and IPv6 addresses can be given.
There will be one TFTP server instances listening on each IP address.
set service tftp-server listen-address <address> vrf <name>
Additional option to run TFTP server in the VRF context
Example
Provide TFTP server listening on both IPv4 and IPv6 addresses 192.0.2.1 and 2001:db8::1 serving the content
from /config/tftpboot. Uploading via TFTP to this server is disabled.
The resulting configuration will look like:
Verification
Client:
Server:
8.10.23 Webproxy
The proxy service in VyOS is based on Squid and some related modules.
Squid is a caching and forwarding HTTP web proxy. It has a wide variety of uses, including speeding up a web server
by caching repeated requests, caching web, DNS and other computer network lookups for a group of people sharing
network resources, and aiding security by filtering traffic. Although primarily used for HTTP and FTP, Squid includes
limited support for several other protocols including Internet Gopher, SSL,[6] TLS and HTTPS. Squid does not support
the SOCKS protocol.
URL Filtering is provided by SquidGuard.
Configuration
Non-transparent proxying requires that the client browsers be configured with the proxy settings before requests
are redirected. The advantage of this is that the client web browser can detect that a proxy is in use and can
behave accordingly. In addition, web-transmitted malware can sometimes be blocked by a non-transparent web
proxy, since they are not aware of the proxy settings.
Authentication
The embedded Squid proxy can use LDAP to authenticate users against a company wide directory. The following
configuration is an example of how to use Active Directory as authentication backend. Queries are done via LDAP.
set service webproxy authentication children <number>
Maximum number of authenticator processes to spawn. If you start too few Squid will have to wait for them
to process a backlog of credential verifications, slowing it down. When password verifications are done via a
(slow) network you are likely to need lots of authenticator processes.
This defaults to 5.
LDAP
Note: This can only be done if all your users are located directly under the same position in the LDAP tree
and the login name is used for naming each user object. If your LDAP tree does not match these criterias
or if you want to filter who are valid users then you need to use a search filter to search for your users DN
(filter-expression).
URL filtering
Operation
Filtering
Update
If you want to use existing blacklists you have to create/download a database first. Otherwise you will not be able to
commit the config changes.
update webproxy blacklists
Download/Update complete blacklist
Some services don’t work correctly when being handled via a web proxy. So sometimes it is useful to bypass a trans-
parent proxy:
• To bypass the proxy for every request that is directed to a specific destination:
set service webproxy whitelist destination-address 198.51.100.33
set service webproxy whitelist destination-address 192.0.2.0/24
• To bypass the proxy for every request that is coming from a specific source:
set service webproxy whitelist source-address 192.168.1.2
set service webproxy whitelist source-address 192.168.2.0/24
(This can be useful when a called service has many and/or often changing destination addresses - e.g. Netflix.)
Examples
8.11 System
8.11.1 Acceleration
In this command tree, all hardware acceleration options will be handled. At the moment only Intel® QAT is supported
Intel® QAT
if there is non device the command will show `No QAT device found`
set system acceleration qat
if there is a supported device, enable Intel® QAT
show system acceleration qat status
Check if the Intel® QAT device is up and ready to do the job.
Operation Mode
Example
Side B:
with set system acceleration qat on both systems the bandwidth increases.
8.11.2 Conntrack
VyOS can be configured to track connections using the connection tracking subsystem. Connection tracking becomes
operational once either stateful firewall or NAT is configured.
Configure
Contrack Timeouts
You can define custom timeout values to apply to a specific subset of connections, based on a packet and flow selector.
To do this, you need to create a rule defining the packet and flow selector.
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> description <test>
Set a rule description.
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> destination address
<ip-address>
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> source address
<ip-address>
Set a destination and/or source address. Accepted input for ipv4:
Possible completions:
<x.x.x.x> IPv4 address to match
<x.x.x.x/x> IPv4 prefix to match
<x.x.x.x>-<x.x.x.x> IPv4 address range to match
!<x.x.x.x> Match everything except the specified address
!<x.x.x.x/x> Match everything except the specified prefix
!<x.x.x.x>-<x.x.x.x> Match everything except the specified range
Possible completions:
<h:h:h:h:h:h:h:h> IP address to match
<h:h:h:h:h:h:h:h/x> Subnet to match
<h:h:h:h:h:h:h:h>-<h:h:h:h:h:h:h:h>
IP range to match
!<h:h:h:h:h:h:h:h> Match everything except the specified address
!<h:h:h:h:h:h:h:h/x> Match everything except the specified prefix
!<h:h:h:h:h:h:h:h>-<h:h:h:h:h:h:h:h>
Match everything except the specified range
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> destination port
<value>
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> source port <value>
Set a destination and/or source port. Accepted input:
Multiple destination ports can be specified as a comma-separated list. The whole list can also be
“negated” using ‘!’. For example: !22,telnet,http,123,1001-1005`
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> protocol tcp close
<1-21474836>
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> protocol tcp close-wait
<1-21474836>
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> protocol tcp
established <1-21474836>
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> protocol tcp fin-wait
<1-21474836>
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> protocol tcp last-ack
<1-21474836>
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> protocol tcp syn-recv
<1-21474836>
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> protocol tcp syn-sent
<1-21474836>
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> protocol tcp time-wait
<1-21474836>
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> protocol udp replied
<1-21474836>
set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999> protocol udp unreplied
<1-21474836>
Set the timeout in seconds for a protocol or state in a custom rule.
Note: Important note about conntrack ignore rules: Starting from vyos-1.5-rolling-202406120020, ignore rules
can be defined in set firewall [ipv4 | ipv6] prerouting raw .... It’s expected that in the future the con-
ntrack ignore rules will be removed.
Customized ignore rules, based on a packet and flow selector.
set system conntrack ignore [ipv4 | ipv6] rule <1-999999> description <text>
set system conntrack ignore [ipv4 | ipv6] rule <1-999999> destination address
<ip-address>
set system conntrack ignore [ipv4 | ipv6] rule <1-999999> destination port <port>
set system conntrack ignore [ipv4 | ipv6] rule <1-999999> inbound-interface <interface>
set system conntrack ignore [ipv4 | ipv6] rule <1-999999> protocol <protocol>
set system conntrack ignore [ipv4 | ipv6] rule <1-999999> source address <ip-address>
set system conntrack ignore [ipv4 | ipv6] rule <1-999999> source port <port>
set system conntrack ignore [ipv4 | ipv6] rule <1-999999> tcp flags [not] <text>
Allowed values fpr TCP flags: ack, cwr, ecn, fin, psh, rst, syn and urg. Multiple values are supported, and
for inverted selection use not, as shown in the example.
Conntrack log
For the average user a serial console has no advantage over a console offered by a directly attached keyboard and screen.
Serial consoles are much slower, taking up to a second to fill a 80 column by 24 line screen. Serial consoles generally
only support non-proportional ASCII text, with limited support for languages other than English.
There are some scenarios where serial consoles are useful. System administration of remote computers is usually done
using SSH, but there are times when access to the console is the only way to diagnose and correct software failures.
Major upgrades to the installed distribution may also require console access.
set system console device <device>
Defines the specified device as a system console. Available console devices can be (see completion helper):
• ttySN - Serial device name
• ttyUSBX - USB Serial device name
• hvc0 - Xen console
Note: If you use USB to serial converters for connecting to your VyOS appliance please note that most of them
use software emulation without flow control. This means you should start with a common baud rate (most likely
9600 baud) as otherwise you probably can not connect to the device using high speed baud rates as your serial
converter simply can not process this data rate.
VyOS supports flow-accounting for both IPv4 and IPv6 traffic. The system acts as a flow exporter, and you are free to
use it with any compatible collector.
Flows can be exported via two different protocols: NetFlow (versions 5, 9 and 10/IPFIX) and sFlow. Additionally, you
may save flows to an in-memory table internally in a router.
Warning: You need to disable the in-memory table in production environments! Using IMT (In-Memory Table)
may lead to heavy CPU overloading and unstable flow-accounting behavior.
NetFlow / IPFIX
NetFlow is a feature that was introduced on Cisco routers around 1996 that provides the ability to collect IP network
traffic as it enters or exits an interface. By analyzing the data provided by NetFlow, a network administrator can
determine things such as the source and destination of traffic, class of service, and the causes of congestion. A typical
flow monitoring setup (using NetFlow) consists of three main components:
• exporter: aggregates packets into flows and exports flow records towards one or more flow collectors
• collector: responsible for reception, storage and pre-processing of flow data received from a flow exporter
• application: analyzes received flow data in the context of intrusion detection or traffic profiling, for example
For connectionless protocols as like ICMP and UDP, a flow is considered complete once no more packets for this flow
appear after configurable timeout.
NetFlow is usually enabled on a per-interface basis to limit load on the router components involved in NetFlow, or to
limit the amount of NetFlow records exported.
Configuration
In order for flow accounting information to be collected and displayed for an interface, the interface must be configured
for flow accounting.
set system flow-accounting interface <interface>
Configure and enable collection of flow information for the interface identified by <interface>.
You can configure multiple interfaces which would participate in flow accounting.
Note: Will be recorded only packets/flows on incoming direction in configured interfaces by default.
By default, recorded flows will be saved internally and can be listed with the CLI command. You may disable using
the local in-memory table with the command:
set system flow-accounting disable-imt
If you need to sample also egress traffic, you may want to configure egress flow-accounting:
set system flow-accounting enable-egress
Internally, in flow-accounting processes exist a buffer for data exchanging between core process and plugins
(each export target is a separated plugin). If you have high traffic levels or noted some problems with missed
records or stopping exporting, you may try to increase a default buffer size (10 MiB) with the next command:
set system flow-accounting buffer-size <buffer size>
In case, if you need to catch some logs from flow-accounting daemon, you may configure logging facility:
set system flow-accounting syslog-facility <facility>
TBD
Flow Export
In addition to displaying flow accounting information locally, one can also exported them to a collection server.
NetFlow
NetFlow engine-id which will appear in NetFlow data. The range is 0 to 255.
set system flow-accounting netflow sampling-rate <rate>
Use this command to configure the sampling rate for flow accounting. The system samples one in every <rate>
packets, where <rate> is the value configured for the sampling-rate option. The advantage of sampling every n
packets, where n > 1, allows you to decrease the amount of processing resources required for flow accounting.
The disadvantage of not sampling every packet is that the statistics produced are estimates of actual data flows.
Per default every packet is sampled (that is, the sampling rate is 1).
set system flow-accounting netflow timeout expiry-interval <interval>
Specifies the interval at which Netflow data will be sent to a collector. As per default, Netflow data will be sent
every 60 seconds.
You may also additionally configure timeouts for different types of connections.
set system flow-accounting netflow max-flows <n>
If you want to change the maximum number of flows, which are tracking simultaneously, you may do this with
this command (default 8192).
sFlow
Example:
NetFlow v5 example:
Operation
Once flow accounting is configured on an interfaces it provides the ability to display captured network traffic information
for all configured interfaces.
show flow-accounting interface <interface>
Show flow accounting information for given <interface>.
8.11.5 FRR
VyOS uses [FRRouting](https://frrouting.org/) as the control plane for dynamic and static routing. The routing daemon
behavior can be adjusted during runtime, but require either a restart of the routing daemon, or a reboot of the system.
set system frr bmp
Enable BMP (BGP Monitoring Protocol) support
set system frr descriptors <numer>
This allows the operator to control the number of open file descriptors each daemon is allowed to start with. If
the operator plans to run bgp with several thousands of peers then this is where we would modify FRR to allow
this to happen.
set system frr irdp
Enable ICMP Router Discovery Protocol support
set system frr snmp <daemon>
Enable SNMP support for an individual routing daemon.
Supported daemons:
• bgpd
• isisd
• ldpd
• ospf6d
• ospfd
• ripd
• zebra
This section describes the system’s host information and how to configure them, it covers the following topics:
• Host name
• Domain
• IP address
• Aliases
Hostname
A hostname is the label (name) assigned to a network device (a host) on a network and is used to distinguish one device
from another on specific networks or over the internet. On the other hand this will be the name which appears on the
command line prompt.
set system host-name <hostname>
The hostname can be up to 63 characters. A hostname must start and end with a letter or digit, and have as
interior characters only letters, digits, or a hyphen.
The default hostname used is vyos.
Domain Name
A domain name is the label (name) assigned to a computer network and is thus unique. VyOS appends the domain
name as a suffix to any unqualified name. For example, if you set the domain name example.com, and you would ping
the unqualified name of crux, then VyOS qualifies the name to crux.example.com.
set system domain-name <domain>
Configure system domain name. A domain name must start and end with a letter or digit, and have as interior
characters only letters, digits, or a hyphen.
How an IP address is assigned to an interface in Ethernet. This section shows how to statically map an IP address to
a hostname for local (meaning on this VyOS instance) name resolution. This is the VyOS equivalent to /etc/hosts file
entries.
Note: Do not manually edit /etc/hosts. This file will automatically be regenerated on boot based on the settings in this
section, which means you’ll lose all your manual edits. Instead, configure static host mappings as follows.
8.11.7 IP
Zebra supports prefix-lists and Route Maps to match routes received from other FRR components. The permit/deny
facilities provided by these commands can be used to filter which routes zebra will install in the kernel.
set system ip protocol <protocol> route-map <route-map>
Apply a route-map filter to routes for the specified protocol. The following protocols can be used: any, babel,
bgp, connected, eigrp, isis, kernel, ospf, rip, static, table
Note: If you choose any as the option that will cause all protocols that are sending routes to zebra.
Nexthop Tracking
Nexthop tracking resolve nexthops via the default route by default. This is enabled by default for a traditional profile
of FRR which we use. It and can be disabled if you do not want to e.g. allow BGP to peer across the default route.
set system ip nht no-resolve-via-default
Do not allow IPv4 nexthop tracking to resolve via the default route. This parameter is configured per-VRF, so
the command is also available in the VRF subnode.
Operational commands
show commands
See below the different parameters available for the IPv4 show command:
vyos@vyos:~$ show ip
Possible completions:
access-list Show all IP access-lists
as-path-access-list
Show all as-path-access-lists
bgp Show Border Gateway Protocol (BGP) information
community-list
Show IP community-lists
extcommunity-list
Show extended IP community-lists
forwarding Show IP forwarding status
groups Show IP multicast group membership
igmp Show IGMP (Internet Group Management Protocol) information
large-community-list
Show IP large-community-lists
multicast Show IP multicast
ospf Show IPv4 Open Shortest Path First (OSPF) routing information
pim Show PIM (Protocol Independent Multicast) information
ports Show IP ports in use by various system services
prefix-list Show all IP prefix-lists
protocol Show IP route-maps per protocol
rip Show Routing Information Protocol (RIP) information
route Show IP routes
reset commands
vyos@vyos:~$ reset ip
Possible completions:
arp Reset Address Resolution Protocol (ARP) cache
bgp Clear Border Gateway Protocol (BGP) statistics or status
igmp IGMP clear commands
multicast IP multicast routing table
route Reset IP route
8.11.8 IPv6
Zebra supports prefix-lists and Route Maps to match routes received from other FRR components. The permit/deny
facilities provided by these commands can be used to filter which routes zebra will install in the kernel.
set system ipv6 protocol <protocol> route-map <route-map>
Apply a route-map filter to routes for the specified protocol. The following protocols can be used: any, babel,
bgp, connected, isis, kernel, ospfv3, ripng, static, table
Note: If you choose any as the option that will cause all protocols that are sending routes to zebra.
Nexthop Tracking
Nexthop tracking resolve nexthops via the default route by default. This is enabled by default for a traditional profile
of FRR which we use. It and can be disabled if you do not want to e.g. allow BGP to peer across the default route.
set system ipv6 nht no-resolve-via-default
Do not allow IPv6 nexthop tracking to resolve via the default route. This parameter is configured per-VRF, so
the command is also available in the VRF subnode.
Operational commands
Show commands
Reset commands
The system LCD LCD (Liquid-crystal display) option is for users running VyOS on hardware that features an LCD
display. This is typically a small display built in an 19 inch rack-mountable appliance. Those displays are used to show
runtime data.
To configure your LCD display you must first identify the used hardware, and connectivity of the display to your system.
This can be any serial port (ttySxx) or serial via USB or even old parallel port interfaces.
Configuration
Note: We can’t support all displays from the beginning. If your display type is missing, please create a feature
request via Phabricator.
The default VyOS user account (vyos), as well as newly created user accounts, have all capabilities to configure the
system. All accounts have sudo capabilities and therefore can operate as root on the system.
Both local administered and remote administered RADIUS (Remote Authentication Dial-In User Service) accounts are
supported.
Local
It is highly recommended to use SSH key authentication. By default there is only one user (vyos), and you can assign
any number of keys to that user. You can generate a ssh key with the ssh-keygen command on your local machine,
which will (by default) save it as ~/.ssh/id_rsa.pub.
Every SSH key comes in three parts:
ssh-rsa AAAAB3NzaC1yc2EAAAABAA...VBD5lKwEWB [email protected]
Only the type (ssh-rsa) and the key (AAAB3N...) are used. Note that the key will usually be several hundred characters
long, and you will need to copy and paste it. Some terminal emulators may accidentally split this over several lines. Be
attentive when you paste it that it only pastes as a single line. The third part is simply an identifier, and is for your own
reference.
See also:
SSH Operation
set system login user <username> authentication public-keys <identifier> key <key>
Assign the SSH public key portion <key> identified by per-key <identifier> to the local user <username>.
set system login user <username> authentication public-keys <identifier> type <type>
Every SSH public key portion referenced by <identifier> requires the configuration of the <type> of public-key
used. This type can be any of:
• ecdsa-sha2-nistp256
• ecdsa-sha2-nistp384
• ecdsa-sha2-nistp521
• ssh-dss
• ssh-ed25519
• ssh-rsa
Note: You can assign multiple keys to the same user by using a unique identifier per SSH key.
It is possible to enhance authentication security by using the 2FA (Two-factor authentication)/MFA (Multi-factor au-
thentication) feature together with OTP (One-Time-Pad) on VyOS. 2FA/MFA is configured independently per each
user. If an OTP key is configured for a user, 2FA/MFA is automatically enabled for that particular user. If a user does
not have an OTP key configured, there is no 2FA/MFA check for that user.
set system login user <username> authentication otp key <key>
Enable OTP 2FA for user username with default settings, using the BASE32 encoded 2FA/MFA key specified
by <key>.
Optional/default settings
set system login user <username> authentication otp rate-limit <limit> default: 3
Limit logins to <limit> per every rate-time seconds. Rate limit must be between 1 and 10 attempts.
set system login user <username> authentication otp rate-time <seconds> default: 30
Limit logins to rate-limit attemps per every <seconds>. Rate time must be between 15 and 600 seconds.
set system login user <username> authentication otp window-size <size> default: 3
Set window of concurrently valid codes.
By default, a new token is generated every 30 seconds by the mobile application. In order to compensate for
possible time-skew between the client and the server, an extra token before and after the current time is allowed.
This allows for a time skew of up to 30 seconds between authentication server and client.
For example, if problems with poor time synchronization are experienced, the window can be increased from its
default size of 3 permitted codes (one previous code, the current code, the next code) to 17 permitted codes (the
8 previous codes, the current code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
The window size must be between 1 and 21.
OTP-key generation
The following command can be used to generate the OTP key as well as the CLI commands to configure them:
generate system login username <username> otp-key hotp-time rate-limit <1-10> rate-time
<15-600> window-size <1-21>
An example of key generation:
# You can share it with the user, he just needs to scan the QR in his OTP app
# username: otptester
# OTP KEY: J5A64ERPMGJOZXY6FMHHLKXKANNI6TCY
# OTP URL: otpauth://totp/otptester@vyos?secret=J5A64ERPMGJOZXY6FMHHLKXKANNI6TCY&
˓→digits=6&period=30
Once a user has 2FA/OTP configured against their account, they must login using their password with the OTP code
appended to it. For example: If the users password is vyosrocks and the OTP code is 817454 then they would enter
their password as vyosrocks817454
RADIUS
In large deployments it is not reasonable to configure each user individually on every system. VyOS supports using
RADIUS servers as backend for user authentication.
Configuration
Configuration Example
Hint: If you want to have admin users to authenticate via RADIUS it is essential to sent the Cisco-AV-Pair
shell:priv-lvl=15 attribute. Without the attribute you will only get regular, non privilegued, system users.
TACACS+
In addition to RADIUS, TACACS (Terminal Access Controller Access Control System) can also be found in large
deployments.
TACACS is defined in RFC 8907.
Configuration
Configuration Example
Login Banner
You are able to set post-login or pre-login banner messages to display certain information for this system.
set system login banner pre-login <message>
Configure <message> which is shown during SSH connect and before a user is logged in.
set system login banner post-login <message>
Configure <message> which is shown after user has logged in to the system.
Note: To create a new line in your login message you need to escape the new line character by using \\n.
Limits
Login limits
set system login max-login-session <number>
Set a limit on the maximum number of concurrent logged-in users on the system.
This option must be used with timeout option.
set system login timeout <timeout>
Configure session timeout after which the user will be logged out.
Example
In the following example, both User1 and User2 will be able to SSH into VyOS as user vyos using their very own keys.
User1 is restricted to only be able to connect from a single IP address. In addition if password base login is wanted for
the vyos user a 2FA/MFA keycode is required in addition to the password.
set system login user vyos authentication public-keys 'User1' key "AAAAB3Nz...KwEW"
set system login user vyos authentication public-keys 'User1' type ssh-rsa
set system login user vyos authentication public-keys 'User1' options "from="192.
˓→168.0.100""
set system login user vyos authentication public-keys 'User2' key "AAAAQ39x...fbV3"
set system login user vyos authentication public-keys 'User2' type ssh-rsa
TACACS Example
commit
You can now SSH into your system using admin/admin as a default user supplied from the lfkeitel/
tacacs_plus:latest container.
Warning: If you are configuring a VRF for management purposes, there is currently no way to force system DNS
traffic via a specific VRF.
Example
In this example, some OpenNIC servers are used, two IPv4 addresses and two IPv6 addresses:
In order for the system to use and complete unqualified host names, a list can be defined which will be used for domain
searches.
set system domain-search <domain>
Use this command to define domains, one at a time, so that the system uses them to complete unqualified host
names. Maximum: 6 entries.
Note: Domain names can include letters, numbers, hyphens and periods with a maximum length of 253 characters.
Example
The system is configured to attempt domain completion in the following order: vyos.io (first), vyos.net (second) and
vyos.network (last):
8.11.12 Option
General
Kernel
Note: Setting will only become active with the next reboot!
Note: Setting will only become active with the next reboot!
HTTP client
Note: source-address and source-interface can not be used at the same time.
SSH client
Keyboard Layout
When starting a VyOS live system (the installation CD) the configured keyboard layout defaults to US. As this might
not suite everyone’s use case you can adjust the used keyboard layout on the system console.
set system option keyboard-layout <us | fr | de | fi | no | dk>
Change system keyboard layout to given language.
Defaults to us.
Note: Changing the keymap only has an effect on the system console, using SSH or Serial remote access to
the device is not affected as the keyboard layout here corresponds to your access system.
Performance
As more and more routers run on Hypervisors, expecially with a NOS (Network Operating System) as VyOS, it makes
fewer and fewer sense to use static resource bindings like smp-affinity as present in VyOS 1.2 and earlier to pin
certain interrupt handlers to specific CPUs.
We now utilize tuned for dynamic resource balancing based on profiles.
See also:
https://access.redhat.com/sites/default/files/attachments/201501-perf-brief-low-latency-tuning-rhel7-v2.1.pdf
set system option performance < throughput | latency >
Configure one of the predefined system performance profiles.
• throughput: A server profile focused on improving network throughput. This profile favors performance
over power savings by setting intel_pstate and max_perf_pct=100 and increasing kernel network
buffer sizes.
It enables transparent huge pages, and uses cpupower to set the performance cpufreq governor. It also sets
kernel.sched_min_granularity_ns to 10 us, kernel.sched_wakeup_granularity_ns to 15 uss,
and vm.dirty_ratio to 40%.
• latency: A server profile focused on lowering network latency. This profile favors performance over
power savings by setting intel_pstate and min_perf_pct=100.
It disables transparent huge pages, and automatic NUMA balancing. It also uses cpupower to set the perfor-
mance cpufreq governor, and requests a cpu_dma_latency value of 1. It also sets busy_read and busy_poll
times to 50 us, and tcp_fastopen to 3.
Some IT environments require the use of a proxy to connect to the Internet. Without this configuration VyOS updates
could not be installed directly by using the add system image command (Update VyOS).
set system proxy url <url>
Set proxy for all connections initiated by VyOS, including HTTP, HTTPS, and FTP (anonymous ftp).
set system proxy port <port>
Configure proxy port if it does not listen to the default port 80.
set system proxy username <username>
Some proxys require/support the “basic” HTTP authentication scheme as per RFC 7617, thus a username can
be configured.
set system proxy password <password>
Some proxys require/support the “basic” HTTP authentication scheme as per RFC 7617, thus a password can
be configured.
8.11.14 sFlow
VyOS supports sFlow accounting for both IPv4 and IPv6 traffic. The system acts as a flow exporter, and you are free
to use it with any compatible collector.
sFlow is a technology that enables monitoring of network traffic by sending sampled packets to a collector device.
The sFlow accounting based on hsflowd https://sflow.net/
Configuration
Example
8.11.15 Syslog
Per default VyOSs has minimal syslog logging enabled which is stored and rotated locally. Errors will be always logged
to a local file, which includes local7 error messages, emergency messages will be sent to the console, too.
To configure syslog, you need to switch into configuration mode.
Logging
Syslog supports logging to multiple targets, those targets could be a plain file on your VyOS installation itself, a serial
console or a remote syslog server which is reached via IP (Internet Protocol) UDP/TCP.
Console
Custom File
Remote Host
Logging to a remote host leaves the local logging configuration intact, it can be configured in parallel to a custom file
or console logging. You can log to multiple hosts at the same time, using either TCP or UDP. The default is sending
the messages via port 514/UDP.
set system syslog host <address> facility <keyword> level <keyword>
Log syslog messages to remote host specified by <address>. The address can be specified by either FQDN or
IP address. For an explanation on Facilities keywords and Severity Level keywords see tables below.
set system syslog host <address> facility <keyword> protocol <udp|tcp>
Configure protocol used for communication to remote syslog host. This can be either UDP or TCP.
Facilities
List of facilities used by syslog. Most facilities names are self explanatory. Facilities local0 - local7 common usage is
f.e. as network logs facilities for nodes and network equipment. Generally it depends on the situation how to classify
logs and put them to facilities. See facilities more as a tool rather than a directive to follow.
Facilities can be adjusted to meet the needs of the user:
Severity Level
Display Logs
all Display contents of all master log files of the specified image
authorization Display all authorization attempts of the specified image
directory Display list of all user-defined log files of the specified image
file <file name> Display contents of a specified user-defined log file of the specified image
tail Display last lines of the system log of the specified image
<lines> Number of lines to be displayed, default 10
When no options/parameters are used, the contents of the main syslog file are displayed.
Hint: Use show log | strip-private if you want to hide private data when sharing your logs.
Delete Logs
8.11.16 Sysctl
The task scheduler allows you to execute tasks on a given schedule. It makes use of UNIX cron.
Note: All scripts executed this way are executed as root user - this may be dangerous. Together with Command
Scripting this can be used for automating (re-)configuration.
Time Zone setting is very important as e.g all your logfile entries will be based on the configured zone. Without proper
time zone configuration it will be very difficult to compare logfiles from different systems.
set system time-zone <timezone>
Specify the systems <timezone> as the Region/Location that best defines your location. For example, specifying
US/Pacific sets the time zone to US Pacific time.
Command completion can be used to list available time zones. The adjustment for daylight time will take place
automatically based on the time of year.
8.11.19 Updates
Configuration
Example
Check:
vyos@r4:~$
In the past (VyOS 1.1) used a gateway-address configured under the system tree (set system gateway-address
<address>), this is no longer supported and existing configurations are migrated to the new CLI command.
Configuration
Operation
See also:
Configuration of Static
8.12.1 QoS
The generic name of Quality of Service or Traffic Control involves things like shaping traffic, scheduling or dropping
packets, which are the kind of things you may want to play with when you have, for instance, a bandwidth bottleneck
in a link and you want to somehow prioritize some type of traffic over another.
tc is a powerful tool for Traffic Control found at the Linux kernel. However, its configuration is often considered a
cumbersome task. Fortunately, VyOS eases the job through its CLI, while using tc as backend.
In order to have VyOS Traffic Control working you need to follow 2 steps:
1. Create a traffic policy.
2. Apply the traffic policy to an interface ingress or egress.
But before learning to configure your policy, we will warn you about the different units you can use and also show you
what classes are and how they work, as some policies may require you to configure them.
Units
When configuring your traffic policy, you will have to set data rate values, watch out the units you are managing, it is
easy to get confused with the different prefixes and suffixes you can use. VyOS will always show you the different units
you can use.
Prefixes
Or binary prefixes.
Suffixes
Classes
In the Creating a traffic policy section you will see that some of the policies use classes. Those policies let you distribute
traffic into different classes according to different parameters you can choose. So, a class is just a specific type of traffic
you select.
The ultimate goal of classifying traffic is to give each class a different treatment.
Matching traffic
In order to define which traffic goes into which class, you define filters (that is, the matching criteria). Packets go
through these matching rules (as in the rules of a firewall) and, if a packet matches the filter, it is assigned to that class.
In VyOS, a class is identified by a number you can choose when configuring it.
Note: The meaning of the Class ID is not the same for every type of policy. Normally policies just need a meaningless
number to identify a class (Class ID), but that does not apply to every policy. The number of a class in a Priority Queue
it does not only identify it, it also defines its priority.
In the command above, we set the type of policy we are going to work with and the name we choose for it; a class (so
that we can differentiate some traffic) and an identifiable number for that class; then we configure a matching rule (or
filter) and a name for it.
A class can have multiple match filters:
A match filter can contain multiple criteria and will match traffic if all those criteria are true.
For example:
set qos policy shaper MY-SHAPER class 30 match HTTP ip protocol tcp
set qos policy shaper MY-SHAPER class 30 match HTTP ip source port 80
As shown in the example above, one of the possibilities to match packets is based on marks done by the firewall, that
can give you a great deal of flexibility.
You can also write a description for a filter:
set qos policy shaper MY-SHAPER class 30 match MY-FIRST-FILTER description "My filter␣
˓→description"
Note: An IPv4 TCP filter will only match packets with an IPv4 header length of 20 bytes (which is the majority of
IPv4 packets anyway).
Note: IPv6 TCP filters will only match IPv6 packets with no header extension, see https://en.wikipedia.org/wiki/
IPv6_packet#Extension_headers
In some case where we need to have an organization of our matching selection, in order to be more flexible and organize
with our filter definition. We can apply traffic match groups, allowing us to create distinct filter groups within our policy
and define various parameters for each group:
A match group can contain multiple criteria and inherit them in the same policy.
For example:
In this example, we can observe that different DSCP criteria are defined based on our QoS configuration within the
same policy group.
Default
Often you will also have to configure your default traffic in the same way you do with a class. Default can be considered
a class as it behaves like that. It contains any traffic that did not match any of the defined classes, so it is like an open
class, a class without matching filters.
Class treatment
Once a class has a filter configured, you will also have to define what you want to do with the traffic of that class, what
specific Traffic-Control treatment you want to give it. You will have different possibilities depending on the Traffic
Policy you are configuring.
For instance, with set qos policy shaper MY-SHAPER class 30 set-dscp EF you would be modifying the
DSCP field value of packets in that class to Expedite Forwarding.
Often we need to embed one policy into another one. It is possible to do so on classful policies, by attaching a new
policy into a class. For instance, you might want to apply different policies to the different classes of a Round-Robin
policy you have configured.
A common example is the case of some policies which, in order to be effective, they need to be applied to an interface
that is directly connected where the bottleneck is. If your router is not directly connected to the bottleneck, but some
hop before it, you can emulate the bottleneck by embedding your non-shaping policy into a classful shaping one so that
it takes effect.
You can configure a policy into a class through the queue-type setting.
As shown in the last command of the example above, the queue-type setting allows these combinations. You will be
able to use it in many policies.
Note: Some policies already include other embedded policies inside. That is the case of Shaper: each of its classes
use fair-queue unless you change it.
VyOS lets you control traffic in many different ways, here we will cover every possibility. You can configure as many
policies as you want, but you will only be able to apply one policy per interface and direction (inbound or outbound).
Some policies can be combined, you will be able to embed a different policy that will be applied to a class of the main
policy.
Hint: If you are looking for a policy for your outbound traffic but you don’t know which one you need and you
don’t want to go through every possible policy shown here, our bet is that highly likely you are looking for a Shaper
policy and you want to set its queues as FQ-CoDel.
Drop Tail
This the simplest queue possible you can apply to your traffic. Traffic must go through a finite queue before it is actually
sent. You must define how many packets that queue can contain.
When a packet is to be sent, it will have to go through that queue, so the packet will be placed at the tail of it. When
the packet completely goes through it, it will be dequeued emptying its place in the queue and being eventually handed
to the NIC to be actually sent out.
Despite the Drop-Tail policy does not slow down packets, if many packets are to be sent, they could get dropped when
trying to get enqueued at the tail. This can happen if the queue has still not been able to release enough packets from
its head.
This is the policy that requires the lowest resources for the same amount of traffic. But very likely you do not need it
as you cannot get much from it. Sometimes it is used just to enable logging.
set qos policy drop-tail <policy-name> queue-limit <number-of-packets>
Use this command to configure a drop-tail policy (PFIFO). Choose a unique name for this policy and the size
of the queue by setting the number of packets it can contain (maximum 4294967295).
Fair Queue
Fair Queue is a work-conserving scheduler which schedules the transmission of packets based on flows, that is, it
balances traffic distributing it through different sub-queues in order to ensure fairness so that each flow is able to send
data in turn, preventing any single one from drowning out the rest.
set qos policy fair-queue <policy-name>
Use this command to create a Fair-Queue policy and give it a name. It is based on the Stochastic Fairness
Queueing and can be applied to outbound traffic.
In order to separate traffic, Fair Queue uses a classifier based on source address, destination address and source port.
The algorithm enqueues packets to hash buckets based on those tree parameters. Each of these buckets should represent
a unique flow. Because multiple flows may get hashed to the same bucket, the hashing algorithm is perturbed at con-
figurable intervals so that the unfairness lasts only for a short while. Perturbation may however cause some inadvertent
packet reordering to occur. An advisable value could be 10 seconds.
One of the uses of Fair Queue might be the mitigation of Denial of Service attacks.
set qos policy fair-queue <policy-name> hash-interval <seconds>
Use this command to define a Fair-Queue policy, based on the Stochastic Fairness Queueing, and set the number
of seconds at which a new queue algorithm perturbation will occur (maximum 4294967295).
When dequeuing, each hash-bucket with data is queried in a round robin fashion. You can configure the length of the
queue.
set qos policy fair-queue <policy-name> queue-limit <limit>
Use this command to define a Fair-Queue policy, based on the Stochastic Fairness Queueing, and set the number
of maximum packets allowed to wait in the queue. Any other packet will be dropped.
Note: Fair Queue is a non-shaping (work-conserving) policy, so it will only be useful if your outgoing interface is
really full. If it is not, VyOS will not own the queue and Fair Queue will have no effect. If there is bandwidth available
on the physical link, you can embed Fair-Queue into a classful shaping policy to make sure it owns the queue.
FQ-CoDel
The FQ-CoDel policy distributes the traffic into 1024 FIFO queues and tries to provide good service between all of
them. It also tries to keep the length of all the queues short.
FQ-CoDel fights bufferbloat and reduces latency without the need of complex configurations. It has become the new
default Queueing Discipline for the interfaces of some GNU/Linux distributions.
It uses a stochastic model to classify incoming packets into different flows and is used to provide a fair share of the
bandwidth to all the flows using the queue. Each flow is managed by the CoDel queuing discipline. Reordering within
a flow is avoided since Codel internally uses a FIFO queue.
FQ-CoDel is based on a modified Deficit Round Robin (DRR) queue scheduler with the CoDel Active Queue Manage-
ment (AQM) algorithm operating on each queue.
Note: FQ-Codel is a non-shaping (work-conserving) policy, so it will only be useful if your outgoing interface is really
full. If it is not, VyOS will not own the queue and FQ-Codel will have no effect. If there is bandwidth available on the
physical link, you can embed FQ-Codel into a classful shaping policy to make sure it owns the queue. If you are not
sure if you need to embed your FQ-CoDel policy into a Shaper, do it.
FQ-CoDel is tuned to run ok with its default parameters at 10Gbit speeds. It might work ok too at other speeds without
configuring anything, but here we will explain some cases when you might want to tune its parameters.
When running it at 1Gbit and lower, you may want to reduce the queue-limit to 1000 packets or less. In rates like
10Mbit, you may want to set it to 600 packets.
If you are using FQ-CoDel embedded into Shaper and you have large rates (100Mbit and above), you may consider
increasing quantum to 8000 or higher so that the scheduler saves CPU.
On low rates (below 40Mbit) you may want to tune quantum down to something like 300 bytes.
At very low rates (below 3Mbit), besides tuning quantum (300 keeps being ok) you may also want to increase target to
something like 15ms and increase interval to something around 150 ms.
set qos policy fq-codel <policy name> codel-quantum <bytes>
Use this command to configure an fq-codel policy, set its name and the maximum number of bytes (default:
1514) to be dequeued from a queue at once.
set qos policy fq-codel <policy name> flows <number-of-flows>
Use this command to configure an fq-codel policy, set its name and the number of sub-queues (default: 1024)
into which packets are classified.
set qos policy fq-codel <policy name> interval <milliseconds>
Use this command to configure an fq-codel policy, set its name and the time period used by the control loop
of CoDel to detect when a persistent queue is developing, ensuring that the measured minimum delay does not
become too stale (default: 100ms).
set qos policy fq-codel <policy-name> queue-limit <number-of-packets>
Use this command to configure an fq-codel policy, set its name, and define a hard limit on the real queue size.
When this limit is reached, new packets are dropped (default: 10240 packets).
set qos policy fq-codel <policy-name> target <milliseconds>
Use this command to configure an fq-codel policy, set its name, and define the acceptable minimum stand-
ing/persistent queue delay. This minimum delay is identified by tracking the local minimum queue delay that
packets experience (default: 5ms).
Example
Limiter
Limiter is one of those policies that uses classes (Ingress qdisc is actually a classless policy but filters do work in it).
The limiter performs basic ingress policing of traffic flows. Multiple classes of traffic can be defined and traffic limits
can be applied to each class. Although the policer uses a token bucket mechanism internally, it does not have the
capability to delay a packet as a shaping mechanism does. Traffic exceeding the defined bandwidth limits is directly
dropped. A maximum allowed burst can be configured too.
You can configure classes (up to 4090) with different settings and a default policy which will be applied to any traffic
not matching any of the configured classes.
Note: In the case you want to apply some kind of shaping to your inbound traffic, check the ingress-shaping section.
set qos policy limiter <policy-name> class <class ID> match <match-name> description
<description>
Use this command to configure an Ingress Policer, defining its name, a class identifier (1-4090), a class matching
rule name and its description.
Once the matching rules are set for a class, you can start configuring how you want matching traffic to behave.
set qos policy limiter <policy-name> class <class-ID> bandwidth <rate>
Use this command to configure an Ingress Policer, defining its name, a class identifier (1-4090) and the maximum
allowed bandwidth for this class.
set qos policy limiter <policy-name> class <class-ID> burst <burst-size>
Use this command to configure an Ingress Policer, defining its name, a class identifier (1-4090) and the burst
size in bytes for this class (default: 15).
set qos policy limiter <policy-name> default bandwidth <rate>
Use this command to configure an Ingress Policer, defining its name and the maximum allowed bandwidth for
its default policy.
set qos policy limiter <policy-name> default burst <burst-size>
Use this command to configure an Ingress Policer, defining its name and the burst size in bytes (default: 15) for
its default policy.
set qos policy limiter <policy-name> class <class ID> priority <value>
Use this command to configure an Ingress Policer, defining its name, a class identifier (1-4090), and the priority
(0-20, default 20) in which the rule is evaluated (the lower the number, the higher the priority).
Network Emulator
VyOS Network Emulator policy emulates the conditions you can suffer in a real network. You will be able to configure
things like rate, burst, delay, packet loss, packet corruption or packet reordering.
This could be helpful if you want to test how an application behaves under certain network conditions.
set qos policy network-emulator <policy-name> bandwidth <rate>
Use this command to configure the maximum rate at which traffic will be shaped in a Network Emulator policy.
Define the name of the policy and the rate.
set qos policy network-emulator <policy-name> burst <burst-size>
Use this command to configure the burst size of the traffic in a Network Emulator policy. Define the name of the
Network Emulator policy and its traffic burst size (it will be configured through the Token Bucket Filter qdisc).
Default:15kb. It will only take effect if you have configured its bandwidth too.
set qos policy network-emulator <policy-name> delay <delay>
Use this command to configure a Network Emulator policy defining its name and the fixed amount of time you
want to add to all packet going out of the interface. The latency will be added through the Token Bucket Filter
qdisc. It will only take effect if you have configured its bandwidth too. You can use secs, ms and us. Default:
50ms.
set qos policy network-emulator <policy-name> corruption <percent>
Use this command to emulate noise in a Network Emulator policy. Set the policy name and the percentage of
corrupted packets you want. A random error will be introduced in a random position for the chosen percent of
packets.
set qos policy network-emulator <policy-name> loss <percent>
Use this command to emulate packet-loss conditions in a Network Emulator policy. Set the policy name and
the percentage of loss packets your traffic will suffer.
set traffic-policy network-emulator <policy-name> reordering <percent>
Use this command to emulate packet-reordering conditions in a Network Emulator policy. Set the policy name
and the percentage of reordered packets your traffic will suffer.
set traffic-policy network-emulator <policy-name> queue-limit <limit>
Use this command to define the length of the queue of your Network Emulator policy. Set the policy name and
the maximum number of packets (1-4294967295) the queue may hold queued at a time.
Priority Queue
The Priority Queue is a classful scheduling policy. It does not delay packets (Priority Queue is not a shaping policy),
it simply dequeues packets according to their priority.
Note: Priority Queue, as other non-shaping policies, is only useful if your outgoing interface is really full. If it is not,
VyOS will not own the queue and Priority Queue will have no effect. If there is bandwidth available on the physical
link, you can embed Priority Queue into a classful shaping policy to make sure it owns the queue. In that case packets
can be prioritized based on DSCP.
Up to seven queues -defined as classes with different priorities- can be configured. Packets are placed into queues
based on associated match criteria. Packets are transmitted from the queues in priority order. If classes with a higher
priority are being filled with packets continuously, packets from lower priority classes will only be transmitted after
traffic volume from higher priority classes decreases.
Note: In Priority Queue we do not define classes with a meaningless class ID number but with a class priority number
(1-7). The lower the number, the higher the priority.
As with other policies, you can define different type of matching rules for your classes:
As with other policies, you can embed other policies into the classes (and default) of your Priority Queue policy through
the queue-type setting:
Random-Detect
A simple Random Early Detection (RED) policy would start randomly dropping packets from a queue before it reaches
its queue limit thus avoiding congestion. That is good for TCP connections as the gradual dropping of packets acts as
a signal for the sender to decrease its transmission rate.
In contrast to simple RED, VyOS’ Random-Detect uses a Generalized Random Early Detect policy that provides dif-
ferent virtual queues based on the IP Precedence value so that some virtual queues can drop more packets than others.
This is achieved by using the first three bits of the ToS (Type of Service) field to categorize data streams and, in
accordance with the defined precedence parameters, a decision is made.
IP precedence as defined in RFC 791:
Precedence Priority
7 Network Control
6 Internetwork Control
5 CRITIC/ECP
4 Flash Override
3 Flash
2 Immediate
1 Priority
0 Routine
Random-Detect could be useful for heavy traffic. One use of this algorithm might be to prevent a backbone overload.
But only for TCP (because dropped packets could be retransmitted), not for UDP.
Note: When configuring a Random-Detect policy: the higher the precedence number, the higher the priority.
If the current queue size is larger than queue-limit, then packets will be dropped. The average queue size depends on
its former average size and its current one.
If max-threshold is set but min-threshold is not, then **min-threshold is scaled to 50% of max-threshold.
In principle, values must be min-threshold < max-threshold < queue-limit.
Rate Control
Rate-Control is a classless policy that limits the packet flow to a set rate. It is a pure shaper, it does not schedule traffic.
Traffic is filtered based on the expenditure of tokens. Tokens roughly correspond to bytes.
Short bursts can be allowed to exceed the limit. On creation, the Rate-Control traffic is stocked with tokens which
correspond to the amount of traffic that can be burst in one go. Tokens arrive at a steady rate, until the bucket is full.
set qos policy rate-control <policy-name> bandwidth <rate>
Use this command to configure a Rate-Control policy, set its name and the rate limit you want to have.
set qos policy rate-control <policy-name> burst <burst-size>
Use this command to configure a Rate-Control policy, set its name and the size of the bucket in bytes which will
be available for burst.
As a reference: for 10mbit/s on Intel, you might need at least 10kbyte buffer if you want to reach your configured rate.
A very small buffer will soon start dropping packets.
set qos policy rate-control <policy-name> latency
Use this command to configure a Rate-Control policy, set its name and the maximum amount of time a packet
can be queued (default: 50 ms).
Rate-Control is a CPU-friendly policy. You might consider using it when you just simply want to slow traffic down.
Round Robin
The round-robin policy is a classful scheduler that divides traffic in different classes you can configure (up to 4096).
You can embed a new policy into each of those classes (default included).
Each class is assigned a deficit counter (the number of bytes that a flow is allowed to transmit when it is its turn)
initialized to quantum. Quantum is a parameter you configure which acts like a credit of fix bytes the counter receives
on each round. Then the Round-Robin policy starts moving its Round Robin pointer through the queues. If the deficit
counter is greater than the packet’s size at the head of the queue, this packet will be sent and the value of the counter
will be decremented by the packet size. Then, the size of the next packet will be compared to the counter value again,
repeating the process. Once the queue is empty or the value of the counter is insufficient, the Round-Robin pointer will
move to the next queue. If the queue is empty, the value of the deficit counter is reset to 0.
At every round, the deficit counter adds the quantum so that even large packets will have their opportunity to be de-
queued.
set qos policy round-robin <policy name> class <class-ID> quantum <packets>
Use this command to configure a Round-Robin policy, set its name, set a class ID, and the quantum for that
class. The deficit counter will add that value each round.
set qos policy round-robin <policy name> class <class ID> queue-limit <packets>
Use this command to configure a Round-Robin policy, set its name, set a class ID, and the queue size in packets.
As with other policies, Round-Robin can embed another policy into a class through the queue-type setting.
Shaper
The Shaper policy does not guarantee a low delay, but it does guarantee bandwidth to different traffic classes and also
lets you decide how to allocate more traffic once the guarantees are met.
Each class can have a guaranteed part of the total bandwidth defined for the whole policy, so all those shares together
should not be higher than the policy’s whole bandwidth.
If guaranteed traffic for a class is met and there is room for more traffic, the ceiling parameter can be used to set how
much more bandwidth could be used. If guaranteed traffic is met and there are several classes willing to use their
ceilings, the priority parameter will establish the order in which that additional traffic will be allocated. Priority can be
any number from 0 to 7. The lower the number, the higher the priority.
set qos policy shaper <policy-name> bandwidth <rate>
Use this command to configure a Shaper policy, set its name and the maximum bandwidth for all combined
traffic.
set qos policy shaper <policy-name> class <class-ID> bandwidth <rate>
Use this command to configure a Shaper policy, set its name, define a class and set the guaranteed traffic you
want to allocate to that class.
set qos policy shaper <policy-name> class <class-ID> burst <bytes>
Use this command to configure a Shaper policy, set its name, define a class and set the size of the tocken bucket
in bytes, which will be available to be sent at ceiling speed (default: 15Kb).
set qos policy shaper <policy-name> class <class-ID> ceiling <bandwidth>
Use this command to configure a Shaper policy, set its name, define a class and set the maximum speed possible
for this class. The default ceiling value is the bandwidth value.
set qos policy shaper <policy-name> class <class-ID> priority <0-7>
Use this command to configure a Shaper policy, set its name, define a class and set the priority for usage of
available bandwidth once guarantees have been met. The lower the priority number, the higher the priority. The
default priority value is 0, the highest priority.
As with other policies, Shaper can embed other policies into its classes through the queue-type setting and then
configure their parameters.
Note: If you configure a class for VoIP traffic, don’t give it any ceiling, otherwise new VoIP calls could start when
the link is available and get suddenly dropped when other classes start using their assigned bandwidth share.
Example
CAKE
Common Applications Kept Enhanced (CAKE) is a comprehensive queue management system, implemented as a queue
discipline (qdisc) for the Linux kernel. It is designed to replace and improve upon the complex hierarchy of simple
qdiscs presently required to effectively tackle the bufferbloat problem at the network edge.
set qos policy cake <text> bandwidth <value>
Set the shaper bandwidth, either as an explicit bitrate or a percentage of the interface bandwidth.
set qos policy cake <text> description
Set a description for the shaper.
set qos policy cake <text> flow-isolation blind
Disables flow isolation, all traffic passes through a single queue.
set qos policy cake <text> flow-isolation dst-host
Flows are defined only by destination address.
set qos policy cake <text> flow-isolation dual-dst-host
Flows are defined by the 5-tuple. Fairness is applied first over destination addresses, then over individual flows.
set qos policy cake <text> flow-isolation dual-src-host
Flows are defined by the 5-tuple. Fairness is applied first over source addresses, then over individual flows.
set qos policy cake <text> flow-isolation flow
Flows are defined by the entire 5-tuple (source IP address, source port, destination IP address, destination port,
transport protocol).
set qos policy cake <text> flow-isolation host
Flows are defined by source-destination host pairs.
set qos policy cake <text> flow-isolation nat
Perform NAT lookup before applying flow-isolation rules.
set qos policy cake <text> flow-isolation src-host
Flows are defined only by source address.
set qos policy cake <text> flow-isolation triple-isolate
(Default) Flows are defined by the 5-tuple, fairness is applied over source and destination addresses and also
over individual flows.
set qos policy cake <text> rtt
Defines the round-trip time used for active queue management (AQM) in milliseconds. The default value is 100.
You can only apply one policy per interface and direction, but you could reuse a policy on different interfaces and
directions:
For the ingress traffic of an interface, there is only one policy you can directly apply, a Limiter policy. You cannot
apply a shaping policy directly to the ingress traffic of any interface because shaping only works for outbound traffic.
This workaround lets you apply a shaping policy to the ingress traffic by first redirecting it to an in-between virtual
interface (Intermediate Functional Block). There, in that virtual interface, you will be able to apply any of the policies
that work for outbound traffic, for instance, a shaping one.
That is how it is possible to do the so-called “ingress shaping”.
Warning: Do not configure IFB as the first step. First create everything else of your traffic-policy, and then you
can configure IFB. Otherwise you might get the RTNETLINK answer: File exists error, which can be solved
with sudo ip link delete ifb0.
8.13 VPN
8.13.1 IPsec
GRE (Generic Routing Encapsulation), GRE/IPsec (or IPIP/IPsec, SIT/IPsec, or any other stateless tunnel protocol
over IPsec) is the usual way to protect the traffic inside a tunnel.
An advantage of this scheme is that you get a real interface with its own address, which makes it easier to setup static
routes or use dynamic routing protocols without having to modify IPsec policies. The other advantage is that it greatly
simplifies router to router communication, which can be tricky with plain IPsec because the external outgoing address of
the router usually doesn’t match the IPsec policy of typical site-to-site setup and you need to add special configuration
for it, or adjust the source address for outgoing traffic of your applications. GRE/IPsec has no such problem and is
completely transparent for the applications.
GRE/IPIP/SIT and IPsec are widely accepted standards, which make this scheme easy to implement between VyOS
and virtually any other router.
For simplicity we’ll assume that the protocol is GRE, it’s not hard to guess what needs to be changed to make it work
with a different protocol. We assume that IPsec will use pre-shared secret authentication and will use AES128/SHA1
for the cipher and hash. Adjust this as necessary.
Note: VMware users should ensure that a VMXNET3 adapter is used. E1000 adapters have known issues with GRE
processing.
IKE performs mutual authentication between two parties and establishes an IKE security association (SA) that includes
shared secret information that can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) or
Authentication Header (AH) and a set of cryptographic algorithms to be used by the SAs to protect the traffic that they
carry. https://datatracker.ietf.org/doc/html/rfc5996
In VyOS, IKE attributes are specified through IKE groups. Multiple proposals can be specified in a single group.
VyOS IKE group has the next options:
• close-action defines the action to take if the remote peer unexpectedly closes a CHILD_SA:
• none set action to none (default);
• trap installs a trap policy for the CHILD_SA;
• start tries to immediately re-create the CHILD_SA;
• dead-peer-detection controls the use of the Dead Peer Detection protocol (DPD, RFC 3706) where
R_U_THERE notification messages (IKEv1) or empty INFORMATIONAL messages (IKEv2) are periodically
sent in order to check the liveliness of the IPsec peer:
• action keep-alive failure action:
• trap installs a trap policy, which will catch matching traffic and tries to re-negotiate the tunnel on-
demand;
• clear closes the CHILD_SA and does not take further action (default);
• restart immediately tries to re-negotiate the CHILD_SA under a fresh IKE_SA;
• interval keep-alive interval in seconds <2-86400> (default 30);
• timeout keep-alive timeout in seconds <2-86400> (default 120) IKEv1 only
• ikev2-reauth whether rekeying of an IKE_SA should also reauthenticate the peer. In IKEv1, reauthentication
is always done. Setting this parameter enables remote host re-authentication during an IKE rekey.
• key-exchange which protocol should be used to initialize the connection If not set both protocols are handled
and connections will use IKEv2 when initiating, but accept any protocol version when responding:
• ikev1 use IKEv1 for Key Exchange;
• ikev2 use IKEv2 for Key Exchange;
• lifetime IKE lifetime in seconds <0-86400> (default 28800);
• disable-mobike disables MOBIKE Support. MOBIKE is only available for IKEv2 and enabled by default.
• mode IKEv1 Phase 1 Mode Selection:
• main use Main mode for Key Exchanges in the IKEv1 Protocol (Recommended Default);
• aggressive use Aggressive mode for Key Exchanges in the IKEv1 protocol aggressive mode is much more
insecure compared to Main mode;
• proposal the list of proposals and their parameters:
• dh-group dh-group;
• encryption encryption algorithm;
• hash hash algorithm.
• prf pseudo-random function.
ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form
of partial sequence integrity), and limited traffic flow confidentiality. https://datatracker.ietf.org/doc/html/rfc4303
In VyOS, ESP attributes are specified through ESP groups. Multiple proposals can be specified in a single group.
VyOS ESP group has the next options:
• compression Enables the IPComp(IP Payload Compression) protocol which allows compressing the content of
IP packets.
• life-bytes ESP life in bytes <1024-26843545600000>. Number of bytes transmitted over an IPsec SA before
it expires;
• life-packets ESP life in packets <1000-26843545600000>. Number of packets transmitted over an IPsec SA
before it expires;
• lifetime ESP lifetime in seconds <30-86400> (default 3600). How long a particular instance of a connection
(a set of encryption/authentication keys for user packets) should last, from successful negotiation to expiry;
• mode the type of the connection:
• tunnel tunnel mode (default);
• transport transport mode;
• pfs whether Perfect Forward Secrecy of keys is desired on the connection’s keying channel and defines a Diffie-
Hellman group for PFS:
• enable Inherit Diffie-Hellman group from IKE group (default);
• disable Disable PFS;
• < dh-group > defines a Diffie-Hellman group for PFS;
• options
• disable-route-autoinstall Do not automatically install routes to remote networks;
• flexvpn Allows FlexVPN vendor ID payload (IKEv2 only). Send the Cisco FlexVPN vendor ID payload
(IKEv2 only), which is required in order to make Cisco brand devices allow negotiating a local traffic selec-
tor (from strongSwan’s point of view) that is not the assigned virtual IP address if such an address is requested by
strongSwan. Sending the Cisco FlexVPN vendor ID prevents the peer from narrowing the initiator’s local traffic
selector and allows it to e.g. negotiate a TS of 0.0.0.0/0 == 0.0.0.0/0 instead. This has been tested with a “tunnel
mode ipsec ipv4” Cisco template but should also work for GRE encapsulation;
• interface Interface Name to use. The name of the interface on which virtual IP addresses should be installed.
If not specified the addresses will be installed on the outbound interface;
• virtual-ip Allows to install virtual-ip addresses. Comma separated list of virtual IPs to request in IKEv2 con-
figuration payloads or IKEv1 Mode Config. The wildcard addresses 0.0.0.0 and :: request an arbitrary address,
specific addresses may be defined. The responder may return a different address, though, or none at all. Define
the virtual-address option to configure the IP address in site-to-site hierarchy.
The first and arguably cleaner option is to make your IPsec policy match GRE packets between external addresses of
your routers. This is the best option if both routers have static external addresses.
Suppose the LEFT router has external address 192.0.2.10 on its eth0 interface, and the RIGHT router is 203.0.113.45
On the LEFT:
# GRE tunnel
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 192.0.2.10
set interfaces tunnel tun0 remote 203.0.113.45
set interfaces tunnel tun0 address 10.10.10.1/30
## IPsec
set vpn ipsec interface eth0
# Pre-shared-secret
set vpn ipsec authentication psk vyos id 192.0.2.10
set vpn ipsec authentication psk vyos id 203.0.113.45
set vpn ipsec authentication psk vyos secret MYSECRETKEY
# IKE group
set vpn ipsec ike-group MyIKEGroup proposal 1 dh-group '2'
set vpn ipsec ike-group MyIKEGroup proposal 1 encryption 'aes128'
set vpn ipsec ike-group MyIKEGroup proposal 1 hash 'sha1'
# ESP group
(continues on next page)
# IPsec tunnel
set vpn ipsec site-to-site peer right authentication mode pre-shared-secret
set vpn ipsec site-to-site peer right authentication remote-id 203.0.113.45
On the RIGHT, setup by analogy and swap local and remote addresses.
The scheme above doesn’t work when one of the routers has a dynamic external address though. The classic workaround
for this is to setup an address on a loopback interface and use it as a source address for the GRE tunnel, then setup an
IPsec policy to match those loopback addresses.
We assume that the LEFT router has static 192.0.2.10 address on eth0, and the RIGHT router has a dynamic address
on eth0.
The peer names RIGHT and LEFT are used as informational text.
Setting up the GRE tunnel
On the LEFT:
On the RIGHT:
Setting up IPSec
However, now you need to make IPsec work with dynamic address on one side. The tricky part is that pre-shared secret
authentication doesn’t work with dynamic address, so we’ll have to use RSA keys.
First, on both routers run the operational command “generate pki key-pair install <key-pair name>”. You may choose
different length than 2048 of course.
Configuration commands for the private and public key will be displayed on the screen which needs to be set on the
router first. Note the command with the public key (set pki key-pair ipsec-LEFT public key ‘MIIBIjANBgkqh. . . ’).
Then do the same on the opposite router:
Note the command with the public key (set pki key-pair ipsec-RIGHT public key ‘FAAOCAQ8AMII. . . ’).
Now the noted public keys should be entered on the opposite routers.
On the LEFT:
On the RIGHT:
Now you are ready to setup IPsec. You’ll need to use an ID instead of address for the peer.
On the LEFT (static address):
set vpn ipsec site-to-site peer RIGHT tunnel 1 remote prefix 192.168.99.2/32 #␣
˓→Additional loopback address on the remote
set vpn ipsec site-to-site peer LEFT tunnel 1 remote prefix 192.168.99.1/32 # Additional␣
˓→loopback address on the remote
Internet Key Exchange version 2, IKEv2 for short, is a request/response protocol developed by both Cisco and Mi-
crosoft. It is used to establish and secure IPv4/IPv6 connections, be it a site-to-site VPN or from a road-warrior
connecting to a hub site. IKEv2, when run in point-to-multipoint, or remote-access/road-warrior mode, secures the
server-side with another layer by using an x509 signed server certificate.
Key exchange and payload encryption is still done using IKE and ESP proposals as known from IKEv1 but the con-
nections are faster to establish, more reliable, and also support roaming from IP to IP (called MOBIKE which makes
sure your connection does not drop when changing networks from e.g. WIFI to LTE and back).
This feature closely works together with PKI subsystem as you required a x509 certificate.
This example uses CACert as certificate authority.
set pki ca CAcert_Class_3_Root certificate
˓→'MIIGPTCCBCWgAwIBAgIDFOIoMA0GCSqGSIb3DQEBDQUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY
˓→UErEa4w75/
˓→ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUoqMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX
˓→fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/
˓→8BBdwPSUp2rVO5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcDrb60LhPtXapI19
˓→LP/
˓→Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ92ZCdB6K4/
˓→jc0m+YnMtHmJVABfvpAgMBAAGjgfIwge8wDwYDVR0TAQH/BAUwAwEB/
˓→zBhBggrBgEFBQcBAQRVMFMwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCwGCCsGAQUFBzAChiBodHRwOi8vd3d
˓→mARN+Yz5R3lzUvXs3zSX+z534NzRg4i6iHNHWqakFcQNcA0PnksTB37vGD75pQGqeSmx51L6UzrIpn+274mhsaFNL85jhX+lKuk71M
˓→vvoLNkh/L3iEQ5/
˓→LnmLMCYJNRALF7I7gsduAJNJrgKGMYvHkt1bo8uIXO8wgNV7qoU4JoaB1ML30QUqGcFr0TI06FFdgK2fwy5hulPxm6wuxW0v+iAtXY
˓→mRkwQpYbcVQtrIDvx1CT1k50cQxi+jIKjkcFWHw3kBoDnCos0/
˓→ukegPT7aQnk2AbL4c7nCkuAcEKw1BAlSETkfqi5btdlhh58MhewZv1LcL5zQyg8w1puclT3wXQvy8VwPGn0J/
˓→mGD4gLLZ9rGcHDUECokxFoWk+u5MCcVqmGbsyG4q5suS3CNslsHURfM8bQK4oLvHR8LCHEBMRcdFBn87cSvOK6eB1kdGKLA8ymXxZp
˓→'
˓→pnCujW0r8+55jE8Ez64AO7NV1sId6eINm6zWYyN3L69wj1x81YyY7nDl7qPv4coRQKFWyGhFtkZip6qUtTefWIonvuLwphK42yfk1W
˓→JHIJ6BVgrCFvzOKKrF11myZjXnhCLotLddJr3cQxyYN/
˓→Nb5gznZY0dj4kepKwDpUeb+agRThHqtdB7Uq3EvbXG4OKDy7YCbZZ16oE/
˓→9KTfWgu3YtLq1i6L43qlaegw1SJpfvbi1EinbLDvhG+LJGGi5Z4rSDTii8aP8bQUWWHIbEZAWV/
˓→RRyH9XzQQUxPKZgh/
˓→TMfdQwEUfoZd9vUFBzugcMd9Zi3aQaRIt0AUMyBMawSB3s42mhb5ivUfslfrejrckzzAeVLIL+aplfKkQABi6F1ITe1Yw1nPkZPcCB
˓→0PsmBsJUUtaWsJx8cTLc6nloQsCAwEAAaOCAX8wggF7MB0GA1UdDgQWBBQWtTIb1Mfz4OaO873SsDrusjkY0TAPBgNVHRMBAf8EBTA
˓→MDQGCWCGSAGG+EIBCAQnFiVodHRwOi8vd3d3LmNhY2VydC5vcmcvaW5kZXgucGhwP2lkPTEwMFYGCWCGSAGG+EIBDQRJFkdUbyBnZX
˓→1Xpgdw/+IP1GRwdg7xUpReUA482l4MH1kf0W0ad94SuIfNWQHcdLApmno/
˓→SUh1bpZyeWrMnlhkGNDKMxCCQXQ360TwFHc8dfEAaq5ry6cZzm1oetrkSviE2qofxvv1VFiQ+9TX3/zkECCsUB/
˓→EjPM0lxFBmu9T5Ih+Eqns9ivmrEIQDv9tNyJHuLsDNqbUBal7OoiPZnXk9LH+qb+pLf1ofv5noy5vX2a5OKebHe+0Ex/
˓→A7e+G/HuOjVNqhZ9j5Nispfq9zNyOHGWD8ofj8DHwB50L1Xh5H+EbIoga/
˓→hJCQnRtxWkHP699T1JpLFYwapgplivF4TFv4fqp0nHTKC1x9gGrIgvuYJl1txIKmxXdfJzgscMzqpabhtHOMXOiwQBpWzyJkofF/
˓→w55e0LttZDBkEsilV/
˓→vW0CJsPs3eNaQF+iMWscGOkgLFlWsAS3HwyiYLNJo26aqyWPaIdc8E4ck7Sk08WrFrHIK3EHr4n1FZwmLpFAvucKqgl0hr+2jypyh5
˓→'
After you obtained your server certificate you can import it from a file on the local filesystem, or paste it into the CLI.
Please note that when entering the certificate manually you need to strip the -----BEGIN KEY----- and -----END
KEY----- tags. Also, the certificate or key needs to be presented in a single line without line breaks (\n).
To import it from the filesystem use:
After the PKI certs are all set up we can start configuring our IPSec/IKE proposals used for key-exchange end data
encryption. The used encryption ciphers and integrity algorithms vary from operating system to operating system. The
ones used in this post are validated to work on both Windows 10 and iOS/iPadOS 14 to 17.
Every connection/remote-access pool we configure also needs a pool where we can draw our client IP addresses from.
We provide one IPv4 and IPv6 pool. Authorized clients will receive an IPv4 address from the 192.0.2.128/25 prefix
and an IPv6 address from the 2001:db8:2000::/64 prefix. We can also send some DNS nameservers down to our clients
used on their connection.
VyOS supports multiple IKEv2 remote-access connections. Every connection can have its dedicated IKE/ESP ciphers,
certificates or local listen address for e.g. inbound load balancing.
We configure a new connection named rw for road-warrior, that identifies itself as 192.0.2.1 to the clients and uses
the vyos certificate signed by the CAcert_Class3_Root` intermediate CA. We select our previously specified IKE/ESP
groups and also link the IP address pool to draw addresses from.
VyOS also supports (currently) two different modes of authentication, local and RADIUS. To create a new local user
named vyos with password vyos use the following commands.
If you feel better forwarding all authentication requests to your enterprises RADIUS server, use the commands below.
Configuring VyOS to act as your IPSec access concentrator is one thing, but you probably need to setup your client
connecting to the server so they can talk to the IPSec gateway.
Windows 10 does not allow a user to choose the integrity and encryption ciphers using the GUI and it uses some older
proposals by default. A user can only change the proposals on the client side by configuring the IPSec connection
profile via PowerShell.
We generate a connection profile used by Windows clients that will connect to the “rw” connection on our VyOS server
on the VPN servers IP address/fqdn vpn.vyos.net.
Note: Microsoft Windows expects the server name to be also used in the server’s certificate common name, so it’s
best to use this DNS name for your VPN connection.
As both Microsoft Windows and Apple iOS/iPadOS only support a certain set of encryption ciphers and integrity
algorithms we will validate the configured IKE/ESP proposals and only list the compatible ones to the user — if
multiple are defined. If there are no matching proposals found — we can not generate a profile for you.
When first connecting to the new VPN the user is prompted to enter proper credentials.
Like on Microsoft Windows, Apple iOS/iPadOS out of the box does not expose all available VPN options via the device
GUI.
If you want, need, and should use more advanced encryption ciphers (default is still 3DES) you need to provision your
device using a so-called “Device Profile”. A profile is a simple text file containing XML nodes with a .mobileconfig
file extension that can be sent and opened on any device from an E-Mail.
Profile generation happens from the operational level and is as simple as issuing the following command to create
a profile to connect to the IKEv2 access server at vpn.vyos.net with the configuration for the rw remote-access
connection group.
Note: Apple iOS/iPadOS expects the server name to be also used in the server’s certificate common name, so it’s best
to use this DNS name for your VPN connection.
<plist version="1.0">
...
</plist>
==== </snip> ====
In the end, an XML structure is generated which can be saved as vyos.mobileconfig and sent to the device by E-Mail
where it later can be imported.
During profile import, the user is asked to enter its IPSec credentials (username and password) which is stored on the
mobile.
8.13.2 L2TP
VyOS utilizes accel-ppp to provide L2TP server functionality. It can be used with local authentication or a connected
RADIUS server.
Configuring IPsec
To allow VPN-clients access via your external address, a NAT rule is required:
To enable RADIUS based authentication, the authentication mode needs to be changed within the configuration. Pre-
vious settings like the local users, still exists within the configuration, however they are not used if the mode has been
changed from local to radius. Once changed back to local, it will use all local accounts again.
set vpn l2tp remote-access authentication radius server <server> key <secret>
Configure RADIUS <server> and its required shared <secret> for communicating with the RADIUS server.
Since the RADIUS server would be a single point of failure, multiple RADIUS servers can be setup and will be used
subsequentially. For example:
set vpn l2tp remote-access authentication radius server 10.0.0.1 key 'foo'
set vpn l2tp remote-access authentication radius server 10.0.0.2 key 'foo'
Note: Some RADIUS severs use an access control list which allows or denies queries, make sure to add your VyOS
router to the allowed client list.
If you are using OSPF as IGP, always the closest interface connected to the RADIUS server is used. With VyOS 1.2
you can bind all outgoing RADIUS requests to a single source IP e.g. the loopback interface.
set vpn l2tp remote-access authentication radius source-address <address>
Source IPv4 address used in all RADIUS server queires.
Note: The source-address must be configured on one of VyOS interface. Best practice would be a loopback or
dummy interface.
set vpn l2tp remote-access authentication radius server <server> port <port>
Configure RADIUS <server> and its required port for authentication requests.
set vpn l2tp remote-access authentication radius server <server> fail-time <time>
Mark RADIUS server as offline for this given <time> in seconds.
set vpn l2tp remote-access authentication radius server <server> disable
Temporary disable this RADIUS server.
set vpn l2tp remote-access authentication radius acct-timeout <timeout>
Timeout to wait reply for Interim-Update packets. (default 3 seconds)
set vpn l2tp remote-access authentication radius dynamic-author server <address>
Specifies IP address for Dynamic Authorization Extension server (DM/CoA)
set vpn l2tp remote-access authentication radius dynamic-author port <port>
Port for Dynamic Authorization Extension server (DM/CoA)
set vpn l2tp remote-access authentication radius dynamic-author key <secret>
Secret for Dynamic Authorization Extension server (DM/CoA)
set vpn l2tp remote-access authentication radius max-try <number>
Maximum number of tries to send Access-Request/Accounting-Request queries
set vpn l2tp remote-access authentication radius timeout <timeout>
Timeout to wait response from server (seconds)
set vpn l2tp remote-access authentication radius nas-identifier <identifier>
Value to send to RADIUS server in NAS-Identifier attribute and to be matched in DM/CoA requests.
set vpn l2tp remote-access authentication radius nas-ip-address <address>
Value to send to RADIUS server in NAS-IP-Address attribute and to be matched in DM/CoA requests. Also
DM/CoA server will bind to that address.
set vpn l2tp remote-access authentication radius source-address <address>
Source IPv4 address used in all RADIUS server queires.
set vpn l2tp remote-access authentication radius rate-limit attribute <attribute>
Specifies which RADIUS server attribute contains the rate limit information. The default attribute is Filter-Id.
Note: If you set a custom RADIUS attribute you must define it on both dictionaries at RADIUS server and client.
If the RADIUS server sends the attribute Framed-IP-Address then this IP address will be allocated to the client and
the option default-pool within the CLI config is being ignored.
If the RADIUS server sends the attribute Framed-Pool, IP address will be allocated from a predefined IP pool whose
name equals the attribute value.
If the RADIUS server sends the attribute Stateful-IPv6-Address-Pool, IPv6 address will be allocated from a
predefined IPv6 pool prefix whose name equals the attribute value.
If the RADIUS server sends the attribute Delegated-IPv6-Prefix-Pool, IPv6 delegation pefix will be allocated
from a predefined IPv6 pool delegate whose name equals the attribute value.
User interface can be put to VRF context via RADIUS Access-Accept packet, or change it via RADIUS CoA.
Accel-VRF-Name is used from these purposes. It is custom ACCEL-PPP attribute. Define it in your RADIUS server.
If the RADIUS server uses the attribute NAS-Port-Id, ppp tunnels will be renamed.
Note: The value of the attribute NAS-Port-Id must be less than 16 characters, otherwise the interface won’t be
renamed.
IPv6
set vpn l2tp remote-access ppp-options ipv6 <require | prefer | allow | deny>
Specifies IPv6 negotiation preference.
• require - Require IPv6 negotiation
• prefer - Ask client for IPv6 negotiation, do not fail if it rejects
• allow - Negotiate IPv6 only if client requests
• deny - Do not negotiate IPv6 (default value)
set vpn l2tp remote-access client-ipv6-pool <IPv6-POOL-NAME> prefix <address> mask
<number-of-bits>
Use this comand to set the IPv6 address pool from which an l2tp client will get an IPv6 prefix of your defined
length (mask) to terminate the l2tp endpoint at their side. The mask length can be set from 48 to 128 bit long,
the default value is 64.
set vpn l2tp remote-access client-ipv6-pool <IPv6-POOL-NAME> delegate <address>
delegation-prefix <number-of-bits>
Use this command to configure DHCPv6 Prefix Delegation (RFC3633) on l2tp. You will have to set your IPv6
pool and the length of the delegation prefix. From the defined IPv6 pool you will be handing out networks of
the defined length (delegation-prefix). The length of the delegation prefix can be set from 32 to 64 bit long.
set vpn l2tp remote-access default-ipv6-pool <IPv6-POOL-NAME>
Use this command to define default IPv6 address pool name.
Scripting
Advanced Options
Monitoring
8.13.3 OpenConnect
OpenConnect-compatible server feature is available from this release. Openconnect VPN supports SSL connection
and offers full network access. SSL VPN network extension connects the end-user system to the corporate network
with access controls based only on network layer information, such as destination IP address and port number. So, it
provides safe communication for all types of device traffic across public networks and private networks, also encrypts
the traffic with SSL protocol.
The remote user will use the openconnect client to connect to the router and will receive an IP address from a VPN
pool, allowing full access to the network.
Configuration
SSL Certificates
We need to generate the certificate which authenticates users who attempt to access the network resource through the
SSL VPN tunnels. The following commands will create a self signed certificates and will be stored in configuration:
We can also create the certificates using Cerbort which is an easy-to-use client that fetches a certificate from Let’s
Encrypt an open certificate authority launched by the EFF, Mozilla, and others and deploys it to a web server.
Server Configuration
Instead of password only authentication, 2FA password authentication + OTP key can be used. Alternatively, OTP au-
thentication only, without a password, can be used. To do this, an OTP configuration must be added to the configuration
above:
For generating an OTP key in VyOS, you can use the CLI command (operational mode):
Verification
Example
Each of the install command should be applied to the configuration and commited before using under the openconnect
configuration:
vyos@vyos# commit
[edit]
vyos@vyos# save
Saving configuration to '/config/config.boot'...
Done
[edit]
Openconnect Configuration
To enable the HTTP security headers in the configuration file, use the command:
First the OTP keys must be generated and sent to the user and to the configuration:
Now when connecting the user will first be asked for the password and then the OTP key.
Warning: When using Time-based one-time password (TOTP) (OTP HOTP-time), be sure that the time on the
server and the OTP token generator are synchronized by NTP
OpenConnect supports a subset of it’s configuration options to be applied on a per user/group basis, for configuration
purposes we refer to this functionality as “Identity based config”. The following OpenConnect Server Manual outlines
the set of configuration options that are allowed. This can be leveraged to apply different sets of configs to different
users or groups of users.
Warning: The above directory and default-config must be a child directory of /config/auth, since files outside this
directory are not persisted after an image upgrade.
Once you commit the above changes you can create a config file in the /config/auth/ocserv/config-per-user directory
that matches a username of a user you have created e.g. “tst”. Now when logging in with the “tst” user the config
options you set in this file will be loaded.
Be sure to set a sane default config in the default config file, this will be loaded in the case that a user is authenticated
and no file is found in the configured directory matching the users username/group.
The same configuration options apply when Identity based config is configured in group mode except that group mode
can only be used with RADIUS authentication.
Warning: OpenConnect server matches the filename in a case sensitive manner, make sure the username/group
name you configure matches the filename exactly.
OpenConnect can be configured to send accounting information to a RADIUS server to capture user session data such
as time of connect/disconnect, data transferred, and so on.
Configure an accounting server and enable accounting with:
Warning: The RADIUS accounting feature must be used with the OpenConnect authentication mode RADIUS.
It cannot be used with local authentication. You must configure the OpenConnect authentication mode to “radius”.
+----------+---------------+---------------------+---------------------+-----------------
˓→+------------------+-------------------+-----------------+-----------------------------
˓→------+
˓→------+
+----------+---------------+---------------------+---------------------+-----------------
˓→+------------------+-------------------+-----------------+-----------------------------
˓→------+
8.13.4 PPTP-Server
The Point-to-Point Tunneling Protocol (PPTP) has been implemented in VyOS only for backwards compatibility. PPTP
has many well known security issues and you should use one of the many other new VPN implementations.
To enable RADIUS based authentication, the authentication mode needs to be changed within the configuration. Pre-
vious settings like the local users, still exists within the configuration, however they are not used if the mode has been
changed from local to radius. Once changed back to local, it will use all local accounts again.
set vpn pptp remote-access authentication radius server <server> key <secret>
Configure RADIUS <server> and its required shared <secret> for communicating with the RADIUS server.
Since the RADIUS server would be a single point of failure, multiple RADIUS servers can be setup and will be used
subsequentially. For example:
set vpn pptp remote-access authentication radius server 10.0.0.1 key 'foo'
set vpn pptp remote-access authentication radius server 10.0.0.2 key 'foo'
Note: Some RADIUS severs use an access control list which allows or denies queries, make sure to add your VyOS
router to the allowed client list.
If you are using OSPF as IGP, always the closest interface connected to the RADIUS server is used. You can bind all
outgoing RADIUS requests to a single source IP e.g. the loopback interface.
set vpn pptp remote-access authentication radius source-address <address>
Source IPv4 address used in all RADIUS server queires.
Note: The source-address must be configured on one of VyOS interface. Best practice would be a loopback or
dummy interface.
set vpn pptp remote-access authentication radius server <server> port <port>
Configure RADIUS <server> and its required port for authentication requests.
set vpn pptp remote-access authentication radius server <server> fail-time <time>
Mark RADIUS server as offline for this given <time> in seconds.
set vpn pptp remote-access authentication radius server <server> disable
Temporary disable this RADIUS server.
set vpn pptp remote-access authentication radius acct-timeout <timeout>
Timeout to wait reply for Interim-Update packets. (default 3 seconds)
set vpn pptp remote-access authentication radius dynamic-author server <address>
Specifies IP address for Dynamic Authorization Extension server (DM/CoA)
set vpn pptp remote-access authentication radius dynamic-author port <port>
Port for Dynamic Authorization Extension server (DM/CoA)
set vpn pptp remote-access authentication radius dynamic-author key <secret>
Secret for Dynamic Authorization Extension server (DM/CoA)
set vpn pptp remote-access authentication radius max-try <number>
Maximum number of tries to send Access-Request/Accounting-Request queries
set vpn pptp remote-access authentication radius timeout <timeout>
Timeout to wait response from server (seconds)
set vpn pptp remote-access authentication radius nas-identifier <identifier>
Value to send to RADIUS server in NAS-Identifier attribute and to be matched in DM/CoA requests.
set vpn pptp remote-access authentication radius nas-ip-address <address>
Value to send to RADIUS server in NAS-IP-Address attribute and to be matched in DM/CoA requests. Also
DM/CoA server will bind to that address.
set vpn pptp remote-access authentication radius source-address <address>
Source IPv4 address used in all RADIUS server queires.
set vpn pptp remote-access authentication radius rate-limit attribute <attribute>
Specifies which RADIUS server attribute contains the rate limit information. The default attribute is Filter-Id.
Note: If you set a custom RADIUS attribute you must define it on both dictionaries at RADIUS server and client.
If the RADIUS server sends the attribute Framed-IP-Address then this IP address will be allocated to the client and
the option default-pool within the CLI config is being ignored.
If the RADIUS server sends the attribute Framed-Pool, IP address will be allocated from a predefined IP pool whose
name equals the attribute value.
If the RADIUS server sends the attribute Stateful-IPv6-Address-Pool, IPv6 address will be allocated from a
predefined IPv6 pool prefix whose name equals the attribute value.
If the RADIUS server sends the attribute Delegated-IPv6-Prefix-Pool, IPv6 delegation pefix will be allocated
from a predefined IPv6 pool delegate whose name equals the attribute value.
User interface can be put to VRF context via RADIUS Access-Accept packet, or change it via RADIUS CoA.
Accel-VRF-Name is used from these purposes. It is custom ACCEL-PPP attribute. Define it in your RADIUS server.
If the RADIUS server uses the attribute NAS-Port-Id, ppp tunnels will be renamed.
Note: The value of the attribute NAS-Port-Id must be less than 16 characters, otherwise the interface won’t be
renamed.
IPv6
set vpn pptp remote-access ppp-options ipv6 <require | prefer | allow | deny>
Specifies IPv6 negotiation preference.
• require - Require IPv6 negotiation
• prefer - Ask client for IPv6 negotiation, do not fail if it rejects
• allow - Negotiate IPv6 only if client requests
• deny - Do not negotiate IPv6 (default value)
set vpn pptp remote-access client-ipv6-pool <IPv6-POOL-NAME> prefix <address> mask
<number-of-bits>
Use this comand to set the IPv6 address pool from which an PPTP client will get an IPv6 prefix of your defined
length (mask) to terminate the PPTP endpoint at their side. The mask length can be set from 48 to 128 bit long,
the default value is 64.
set vpn pptp remote-access client-ipv6-pool <IPv6-POOL-NAME> delegate <address>
delegation-prefix <number-of-bits>
Use this command to configure DHCPv6 Prefix Delegation (RFC3633) on PPTP. You will have to set your IPv6
pool and the length of the delegation prefix. From the defined IPv6 pool you will be handing out networks of
the defined length (delegation-prefix). The length of the delegation prefix can be set from 32 to 64 bit long.
set vpn pptp remote-access default-ipv6-pool <IPv6-POOL-NAME>
Use this command to define default IPv6 address pool name.
Scripting
Advanced Options
Monitoring
Troubleshooting
Feb 29 14:58:57 vyos accel-pptp[4629]: :: send [LCP ConfRej id=0 <pcomp> <accomp> < d 3␣
˓→6 >]
Feb 29 14:58:57 vyos accel-pptp[4629]: :: recv [LCP ConfReq id=1 <mru 1400> <magic␣
˓→0142785a>]
Feb 29 14:59:00 vyos accel-pptp[4629]: :: recv [LCP ConfNak id=75 <auth MSCHAP-v2>]
Feb 29 14:59:00 vyos accel-pptp[4629]: :: send [LCP ConfReq id=76 <auth CHAP-md5> <mru␣
˓→1436> <magic 483920bd>]
Feb 29 14:59:00 vyos accel-pptp[4629]: :: recv [LCP ConfNak id=76 <auth MSCHAP-v2>]
Feb 29 14:59:00 vyos accel-pptp[4629]: :: send [LCP ConfReq id=77 <auth MSCHAP-v1> <mru␣
˓→1436> <magic 483920bd>]
Feb 29 14:59:00 vyos accel-pptp[4629]: :: recv [LCP ConfNak id=77 <auth MSCHAP-v2>]
Feb 29 14:59:00 vyos accel-pptp[4629]: :: send [LCP ConfReq id=78 <auth MSCHAP-v2> <mru␣
˓→1436> <magic 483920bd>]
Feb 29 14:59:00 vyos accel-pptp[4629]: :: recv [LCP ConfAck id=78 <auth MSCHAP-v2> <mru␣
˓→1436> <magic 483920bd>]
˓→name="test"]
Feb 29 14:59:00 vyos accel-pptp[4629]: ppp0:test: send [IPCP ConfReq id=3b <addr 10.0.0.
˓→1>]
Feb 29 14:59:00 vyos accel-pptp[4629]: ppp0:test: send [IPCP ConfRej id=6 <dns1 0.0.0.0>
˓→<wins1 0.0.0.0> <dns2 0.0.0.0> <wins2 0.0.0.0>]
Feb 29 14:59:00 vyos accel-pptp[4629]: ppp0:test: recv [LCP ProtoRej id=7 <80fd>]
Feb 29 14:59:00 vyos accel-pptp[4629]: ppp0:test: ccp_layer_finished
Feb 29 14:59:00 vyos accel-pptp[4629]: ppp0:test: recv [IPCP ConfAck id=3b <addr 10.0.0.
˓→1>]
Feb 29 14:59:00 vyos accel-pptp[4629]: ppp0:test: recv [IPCP ConfReq id=8 <addr 0.0.0.0>]
Feb 29 14:59:00 vyos accel-pptp[4629]: ppp0:test: send [IPCP ConfNak id=8 <addr 10.0.0.2>
˓→]
8.13.5 RSA-Keys
RSA can be used for services such as key exchanges and for encryption purposes. To make IPSec work with dynamic
address on one/both sides, we will have to use RSA keys for authentication. They are very fast and easy to setup.
First, on both routers run the operational command “generate pki key-pair install <key-pair nam>>”. You may choose
different length than 2048 of course.
Configuration commands will display. Note the command with the public key (set pki key-pair ipsec-LEFT public key
‘MIIBIjANBgkqh. . . ’). Then do the same on the opposite router:
Note the command with the public key (set pki key-pair ipsec-RIGHT public key ‘FAAOCAQ8AMII. . . ’).
The noted public keys should be entered on the opposite routers.
On the LEFT:
On the RIGHT:
set vpn ipsec site-to-site peer @RIGHT tunnel 1 remote prefix 192.168.99.2/32 #␣
˓→Additional loopback address on the remote
set vpn ipsec site-to-site peer 192.0.2.10 tunnel 1 remote prefix 192.168.99.1/32 #␣
˓→Additional loopback address on the remote
SSTP is a form of VPN (Virtual Private Network) tunnel that provides a mechanism to transport PPP traffic through
an SSL/TLS channel. SSL/TLS provides transport-level security with key negotiation, encryption and traffic integrity
checking. The use of SSL/TLS over TCP port 443 allows SSTP to pass through virtually all firewalls and proxy servers
except for authenticated web proxies.
SSTP is available for Linux, BSD, and Windows.
VyOS utilizes accel-ppp to provide SSTP server functionality. We support both local and RADIUS authentication.
As SSTP provides PPP via a SSL/TLS channel the use of either publically signed certificates as well as a private PKI
is required.
Certificates
Using our documentation chapter - PKI generate and install CA and Server certificate
Configuration
To enable RADIUS based authentication, the authentication mode needs to be changed within the configuration. Pre-
vious settings like the local users, still exists within the configuration, however they are not used if the mode has been
changed from local to radius. Once changed back to local, it will use all local accounts again.
Note: Some RADIUS severs use an access control list which allows or denies queries, make sure to add your VyOS
router to the allowed client list.
If you are using OSPF as IGP, always the closest interface connected to the RADIUS server is used. You can bind all
outgoing RADIUS requests to a single source IP e.g. the loopback interface.
set vpn sstp authentication radius source-address <address>
Source IPv4 address used in all RADIUS server queires.
Note: The source-address must be configured on one of VyOS interface. Best practice would be a loopback or
dummy interface.
Note: If you set a custom RADIUS attribute you must define it on both dictionaries at RADIUS server and client.
If the RADIUS server sends the attribute Framed-IP-Address then this IP address will be allocated to the client and
the option default-pool within the CLI config is being ignored.
If the RADIUS server sends the attribute Framed-Pool, IP address will be allocated from a predefined IP pool whose
name equals the attribute value.
If the RADIUS server sends the attribute Stateful-IPv6-Address-Pool, IPv6 address will be allocated from a
predefined IPv6 pool prefix whose name equals the attribute value.
If the RADIUS server sends the attribute Delegated-IPv6-Prefix-Pool, IPv6 delegation pefix will be allocated
from a predefined IPv6 pool delegate whose name equals the attribute value.
User interface can be put to VRF context via RADIUS Access-Accept packet, or change it via RADIUS CoA.
Accel-VRF-Name is used from these purposes. It is custom ACCEL-PPP attribute. Define it in your RADIUS server.
If the RADIUS server uses the attribute NAS-Port-Id, ppp tunnels will be renamed.
Note: The value of the attribute NAS-Port-Id must be less than 16 characters, otherwise the interface won’t be
renamed.
IPv6
Scripting
Advanced Options
Once you have setup your SSTP server there comes the time to do some basic testing. The Linux client used for testing
is called sstpc. sstpc requires a PPP configuration/peer file.
If you use a self-signed certificate, do not forget to install CA on the client side.
The following PPP configuration tests MSCHAP-v2:
$ cat /etc/ppp/peers/vyos
usepeerdns
#require-mppe
#require-pap
require-mschap-v2
noauth
lock
refuse-pap
refuse-eap
refuse-chap
refuse-mschap
#refuse-mschap-v2
nobsdcomp
nodeflate
debug
You can now “dial” the peer with the follwoing command: sstpc --log-level 4 --log-stderr --user vyos
--password vyos vpn.example.com -- call vyos.
A connection attempt will be shown as:
link/ppp promiscuity 0
inet 100.64.2.2 peer 100.64.1.1/32 scope global ppp0
valid_lft forever preferred_lft forever
Monitoring
Troubleshooting
Feb 28 17:03:04 vyos accel-sstp[2492]: :: recv [LCP ConfReq id=0 <mru 4091> <magic␣
˓→345f64ca> <pcomp> <accomp> < d 3 6 >]
Feb 28 17:03:04 vyos accel-sstp[2492]: :: send [LCP ConfRej id=0 <pcomp> <accomp> < d 3␣
˓→6 >]
Feb 28 17:03:04 vyos accel-sstp[2492]: :: recv [LCP ConfReq id=1 <mru 4091> <magic␣
˓→345f64ca>]
Feb 28 17:03:04 vyos accel-sstp[2492]: :: send [LCP ConfNak id=1 <mru 1452>]
Feb 28 17:03:04 vyos accel-sstp[2492]: :: recv [LCP ConfReq id=2 <mru 1452> <magic␣
˓→345f64ca>]
Feb 28 17:03:07 vyos accel-sstp[2492]: :: recv [LCP ConfAck id=56 <auth PAP> <mru 1452>
˓→<magic 1cd9ad05>]
Feb 28 17:03:07 vyos accel-sstp[2492]: ppp0:test: send [IPCP ConfReq id=25 <addr 10.0.0.
˓→1>]
Feb 28 17:03:07 vyos accel-sstp[2492]: ppp0:test: send [IPCP ConfRej id=7 <dns1 0.0.0.0>
˓→<wins1 0.0.0.0> <dns2 0.0.0.0> <wins2 0.0.0.0>]
Feb 28 17:03:07 vyos accel-sstp[2492]: ppp0:test: recv [IPCP ConfAck id=25 <addr 10.0.0.
˓→1>]
Feb 28 17:03:07 vyos accel-sstp[2492]: ppp0:test: recv [IPCP ConfReq id=8 <addr 0.0.0.0>]
Feb 28 17:03:07 vyos accel-sstp[2492]: ppp0:test: send [IPCP ConfNak id=8 <addr 10.0.0.5>
˓→]
Feb 28 17:03:07 vyos accel-sstp[2492]: ppp0:test: recv [IPCP ConfReq id=9 <addr 10.0.0.5>
˓→]
pages to sort
8.13.7 DMVPN
DMVPN (Dynamic Multipoint Virtual Private Network) is a dynamic VPN technology originally developed by Cisco.
While their implementation was somewhat proprietary, the underlying technologies are actually standards based. The
three technologies are:
• NHRP (Next Hop Resolution Protocol) RFC 2332
• mGRE (Multipoint Generic Routing Encapsulation) RFC 1702
• IPSec (IP Security) - too many RFCs to list, but start with RFC 4301
NHRP provides the dynamic tunnel endpoint discovery mechanism (endpoint registration, and endpoint discov-
ery/lookup), mGRE provides the tunnel encapsulation itself, and the IPSec protocols handle the key exchange, and
crypto mechanism.
In short, DMVPN provides the capability for creating a dynamic-mesh VPN network without having to pre-configure
(static) all possible tunnel end-point peers.
Note: DMVPN only automates the tunnel endpoint discovery and setup. A complete solution also incorporates the
use of a routing protocol. BGP is particularly well suited for use with DMVPN.
Configuration
• Please refer to the Tunnel documentation for the individual tunnel related options.
• Please refer to the IPsec documentation for the individual IPSec related options.
set protocols nhrp tunnel <tunnel> cisco-authentication <secret>
Enables Cisco style authentication on NHRP packets. This embeds the secret plaintext password to the outgoing
NHRP packets. Incoming NHRP packets on this interface are discarded unless the secret password is present.
Maximum length of the secret is 8 characters.
set protocols nhrp tunnel <tunnel> dynamic-map <address> nbma-domain-name <fqdn>
Specifies that the NBMA (Non-broadcast multiple-access network) addresses of the next hop servers are defined
in the domain name nbma-domain-name. For each A record opennhrp creates a dynamic NHS entry.
Each dynamic NHS will get a peer entry with the configured network address and the discovered NBMA address.
The first registration request is sent to the protocol broadcast address, and the server’s real protocol address is
dynamically detected from the first registration reply.
set protocols nhrp tunnel <tunnel> holding-time <timeout>
Specifies the holding time for NHRP Registration Requests and Resolution Replies sent from this interface or
shortcut-target. The holdtime is specified in seconds and defaults to two hours.
set protocols nhrp tunnel <tunnel> map cisco
If the statically mapped peer is running Cisco IOS, specify the cisco keyword. It is used to fix statically the
Registration Request ID so that a matching Purge Request can be sent if NBMA address has changed. This is
to work around broken IOS which requires Purge Request ID to match the original Registration Request ID.
set protocols nhrp tunnel <tunnel> map nbma-address <address>
Creates static peer mapping of protocol-address to NBMA address.
If the IP prefix mask is present, it directs opennhrp to use this peer as a next hop server when sending Resolution
Requests matching this subnet.
This is also known as the HUBs IP address or FQDN.
set protocols nhrp tunnel <tunnel> map register
The optional parameter register specifies that Registration Request should be sent to this peer on startup.
This option is required when running a DMVPN spoke.
set protocols nhrp tunnel <tunnel> multicast <dynamic | nhs>
Determines how opennhrp daemon should soft switch the multicast traffic. Currently, multicast traffic is captured
by opennhrp daemon using a packet socket, and resent back to proper destinations. This means that multicast
packet sending is CPU intensive.
Specfying nhs makes all multicast packets to be repeated to each statically configured next hop.
Synamic instructs to forward to all peers which we have a direct connection with. Alternatively, you can specify
the directive multiple times for each protocol-address the multicast traffic should be sent to.
Warning: It is very easy to misconfigure multicast repeating if you have multiple NHSes.
Example
This blueprint uses VyOS as the DMVPN Hub and Cisco (7206VXR) and VyOS as multiple spoke sites. The lab was
build using EVE-NG (Emulated Virtual Environment NG).
Each node (Hub and Spoke) uses an IP address from the network 172.16.253.128/29.
The below referenced IP address 192.0.2.1 is used as example address representing a global unicast address under
which the HUB can be contacted by each and every individual spoke.
Configuration
Hub
Note: Setting this up on AWS will require a “Custom Protocol Rule” for protocol number “47” (GRE) Allow Rule in
TWO places. Firstly on the VPC Network ACL, and secondly on the security group network ACL attached to the EC2
instance. This has been tested as working for the official AMI image on the AWS Marketplace. (Locate the correct
VPC and security group by navigating through the details pane below your EC2 instance in the AWS console).
Spoke
The individual spoke configurations only differ in the local IP address on the tun10 interface. See the above diagram
for the individual IP addresses.
spoke01-spoke04
spoke05
8.13.8 Site-to-Site
Site-to-site mode provides a way to add remote peers, which could be configured to exchange encrypted information
between them and VyOS itself or connected/routed networks.
To configure site-to-site connection you need to add peers with the set vpn ipsec site-to-site peer <name>
command.
The peer name must be an alphanumeric and can have hypen or underscore as special characters. It is purely informa-
tional.
Each site-to-site peer has the next options:
• authentication - configure authentication between VyOS and a remote peer. If pre-shared-secret mode is
used, the secret key must be defined in set vpn ipsec authentication and suboptions:
• psk - Preshared secret key name:
• dhcp-interface - ID for authentication generated from DHCP address dynamically;
• id - static ID’s for authentication. In general local and remote address <x.x.x.x>,
<h:h:h:h:h:h:h:h> or %any;
• secret - predefined shared secret. Used if configured mode pre-shared-secret;
• local-id - ID for the local VyOS router. If defined, during the authentication it will be send to
remote peer;
• mode - mode for authentication between VyOS and remote peer:
• pre-shared-secret - use predefined shared secret phrase;
• rsa - use simple shared RSA key.
• x509 - use certificates infrastructure for authentication.
• remote-id - define an ID for remote peer, instead of using peer name or address. Useful in case if
the remote peer is behind NAT or if mode x509 is used;
• rsa - options for RSA authentication mode:
• local-key - name of PKI key-pair with local private key
• remote-key - name of PKI key-pair with remote public key
• passphrase - local private key passphrase
• use-x509-id - use local ID from x509 certificate. Cannot be used when id is defined;
• x509 - options for x509 authentication mode:
• ca-certificate - CA certificate in PKI configuration. Using for authenticating remote peer;
• certificate - certificate file in PKI configuration, which will be used for authenticating local router
on remote peer;
• passphrase - private key passphrase, if needed.
• connection-type - how to handle this connection process. Possible variants:
• initiate - does initial connection to remote peer immediately after configuring and after boot. In this mode
the connection will not be restarted in case of disconnection, therefore should be used only together with DPD
or another session tracking methods;
• respond - does not try to initiate a connection to a remote peer. In this mode, the IPSec session will be established
only after initiation from a remote peer. Could be useful when there is no direct connectivity to the peer due to
firewall or NAT in the middle of the local and remote side.
• none - loads the connection only, which then can be manually initiated or used as a responder configuration.
• default-esp-group - ESP group to use by default for traffic encryption. Might be overwritten by individual
settings for tunnel or VTI interface binding;
• description - description for this peer;
• dhcp-interface - use an IP address, received from DHCP for IPSec connection with this peer, instead of
local-address;
• force-udp-encapsulation - force encapsulation of ESP into UDP datagrams. Useful in case if between local
and remote side is firewall or NAT, which not allows passing plain ESP packets between them;
• ike-group - IKE group to use for key exchanges;
• ikev2-reauth - reauthenticate remote peer during the rekeying process. Can be used only with IKEv2. Create
a new IKE_SA from the scratch and try to recreate all IPsec SAs;
• local-address - local IP address for IPSec connection with this peer. If defined any, then an IP address which
configured on interface with default route will be used;
• remote-address - remote IP address or hostname for IPSec connection. IPv4 or IPv6 address is used when a
peer has a public static IP address. Hostname is a DNS name which could be used when a peer has a public IP
address and DNS name, but an IP address could be changed from time to time.
• replay-window - IPsec replay window to configure for this CHILD_SA (default: 32), a value of 0 disables
IPsec replay protection
• tunnel - define criteria for traffic to be matched for encrypting and send it to a peer:
• disable - disable this tunnel;
• esp-group - define ESP group for encrypt traffic, defined by this tunnel;
• local - define a local source for match traffic, which should be encrypted and send to this peer:
• port - define port. Have effect only when used together with prefix;
• prefix - IP network at local side.
• priority - Add priority for policy-based IPSec VPN tunnels(lowest value more preferable)
• protocol - define the protocol for match traffic, which should be encrypted and send to this peer;
• remote - define the remote destination for match traffic, which should be encrypted and send to this
peer:
• port - define port. Have effect only when used together with prefix;
• prefix - IP network at remote side.
• vti - use a VTI interface for traffic encryption. Any traffic, which will be send to VTI interface will be encrypted
and send to this peer. Using VTI makes IPSec configuration much flexible and easier in complex situation, and
allows to dynamically add/delete remote networks, reachable via a peer, as in this mode router don’t need to
create additional SA/policy for each remote network:
• bind - select a VTI interface to bind to this peer;
• esp-group - define ESP group for encrypt traffic, passed this VTI interface.
• virtual-address - Defines a virtual IP address which is requested by the initiator and one or several IPv4
and/or IPv6 addresses are assigned from multiple pools by the responder.
Examples:
IKEv1
Example:
• WAN interface on eth1
• left subnet: 192.168.0.0/24 site1, server side (i.e. locality, actually there is no client or server roles)
• left local_ip: 198.51.100.3 # server side WAN IP
• right subnet: 10.0.0.0/24 site2,remote office side
• right local_ip: 203.0.113.2 # remote office side WAN IP
# server config
set vpn ipsec authentication psk OFFICE-B id '198.51.100.3'
set vpn ipsec authentication psk OFFICE-B id '203.0.113.2'
set vpn ipsec authentication psk OFFICE-B secret 'SomePreSharedKey'
set vpn ipsec esp-group office-srv-esp lifetime '1800'
set vpn ipsec esp-group office-srv-esp mode 'tunnel'
set vpn ipsec esp-group office-srv-esp pfs 'enable'
set vpn ipsec esp-group office-srv-esp proposal 1 encryption 'aes256'
set vpn ipsec esp-group office-srv-esp proposal 1 hash 'sha1'
set vpn ipsec ike-group office-srv-ike key-exchange 'ikev1'
set vpn ipsec ike-group office-srv-ike lifetime '3600'
set vpn ipsec ike-group office-srv-ike proposal 1 encryption 'aes256'
set vpn ipsec ike-group office-srv-ike proposal 1 hash 'sha1'
set vpn ipsec interface 'eth1'
set vpn ipsec site-to-site peer OFFICE-B authentication local-id '198.51.100.3'
set vpn ipsec site-to-site peer OFFICE-B authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer OFFICE-B authentication remote-id '203.0.113.2'
set vpn ipsec site-to-site peer OFFICE-B ike-group 'office-srv-ike'
set vpn ipsec site-to-site peer OFFICE-B local-address '198.51.100.3'
set vpn ipsec site-to-site peer OFFICE-B remote-address '203.0.113.2'
set vpn ipsec site-to-site peer OFFICE-B tunnel 0 esp-group 'office-srv-esp'
set vpn ipsec site-to-site peer OFFICE-B tunnel 0 local prefix '192.168.0.0/24'
set vpn ipsec site-to-site peer OFFICE-B tunnel 0 remote prefix '10.0.0.0/21'
# server side
set nat source rule 10 destination address '10.0.0.0/24'
set nat source rule 10 'exclude'
set nat source rule 10 outbound-interface name 'eth1'
set nat source rule 10 source address '192.168.0.0/24'
To allow traffic to pass through to clients, you need to add the following rules. (if you used the default configuration at
the top of this page)
# server side
set firewall name OUTSIDE-LOCAL rule 32 action 'accept'
set firewall name OUTSIDE-LOCAL rule 32 source address '10.0.0.0/24'
IKEv2
Example:
• left local_ip: 192.168.0.10 # VPN Gateway, behind NAT device
• left public_ip:172.18.201.10
• right local_ip: 172.18.202.10 # right side WAN IP
Imagine the following topology
LEFT: * WAN interface on eth0.201 * eth0.201 interface IP: 172.18.201.10/24 * vti10 interface IP: 10.0.0.2/31 * dum0
interface IP: 10.0.11.1/24 (for testing purposes)
RIGHT: * WAN interface on eth0.202 * eth0.201 interface IP: 172.18.202.10/24 * vti10 interface IP: 10.0.0.3/31 *
dum0 interface IP: 10.0.12.1/24 (for testing purposes)
Note: Don’t get confused about the used /31 tunnel subnet. RFC 3021 gives you additional information for using /31
subnets on point-to-point links.
LEFT
RIGHT
Key Parameters:
• authentication local-id/remote-id - IKE identification is used for validation of VPN peer devices during
IKE negotiation. If you do not configure local/remote-identity, the device uses the IPv4 or IPv6 address that
corresponds to the local/remote peer by default. In certain network setups (like ipsec interface with dynamic
address, or behind the NAT ), the IKE ID received from the peer does not match the IKE gateway configured on
the device. This can lead to a Phase 1 validation failure. So, make sure to configure the local/remote id explicitly
and ensure that the IKE ID is the same as the remote-identity configured on the peer device.
• disable-route-autoinstall - This option when configured disables the routes installed in the default table
220 for site-to-site ipsec. It is mostly used with VTI configuration.
• dead-peer-detection action = clear | trap | restart - R_U_THERE notification mes-
sages(IKEv1) or empty INFORMATIONAL messages (IKEv2) are periodically sent in order to check
the liveliness of the IPsec peer. The values clear, trap, and restart all activate DPD and determine the action
to perform on a timeout. With clear the connection is closed with no further actions taken. trap installs a
trap policy, which will catch matching traffic and tries to re-negotiate the connection on demand. restart will
immediately trigger an attempt to re-negotiate the connection.
• close-action = none | clear | trap | start - defines the action to take if the remote peer unexpect-
edly closes a CHILD_SA (see above for meaning of values). A closeaction should not be used if the peer uses
reauthentication or uniqueids.
When the close-action option is set on the peers, the connection-type of each peer has to considered carefully.
For example, if the option is set on both peers, then both would attempt to initiate and hold open multiple copies
of each child SA. This might lead to instability of the device or cpu/memory utilization.
Below flow-chart could be a quick reference for the close-action combination depending on how the peer is
configured.
Internet Key Exchange version 2 (IKEv2) is a tunneling protocol, based on IPsec, that establishes a secure VPN com-
munication between VPN devices, and defines negotiation and authentication processes for IPsec security associations
(SAs). It is often known as IKEv2/IPSec or IPSec IKEv2 remote-access — or road-warriors as others call it.
Key exchange and payload encryption is done using IKE and ESP proposals as known from IKEv1 but the connections
are faster to establish, more reliable, and also support roaming from IP to IP (called MOBIKE which makes sure your
connection does not drop when changing networks from e.g. WIFI to LTE and back). Authentication can be achieved
with X.509 certificates.
Setting up certificates:
First of all, we need to create a CA root certificate and server certificate on the server side.
[email protected]# comp
[pki ca]
+ ca_root {
+ certificate "MIIDnTCCAoWgAwI...."
+ private {
+ key "MIIEvAIBADANBgkqhkiG9....”
[email protected]# comp
[pki certificate]
+ server_cert {
+ certificate "MIIDuzCCAqOgAwIBAgIUaSrCPWx........."
+ private {
+ key "MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBK....."
+ }
+ }
Once the command is completed, it will add the certificate to the configuration session, to the pki subtree. You can
Setting up IPSec:
After the PKI certs are all set up we can start configuring our IPSec/IKE proposals used for key-exchange end data
encryption. The used encryption ciphers and integrity algorithms vary from operating system to operating system. The
ones used in this example are validated to work on Windows 10.
Every connection/remote-access pool we configure also needs a pool where we can draw our client IP addresses from.
We provide one IPv4 and IPv6 pool. Authorized clients will receive an IPv4 address from the configured IPv4 prefix
and an IPv6 address from the IPv6 prefix. We can also send some DNS nameservers down to our clients used on their
connection.
Setting up tunnel:
VyOS also supports two different modes of authentication, local and RADIUS. To create a new local user named “vyos”
with a password of “vyos” use the following commands.
Client Configuration
Most operating systems include native client support for IPsec IKEv2 VPN connections, and others typically have an
app or add-on package which adds the capability. This section covers IPsec IKEv2 client configuration for Windows
10.
VyOS provides a command to generate a connection profile used by Windows clients that will connect to the “rw”
connection on our VyOS server.
Note: Windows expects the server name to be also used in the server’s certificate common name, so it’s best to use
this DNS name for your VPN connection.
Add the commands from Snippet in the Windows side via PowerShell. Also import the root CA cert to the Windows
“Trusted Root Certification Authorities” and establish the connection.
Verification:
8.14 VRF
VRF devices combined with ip rules provides the ability to create virtual routing and forwarding domains (aka VRFs,
VRF-lite to be specific) in the Linux network stack. One use case is the multi-tenancy problem where each tenant has
their own unique routing tables and in the very least need different default gateways.
8.14.1 Configuration
A VRF device is created with an associated route table. Network interfaces are then enslaved to a VRF device.
set vrf name <name>
Create new VRF instance with <name>. The name is used when placing individual interfaces into the VRF.
set vrf name <name> table <id>
Configured routing table <id> is used by VRF <name>.
Note: A routing table ID can not be modified once it is assigned. It can only be changed by deleting and
re-adding the VRF instance.
Zebra supports prefix-lists and Route Maps to match routes received from other FRR components. The permit/deny
facilities provided by these commands can be used to filter which routes zebra will install in the kernel.
set vrf <name> ip protocol <protocol> route-map <route-map>
Apply a route-map filter to routes for the specified protocol.
The following protocols can be used: any, babel, bgp, connected, eigrp, isis, kernel, ospf, rip, static, table
Note: If you choose any as the option that will cause all protocols that are sending routes to zebra.
Note: If you choose any as the option that will cause all protocols that are sending routes to zebra.
Nexthop Tracking
Nexthop tracking resolve nexthops via the default route by default. This is enabled by default for a traditional profile
of FRR which we use. It and can be disabled if you do not want to e.g. allow BGP to peer across the default route.
set vrf name <name> ip nht no-resolve-via-default
Do not allow IPv4 nexthop tracking to resolve via the default route. This parameter is configured per-VRF, so
the command is also available in the VRF subnode.
set vrf name <name> ipv6 nht no-resolve-via-default
Do not allow IPv4 nexthop tracking to resolve via the default route. This parameter is configured per-VRF, so
the command is also available in the VRF subnode.
Interfaces
When VRFs are used it is not only mandatory to create a VRF but also the VRF itself needs to be assigned to an
interface.
set interfaces <dummy | ethernet | bonding | bridge | pppoe> <interface> vrf <name>
Assign interface identified by <interface> to VRF named <name>.
Routing
Note: VyOS 1.4 (sagitta) introduced dynamic routing support for VRFs.
Example
The following commands would be required to set options for a given dynamic routing protocol inside a given vrf:
• BGP: set vrf name <name> protocols bgp ...
• IS-IS: set vrf name <name> protocols isis ...
• OSPF: set vrf name <name> protocols ospf ...
• OSPFv3 (IPv6): set vrf name <name> protocols ospfv3 ...
• Static: set vrf name <name> protocols static ...
8.14.2 Operation
It is not sufficient to only configure a VRF but VRFs must be maintained, too. For VRF maintenance the following
operational commands are in place.
show vrf
Lists VRFs that have been created
Note: Command should probably be extended to list also the real interfaces assigned to this one VRF to get a
better overview.
VRF blue:
K 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:00:50
S>* 172.16.0.0/16 [1/0] via 192.0.2.1, dum1, 00:00:02
C>* 192.0.2.0/24 is directly connected, dum1, 00:00:06
VRF red:
K ::/0 [255/8192] unreachable (ICMP unreachable), 00:43:20
C>* 2001:db8::/64 is directly connected, dum1, 00:02:19
C>* fe80::/64 is directly connected, dum1, 00:43:19
K>* ff00::/8 [0/256] is directly connected, dum1, 00:43:19
Note: Ping command can be interrupted at any given time using <Ctrl>+c. A brief statistic is shown after-
wards.
8.14.3 Example
Configuration
set vrf name blue protocols static route 10.0.0.0/24 interface eth1 vrf
˓→'default'
Configuration
set vrf name blue protocols static route 172.16.50.0/24 interface eth0 vrf 'red
˓→'
set vrf name red protocols static route 0.0.0.0/0 next-hop 172.16.50.1
set vrf name red protocols static route 192.168.130.0/24 interface eth1 vrf
˓→'blue'
Operation
After committing the configuration we can verify all leaked routes are installed, and try to ICMP ping PC1 from PC3.
VPCS> show ip
NAME : VPCS[1]
IP/MASK : 10.30.0.1/24
GATEWAY : 10.30.0.254
DNS :
MAC : 00:50:79:66:68:0f
S>* 10.30.0.0/24 [1/0] is directly connected, br10 (vrf red), weight 1,␣
˓→00:07:38
VRF red:
K>* 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:07:57
S>* 10.0.0.0/24 [1/0] is directly connected, eth1 (vrf default), weight 1,␣
˓→00:07:40
VRF blue:
K>* 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:08:00
S>* 10.0.0.0/24 [1/0] is directly connected, eth1 (vrf default), weight 1,␣
˓→00:07:44
L3VPN VRFs ( Layer 3 Virtual Private Networks ) bgpd supports for IPv4 RFC 4364 and IPv6 RFC 4659. L3VPN
routes, and their associated VRF MPLS labels, can be distributed to VPN SAFI neighbors in the default, i.e., non VRF,
BGP instance. VRF MPLS labels are reached using core MPLS labels which are distributed using LDP or BGP labeled
unicast. bgpd also supports inter-VRF route leaking.
BGP routes may be leaked (i.e. copied) between a unicast VRF RIB and the VPN SAFI RIB of the default VRF for
use in MPLS-based L3VPNs. Unicast routes may also be leaked between any VRFs (including the unicast RIB of the
default BGP instance). A shortcut syntax is also available for specifying leaking from one VRF to another VRF using
the default instance’s VPN RIB as the intemediary . A common application of the VRF-VRF feature is to connect a
customer’s private routing domain to a provider’s VPN service. Leaking is configured from the point of view of an
individual VRF: import refers to routes leaked from VPN to a unicast VRF, whereas export refers to routes leaked from
a unicast VRF to VPN.
Note: Routes exported from a unicast VRF to the VPN RIB must be augmented by two parameters:
an RD / RTLIST
Configuration for these exported routes must, at a minimum, specify these two parameters.
8.15.2 Configuration
Configuration of route leaking between a unicast VRF RIB and the VPN SAFI RIB of the default VRF is accomplished
via commands in the context of a VRF address-family.
set vrf name <name> protocols bgp address-family <ipv4-unicast|ipv6-unicast> rd vpn
export <asn:nn|address:nn>
Specifies the route distinguisher to be added to a route exported from the current unicast VRF to VPN.
set vrf name <name> protocols bgp address-family <ipv4-unicast|ipv6-unicast> route-target
vpn <import|export|both> [RTLIST]
Specifies the route-target list to be attached to a route (export) or the route-target list to match against (import)
when exporting/importing between the current unicast VRF and VPN.The RTLIST is a space-separated list of
route-targets, which are BGP extended community values as described in Extended Communities Attribute.
set vrf name <name> protocols bgp address-family <ipv4-unicast|ipv6-unicast> label vpn
export <0-1048575|auto>
Enables an MPLS label to be attached to a route exported from the current unicast VRF to VPN. If the value
specified is auto, the label value is automatically assigned from a pool maintained.
set vrf name <name> protocols bgp address-family <ipv4-unicast|ipv6-unicast> label vpn
allocation-mode per-nexthop
Select how labels are allocated in the given VRF. By default, the per-vrf mode is selected, and one label is used
for all prefixes from the VRF. The per-nexthop will use a unique label for all prefixes that are reachable via the
same nexthop.
set vrf name <name> protocols bgp address-family <ipv4-unicast|ipv6-unicast> route-map
vpn <import|export> [route-map <name>]
Specifies an optional route-map to be applied to routes imported or exported between the current unicast VRF
and VPN.
set vrf name <name> protocols bgp address-family <ipv4-unicast|ipv6-unicast>
<import|export> vpn
Enables import or export of routes between the current unicast VRF and VPN.
set vrf name <name> protocols bgp address-family <ipv4-unicast|ipv6-unicast> import vrf
<name>
Shortcut syntax for specifying automatic leaking from vrf VRFNAME to the current VRF using the VPN RIB
as intermediary. The RD and RT are auto derived and should not be specified explicitly for either the source or
destination VRF’s.
set vrf name <name> protocols bgp interface <interface> mpls forwarding
It is possible to permit BGP install VPN prefixes without transport labels. This configuration will install VPN
prefixes originated from an e-bgp session, and with the next-hop directly connected.
8.15.3 Operation
It is not sufficient to only configure a L3VPN VRFs but L3VPN VRFs must be maintained, too.For L3VPN VRF
maintenance the following operational commands are in place.
show bgp <ipv4|ipv6> vpn
Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
NINE
OPERATION MODE
9.1 Information
VyOS features a rich set of operational level commands to retrieve arbitrary information about your running system.
9.1.1 Hardware
USB
In the past serial interface have been defined as ttySx and ttyUSBx where x was an instance number of the serial
interface. It was discovered that from system boot to system boot the mapping of USB based serial interfaces will
differ, depending which driver was loaded first by the operating system. This will become rather painful if you not only
have serial interfaces for a console server connected but in addition also a serial backed WWAN - Wireless Wide-Area-
Network.
To overcome this issue and the fact that in almost 50% of all cheap USB to serial converters there is no serial number
programmed, the USB to serial interface is now directly identified by the USB root bridge and bus it connects to. This
somehow mimics the new network interface definitions we see in recent Linux distributions.
For additional details you can refer to https://vyos.dev/T2490.
show hardware usb
Retrieve a tree like representation of all connected USB devices.
Note: If a device is unplugged and re-plugged it will receive a new Port, Dev, If identification.
1053
VyOS Documentation, Release 1.5.x (circinus)
9.1.2 Version
show version
Return the current running VyOS version and build information. This includes also the name of the release train
which is crux on VyOS 1.2, equuleus on VyOS 1.3 and sagitta on VyOS 1.4.
Architecture: x86_64
Boot via: installed image
System type: KVM guest
Warning: This function may be highly disruptive. It may cause major service interruption, so make sure you
really need it and verify your input carefully.
VyOS has several kernel command line options to modify the normal boot process. To add an option, select the desired
image in GRUB menu at load time, press e, edit the first line, and press Ctrl-x to boot when ready.
Tells the system to use specified file instead of /config/config.boot. If specified file does not exist or is not
readable, fall back to default config. No additional verification is performed, so make sure you specify a valid config
file.
vyos-config=/path/to/file
vyos-config=/opt/vyatta/etc/config.boot.default
These options disable some boot steps. Make sure you understand the boot process well before using them!
no-vyos-migrate
Do not perform config migration.
no-vyos-firewall
Do not initialize default firewall chains, renders any firewall configuration unusable.
Using the console, restart the VyOS router. The GRUB menu appears. Select the relevant option from the GRUB menu
and press Enter. The option must start with “Lost password change.”
The stand-alone user-password recovery tool starts running and prompts you to reset the local system user password.
9.4 RAID-1
A Redundant Array of Independent Disks (RAID) uses two or more hard disk drives to improve disk speed, store
more data, and/or provide fault tolerance. There are several storage schemes possible in a RAID array, each offering a
different combination of storage, reliability, and/or performance. The VyOS system supports a “RAID 1” deployment.
RAID 1 allows two or more disks to mirror one another to provide system fault tolerance. In a RAID 1 solution, every
sector of one disk is duplicated onto every sector of all disks in the array. Provided even one disk in the RAID 1 set is
operational, the system continues to run, even through disk replacement (provided that the hardware supports in-service
replacement of drives). RAID 1 can be implemented using special hardware or it can be implemented in software. The
VyOS system supports software RAID 1 on two disks. The VyOS implementation of RAID 1 allows the following:
• Detection and reporting of disk failure
• The ability to maintain system operation with one failed disk
• The ability to boot the system with one failed disk
• The ability to replace a failed disk and initiate re-mirroring
• The ability to monitor the status of remirroring
The VyOS systems installation utility provides several options for installing to a RAID 1 set. You can:
• Use the install system to create the RAID 1 set
• Use the underlying Linux commands to create a RAID 1 set before running the install system command.
• Use a previously-created RAID 1 set.
9.4.2 Configuration
When the VyOS system is installed, it automatically detects the presence of two disks not currently part of a RAID
array. In these cases, the VyOS installation utility automatically offers you the option of configuring RAID 1 mirroring
for the drives, with the following prompt.
• If you do not want to configure RAID 1 mirroring, enter “No” at the prompt and continue with installation in the
normal way.
Empty 2+ Disk
If VyOS system detect two identical disks that are not currently part of a RAID-1 set, the VyOS installation utility
automatically offers you the option of configuring RAID 1 mirroring for the drives, with the following prompt.
1 - To create a new RAID 1 array, enter “Yes” at the prompt. If the system detects a filesystem on the partitions being
used for RAID 1 it will prompt you to indicate whether you want to continue creating the RAID 1 array.
4 - Enter “Yes” at the prompt to retain the current VyOS configuration once installation is complete. Enter “No” to
delete the current VyOS configuration.
5 - Enter “Yes” at the prompt to retain the current VyOS configuration once installation is complete. Enter “No” to
delete the current VyOS configuration.
6 - Continue with installation in the normal way.
Present RAID-1
When the VyOS software on a system with a RAID 1 set already configured, the installation utility will detect the array
and will display the following prompt:
1 - To break apart the current RAID 1 set, enter “No” at the prompt. The
installation utility detects that there are two identical disks and offers you the option of configuring RAID 1 mirroring
on them, displaying the following prompt:
2 - To decline to set up a new RAID 1 configuration on the disks, enter “No” at the prompt. The system prompts you
to indicate which partition you would like the system installed on.
3 - Enter the partition where you would like the system installed. The system then prompts you to indicate whether you
want to save the old configuration data. This represents the current VyOS configuration.
4 - Enter “Yes” at the prompt to retain the current VyOS configuration once installation is complete. Enter “No” to
delete the current VyOS configuration.
5 - Continue with installation in the normal way.
The VyOS system automatically detects a disk failure within a RAID 1 set and reports it to the system console. You
can verify the failure by issuing the show raid command.
To replace a bad disk within a RAID 1 set, perform the following steps:
1 - Remove the failed disk from the RAID 1 set by issuing the following command:
delete raid <RAID-1-device> member <disk-partition>
where RAID-1-device is the name of the RAID 1 device (for example, md0) and disk-partition is the name of
the failed disk partition (for example, sdb2).
2- Physically remove the failed disk from the system. If the drives are not hot-swappable, then you must shut down the
system before removing the disk.
3 - Replace the failed drive with a drive of the same size or larger.
4 - Format the new disk for RAID 1 by issuing the following command:
format disk <disk-device1> like <disk-device2>
where disk-device1 is the replacement disk (for example, sdb) and disk-device2 is the existing healthy disk (for
example, sda).
5-Add the replacement disk to the RAID 1 set by issuing the following command:
add raid <RAID-1-device> member <disk-partition>
where RAID-1-device is the name of the RAID 1 device (for example, md0) and disk-partition is the name of
the replacement disk partition (for example, sdb2).
9.4.3 Operation
This part introduces how to add a disk partition to a RAID-1 set initiates mirror synchronization, check and display
information.
add raid <RAID-1-device> member <disk-partition>
Use this command to add a member disk partition to the RAID 1 set. Adding a disk partition to a RAID 1 set
initiates mirror synchronization, where all data on the existing member partition is copied to the new partition.
format disk <disk-device1> like <disk-device2>
This command is typically used to prepare a disk to be added to a preexisting RAID 1 set (of which disk-device2
is already a member).
show raid <RAID-1-device>
shows output for show raid md0 as sdb1 is being added to the RAID 1 set and is in the process of being resyn-
chronized.
TEN
VYOS AUTOMATION
10.1.1 Authentication
All endpoints only listen on HTTP POST requests and the API KEY must set as key in the formdata.
Below see one example for curl and one for python. The rest of the documentation is reduced to curl.
import requests
url = "https://vyos/retrieve"
payload={'data': '{"op": "showConfig", "path": []}',
'key': 'MY-HTTPS-API-PLAINTEXT-KEY'
}
headers = {}
response = requests.request("POST", url, headers=headers, data=payload)
print(response.text)
/retrieve
With the retrieve endpoint you get parts or the whole configuration.
To get the whole configuration, pass an empty list to the path field
response (shorted)
{
(continues on next page)
1061
VyOS Documentation, Release 1.5.x (circinus)
response:
{
"success": true,
"data": {
"global": {
"facility": {
"all": {
"level": "info"
},
"protocols": {
"level": "debug"
}
}
}
},
"error": null
}
if you just want the Value of a multi-valued node, use the returnValues operation.
For example, get the addresses of a dum0 interface.
respone:
(continues on next page)
response:
{
"success": true,
"data": true,
"error": null
}
response:
{
"success": true,
"data": false,
"error": null
}
/reset
respone:
{
"success": true,
"data": "",
"error": null
}
/reboot
respone:
{
"success": true,
"data": "",
"error": null
}
/poweroff
respone:
{
"success": true,
"data": "",
"error": null
}
/image
--form key='MY-HTTPS-API-PLAINTEXT-KEY'
respone (shorted):
{
"success": true,
"data": "Trying to fetch ISO file from https://downloads.vyos.io/rolling-latest.iso\n
...
Setting up grub configuration...\nDone.\n",
"error": null
}
response:
{
"success": true,
"data": "Deleting the \"1.3-rolling-202006070117\" image...\nDone\n",
"error": null
}
/show
response:
{
"success": true,
"data": "The system currently has the following image(s) installed:\n\n
1: 1.4-rolling-202102280559 (default boot)\n
2: 1.4-rolling-202102230218\n
3: 1.3-beta-202102210443\n\n",
"error": null
}
/generate
response:
{
"success": true,
"data": "Private key: CFZR2eyhoVZwk4n3JFPMJx3E145f1EYgDM+ubytXYVY=\n
Public key: jjtpPT8ycI1Q0bNtrWuxAkO4k88Xwzg5VHV9xGZ58lU=\n\n",
"error": null
}
/configure
You can pass a set, delete or comment command to the /configure endpoint.
set a single command
--form key='MY-HTTPS-API-PLAINTEXT-KEY'
response:
{
"success": true,
"data": null,
"error": null
}
--form key='MY-HTTPS-API-PLAINTEXT-KEY'
response:
{
"success": true,
"data": null,
"error": null
}
The API pushes every request to a session and commit it. But some of VyOS components like DHCP and PPPoE
Servers, IPSec, VXLAN, and other tunnels require full configuration for commit. The endpoint will process multiple
commands when you pass them as a list to the data field.
--form key='MY-HTTPS-API-PLAINTEXT-KEY'
response:
{
"success": true,
"data": null,
"error": null
}
/config-file
response:
{
"success": true,
"data": "Saving configuration to '/config/config.boot'...\nDone\n",
"error": null
}
response:
{
"success": true,
"data": "Saving configuration to '/config/test.config'...\nDone\n",
"error": null
}
response:
{
"success": true,
"data": null,
"error": null
}
10.2 Ansible
VyOS supports configuration via ansible. Need to install ansible and python3-paramiko module
Structure of files
.
ansible.cfg
files
(continues on next page)
ansible.cfg
[defaults]
host_key_checking = no
retry_files_enabled = False
ANSIBLE_INVENTORY_UNPARSED_FAILED = true
AAAAB3NzaC1yc2EAAAADAQABAAABAQCoDgfhQJuJRFWJijHn7ZinZ3NWp4hWVrt7HFcvn0kgtP/5PeCtMt
hosts
[vyos_hosts]
r11 ansible_ssh_host=192.0.2.11
[vyos_hosts:vars]
ansible_python_interpreter=/usr/bin/python3
ansible_user=vyos
ansible_ssh_pass=vyos
ansible_network_os=vyos
ansible_connection=network_cli
main.yml
---
- hosts: r11
connection: network_cli
gather_facts: 'no'
tasks:
- name: Configure remote r11
vyos_config:
lines:
- set system host-name r11
- set system name-server 203.0.113.254
- set service ssh disable-host-validation
- set system login user vyos authentication public-keys docker@work type ssh-
˓→rsa
- set system login user vyos authentication public-keys docker@work key "{{␣
˓→lookup('file', 'id_rsa_docker.pub') }}"
PLAY [r11]␣
˓→******************************************************************************************************
changed: [r11]
PLAY RECAP␣
˓→******************************************************************************************************
VyOS supports development infrastructure via Terraform and provisioning via Ansible. Terraform allows you to au-
tomate the process of deploying instances on many cloud and virtual platforms. In this article, we will look at using
terraforms to deploy VyOS on platforms - AWS, Azure, and vSphere. For more details about Terraform please have a
look here link.
Need to install Terraform
Structure of files in the standard Terraform project:
.
main.tf # The main script
version.tf # File for the changing version of Terraform.
variables.tf # The file of all variables in "main.tf"
terraform.tfvars # The value of all variables (passwords, login, ip adresses and␣
˓→so on)
With the help of Terraform, you can quickly deploy VyOS-based infrastructure in the AWS cloud. If necessary, the
infrastructure can be removed using terraform. Also we will make provisioning using Ansible.
In this case, we’ll create the necessary files for Terraform and Ansible next using Terraform we’ll create a single instance
on the AWS cloud and make provisioning using Ansible.
How to create a single instance and install your configuration using Terraform+Ansible+AWS Step by step:
AWS
1 Create an account with AWS and get your “access_key”, “secret key”
2 Create a key pair and download your .pem key
Terraform
1 Create an UNIX or Windows instance
2 Download and install Terraform
3 Create the folder for example /root/awsterraform
mkdir /root/awsterraform
4 Copy all files into your Terraform project "/root/awsterraform" (vyos.tf, var.tf,␣
˓→terraform.tfvars,version.tf), more detailed see `Structure of files Terrafom for AWS`_
cd /<your folder>
terraform init
Ansible
1 Create an UNIX instance whenever you want (local, cloud, and so on)
2 Download and install Ansible
3 Create the folder for example /root/aws/
4 Copy all files into your Ansible project “/root/aws/” (ansible.cfg, instance.yml, mykey.pem and “all”),
more detailed see Structure of files Ansible for AWS
mykey.pem you have to get using step 1.2
Start
Type the commands on your Terrafom instance:
cd /<your folder>
terraform plan
terraform apply
yes
Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
+ create
Changes to Outputs:
+ my_IP = (known after apply)
aws_instance.myVyOSec2: Creating...
aws_instance.myVyOSec2: Still creating... [10s elapsed]
aws_instance.myVyOSec2: Still creating... [20s elapsed]
aws_instance.myVyOSec2: Still creating... [30s elapsed]
aws_instance.myVyOSec2: Still creating... [40s elapsed]
aws_instance.myVyOSec2: Creation complete after 44s [id=i-09edfca15aac2fe0a]
null_resource.SSHconnection1: Creating...
null_resource.SSHconnection2: Creating...
null_resource.SSHconnection1: Provisioning with 'file'...
null_resource.SSHconnection2: Provisioning with 'remote-exec'...
null_resource.SSHconnection2 (remote-exec): Connecting to remote host via SSH...
null_resource.SSHconnection2 (remote-exec): Host: 10.217.80.104
null_resource.SSHconnection2 (remote-exec): User: root
null_resource.SSHconnection2 (remote-exec): Password: true
null_resource.SSHconnection2 (remote-exec): Private key: false
null_resource.SSHconnection2 (remote-exec): Certificate: false
null_resource.SSHconnection2 (remote-exec): SSH Agent: false
null_resource.SSHconnection2 (remote-exec): Checking Host Key: false
null_resource.SSHconnection2 (remote-exec): Target Platform: unix
local_file.ip: Creating...
local_file.ip: Creation complete after 0s [id=e8e91f2e24579cd28b92e2d152c0c24c3bf4b52c]
null_resource.SSHconnection2 (remote-exec): Connected!
null_resource.SSHconnection1: Creation complete after 0s [id=7070868940858935600]
Outputs:
my_IP = "54.xxx.xxx.xxx"
After executing all the commands you will have your VyOS instance on the AWS cloud with your configuration, it’s a
very convenient desition. If you need to delete the instance please type the command:
terraform destroy
Troubleshooting
1 Ansible doesn’t connect via SSH to your AWS instance: you have to check that your SSH key has copied
into the path /root/aws/.
Also, increase the time in the file instance.yml from 300 sec to 500 sec or more. (It depends on your location). Make
sure that you have opened access to the instance in the security group.
2 Terraform doesn’t connect via SSH to your Ansible instance: you have to check the correct login and
password in the part of the file VyOS. tf
connection {
type = "ssh"
user = "root" # open root access using login and password on your␣
˓→Ansible
.
vyos.tf # The main script
var.tf # The file of all variables in "vyos.tf"
versions.tf # File for the changing version of Terraform.
terraform.tfvars # The value of all variables (passwords, login, ip␣
˓→adresses and so on)
vyos.tf
##############################################################################
# Build an VyOS VM from the Marketplace
# To finde nessesery AMI image_ in AWS
#
# In the script vyos.tf we'll use default values (you can chang it as you need)
# AWS Region = "us-east-1"
# AMI = "standard AMI of VyOS from AWS Marketplace"
# Size of VM = "t2.micro"
# AWS Region = "us-east-1"
# After deploying the AWS instance and getting an IP address, the IP address is copied␣
˓→into the file
provider "aws" {
access_key = var.access
secret_key = var.secret
region = var.region
}
variable "region" {
default = "us-east-1"
description = "AWS Region"
}
variable "ami" {
default = "ami-**************3b3" # ami image please enter your␣
˓→details
variable "type" {
default = "t2.micro"
description = "Size of VM"
}
instance_type = var.type
tags = {
name = "VyOS System"
}
}
##############################################################################
# specific variable (to getting type "terraform plan"):
# aws_instance.myVyOSec2.public_ip - the information about public IP address
# of our instance, needs for provisioning and ssh connection from Ansible
##############################################################################
output "my_IP"{
value = aws_instance.myVyOSec2.public_ip
}
##############################################################################
#
# IP of aws instance copied to a file ip.txt in local system Terraform
# ip.txt looks like:
# cat ./ip.txt
# ...
##############################################################################
##############################################################################
# Steps "SSHconnection1" and "SSHconnection2" need to get file ip.txt from the terraform␣
˓→node and start remotely the playbook of Ansible.
##############################################################################
#copying the ip.txt file to the Ansible control node from local system
}
}
]
}
}
var.tf
variable "password" {
description = "pass for Ansible"
type = string
sensitive = true
}
variable "host"{
description = "The IP of my Ansible"
type = string
}
variable "access" {
description = "my access_key for AWS"
type = string
sensitive = true
}
variable "secret" {
description = "my secret_key for AWS"
type = string
sensitive = true
}
versions.tf
terraform {
required_providers {
aws = {
(continues on next page)
terraform.tfvars
.
group_vars
all
ansible.cfg
mykey.pem
instance.yml
ansible.cfg
[defaults]
inventory = /root/aws/ip.txt
host_key_checking= False
private_key_file = /root/aws/awsterraform.pem # check the name
remote_user=vyos
mykey.pem
instance.yml
##############################################################################
# About tasks:
# "Wait 300 seconds, but only start checking after 60 seconds" - try to make ssh␣
˓→connection every 60 seconds until 300 seconds
# "Configure general settings for the VyOS hosts group" - make provisioning into AWS␣
˓→VyOS node
# You have to add all necessary cammans of VyOS under the block "lines:"
##############################################################################
tasks:
- name: "Wait 300 seconds, but only start checking after 60 seconds"
wait_for_connection:
delay: 60
timeout: 300
group_vars/all
ansible_connection: ansible.netcommon.network_cli
ansible_network_os: vyos.vyos.vyos
ansible_user: vyos
With the help of Terraform, you can quickly deploy VyOS-based infrastructure in the Azure cloud. If necessary, the
infrastructure can be removed using terraform. Also we will make provisioning using Ansible.
In this case, we’ll create the necessary files for Terraform and Ansible next using Terraform we’ll create a single instance
on the Azure cloud and make provisioning using Ansible.
How to create a single instance and install your configuration using Terraform+Ansible+Azure Step by step:
Azure
1 Create an account with Azure
Terraform
1 Create an UNIX or Windows instance
2 Download and install Terraform
3 Create the folder for example /root/azvyos/
mkdir /root/azvyos
4 Copy all files into your Terraform project "/root/azvyos" (vyos.tf, var.tf, terraform.
(continues on next page)
az login
cd /<your folder>
terraform init
Ansible
1 Create an UNIX instance whenever you want (local, cloud, and so on)
2 Download and install Ansible
3 Create the folder for example /root/az/
4 Copy all files into your Ansible project “/root/az/” (ansible.cfg, instance.yml,”all”), more detailed see
Structure of files Ansible for Azure
Start
Type the commands on your Terrafom instance:
cd /<your folder>
terraform plan
terraform apply
yes
After executing all the commands you will have your VyOS instance on the Azure cloud with your configuration, it’s a
very convenient desition. If you need to delete the instance please type the command:
terraform destroy
.
vyos.tf # The main script
var.tf # File for the changing version of␣
˓→Terraform.
vyos.tf
##############################################################################
# HashiCorp Guide to Using Terraform on Azure
# This Terraform configuration will create the following:
# Resource group with a virtual network and subnet
# An VyOS server without ssh key (only login+password)
##############################################################################
# Chouse a provider
provider "azurerm" {
features {}
}
##############################################################################
# Build an VyOS VM from the Marketplace
# To finde nessesery image use the command:
#
# az vm image list --offer vyos --all
#
# Now that we have a network, we'll deploy an VyOS server.
# An Azure Virtual Machine has several components. In this example we'll build
# a security group, a network interface, a public ip address, a storage
# account and finally the VM itself. Terraform handles all the dependencies
(continues on next page)
security_rule {
name = "SSH"
priority = 100
direction = "Inbound"
access = "Allow"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "22"
source_address_prefix = "${var.source_network}"
destination_address_prefix = "*"
}
}
# A network interface.
ip_configuration {
name = "${var.prefix}ipconfig"
subnet_id = "${azurerm_subnet.subnet.id}"
private_ip_address_allocation = "Dynamic"
public_ip_address_id = "${azurerm_public_ip.vyos-pip.id}"
}
}
network_interface_ids = ["${azurerm_network_interface.vyos-nic.id}"]
delete_os_disk_on_termination = "true"
plan {
publisher = "sentriumsl"
name = "vyos-1-3"
product = "vyos-1-2-lts-on-azure"
}
storage_image_reference {
publisher = "${var.image_publisher}"
offer = "${var.image_offer}"
sku = "${var.image_sku}"
version = "${var.image_version}"
}
storage_os_disk {
name = "${var.hostname}-osdisk"
managed_disk_type = "Standard_LRS"
caching = "ReadWrite"
create_option = "FromImage"
}
os_profile {
computer_name = "${var.hostname}"
admin_username = "${var.admin_username}"
admin_password = "${var.admin_password}"
}
os_profile_linux_config {
disable_password_authentication = false
}
}
# Copying the ip.txt file to the Ansible control node from local system
provisioner "file" {
source = "ip.txt"
destination = "/root/az/ip.txt"
}
}
provisioner "remote-exec" {
inline = [
"cd /root/az/",
"ansible-playbook instance.yml"
]
}
}
var.tf
##############################################################################
# Variables File
#
# Here is where we store the default values for all the variables used in our
# Terraform code.
##############################################################################
(continues on next page)
variable "resource_group" {
description = "The name of your Azure Resource Group."
default = "my_resource_group"
}
variable "prefix" {
description = "This prefix will be included in the name of some resources."
default = "vyos"
}
variable "hostname" {
description = "Virtual machine hostname. Used for local hostname, DNS, and storage-
˓→related names."
default = "vyos_terraform"
}
variable "location" {
description = "The region where the virtual network is created."
default = "centralus"
}
variable "virtual_network_name" {
description = "The name for your virtual network."
default = "vnet"
}
variable "address_space" {
description = "The address space that is used by the virtual network. You can supply␣
˓→more than one address space. Changing this forces a new resource to be created."
default = "10.0.0.0/16"
}
variable "subnet_prefix" {
description = "The address prefix to use for the subnet."
default = "10.0.10.0/24"
}
variable "storage_account_tier" {
description = "Defines the storage tier. Valid options are Standard and Premium."
default = "Standard"
}
variable "storage_replication_type" {
description = "Defines the replication type to use for this storage account. Valid␣
˓→options include LRS, GRS etc."
default = "LRS"
}
variable "vm_size" {
(continues on next page)
variable "image_publisher" {
description = "Name of the publisher of the image (az vm image list)"
default = "sentriumsl"
}
variable "image_offer" {
description = "Name of the offer (az vm image list)"
default = "vyos-1-2-lts-on-azure"
}
variable "image_sku" {
description = "Image SKU to apply (az vm image list)"
default = "vyos-1-3"
}
variable "image_version" {
description = "Version of the image to apply (az vm image list)"
default = "1.3.3"
}
variable "admin_username" {
description = "Administrator user name"
default = "vyos"
}
variable "admin_password" {
description = "Administrator password"
default = "Vyos0!"
}
variable "source_network" {
description = "Allow access from this network prefix. Defaults to '*'."
default = "*"
}
variable "password" {
description = "pass for Ansible"
type = string
sensitive = true
}
variable "host"{
description = "IP of my Ansible"
}
terraform.tfvars
.
group_vars
all
ansible.cfg
instance.yml
ansible.cfg
[defaults]
inventory = /root/az/ip.txt
host_key_checking= False
remote_user=vyos
instance.yml
##############################################################################
# About tasks:
# "Wait 300 seconds, but only start checking after 60 seconds" - try to make ssh␣
˓→connection every 60 seconds until 300 seconds
# "Configure general settings for the VyOS hosts group" - make provisioning into Azure␣
˓→VyOS node
# You have to add all necessary cammans of VyOS under the block "lines:"
##############################################################################
tasks:
- name: "Wait 300 seconds, but only start checking after 60 seconds"
wait_for_connection:
delay: 60
timeout: 300
group_vars/all
ansible_connection: ansible.netcommon.network_cli
ansible_network_os: vyos.vyos.vyos
ansible_user: vyos
ansible_ssh_pass: Vyos0!
With the help of Terraform, you can quickly deploy VyOS-based infrastructure in the vSphere. Also we will make
provisioning using Ansible.
In this case, we’ll create the necessary files for Terraform and Ansible next using Terraform we’ll create a single instance
on the vSphere cloud and make provisioning using Ansible.
How to create a single instance and install your configuration using Terraform+Ansible+vSphere Step by step:
vSphere
1 Collect all data in to file “terraform.tfvars” and create resources for example “terraform”
Terraform
1 Create an UNIX or Windows instance
2 Download and install Terraform
3 Create the folder for example /root/vsphereterraform
mkdir /root/vsphereterraform
4 Copy all files into your Terraform project "/root/vsphereterraform" (vyos.tf, var.tf,␣
˓→terraform.tfvars,version.tf), more detailed see `Structure of files Terrafom for␣
˓→vSphere`_
cd /<your folder>
terraform init
Ansible
1 Create an UNIX instance whenever you want (local, cloud, and so on)
2 Download and install Ansible
3 Create the folder for example /root/vsphereterraform/
4 Copy all files into your Ansible project “/root/vsphereterraform/” (ansible.cfg, instance.yml,”all”), more
detailed see Structure of files Ansible for vSphere
Start
Type the commands on your Terrafom instance:
cd /<your folder>
terraform plan
terraform apply
yes
After executing all the commands you will have your VyOS instance on the vSphere with your configuration, it’s a very
convenient desition. If you need to delete the instance please type the command:
terraform destroy
.
vyos.tf # The main script
versions.tf # File for the changing version of Terraform.
var.tf # File for the changing version of␣
˓→Terraform.
vyos.tf
provider "vsphere" {
user = var.vsphere_user
password = var.vsphere_password
vsphere_server = var.vsphere_server
allow_unverified_ssl = true
}
ovf_deploy {
allow_unverified_ssl_cert = true
remote_ovf_url = var.url_ova
disk_provisioning = "thin"
ip_protocol = "IPv4"
ip_allocation_policy = "dhcpPolicy"
ovf_network_map = {
"Network 1" = data.vsphere_network.network.id
"Network 2" = data.vsphere_network.network.id
}
}
vapp {
properties = {
"password" = "12345678",
"local-hostname" = "terraform_vyos"
}
}
}
output "ip" {
description = "default ip address of the deployed VM"
value = vsphere_virtual_machine.vmFromRemoteOvf.default_ip_address
}
# Copying the ip.txt file to the Ansible control node from local system
provisioner "file" {
source = "ip.txt"
destination = "/root/vsphere/ip.txt"
}
}
provisioner "remote-exec" {
inline = [
"cd /root/vsphere/",
"ansible-playbook instance.yml"
]
}
}
versions.tf
terraform {
required_providers {
(continues on next page)
var.tf
variable "vsphere_server" {
description = "vSphere server"
type = string
}
variable "vsphere_user" {
description = "vSphere username"
type = string
}
variable "vsphere_password" {
description = "vSphere password"
type = string
sensitive = true
}
variable "datacenter" {
description = "vSphere data center"
type = string
}
variable "cluster" {
description = "vSphere cluster"
type = string
}
variable "datastore" {
description = "vSphere datastore"
type = string
}
variable "network_name" {
description = "vSphere network name"
type = string
}
variable "host" {
description = "name if yor host"
type = string
}
(continues on next page)
variable "remotename" {
description = "the name of you VM"
type = string
}
variable "url_ova" {
description = "the URL to .OVA file or cloude store"
type = string
}
variable "ansiblepassword" {
description = "Ansible password"
type = string
}
variable "ansiblehost" {
description = "Ansible host name or IP"
type = string
}
terraform.tfvars
vsphere_user = ""
vsphere_password = ""
vsphere_server = ""
datacenter = ""
datastore = ""
cluster = ""
network_name = ""
host = ""
url_ova = ""
ansiblepassword = ""
ansiblehost = ""
remotename = ""
.
group_vars
all
ansible.cfg
instance.yml
ansible.cfg
[defaults]
inventory = /root/vsphere/ip.txt
host_key_checking= False
remote_user=vyos
instance.yml
##############################################################################
# About tasks:
# "Wait 300 seconds, but only start checking after 60 seconds" - try to make ssh␣
˓→connection every 60 seconds until 300 seconds
# "Configure general settings for the VyOS hosts group" - make provisioning into vSphere␣
˓→VyOS node
# You have to add all necessary cammans of VyOS under the block "lines:"
##############################################################################
tasks:
- name: "Wait 300 seconds, but only start checking after 60 seconds"
wait_for_connection:
delay: 60
timeout: 300
group_vars/all
ansible_connection: ansible.netcommon.network_cli
ansible_network_os: vyos.vyos.vyos
# user and password gets from terraform variables "admin_username" and "admin_password"
ansible_user: vyos
# get from vyos.tf "vapp"
ansible_ssh_pass: 12345678
With the help of Terraform, you can quickly deploy VyOS-based infrastructure in the google cloud. If necessary, the
infrastructure can be removed using terraform. Also we will make provisioning using Ansible.
In this case, we’ll create the necessary files for Terraform and Ansible next using Terraform we’ll create a single instance
on the google cloud and make provisioning using Ansible.
How to create a single instance and install your configuration using Terraform+Ansible+google Step by step:
google cloud
1 Create an account with google cloud and a new project
The .JSON file download automaticly after creating and will look like:
Terraform
mkdir /root/google
4 Copy all files into your Terraform project "/root/google" (vyos.tf, var.tf, terraform.
˓→tfvars, .JSON), more detailed see `Structure of files Terrafom for google cloud`_
cd /<your folder>
terraform init
Ansible
1 Create an UNIX instance whenever you want (local, cloud, and so on)
2 Download and install Ansible
3 Create the folder for example /root/google/
4 Copy all files into your Ansible project “/root/google/” (ansible.cfg, instance.yml, mykey.json and “all”),
more detailed see Structure of files Ansible for google cloud
mykey.json you have to get using step 2 of the google cloud
Start
Type the commands on your Terrafom instance:
cd /<your folder>
terraform plan
terraform apply
yes
# terraform apply
Terraform used the selected providers to generate the following execution plan. Resource␣
˓→actions are indicated with the following symbols:
+ create
+ allow {
+ ports = [
+ "22",
]
+ protocol = "tcp"
}
}
+ allow {
+ ports = [
+ "500",
+ "4500",
]
+ protocol = "udp"
}
}
+ boot_disk {
+ auto_delete = true
+ device_name = (known after apply)
+ disk_encryption_key_sha256 = (known after apply)
+ kms_key_self_link = (known after apply)
+ mode = "READ_WRITE"
+ source = (known after apply)
+ initialize_params {
+ image = "projects/sentrium-public/global/images/vyos-1-
˓→3-5-20231222143039"
+ network_interface {
+ internal_ipv6_prefix_length = (known after apply)
+ ipv6_access_type = (known after apply)
+ ipv6_address = (known after apply)
+ name = (known after apply)
+ network = "default"
+ network_ip = (known after apply)
+ nic_type = "GVNIC"
+ stack_type = (known after apply)
+ subnetwork = "default"
+ subnetwork_project = (known after apply)
Changes to Outputs:
+ public_ip_address = (known after apply)
In this context, references are expected literally rather than in quotes. Terraform 0.
˓→11 and earlier required quotes, but quoted references are now deprecated and will be␣
˓→removed in a
future version of Terraform. Remove the quotes surrounding this reference to silence␣
˓→this warning.
google_compute_firewall.udp_500_4500[0]: Creating...
google_compute_firewall.tcp_22[0]: Creating...
google_compute_instance.default: Creating...
google_compute_firewall.udp_500_4500[0]: Still creating... [10s elapsed]
google_compute_firewall.tcp_22[0]: Still creating... [10s elapsed]
google_compute_instance.default: Still creating... [10s elapsed]
google_compute_firewall.tcp_22[0]: Creation complete after 16s [id=projects/vyosproject/
˓→global/firewalls/vyos-tcp-22]
null_resource.SSHconnection1: Creating...
null_resource.SSHconnection2: Creating...
null_resource.SSHconnection1: Provisioning with 'file'...
null_resource.SSHconnection2: Provisioning with 'remote-exec'...
null_resource.SSHconnection2 (remote-exec): Connecting to remote host via SSH...
null_resource.SSHconnection2 (remote-exec): Host: 10.***.***.104
null_resource.SSHconnection2 (remote-exec): User: root
null_resource.SSHconnection2 (remote-exec): Password: true
null_resource.SSHconnection2 (remote-exec): Private key: false
null_resource.SSHconnection2 (remote-exec): Certificate: false
null_resource.SSHconnection2 (remote-exec): SSH Agent: false
null_resource.SSHconnection2 (remote-exec): Checking Host Key: false
null_resource.SSHconnection2 (remote-exec): Target Platform: unix
local_file.ip: Creating...
local_file.ip: Creation complete after 0s [id=7d568c3b994a018c942a3cdb952ccbf3c729d0ca]
null_resource.SSHconnection2 (remote-exec): Connected!
null_resource.SSHconnection1: Creation complete after 4s [id=5175298735911137161]
Outputs:
public_ip_address = "104.***.***.158"
After executing all the commands you will have your VyOS instance on the google cloud with your configuration, it’s
a very convenient desition. If you need to delete the instance please type the command:
terraform destroy
Troubleshooting
1 Increase the time in the file instance.yml from 300 sec to 500 sec or more. (It depends on your location).
Make sure that you have opened access to the instance in the security group.
2 Terraform doesn’t connect via SSH to your Ansible instance: you have to check the correct login and
password in the part of the file VyOS.tf
connection {
type = "ssh"
user = "root" # open root access using login and password on your␣
˓→Ansible
.
vyos.tf # The main script
***.JSON # The credential file from google cloud
var.tf # The file of all variables in "vyos.tf"
terraform.tfvars # The value of all variables (passwords, login, ip␣
˓→adresses and so on)
vyos.tf
##############################################################################
# Build an VyOS VM from the Marketplace
#
# After deploying the GCP instance and getting an IP address, the IP address is copied␣
˓→into the file
terraform {
required_providers {
google = {
source = "hashicorp/google"
}
}
}
provider "google" {
project = var.project_id
request_timeout = "60s"
credentials = file(var.gcp_auth_file)
}
locals {
network_interfaces = [for i, n in var.networks : {
network = n,
subnetwork = length(var.sub_networks) > i ? element(var.sub_networks, i) : null
external_ip = length(var.external_ips) > i ? element(var.external_ips, i) : "NONE"
}
]
}
metadata = {
enable-oslogin = "FALSE"
serial-port-enable = "TRUE"
user-data = var.vyos_user_data
}
boot_disk {
initialize_params {
image = var.image
}
}
can_ip_forward = true
}
}
}
}
}
name = "${var.goog_cm_deployment_name}-tcp-22"
network = element(var.networks, 0)
allow {
ports = ["22"]
protocol = "tcp"
}
source_ranges = ["0.0.0.0/0"]
target_tags = ["${var.goog_cm_deployment_name}-deployment"]
}
name = "${var.goog_cm_deployment_name}-udp-500-4500"
network = element(var.networks, 0)
allow {
ports = ["500", "4500"]
protocol = "udp"
}
source_ranges = ["0.0.0.0/0"]
target_tags = ["${var.goog_cm_deployment_name}-deployment"]
}
output "public_ip_address" {
value = google_compute_instance.default.network_interface[0].access_config[0].nat_ip
}
(continues on next page)
##############################################################################
#
# IP of google instance copied to a file ip.txt in local system Terraform
# ip.txt looks like:
# cat ./ip.txt
# ...
##############################################################################
filename = "ip.txt"
}
##############################################################################
# Steps "SSHconnection1" and "SSHconnection2" need to get file ip.txt from the terraform␣
˓→node and start remotely the playbook of Ansible.
##############################################################################
#copying the ip.txt file to the Ansible control node from local system
provisioner "file" {
source = "ip.txt"
destination = "/root/google/ip.txt" # The folder of your␣
˓→Ansible project
}
}
provisioner "remote-exec" {
(continues on next page)
]
}
}
var.tf
variable "image" {
type = string
default = "projects/sentrium-public/global/images/vyos-1-3-5-20231222143039"
}
variable "project_id" {
type = string
}
variable "zone" {
type = string
}
##############################################################################
# You can choose more chipper type than n2-highcpu-4
##############################################################################
variable "machine_type" {
type = string
default = "n2-highcpu-4"
}
variable "networks" {
description = "The network name to attach the VM instance."
type = list(string)
default = ["default"]
}
variable "sub_networks" {
description = "The sub network name to attach the VM instance."
type = list(string)
default = ["default"]
}
variable "external_ips" {
description = "The external IPs assigned to the VM for public access."
type = list(string)
default = ["EPHEMERAL"]
}
variable "enable_tcp_22" {
description = "Allow SSH traffic from the Internet"
(continues on next page)
variable "enable_udp_500_4500" {
description = "Allow IKE/IPSec traffic from the Internet"
type = bool
default = true
}
variable "vyos_user_data" {
type = string
default = ""
}
variable "password" {
description = "pass for Ansible"
type = string
sensitive = true
}
variable "host"{
description = "The IP of my Ansible"
type = string
}
terraform.tfvars
##############################################################################
# Must be filled in
##############################################################################
zone = "us-west1-a"
gcp_auth_file = "/root/***/***.json" # path of your .json file
project_id = "" # the google project
password = "" # password for Ansible SSH
host = "" # IP of my Ansible
.
group_vars
all
ansible.cfg
instance.yml
ansible.cfg
[defaults]
inventory = /root/google/ip.txt
host_key_checking= False
remote_user=vyos
instance.yml
##############################################################################
# About tasks:
# "Wait 300 seconds, but only start checking after 60 seconds" - try to make ssh␣
˓→connection every 60 seconds until 300 seconds
# "Configure general settings for the VyOS hosts group" - make provisioning into google␣
˓→cloud VyOS node
# You have to add all necessary cammans of VyOS under the block "lines:"
##############################################################################
tasks:
- name: "Wait 300 seconds, but only start checking after 60 seconds"
wait_for_connection:
delay: 60
timeout: 300
group_vars/all
ansible_connection: ansible.netcommon.network_cli
ansible_network_os: vyos.vyos.vyos
ansible_user: vyos
ansible_ssh_pass: vyos
10.4 Napalm
VyOS supports some napalm functions for configuration and op-mode. It requires more tests.
Install napalm-vyos module
10.4.1 Op-mode
#!/usr/bin/env python3
import json
from napalm import get_network_driver
driver = get_network_driver('vyos')
vyos_router = driver(
hostname="192.0.2.1",
username="vyos",
password="vyospass",
optional_args={"port": 22},
)
vyos_router.open()
output = vyos_router.get_facts()
print(json.dumps(output, indent=4))
output = vyos_router.get_arp_table()
print(json.dumps(output, indent=4))
vyos_router.close()
Output op-mode
$ ./vyos-napalm.py
{
"uptime": 7185,
"vendor": "VyOS",
"os_version": "1.3.0-rc5",
"serial_number": "",
"model": "Standard PC (Q35 + ICH9, 2009)",
"hostname": "r4-1.3",
"fqdn": "vyos.local",
"interface_list": [
(continues on next page)
10.4.2 Configuration
Script vyos-napalm.py
#!/usr/bin/env python3
driver = get_network_driver('vyos')
vyos_router = driver(
hostname="192.0.2.1",
username="vyos",
password="vyospass",
optional_args={"port": 22},
)
vyos_router.open()
vyos_router.load_merge_candidate(filename='commands.conf')
diffs = vyos_router.compare_config()
(continues on next page)
if bool(diffs) == True:
print(diffs)
vyos_router.commit_config()
else:
print('No configuration changes to commit')
vyos_router.discard_config()
vyos_router.close()
Output
$./vyos-napalm.py
[edit interfaces ethernet eth1]
+description FOO
[edit service ssh]
+disable-host-validation
+port 2222
[edit system]
+name-server 192.0.2.8
+name-server 203.0.113.8
[edit]
10.5 Netmiko
10.5.1 Example
#!/usr/bin/env python3
vyos_router = {
"device_type": "vyos",
"host": "192.0.2.1",
"username": "vyos",
"password": "vyospass",
"port": 22,
}
net_connect = ConnectHandler(**vyos_router)
config_commands = [
'set interfaces ethernet eth0 description WAN',
'set interfaces ethernet eth1 description LAN',
]
# set configuration
(continues on next page)
# commit configuration
output = net_connect.commit()
print(output)
# op-mode commands
output = net_connect.send_command("run show interfaces")
print(output)
Output
$ ./vyos-netmiko.py
configure
set interfaces ethernet eth0 description WAN
[edit]
[email protected]# set interfaces ethernet eth1 description LAN
[edit]
[email protected]#
commit
[edit]
[email protected]#
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 203.0.113.1/24 u/u WAN
eth1 192.0.2.1/30 u/u LAN
eth2 - u/u
lo 127.0.0.1/8 u/u
::1/128
vtun10 10.10.0.1/24 u/u
[edit]
10.6 Salt
/ # salt-key --list-all
Accepted Keys:
r11
Denied Keys:
Unaccepted Keys:
(continues on next page)
At this step we can get some op-mode information from VyOS nodes:
/ # salt '*' network.interface eth0
r11:
|_
----------
address:
192.0.2.11
broadcast:
192.0.2.255
label:
eth0
netmask:
255.255.255.0
r14:
|_
----------
address:
192.0.2.14
broadcast:
192.0.2.255
label:
eth0
netmask:
255.255.255.0
10.6.1 Netmiko-proxy
It is possible to configure VyOS via netmiko proxy module. It requires a minion with installed packet
python3-netmiko module who has a connection to VyOS nodes. Salt-minion have to communicate with salt master
Configuration
/ # cat /etc/salt/master
file_roots:
base:
- /srv/salt/states
pillar_roots:
base:
- /srv/salt/pillars
Structure of /srv/salt:
/ # tree /srv/salt/
/srv/salt/
|___ pillars
| |__ r11-proxy.sls
| |__ top.sls
|___ states
|__ commands.txt
top.sls
/ # cat /srv/salt/pillars/top.sls
base:
r11-proxy:
- r11-proxy
/ # cat /srv/salt/pillars/r11-proxy.sls
proxy:
proxytype: netmiko # how to connect to proxy minion, change it
device_type: vyos #
host: 192.0.2.250
username: user
password: secret_passwd
commands.txt
/ # cat /srv/salt/states/commands.txt
set interfaces ethernet eth0 description 'WAN'
set interfaces ethernet eth1 description 'LAN'
Examples
Example of op-mode:
r11-proxy:
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 192.0.2.14/24 u/u Upstream
/ #
Example of configuration:
˓→password=vyos
r11-proxy:
configure
set interfaces ethernet eth0 description Link_to_WAN
[edit]
vyos@r14# commit
[edit]
vyos@r14#
/ #
r11-proxy:
configure
set interfaces ethernet eth0 description 'WAN'
[edit]
vyos@r1# set interfaces ethernet eth1 description 'LAN'
[edit]
vyos@r1# commit
[edit]
vyos@r1#
/ #
VyOS supports executing configuration and operational commands non-interactively from shell scripts.
To include VyOS specific functions and aliases you need to source /opt/vyatta/etc/functions/
script-template files at the top of your script.
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
exit
Configuration commands are executed just like from a normal config session. For example, if you want to disable a
BGP peer on VRRP transition to backup:
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
configure
set protocols bgp system-as 65536
set protocols bgp neighbor 192.168.2.1 shutdown
commit
exit
Unlike a normal configuration session, all operational commands must be prepended with run, even if you haven’t
created a session with configure.
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
run show interfaces
exit
Sometimes you simply want to execute a bunch of op-mode commands via SSH on a remote VyOS system.
Will return:
Welcome to VyOS
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
(continues on next page)
If you want to script the configs in a language other than bash you can have your script output commands and then
source them in a bash script.
Here is a simple example:
#!/usr/bin/env python3
print("delete firewall group address-group somehosts")
print("set firewall group address-group somehosts address '192.0.2.3'")
print("set firewall group address-group somehosts address '203.0.113.55'")
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
configure
source <(/config/scripts/setfirewallgroup.py)
commit
There is a pitfall when working with configuration scripts. It is tempting to call configuration scripts with “sudo” (i.e.,
temporary root permissions), because that’s the common way on most Linux platforms to call system commands.
On VyOS this will cause the following problem: After modifying the configuration via script like this once, it is not
possible to manually modify the config anymore:
This will result in the following error message: Set failed If this happens, a reboot is required to be able to edit the
config manually again.
To avoid these problems, the proper way is to call a script with the vyattacfg group, e.g., by using the sg (switch
group) command:
sg vyattacfg -c ./myscript.sh
To make sure that a script is not accidentally called without the vyattacfg group, the script can be safeguarded like
this:
VyOS has the ability to run custom scripts before and after each commit
The default directories where your custom Scripts should be located are:
Scripts are run in alphabetical order. Their names must consist entirely of ASCII upper- and lower-case letters,ASCII
digits, ASCII underscores, and ASCII minus-hyphens.No other characters are allowed.
Note: Custom scripts are not executed with root privileges (Use sudo inside if this is necessary).
A simple example is shown below, where the ops command executed in the post-hook script is “show interfaces”.
#!/bin/sh
# This script is executed at boot time before VyOS configuration is applied.
# Any modifications required to work around unfixed bugs or use
# services not available through the VyOS CLI system can be placed here.
#!/bin/sh
# This script is executed at boot time after VyOS configuration is fully
# applied. Any modifications required to work around unfixed bugs or use
# services not available through the VyOS CLI system can be placed here.
Hint: For configuration/upgrade management issues, modification of this script should be the last option. Always try
to find solutions based on CLI commands first.
Cloud and virtualized instances of VyOS are initialized using the industry-standard cloud-init. Via cloud-init, the
system performs tasks such as injecting SSH keys and configuring the network. In addition, the user can supply a
custom configuration at the time of instance launch.
10.8.2 User-data
Major cloud providers offer a means of providing user-data at the time of instance launch. It can be provided as plain
text or as base64-encoded text, depending on cloud provider. Also, it can be compressed using gzip, which makes sense
with a long configuration commands list, because of the hard limit to ~16384 bytes for the whole user-data.
The easiest way to configure the system via user-data is the Cloud-config syntax described below.
A cloud-config document is written in YAML. The file must begin with #cloud-config line. The only supported
top-level keys are vyos_config_commands and write_files. The use of these keys is described in the following
two sections.
The key used to designate a VyOS configuration is vyos_config_commands. What follows is VyOS configuration
using the “set-style” syntax. Both “set” and “delete” commands are supported.
Commands requirements:
• One command per line.
• If command ends in a value, it must be inside single quotes.
• A single-quote symbol is not allowed inside command or value.
The commands list produced by the show configuration commands command on a VyOS router should comply
with all the requirements, so it is easy to get a proper commands list by copying it from another router.
The configuration specified in the cloud-config document overwrites default configuration values and values configured
via Metadata.
After the vyos_config_commands are executed, cloud-init will automatically perform a commit and save operation.
Here is an example cloud-config that appends configuration at the time of first boot.
#cloud-config
vyos_config_commands:
- set system host-name 'vyos-prod-ashburn'
- set service ntp server 1.pool.ntp.org
- set service ntp server 2.pool.ntp.org
- delete interfaces ethernet eth1 address 'dhcp'
- set interfaces ethernet eth1 address '192.0.2.247/24'
- set protocols static route 198.51.100.0/24 next-hop '192.0.2.1'
System Defaults/Fallbacks
VyOS supports the execution of operational commands and linux commands at initial boot. This is ac-
complished using write_files to certain files in the /opt/vyatta/etc/config/scripts directory. Commands
specified in opt/vyatta/etc/config/scripts/vyos-preconfig-bootup.script are executed prior to configuration. The
/opt/vyatta/etc/config/scripts/vyos-postconfig-bootup.script file contains commands to be executed after configuration.
In both cases, commands are executed as the root user.
Note that the /opt/vyatta/etc/config is used instead of the /config/scripts directory referenced in the Command Script-
ing section of the documentation because the /config/script directory isn’t mounted when the write_files module
executes.
The following example shows how to execute commands after the initial configuration.
#cloud-config
write_files:
- path: /opt/vyatta/etc/config/scripts/vyos-postconfig-bootup.script
owner: root:vyattacfg
permissions: '0775'
content: |
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
filename=/tmp/bgp_status_`date +"%Y_%m_%d_%I_%M_%p"`.log
run show ip bgp summary >> $filename
If you need to gather information from linux commands to configure VyOS, you can execute commands and then
configure VyOS in the same script.
The following example sets the hostname based on the instance identifier obtained from the EC2 metadata service.
#cloud-config
write_files:
- path: /opt/vyatta/etc/config/scripts/vyos-postconfig-bootup.script
owner: root:vyattacfg
permissions: '0775'
content: |
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
hostname=`curl -s http://169.254.169.254/latest/meta-data/instance-id`
configure
set system host-name $hostname
commit
exit
10.8.7 NoCloud
Injecting configuration data is not limited to cloud platforms. Users can employ the NoCloud data source to inject
user-data and meta-data on virtualization platforms such as VMware, Hyper-V and KVM.
While other methods exist, the most straightforward method for using the NoCloud data source is creating a seed ISO
and attaching it to the virtual machine as a CD drive. The volume must be formatted as a vfat or ISO 9660 file system
with the label “cidata” or “CIDATA”.
Create text files named user-data and meta-data. On linux-based systems, the mkisofs utility can be used to create the
seed ISO. The following syntax will add these files to the ISO 9660 file system.
The seed.iso file can be attached to the virtual machine. As an example, the method with KVM to attach the ISO as a
CD drive follows.
$ virt-install -n vyos_r1 \
--ram 4096 \
--vcpus 2 \
--cdrom seed.iso \
--os-type linux \
--os-variant debian10 \
--network network=default \
--graphics vnc \
--hvm \
--virt-type kvm \
--disk path=/var/lib/libvirt/images/vyos_kvm.qcow2,bus=virtio \
--import \
--noautoconsole
For more information on the NoCloud data source, visit its page nocloud in the cloud-init documentation.
10.8.8 Troubleshooting
If you encounter problems, verify that the cloud-config document contains valid YAML. Online resources such as
https://www.yamllint.com/ provide a simple tool for validating YAML.
cloud-init logs to /var/log/cloud-init.log. This file can be helpful in determining why the configuration varies from
what you expect. You can fetch the most important data filtering output for vyos keyword:
Before starting, please refer to cloud-init network-config-docs in order to know how to import user and network con-
figurations.
Most important keys that needs to be considered:
• VyOS configuration commands are defined in user-data file.
• Networking configurations shouldn’t be passed in user-data file.
• If no networking configuration is provided, then dhcp client is going to be enabled on first interface. Bear in
mind that this configuration will be injected at an OS level, so don’t expect to find dhcp client configuration on
vyos cli. Because of this behavior, in next example lab we will disable dhcp-client configuration on eth0.
Also, this lab considers:
• Proxmox IP address: 192.168.0.253/24
• Storaged used: volume local, which is mounted on directory /var/lib/vz, and contains all type of content, includ-
ing snippets.
• Remove default dhcp client on first interface, and load other configuration during first boot, using cloud-init.
A VyOS qcow image with cloud-init options is needed. This can be obtained using vyos-vm-images repo. After cloning
the repo, edit the file qemu.yml and comment the download-iso role.
In this lab, we are using 1.3.0 VyOS version and setting a disk of 10G. Download VyOS .iso file and save it as /tmp/
vyos.iso. Command used for generating qcow image:
In Proxmox server three files are going to be used for this setup:
• network-config: file that will indicate to avoid dhcp client on first interface.
• user-data: includes vyos-commands.
• meta-data: empty file (required).
In this lab, all files are located in /tmp/. So, before going on, lets move to that directory:
cd /tmp/
user-data file must start with #cloud-config and contains vyos-commands. For example:
#cloud-config
vyos_config_commands:
- set system host-name 'vyos-BRAS'
- set service ntp server 1.pool.ntp.org
- set service ntp server 2.pool.ntp.org
- delete interfaces ethernet eth0 address 'dhcp'
- set interfaces ethernet eth0 address '198.51.100.2/30'
- set interfaces ethernet eth0 description 'WAN - ISP01'
- set interfaces ethernet eth1 address '192.168.25.1/24'
- set interfaces ethernet eth1 description 'Comming through VLAN 25'
(continues on next page)
network-config file only has configuration that disables the automatic dhcp client on first interface.
Content of network-config file:
version: 2
ethernets:
eth0:
dhcp4: false
dhcp6: false
Create seed.iso
Once the three files were created, it’s time to generate the seed.iso image, which needs to be mounted to the new VM
as a cd.
Command for generating seed.iso
NOTE: be careful while copying and pasting previous commands. Double quotes may need to be corrected.
Creating the VM
Notes for this particular example, that may need to be modified in other setups:
• VM ID: in this example, VM ID used is 555.
• VM Storage: local volume is used.
• ISO files storage: local volume is used for .iso file storage. In this scenario local volume type is set to
directory, abd attached to /var/lib/vz.
• VM Resources: these parameters can be modified as needed.
seed.iso was previously created in directory /tmp/. It’s necessary to move it to /var/lib/vz/template/iso
mv /tmp/seed.iso /var/lib/vz/template/iso/
On proxmox server:
## Since this server has 1 nic, lets add network intefaces (vlan 25 and 26)
qm set 555 --net1 virtio,bridge=vmbr0,firewall=1,tag=25
qm set 555 --net2 virtio,bridge=vmbr0,firewall=1,tag=26
From cli or GUI, power on VM, and after it boots, verify configuration
References
• VyOS cloud-init-docs.
• Cloud-init network-config-docs.
• Proxmox Cloud-init-Support.
10.9 pyvyos
pyvyos is a Python library designed for interacting with VyOS devices through their API. This documentation is in-
tended to guide you in using pyvyos for programmatic management of your VyOS devices.
• pyvyos Documentation on Read the Docs provides detailed instructions on the installation, configuration, and
operation of the pyvyos library.
• pyvyos Source Code on GitHub allows you to access and contribute to the library’s code.
• pyvyos on PyPI for easy installation via pip, the Python package installer. Execute pip install pyvyos in your
terminal to install.
10.9.1 Installation
import urllib3
urllib3.disable_warnings()
@dataclass
class ApiResponse:
status: int
request: dict
result: dict
error: str
hostname = os.getenv('VYDEVICE_HOSTNAME')
apikey = os.getenv('VYDEVICE_APIKEY')
port = os.getenv('VYDEVICE_PORT')
protocol = os.getenv('VYDEVICE_PROTOCOL')
verify_ssl = os.getenv('VYDEVICE_VERIFY_SSL')
if not response.error:
print(response.result)
response = device.retrieve_show_config(path=[])
if not response.error:
print(response.result)
response = device.config_file_save()
response = device.config_file_save(file="/config/test300.config")
Show Object
Generate Object
keyrand = f'/tmp/key_{randstring}'
response = device.generate(path=["ssh", "client-key", keyrand])
Reset Object
response = device.config_file_load(file="/config/test300.config")
ELEVEN
TROUBLESHOOTING
Sometimes things break or don’t work as expected. This section describes several troubleshooting tools provided by
VyOS that can help when something goes wrong.
Verifying connectivity can be done with the familiar ping and traceroute commands. The options for each are shown
(the options for each command were displayed using the built-in help as described in the Command Line Interface
section and are omitted from the output here):
ping <destination>
Send ICMP echo requests to destination host. There are multiple options to ping, inkl. VRF support.
1128
VyOS Documentation, Release 1.5.x (circinus)
traceroute <destination>
Trace path to target.
vyos@vyos:~$ traceroute
Possible completions:
<hostname> Track network path to specified node
<x.x.x.x>
<h:h:h:h:h:h:h:h>
ipv4 Track network path to <hostname|IPv4 address>
ipv6 Track network path to <hostname|IPv6 address>
My traceroute [v0.85]
vyos (0.0.0.0)
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 10.11.110.4 0.0% 34 0.5 0.5 0.4 0.8 0.1
2. 10.62.255.184 0.0% 34 1.1 1.0 0.9 1.4 0.1
3. 10.62.255.71 0.0% 34 1.4 1.4 1.3 2.0 0.1
4. 10.62.212.12 0.0% 34 1.6 1.6 1.6 1.7 0.0
Note: The output consumes the screen and will replace your command prompt.
Several options are available for changing the display output. Press h to invoke the built in help system. To quit,
just press q and you’ll be returned to the VyOS command prompt.
Router Discovery
Neighbor Discovery
If you find the names of your interfaces have changed, this could be because your MAC addresses have changed.
• For example, you have a VyOS VM with 4 Ethernet interfaces named eth0, eth1, eth2 and eth3. Then, you
migrate your VyOS VM to a different host and find your interfaces now are eth4, eth5, eth6 and eth7.
One way to fix this issue taking control of the MAC addresses is:
Log into VyOS and run this command to display your interface settings.
If it is a VM, go into the settings of the host and set the MAC address to the settings found in the config.boot file.
You can also set the MAC to static if the host allows so.
• Another example could be when cloning VyOS VMs in GNS3 and you get into the same issue: interface names
have changed.
And a more generic way to fix it is just deleting every MAC address at the configuration file of the cloned
machine. They will be correctly regenerated automatically.
11.3 Monitoring
vyos@vyos:~$ monitor
Possible completions:
bandwidth Monitor interface bandwidth in real time
bandwidth-test
Initiate or wait for bandwidth test
cluster Monitor clustering service
command Monitor an operational mode command (refreshes every 2 seconds)
conntrack-sync
Monitor conntrack-sync
content-inspection
Monitor Content-Inspection
dhcp Monitor Dynamic Host Control Protocol (DHCP)
dns Monitor a Domain Name Service (DNS) daemon
firewall Monitor Firewall
https Monitor the Secure Hypertext Transfer Protocol (HTTPS) service
lldp Monitor Link Layer Discovery Protocol (LLDP) daemon
log Monitor last lines of messages file
nat Monitor network address translation (NAT)
ndp Monitor the NDP information received by the router through the device
openvpn Monitor OpenVPN
protocol Monitor routing protocols
snmp Monitor Simple Network Management Protocol (SNMP) daemon
stop-all Stop all current background monitoring processes
traceroute Monitor the path to a destination in realtime
traffic Monitor traffic dumps
vpn Monitor VPN
vrrp Monitor Virtual Router Redundancy Protocol (VRRP)
webproxy Monitor Webproxy service
To monitor interface traffic, issue the monitor traffic interface <name> command, replacing <name> with
your chosen interface.
To quit monitoring, press Ctrl-c and you’ll be returned to the VyOS command prompt.
Traffic can be filtered and saved.
to take a quick view on the used bandwidth of an interface use the monitor bandwidth command
B (RX Bytes/second)
198.00 .|....|.....................................................
165.00 .|....|.....................................................
132.00 ||..|.|.....................................................
99.00 ||..|.|.....................................................
66.00 |||||||.....................................................
33.00 |||||||.....................................................
1 5 10 15 20 25 30 35 40 45 50 55 60
To take a look on the network bandwidth between two nodes, the monitor bandwidth-test command is used to run
iperf.
• The accept command opens a listening iperf server on TCP Port 5001
• The initiate command connects to that server to perform the test.
The monitor command command allows you to repeatedly run a command to view a continuously refreshed output.
The command is run and output every 2 seconds, allowing you to monitor the output continuously without having to
re-run the command. This can be useful to follow routing adjacency formation.
Will clear the screen and show you the output of show interfaces every 2 seconds.
11.4 Terminal/Console
The command follow the same logic as the set command in configuration mode.
VyOS 1.2 uses Debian Jessie as the base Linux operating system. Jessie was the first version of Debian that uses
systemd as the default init system.
These are the boot steps for VyOS 1.2
1. The BIOS loads Grub (or isolinux for the Live CD)
2. Grub then starts the Linux boot and loads the Linux Kernel /boot/vmlinuz
3. Kernel Launches Systemd /lib/systemd/systemd
4. Systemd loads the VyOS service file /lib/systemd/system/vyos-router.service
5. The service file launches the VyOS router init script /usr/libexec/vyos/init/vyos-router - this is part
of the vyatta-cfg Debian package
1. Starts FRR - successor to GNU Zebra and Quagga
2. Initialises the boot configuration file - copies over config.boot.default if there is no configura-
tion
3. Runs the configuration migration, if the configuration is for an older version of VyOS
4. Runs The pre-config script, if there is one /config/scripts/vyos-preconfig-bootup.script
5. If the config file was upgraded, runs any post upgrade scripts /config/scripts/post-upgrade.d
6. Starts rl-system and firewall
7. Mounts the /boot partition
8. The boot configuration file is then applied by /opt/vyatta/sbin/
vyatta-boot-config-loader/opt/vyatta/etc/config/config.boot
1. The config loader script writes log entries to /var/log/vyatta-config-loader.log
TWELVE
CONFIGURATION BLUEPRINTS
This example shows how to configure a VyOS router with VRFs and firewall rules.
Diagram used in this example:
1136
VyOS Documentation, Release 1.5.x (circinus)
As exposed in the diagram, there are four VRFs. These VRFs are MGMT, WAN, LAN and PROD, and their requirements
are:
• VRF MGMT:
– Allow connections to LAN and PROD.
– Deny connections to internet(WAN).
– Allow connections to the router.
• VRF LAN:
– Allow connections to PROD.
– Allow connections to internet(WAN).
• VRF PROD:
– Only accepts connections.
• VRF WAN:
– Allow connection to PROD.
Configuration
And before firewall rules are shown, we need to pay attention how to configure and match interfaces and VRFs. In
case where an interface is assigned to a non-default VRF, if we want to use inbound-interface or outbound-interface in
firewall rules, we need to:
• For inbound-interface: use the interface name with the VRF name, like MGMT or LAN.
• For outbound-interface: use the interface name, like eth0, vtun0, eth2* or similar.
Next, we need to configure the firewall rules. First we will define all rules for transit traffic between VRFs.
Also, we are adding global state policies, in order to allow established and related traffic, in order not to drop valid
responses:
And finally, we need to allow input connections to the router itself only from vrf MGMT:
Note: In T2199 the syntax of the zone configuration was changed. The zone configuration moved from zone-policy
zone <name> to firewall zone <name>.
This specific example is for a router on a stick, but is very easily adapted for however many NICs you have:
• Internet - 192.168.200.100 - TCP/80
• Internet - 192.168.200.100 - TCP/443
• Internet - 192.168.200.100 - TCP/25
• Internet - 192.168.200.100 - TCP/53
• VyOS acts as DHCP, DNS forwarder, NAT, router and firewall.
• 192.168.200.200/2001:0DB8:0:BBBB::200 is an internal/external DNS, web and mail (SMTP/IMAP) server.
• 192.168.100.10/2001:0DB8:0:AAAA::10 is the administrator’s console. It can SSH to VyOS.
• LAN and DMZ hosts have basic outbound access: Web, FTP, SSH.
• LAN can access DMZ resources.
• DMZ cannot access LAN resources.
• Inbound WAN connect to DMZ host.
The VyOS interface is assigned the .1/:1 address of their respective networks. WAN is on VLAN 10, LAN on VLAN
20, and DMZ on VLAN 30.
It will look something like this:
interfaces {
ethernet eth0 {
duplex auto
hw-id 00:53:ed:6e:2a:92
smp_affinity auto
speed auto
(continues on next page)
Zones Basics
Each interface is assigned to a zone. The interface can be physical or virtual such as tunnels (VPN, PPTP, GRE, etc)
and are treated exactly the same.
Traffic flows from zone A to zone B. That flow is what I refer to as a zone-pair-direction. eg. A->B and B->A are two
zone-pair-destinations.
Ruleset are created per zone-pair-direction.
I name rule sets to indicate which zone-pair-direction they represent. eg. ZoneA-ZoneB or ZoneB-ZoneA. LAN-DMZ,
DMZ-LAN.
In VyOS, you have to have unique Ruleset names. In the event of overlap, I add a “-6” to the end of v6 rulesets. eg.
LAN-DMZ, LAN-DMZ-6. This allows for each auto-completion and uniqueness.
In this example we have 4 zones. LAN, WAN, DMZ, Local. The local zone is the firewall itself.
If your computer is on the LAN and you need to SSH into your VyOS box, you would need a rule to allow it in the
LAN-Local ruleset. If you want to access a webpage from your VyOS box, you need a rule to allow it in the Local-LAN
ruleset.
In rules, it is good to keep them named consistently. As the number of rules you have grows, the more consistency you
have, the easier your life will be.
The first two rules are to deal with the idiosyncrasies of VyOS and iptables.
Zones and Rulesets both have a default action statement. When using Zone-Policies, the default action is set by the
zone-policy statement and is represented by rule 10000.
It is good practice to log both accepted and denied traffic. It can save you significant headaches when trying to trou-
bleshoot a connectivity issue.
To add logging to the default rule, do:
By default, iptables does not allow traffic for established sessions to return, so you must explicitly allow this. I do this
by adding two rules to every ruleset. 1 allows established and related state packets through and rule 2 drops and logs
invalid state packets. We place the established/related rule at the top because the vast majority of traffic on a network
is established and the invalid rule to prevent invalid state packets from mistakenly being matched against other rules.
Having the most matched rule listed first reduces CPU load in high volume environments. Note: I have filed a bug to
have this added as a default action as well.
‘’It is important to note, that you do not want to add logging to the established state rule as you will be logging both the
inbound and outbound packets for each session instead of just the initiation of the session. Your logs will be massive
in a very short period of time.”
In VyOS you must have the interfaces created before you can apply it to the zone and the rulesets must be created prior
to applying it to a zone-policy.
I create/configure the interfaces first. Build out the rulesets for each zone-pair-direction which includes at least the
three state rules. Then I setup the zone-policies.
Zones do not allow for a default action of accept; either drop or reject. It is important to remember this because if you
apply an interface to a zone and commit, any active connections will be dropped. Specifically, if you are SSH’d into
VyOS and add local or the interface you are connecting through to a zone and do not have rulesets in place to allow
SSH and established sessions, you will not be able to connect.
The following are the rules that were created for this example (may not be complete), both in IPv4 and IPv6. If there
is no IP specified, then the source/destination address is not explicit.
Lan-wan
Lan-local
Lan-dmz
Wan-lan
Wan-local
Wan-dmz
Local-lan
Local-wan
Local-dmz
Dmz-lan
Dmz-wan
Dmz-local
Even if the two zones will never communicate, it is a good idea to create the zone-pair-direction rulesets and set default-
log. This will allow you to log attempts to access the networks. Without it, you will never see the connection attempts.
This is an example of the three base rules.
name wan-lan {
default-action drop
default-log
rule 1 {
action accept
state {
established enable
(continues on next page)
ipv6-name dmz-wan-6 {
default-action drop
default-log
rule 1 {
action accept
state {
established enable
related enable
}
}
rule 2 {
action drop
log enable
state {
invalid enable
}
rule 100 {
action accept
log enable
protocol ipv6-icmp
}
rule 200 {
action accept
destination {
port 80,443
}
log enable
protocol tcp
}
rule 300 {
action accept
destination {
port 20,21
}
log enable
protocol tcp
}
rule 500 {
(continues on next page)
Once you have all of your rulesets built, then you need to create your zone-policy.
Start by setting the interface and default action for each zone.
In this case, we are setting the v6 ruleset that represents traffic sourced from the LAN, destined for the DMZ. Because
the zone-policy firewall syntax is a little awkward, I keep it straight by thinking of it backwards.
DMZ-LAN policy is LAN-DMZ. You can get a rhythm to it when you build out a bunch at one time.
In the end, you will end up with something like this config. I took out everything but the Firewall, Interfaces, and
zone-policy sections. It is long enough as is.
IPv6 Tunnel
If you are using a IPv6 tunnel from HE.net or someone else, the basis is the same except you have two WAN interfaces.
One for v4 and one for v6.
You would have 5 zones instead of just 4 and you would configure your v6 ruleset between your tunnel interface and
your LAN/DMZ zones instead of to the WAN.
LAN, WAN, DMZ, local and TUN (tunnel)
v6 pairs would be:
lan-tun
lan-local
lan-dmz
tun-lan
tun-local
tun-dmz
local-lan
local-tun
local-dmz
dmz-lan
dmz-tun
dmz-local
rule 400 {
action accept
destination {
address 172.16.10.1
}
log enable
protocol 41
source {
address ip.of.tunnel.broker
}
}
12.2.1 Configuration
• Router A:
• Router B:
12.2.2 Results
• Router A:
• Router B:
12.3.1 Configuration
• Router A:
• Router B:
12.3.2 Results
• Router A:
• Router B:
This guide shows an example of a route-based IKEv2 site-to-site VPN to Azure using VTI and BGP for dynamic routing
updates.
For redundant / active-active configurations see Route-Based Redundant Site-to-Site VPN to Azure (BGP over
IKEv2/IPsec)
12.4.1 Prerequisites
• A pair of Azure VNet Gateways deployed in active-passive configuration with BGP enabled.
• A local network gateway deployed in Azure representing the Vyos device, matching the below Vyos settings
except for address space, which only requires the Vyos private IP, in this example 10.10.0.5/32
• A connection resource deployed in Azure linking the Azure VNet gateway and the local network gateway repre-
senting the Vyos device.
12.4.2 Example
• Configure the IKE and ESP settings to match a subset of those supported by Azure:
This guide shows an example of a redundant (active-active) route-based IKEv2 site-to-site VPN to Azure using VTI
and BGP for dynamic routing updates.
12.5.1 Prerequisites
• A pair of Azure VNet Gateways deployed in active-active configuration with BGP enabled.
• A local network gateway deployed in Azure representing the Vyos device, matching the below Vyos settings
except for address space, which only requires the Vyos private IP, in this example 10.10.0.5/32
• A connection resource deployed in Azure linking the Azure VNet gateway and the local network gateway repre-
senting the Vyos device.
12.5.2 Example
• Configure the IKE and ESP settings to match a subset of those supported by Azure:
12.5. Route-Based Redundant Site-to-Site VPN to Azure (BGP over IKEv2/IPsec) 1154
VyOS Documentation, Release 1.5.x (circinus)
12.5. Route-Based Redundant Site-to-Site VPN to Azure (BGP over IKEv2/IPsec) 1155
VyOS Documentation, Release 1.5.x (circinus)
• Important: Disable connected check, otherwise the routes learned from Azure will not be imported into the
routing table.
This document walks you through a complete HA setup of two VyOS machines. This design is based on a VM as the
primary router and a physical machine as a backup, using VRRP, BGP, OSPF, and conntrack sharing.
This document aims to walk you through setting everything up, so at a point where you can reboot any machine and
not lose more than a few seconds worth of connectivity.
12.6.1 Design
This is based on a real-life production design. One of the complex issues is ensuring you have redundant data INTO
your network. We do this with a pair of Cisco Nexus switches and using Virtual PortChannels that are spanned across
them. As a bonus, this also allows for complete switch failure without an outage. How you achieve this yourself is left
as an exercise to the reader. But our setup is documented here.
Walkthrough suggestion
The commit command is implied after every section. If you make an error, commit will warn you and you can fix it
before getting too far into things. Please ensure you commit early and commit often.
If you are following through this document, it is strongly suggested you complete the entire document, ONLY doing
the virtual router1 steps, and then come back and walk through it AGAIN on the backup hardware router.
This ensures you don’t go too fast or miss a step. However, it will make your life easier to configure the fixed IP address
and default route now on the hardware router.
Example Network
In this document, we have been allocated 203.0.113.0/24 by our upstream provider, which we are publishing on
VLAN100.
They want us to establish a BGP session to their routers on 192.0.2.11 and 192.0.2.12 from our routers 192.0.2.21 and
192.0.2.22. They are AS 65550 and we are AS 65551.
Our routers are going to have a floating IP address of 203.0.113.1, and use .2 and .3 as their fixed IPs.
We are going to use 10.200.201.0/24 for an ‘internal’ network on VLAN201.
When traffic is originated from the 10.200.201.0/24 network, it will be masqueraded to 203.0.113.1
For connection between sites, we are running a WireGuard link to two REMOTE routers and using OSPF over those
links to distribute routes. That remote site is expected to send traffic from anything in 10.201.0.0/16
VLANs
Hardware
Network Cabling
• From Datacenter - This connects into port 1 on both switches, and is tagged as VLAN 50
• Cisco VPC Crossconnect - Ports 39 and 40 bonded between each switch
• Hardware Router - Port 8 of each switch
• compute1 - Port 9 of each switch
• compute2 - Port 10 of each switch
• compute3 - Port 11 of each switch
This is ignoring the extra Out-of-band management networking, which should be on totally different switches, and a
different feed into the rack, and is out of scope of this.
Note: Our implementation uses VMware’s Distributed Port Groups, which allows VMware to use LACP. This is a
part of the ENTERPRISE licence, and is not available on a free licence. If you are implementing this and do not have
access to DPGs, you should not use VMware, and use some other virtualization platform instead.
Create your router1 VM. So it can withstand a VM Host failing or a network link failing. Using VMware, this is
achieved by enabling vSphere DRS, vSphere Availability, and creating a Distributed Port Group that uses LACP.
Many other Hypervisors do this, and I’m hoping that this document will be expanded to document how to do this for
others.
Create an ‘All VLANs’ network group, that passes all trunked traffic through to the VM. Attach this network group to
router1 as eth0.
Note: VMware: You must DISABLE SECURITY on this Port group. Make sure that Promiscuous Mode, MAC
address changes and Forged transmits are enabled. All of these will be done as part of failover.
Create a LACP bond on the hardware router. We are assuming that eth0 and eth1 are connected to port 8 on both
switches, and that those ports are configured as a Port-Channel.
VLAN 100 and 201 will have floating IP addresses, but VLAN50 does not, as this is talking directly to upstream.
Create our IP address on vlan50.
For the hardware router, replace eth0 with bond0. As (almost) every command is identical, this will not be specified
unless different things need to be performed on different hosts.
It is assumed that the routers provided by upstream are capable of acting as a default router, add that as a static route.
Enable SSH
Enable SSH so you can now SSH into the routers, rather than using the console.
At this point, you should be able to SSH into both of them, and will no longer need access to the console (unless you
break something!)
We are setting up VRRP so that it does NOT fail back when a machine returns into service, and it prioritizes router1
over router2.
Internal Network
This has a floating IP address of 10.200.201.1/24, using virtual router ID 201. The difference between them is the
interface name, hello-source-address, and peer-address.
router1
router2
Public Network
This has a floating IP address of 203.0.113.1/24, using virtual router ID 113. The virtual router ID is just a random
number between 1 and 254, and can be set to whatever you want. Best practices suggest you try to keep them unique
enterprise-wide.
router1
router2
The sync group is used to replicate connection tracking. It needs to be assigned to a random VRRP group, and we are
creating a sync group called sync using the vrrp group int.
Testing
At this point, you should be able to see both IP addresses when you run show interfaces, and show vrrp should
show both interfaces in MASTER state (and SLAVE state on router2).
You should be able to ping to and from all the IPs you have allocated.
Masquerade Traffic originating from 10.200.201.0/24 that is heading out the public interface.
Note: We explicitly exclude the primary upstream network so that BGP or OSPF traffic doesn’t accidentally get
NAT’ed.
Conntrack helper modules are enabled by default, but they tend to cause more problems than they’re worth in complex
networks. You can disable all of them at one go.
Now enable replication between nodes. Replace eth0.201 with bond0.201 on the hardware router.
Testing
The simplest way to test is to look at the connection tracking stats on the standby hardware router with the command
show conntrack-sync statistics. The numbers should be very close to the numbers on the primary router.
When you have both routers up, you should be able to establish a connection from a NAT’ed machine out to the internet,
reboot the active machine, and that connection should be preserved, and will not drop out.
Wireguard doesn’t have the concept of an up or down link, due to its design. This complicates AND simplifies using it
for network transport, as for reliable state detection you need to use SOMETHING to detect when the link is down.
If you use a routing protocol itself, you solve two problems at once. This is only a basic example, and is provided as a
starting point.
Configure Wireguard
There is plenty of instructions and documentation on setting up Wireguard. The only important thing you need to
remember is to only use one WireGuard interface per OSPF connection.
We use small /30’s from 10.254.60/24 for the point-to-point links.
router1
Replace the 203.0.113.3 with whatever the other router’s IP address is.
offsite1
This is connecting back to the STATIC IP of router1, not the floating.
Test WireGuard
Make sure you can ping 10.254.60.1 and .2 from both routers.
We only want to export the networks we know. Always do a whitelist on your route filters, both importing and exporting.
A good rule of thumb is ‘If you are not the default router for a network, don’t advertise it’. This means we explicitly
do not want to advertise the 192.0.2.0/24 network (but do want to advertise 10.200.201.0 and 203.0.113.0, which we
ARE the default route for). This filter is applied to redistribute connected. If we WERE to advertise it, the
remote machines would see 192.0.2.21 available via their default route, establish the connection, and then OSPF would
say ‘192.0.2.0/24 is available via this tunnel’, at which point the tunnel would break, OSPF would drop the routes, and
then 192.0.2.0/24 would be reachable via default again. This is called ‘flapping’.
We only want to import networks we know. Our OSPF peer should only be advertising networks in the 10.201.0.0/16
range. Note that this is an INVERSE MATCH. You deny in access-list 100 to accept the route.
set policy access-list 100 description 'Inbound OSPF Routes from Peers'
set policy access-list 100 rule 10 action 'deny'
set policy access-list 100 rule 10 destination any
set policy access-list 100 rule 10 source inverse-mask '0.0.255.255'
set policy access-list 100 rule 10 source network '10.201.0.0'
set policy access-list 100 rule 100 action 'permit'
set policy access-list 100 rule 100 destination any
set policy access-list 100 rule 100 source any
set policy route-map PUBOSPF rule 100 action 'deny'
set policy route-map PUBOSPF rule 100 match ip address access-list '100'
set policy route-map PUBOSPF rule 500 action 'permit'
Enable OSPF
Every router must have a unique router-id. The ‘reference-bandwidth’ is used because when OSPF was originally
designed, the idea of a link faster than 1gbit was unheard of, and it does not scale correctly.
Test OSPF
When you have enabled OSPF on both routers, you should be able to see each other with the command show ip ospf
neighbour. The state must be ‘Full’ or ‘2-Way’. If it is not, then there is a network connectivity issue between the
hosts. This is often caused by NAT or MTU issues. You should not see any new routes (unless this is the second pass)
in the output of show ip route
As a reminder, only advertise routes that you are the default router for. This is why we are NOT announcing the
192.0.2.0/24 network, because if that was announced into OSPF, the other routers would try to connect to that network
over a tunnel that connects to that network!
You should now be able to see the advertised network on the other host.
Duplicate configuration
At this point, you now need to create the X link between all four routers. Use amdifferent /30 for each link.
Priorities
Set the cost on the secondary links to be 200. This means that they will not be used unless the primary links are down.
12.6.7 BGP
router1
The redistribute ospf command is there purely as an example of how this can be expanded. In this walkthrough,
it will be filtered by BGPOUT rule 10000, as it is not 203.0.113.0/24.
router2
This is identical, but you use the BGPPREPENDOUT route-map to advertise the route with a longer path.
Overview
• All traffic coming in through eth2 is balanced between eth0 and eth1 on the router.
• Pings will be sent to four targets for health testing (33.44.55.66, 44.55.66.77, 55.66.77.88 and 66.77.88.99).
• All outgoing packets are assigned the source address of the assigned interface (SNAT).
• eth0 is set to be removed from the load balancer’s interface pool after 5 ping failures, eth1 will be removed after
4 ping failures.
Create static routes through the two ISPs towards the ping targets and commit the changes:
Configure the WAN load balancer with the parameters described above:
Overview
In this example, eth0 is the primary interface and eth1 is the secondary interface. To provide simple failover function-
ality. If eth0 fails, eth1 takes over.
The configuration steps are the same as in the previous example, except rule 10. So we keep the configuration, remove
rule 10 and add a new rule for the failover mode:
The previous example used the failover command to send traffic through eth1 if eth0 fails. In this example, failover
functionality is provided by rule order.
Overview
Two rules will be created, the first rule directs traffic coming in from eth2 to eth0 and the second rule directs the traffic
to eth1. If eth0 fails the first rule is bypassed and the second rule matches, directing traffic to eth1.
We keep the configuration from the previous example, delete rule 10 and create the two new rules as described:
A rule order for prioritizing traffic is useful in scenarios where the secondary link has a lower speed and should only
carry high priority traffic. It is assumed for this example that eth1 is connected to a slower connection than eth0 and
should prioritize VoIP traffic.
Overview
A rule order for prioritizing traffic is useful in scenarios where the secondary link has a lower speed and should only
carry high priority traffic. It is assumed for this example that eth1 is connected to a slower connection than eth0 and
should prioritize VoIP traffic.
Create rule order based configuration with low speed secondary link
We keep the configuration from the previous example, delete rule 20 and create a new rule as described:
In this example two LAN interfaces exist in different subnets instead of one like in the previous examples:
Based on the previous example, another rule for traffic from the second interface eth3 can be added to the load balancer.
However, traffic meant to flow between the LAN subnets will be sent to eth0 and eth1 as well. To prevent this, another
rule is required. This rule excludes traffic between the local subnets from the load balancer. It also excludes locally-
sources packets (required for web caching with load balancing). eth+ is used as an alias that refers to all ethernet
interfaces:
This document is to describe a basic setup using PPPoE with DHCPv6-PD + SLAAC to construct a typical home
network. The user can follow the steps described here to quickly setup a working network and use this as a starting
point to further configure or fine-tune other settings.
To achieve this, your ISP is required to support DHCPv6-PD. If you’re not sure, please contact your ISP for more
information.
12.8.2 Configurations
PPPoE Setup
• Fill password and user with the credential provided by your ISP.
• service-name can be an arbitrary string.
DHCPv6-PD Setup
During address configuration, in addition to assigning an address to the WAN interface, ISP also provides a prefix to
allow the router to configure addresses of LAN interface and other nodes connecting to LAN, which is called prefix
delegation (PD).
• Here we use the prefix to configure the address of eth1 (LAN) to form <prefix>::64, where 64 is hexadecimal
of address 100.
• For home network users, most of time ISP only provides /64 prefix, hence there is no need to set SLA ID and
prefix length. See PPPoE for more information.
Router Advertisement
We need to enable router advertisement for LAN network so that PC can receive the prefix and use SLAAC to configure
the address automatically.
Basic Firewall
To have basic protection while keeping IPv6 network functional, we need to:
• Allow all established and related traffic for router and LAN
• Allow all icmpv6 packets for router and LAN
• Allow DHCPv6 packets for router
Note to allow the router to receive DHCPv6 response from ISP. We need to allow packets with source port 547 (server)
and destination port 546 (client).
IP/MPLS technology is widely used by various service providers and large enterprises in order to achieve better network
scalability, manageability and flexibility. It also provides the possibility to deliver different services for the customers
in a seamless manner. Layer 3 VPN (L3VPN) is a type of VPN mode that is built and delivered through OSI layer 3
networking technologies. Often the border gateway protocol (BGP) is used to send and receive VPN-related data that
is responsible for the control plane. L3VPN utilizes virtual routing and forwarding (VRF) techniques to receive and
deliver user data as well as separate data planes of the end-users. It is built using a combination of IP- and MPLS-based
information. Generally, L3VPNs are used to send data on back-end VPN infrastructures, such as for VPN connections
between data centres, HQs and branches.
An L3VPN consists of multiple access links, multiple VPN routing and forwarding (VRF) tables, and multiple MPLS
paths or multiple P2MP LSPs. An L3VPN can be configured to connect two or more customer sites. In hub-and-spoke
MPLS L3VPN environments, the spoke routers need to have unique Route Distinguishers (RDs). In order to use the
hub site as a transit point for connectivity in such an environment, the spoke sites export their routes to the hub. Spokes
can talk to hubs, but never have direct paths to other spokes. All traffic between spokes is controlled and delivered over
the hub site.
To deploy a Layer3 VPN with MPLS on VyOS, we should meet a couple requirements in order to properly implement
the solution. We’ll use the following nodes in our LAB environment:
• 2 x Route reflectors (VyOS-RRx)
• 4 x Provider routers (VyOS-Px)
• 3 x Provider Edge (VyOs-PEx)
• 3 x Customer Edge (VyOS-CEx)
The following software was used in the creation of this document:
• Operating system: VyOS
• Version: 1.4-rolling-202110310317
• Image name: vyos-1.4-rolling-202110310317-amd64.iso
NOTE: VyOS Router (tested with VyOS 1.4-rolling-202110310317) – The configurations below are specifically for
VyOS 1.4.x.
General information can be found in the L3VPN VRFs chapter.
12.9.1 Topology
As we know the main assumption of L3VPN “Hub and Spoke” is, that the traffic between spokes have to pass via
hub, in our scenario VyOS-PE2 is the Hub PE and the VyOS-CE1-HUB is the central customer office device that is
responsible for controlling access between all spokes and announcing its network prefixes (10.0.0.100/32). VyOS-
PE2 has the main VRF (its name is BLUE_HUB), its own Route-Distinguisher(RD) and route-target import/export
lists. Multiprotocol-BGP(MP-BGP) delivers L3VPN related control-plane information to the nodes across network
where PEs Spokes import the route-target 60535:1030 (this is export route-target of vrf BLUE_HUB) and export its
own route-target 60535:1011(this is vrf BLUE_SPOKE export route-target). Therefore, the Customer edge nodes can
only learn the network prefixes of the HUB site [10.0.0.100/32]. For this example VyOS-CE1 has network prefixes
[10.0.0.80/32] / VyOS-CE2 has network prefixes [10.0.0.90/32]. Route-Reflector devices VyOS-RR1 and VyOS-RR2
are used to simplify network routes exchange and minimize iBGP peerings between devices.
L3VPN configuration parameters table:
12.9.3 Configuration
At the first step we need to configure the IP/MPLS backbone network using OSPF as IGP protocol and LDP as label-
switching protocol for the base connectivity between P (rovider), P (rovider) E (dge) and R (oute) R (eflector) nodes:
• VyOS-P1:
# interfaces
set interfaces dummy dum10 address '10.0.0.3/32'
(continues on next page)
# protocols ospf+ldp
set protocols mpls interface 'eth1'
set protocols mpls interface 'eth2'
set protocols mpls interface 'eth3'
set protocols mpls interface 'eth5'
set protocols mpls interface 'eth0'
set protocols mpls ldp discovery transport-ipv4-address '10.0.0.3'
set protocols mpls ldp interface 'eth0'
set protocols mpls ldp interface 'eth1'
set protocols mpls ldp interface 'eth2'
set protocols mpls ldp interface 'eth3'
set protocols mpls ldp interface 'eth5'
set protocols mpls ldp router-id '10.0.0.3'
set protocols ospf area 0 network '0.0.0.0/0'
set protocols ospf parameters abr-type 'cisco'
set protocols ospf parameters router-id '10.0.0.3
• VyOS-P2:
# interfaces
set interfaces dummy dum10 address '10.0.0.4/32'
set interfaces ethernet eth0 address '172.16.30.2/24'
set interfaces ethernet eth1 address '172.16.20.1/24'
set interfaces ethernet eth2 address '172.16.120.1/24'
set interfaces ethernet eth3 address '172.16.60.1/24'
# protocols ospf+ldp
set protocols mpls interface 'eth1'
set protocols mpls interface 'eth2'
set protocols mpls interface 'eth3'
set protocols mpls interface 'eth0'
set protocols mpls ldp discovery transport-ipv4-address '10.0.0.4'
set protocols mpls ldp interface 'eth0'
set protocols mpls ldp interface 'eth1'
set protocols mpls ldp interface 'eth2'
set protocols mpls ldp interface 'eth3'
set protocols mpls ldp router-id '10.0.0.4'
set protocols ospf area 0 network '0.0.0.0/0'
set protocols ospf parameters abr-type 'cisco'
set protocols ospf parameters router-id '10.0.0.4'
• VyOS-P3:
# interfaces
set interfaces dummy dum10 address '10.0.0.5/32'
set interfaces ethernet eth0 address '172.16.110.1/24'
(continues on next page)
• VyOS-P4:
# interfaces
set interfaces dummy dum10 address '10.0.0.6/32'
set interfaces ethernet eth0 address '172.16.80.2/24'
set interfaces ethernet eth1 address '172.16.130.1/24'
set interfaces ethernet eth2 address '172.16.50.2/24'
set interfaces ethernet eth3 address '172.16.60.2/24'
set interfaces ethernet eth5 address '172.16.140.1/24'
• VyOS-PE1:
# interfaces
set interfaces dummy dum10 address '10.0.0.7/32'
set interfaces ethernet eth0 address '172.16.90.2/24'
(continues on next page)
• VyOS-PE2:
# interfaces
set interfaces dummy dum10 address '10.0.0.8/32'
set interfaces ethernet eth0 address '172.16.110.2/24'
set interfaces ethernet eth1 address '172.16.100.2/24'
set interfaces ethernet eth2 address '172.16.80.1/24'
• VyOS-PE3:
# interfaces
set interfaces dummy dum10 address '10.0.0.10/32'
set interfaces ethernet eth0 address '172.16.140.2/24'
• VyOS-RR1:
# interfaces
set interfaces ethernet eth1 address '172.16.20.2/24'
set interfaces ethernet eth2 address '172.16.10.2/24'
set interfaces dummy dum10 address '10.0.0.1/32'
• VyOS-RR2:
# interfaces
set interfaces ethernet eth0 address '172.16.80.1/24'
set interfaces ethernet eth1 address '172.16.70.2/24'
set interfaces dummy dum10 address '10.0.0.2/32'
At this step we are going to enable iBGP protocol on MPLS nodes and Route Reflectors (two routers for redundancy)
that will deliver IPv4 VPN (L3VPN) routes between them:
• VyOS-RR1:
• VyOS-RR2:
• VyOS-PE1:
• VyOS-PE2:
• VyOS-PE3:
This section provides configuration steps for setting up VRFs on our PE nodes including CE facing interfaces, BGP, rd
and route-target import/export based on the pre-defined parameters.
• VyOS-PE1:
# VRF settings
set vrf name BLUE_SPOKE table '200'
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast export vpn
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast import vpn
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast label vpn export 'auto'
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast network 10.50.50.0/24
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast rd vpn export '10.50.
˓→50.1:1011'
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast redistribute connected
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast route-target vpn␣
˓→export '65035:1011'
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast route-target vpn␣
˓→import '65035:1030'
set vrf name BLUE_SPOKE protocols bgp neighbor 10.50.50.2 remote-as '65035'
# interfaces
set interfaces ethernet eth3 address '10.50.50.1/24'
set interfaces ethernet eth3 vrf 'BLUE_SPOKE'
• VyOS-PE2:
# VRF settings
set vrf name BLUE_HUB table '400'
set vrf name BLUE_HUB protocols bgp address-family ipv4-unicast export vpn
set vrf name BLUE_HUB protocols bgp address-family ipv4-unicast import vpn
set vrf name BLUE_HUB protocols bgp address-family ipv4-unicast label vpn export 'auto'
set vrf name BLUE_HUB protocols bgp address-family ipv4-unicast network 10.80.80.0/24
set vrf name BLUE_HUB protocols bgp address-family ipv4-unicast rd vpn export '10.80.80.
˓→1:1011'
set vrf name BLUE_HUB protocols bgp address-family ipv4-unicast redistribute connected
set vrf name BLUE_HUB protocols bgp address-family ipv4-unicast route-target vpn export
˓→'65035:1030'
set vrf name BLUE_HUB protocols bgp address-family ipv4-unicast route-target vpn import
˓→'65035:1011 65050:2011 65035:1030'
set vrf name BLUE_HUB protocols bgp neighbor 10.80.80.2 remote-as '65035'
# interfaces
set interfaces ethernet eth3 address '10.80.80.1/24'
set interfaces ethernet eth3 vrf 'BLUE_HUB'
• VyOS-PE3:
# VRF settings
set vrf name BLUE_SPOKE table '200'
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast export vpn
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast import vpn
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast label vpn export 'auto'
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast network 10.60.60.0/24
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast rd vpn export '10.60.
˓→60.1:1011'
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast redistribute connected
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast route-target vpn␣
˓→export '65035:1011'
set vrf name BLUE_SPOKE protocols bgp address-family ipv4-unicast route-target vpn␣
˓→import '65035:1030'
set vrf name BLUE_SPOKE protocols bgp neighbor 10.60.60.2 remote-as '65035'
# interfaces
set interfaces ethernet eth3 address '10.60.60.1/24'
set interfaces ethernet eth3 vrf 'BLUE_SPOKE'
Dynamic routing used between CE and PE nodes and eBGP peering established for the route exchanging between them.
All routes received by PEs are then exported to L3VPN and delivered from Spoke sites to Hub and vise-versa based on
previously configured L3VPN parameters.
• VyOS-CE1-SPOKE:
# interfaces
set interfaces dummy dum20 address '10.0.0.80/32'
set interfaces ethernet eth0 address '10.50.50.2/24'
• VyOS-CE1-HUB:
# interfaces
set interfaces dummy dum20 address '10.0.0.100/32'
set interfaces ethernet eth0 address '10.80.80.2/24'
• VyOS-CE2-SPOKE:
# interfaces
set interfaces dummy dum20 address '10.0.0.90/32'
set interfaces ethernet eth0 address '10.60.60.2/24'
Step-5: Verification
This section describes verification commands for MPLS/BGP/LDP protocols and L3VPN related routes as well as
diagnosis and reachability checks between CE nodes.
Let’s check IPv4 routing and MPLS information on provider nodes (same procedure for all P nodes):
• “show ip ospf neighbor” for checking ospf relationship
Now we’re checking iBGP status and routes from route-reflector nodes to other devices:
• “show bgp ipv4 vpn summary” for checking BGP VPNv4 neighbors:
• “show bgp ipv4 vpn” for checking all VPNv4 prefixes information:
• “show bgp ipv4 vpn x.x.x.x/x” for checking best path selected for specific VPNv4 destination
Also we can verify how PE devices receives VPNv4 networks from the RRs and installing them to the specific customer
VRFs:
• “show bgp ipv4 vpn summary” for checking iBGP neighbors against route-reflector devices:
• “show bgp vrf all” for checking all the prefix learning on BGP
within VRFs:
Instance default:
No BGP prefixes displayed, 0 exist
Instance BLUE_SPOKE:
BGP table version is 8, local router ID is 10.50.50.1, vrf id 6
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
• “show ip route vrf BLUE_SPOKE” for viewing the RIB in our Spoke PE.
Using this command we are also able to check the transport and customer label (inner/outer) for Hub net-
work prefix (10.0.0.100/32):
VRF BLUE_SPOKE:
K>* 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 03w0d23h
C>* 10.50.50.0/24 is directly connected, eth3, 03w0d23h
B> 10.80.80.0/24 [200/0] via 10.0.0.8 (vrf default) (recursive), label 80, weight 1,␣
˓→04:22:00
• “show bgp ipv4 vpn x.x.x.x/32” for checking the best-path to the
specific VPNv4 destination including extended community and remotelabel information. This procedure
is the same on all Spoke nodes:
• “show bgp vrf all” for checking all the prefixes learning on BGP
Instance default:
No BGP prefixes displayed, 0 exist
Instance BLUE_HUB:
BGP table version is 50, local router ID is 10.80.80.1, vrf id 8
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
• “show ip route vrf BLUE_HUB” to view the RIB in our Hub PE.
With this command we are able to check the transport and customer label (inner/outer) for network spokes
prefixes 10.0.0.80/32 - 10.0.0.90/32
B> 10.60.60.0/24 [200/0] via 10.0.0.10 (vrf default) (recursive), label 144, weight 1,␣
˓→05:53:15
B> 10.0.0.80/32 [200/0] via 10.0.0.7 (vrf default) (recursive), label 144, weight 1,␣
˓→05:53:15
B> 10.0.0.90/32 [200/0] via 10.0.0.10 (vrf default) (recursive), label 144, weight 1,␣
˓→05:53:15
# check rib
vyos@VyOS-CE1-SPOKE:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
# check icmp
vyos@VyOS-CE1-SPOKE:~$ ping 10.0.0.100 interface 10.0.0.80
PING 10.0.0.100 (10.0.0.100) from 10.0.0.80 : 56(84) bytes of data.
64 bytes from 10.0.0.100: icmp_seq=1 ttl=62 time=6.52 ms
64 bytes from 10.0.0.100: icmp_seq=2 ttl=62 time=4.13 ms
64 bytes from 10.0.0.100: icmp_seq=3 ttl=62 time=4.04 ms
64 bytes from 10.0.0.100: icmp_seq=4 ttl=62 time=4.03 ms
^C
--- 10.0.0.100 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 4.030/4.680/6.518/1.064 ms
# check icmp
vyos@VyOS-CE-HUB:~$ ping 10.0.0.80 interface 10.0.0.100 c 4
PING 10.0.0.80 (10.0.0.80) from 10.0.0.100 : 56(84) bytes of data.
64 bytes from 10.0.0.80: icmp_seq=1 ttl=62 time=3.31 ms
64 bytes from 10.0.0.80: icmp_seq=2 ttl=62 time=4.23 ms
(continues on next page)
# check rib
vyos@rt-ce2-SPOKE:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
# check icmp
vyos@rt-ce2-SPOKE:~$ ping 10.0.0.100 interface 10.0.0.90 c 4
PING 10.0.0.100 (10.0.0.100) from 10.0.0.90 : 56(84) bytes of data.
64 bytes from 10.0.0.100: icmp_seq=1 ttl=62 time=4.97 ms
64 bytes from 10.0.0.100: icmp_seq=2 ttl=62 time=4.45 ms
(continues on next page)
Note: At the moment, trace mpls doesn’t show labels/paths. So we’ll see * * * for the transit routers of the mpls
backbone.
This document is to describe a basic setup using PPPoE over L2TP. LAC and LNS are components of the broadband
topology. LAC - L2TP access concentrator LNS - L2TP Network Server LAC and LNS forms L2TP tunnel. LAC
receives packets from PPPoE clients and forward them to LNS. LNS is the termination point that comes from PPP
packets from the remote client.
In this example we use VyOS 1.5 as LNS and Cisco IOS as LAC. All users with domain vyos.io will be tunneled to
LNS via L2TP.
12.10.2 Configurations
LAC
aaa new-model
!
aaa authentication ppp default local
!
vpdn enable
vpdn aaa attribute nas-ip-address vpdn-nas
!
vpdn-group LAC
request-dialin
protocol l2tp
domain vyos.io
initiate-to ip 192.168.139.100
source-ip 192.168.139.101
local name LAC
l2tp tunnel password 0 test123
!
bba-group pppoe MAIN-BBA
virtual-template 1
!
interface GigabitEthernet0/0
description To LNS
ip address 192.168.139.101 255.255.255.0
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/1
description To PPPoE clients
no ip address
duplex auto
speed auto
media-type rj45
pppoe enable group MAIN-BBA
!
LNS
Note: This setup requires the Compression Control Protocol (CCP) being disabled, the command set vpn l2tp
remote-access ppp-options disable-ccp accomplishes that.
Client
Monitoring
Router#show l2tp
L2TP Tunnel and Session Information Total tunnels 1 sessions 1
LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/
Count VPDN Group
23238 2640 LAC est 192.168.139.100 1 LAC
Virtual Routing and Forwarding is a technology that allow multiple instance of a routing table to exist within a single
device. One of the key aspect of VRFs is that do not share the same routes or interfaces, therefore packets are forwarded
between interfaces that belong to the same VRF only.
Any information related to a VRF is not exchanged between devices -or in the same device- by default, this is a technique
called VRF-Lite.
Keep networks isolated is -in general- a good principle, but there are cases where you might need that some network
can access other in a different VRF.
The scope of this document is to cover such cases in a dynamic way without the use of MPLS-LDP.
General information about L3VPNs can be found in the L3VPN VRFs chapter.
12.11.1 Overview
12.11.2 Topology
IP Schema
RD & RT Schema
VRF RD RT
LAN1 64496:1 64496:1
LAN2 64496:2 64496:2
Management 64496:50 64496:50
Internet 64496:100 64496:100
12.11.3 Configurations
Note: We use a static route configuration in between the Core and each LAN and Management router, and BGP
between the Core router and the ISP router but any dynamic routing protocol can be used.
Remote Networks
The following template configuration can be used in each remote router based in our topology.
# Interface Configuration
set interface eth eth<N> address <IP ADDRESS/CIDR>
Core Router
• Configuration
Set the VRF name and Table ID, set interface address and bind it to the VRF. Last add the static route to the remote
network.
# Interface Configuration
set interface eth eth<N> address <IP ADDRESS/CIDR>
• Verification
Checking the routing table of the VRF should reveal both static and connected entries active. A PING test between the
Core and remote router is a way to validate connectivity within the VRF.
VRF LAN1:
S>* 10.0.0.0/24 [1/0] via 10.1.1.2, eth0, weight 1, 00:05:41
C>* 10.1.1.0/30 is directly connected, eth0, 00:05:44
VRF LAN1:
C>* 2001:db8::/127 is directly connected, eth0, 00:18:43
S>* 2001:db8:0:1::/64 [1/0] via 2001:db8::1, eth0, weight 1, 00:16:03
C>* fe80::/64 is directly connected, eth0, 00:18:43
• Configuration
Setting BGP global local-as as well inside the VRF. Redistribute static routes to inject configured networks into the
BGP process but still inside the VRF.
• Verification
Check the BGP VRF table and verify if the static routes are injected showing the correct next-hop information.
• Configuration
Within the VRF we set the Route-Distinguisher (RD) and Route-Targets (RT), then we enable the export/import VPN.
# set Route-distinguisher
set vrf name <VRF> protocols bgp address-family <AF IPv4/IPv6> rd vpn export '<RD>'
set vrf name <VRF> protocols bgp address-family <AF IPv4/IPv6> route-target vpn import '
˓→<RT:Import>'
A key point to understand is that if we need two VRFs to communicate between each other EXPORT rt from VRF1
has to be in the IMPORT rt list from VRF2. But this is only in ONE direction, to complete the communication the
EXPORT rt from VRF2 has to be in the IMPORT rt list from VRF1.
There are some cases where this is not needed -for example, in some DDoS appliance- but most inter-vrf routing designs
use the above configurations.
• Verification
After configured all the VRFs involved in this topology we take a deeper look at both BGP and Routing table for the
VRF LAN1
VRF LAN1:
B>* 0.0.0.0/0 [20/0] via 10.2.2.2, eth3 (vrf Internet), weight 1, 00:00:38
S>* 10.0.0.0/24 [1/0] via 10.1.1.2, eth0, weight 1, 00:29:57
C>* 10.1.1.0/30 is directly connected, eth0, 00:29:59
B 10.2.2.0/30 [20/0] via 10.2.2.2 (vrf Internet) inactive, weight 1, 00:00:38
B>* 172.16.0.0/24 [20/0] via 172.16.2.2, eth1 (vrf LAN2), weight 1, 00:00:38
B>* 192.0.2.0/24 [20/0] via 10.2.2.2, eth3 (vrf Internet), weight 1, 00:00:38
B>* 198.51.100.0/24 [20/0] via 10.2.2.2, eth3 (vrf Internet), weight 1, 00:00:38
B>* 203.0.113.0/24 [20/0] via 10.2.2.2, eth3 (vrf Internet), weight 1, 00:00:38
VRF LAN1:
B>* ::/0 [20/0] via fe80::5200:ff:fe02:3, eth3 (vrf Internet), weight 1, 00:07:50
C>* 2001:db8::/127 is directly connected, eth0, 05:33:43
B>* 2001:db8::6/127 [20/0] via fe80::5200:ff:fe02:3, eth3 (vrf Internet), weight 1,␣
˓→00:07:50
B>* 2001:db8:2::/48 [20/0] via fe80::5200:ff:fe02:3, eth3 (vrf Internet), weight 1,␣
˓→00:07:50
B>* 2001:db8:3::/48 [20/0] via fe80::5200:ff:fe02:3, eth3 (vrf Internet), weight 1,␣
˓→00:07:50
As we can see in the BGP table any imported route has been injected with a “@” followed by the VPN id; In the routing
table of the VRF, if the route was installed, we can see -between round brackets- the exported VRF table.
• LAN1 to Outside
Note: we are using “source-address” option cause we are not redistributing connected interfaces into BGP on the Core
• LAN1 to LAN2
12.11.4 Conclusions
Inter-VRF routing is a well-known solution to address complex routing scenarios that enable -in a dynamic way- to leak
routes between VRFs. Is recommended to take special consideration while designing route-targets and its application
as it can minimize future interventions while creating a new VRF will automatically take the desired effect in its
propagation.
12.11.5 Appendix-A
• Core
set vrf name Internet protocols bgp address-family ipv4-unicast route-target vpn import
˓→'64496:1 64496:2'
set vrf name Internet protocols bgp address-family ipv6-unicast export vpn
set vrf name Internet protocols bgp address-family ipv6-unicast import vpn
set vrf name Internet protocols bgp address-family ipv6-unicast rd vpn export '64496:100'
set vrf name Internet protocols bgp address-family ipv6-unicast route-target vpn export
˓→'64496:100'
set vrf name Internet protocols bgp address-family ipv6-unicast route-target vpn import
˓→'64496:1 64496:2'
set vrf name LAN1 protocols bgp address-family ipv4-unicast route-target vpn import
˓→'64496:100 64496:50 64496:2'
set vrf name LAN1 protocols bgp address-family ipv6-unicast export vpn
set vrf name LAN1 protocols bgp address-family ipv6-unicast import vpn
set vrf name LAN1 protocols bgp address-family ipv6-unicast rd vpn export '64496:1'
set vrf name LAN1 protocols bgp address-family ipv6-unicast redistribute static
set vrf name LAN1 protocols bgp address-family ipv6-unicast route-target vpn export
˓→'64496:1'
set vrf name LAN1 protocols bgp address-family ipv6-unicast route-target vpn import
˓→'64496:100 64496:50 64496:2'
set vrf name LAN2 protocols bgp address-family ipv4-unicast route-target vpn import
˓→'64496:100 64496:50 64496:1'
set vrf name LAN2 protocols bgp address-family ipv6-unicast export vpn
set vrf name LAN2 protocols bgp address-family ipv6-unicast import vpn
set vrf name LAN2 protocols bgp address-family ipv6-unicast rd vpn export '64496:2'
set vrf name LAN2 protocols bgp address-family ipv6-unicast redistribute static
set vrf name LAN2 protocols bgp address-family ipv6-unicast route-target vpn export
˓→'64496:2'
set vrf name Management protocols bgp address-family ipv4-unicast redistribute static
set vrf name Management protocols bgp address-family ipv4-unicast route-target vpn␣
˓→export '64496:50'
set vrf name Management protocols bgp address-family ipv4-unicast route-target vpn␣
˓→import '64496:1 64496:2'
set vrf name Management protocols bgp address-family ipv6-unicast export vpn
set vrf name Management protocols bgp address-family ipv6-unicast import vpn
set vrf name Management protocols bgp address-family ipv6-unicast rd vpn export '64496:50
˓→'
set vrf name Management protocols bgp address-family ipv6-unicast redistribute static
set vrf name Management protocols bgp address-family ipv6-unicast route-target vpn␣
˓→export '64496:50'
set vrf name Management protocols bgp address-family ipv6-unicast route-target vpn␣
˓→import '64496:1 64496:2'
• LAN1
set interfaces dummy dum0 address '10.0.0.1/24'
set interfaces dummy dum0 address '2001:db8:0:1::1/64'
set interfaces ethernet eth0 address '10.1.1.2/30'
set interfaces ethernet eth0 address '2001:db8::1/127'
set protocols static route 0.0.0.0/0 next-hop 10.1.1.1
set protocols static route6 ::/0 next-hop 2001:db8::*
• LAN2
set interfaces dummy dum0 address '172.16.0.1/24'
set interfaces dummy dum0 address '2001:db8:0:2::1/64'
set interfaces ethernet eth0 hw-id '50:00:00:03:00:00'
set interfaces ethernet eth1 address '172.16.2.2/30'
set interfaces ethernet eth1 address '2001:db8::3/127'
set protocols static route 0.0.0.0/0 next-hop 172.16.2.1
set protocols static route6 ::/0 next-hop 2001:db8::2
• Management
set interfaces dummy dum0 address '192.168.0.1/24'
set interfaces dummy dum0 address '2001:db8:0:3::1/64'
set interfaces ethernet eth2 address '192.168.3.2/30'
(continues on next page)
• ISP
12.11.6 Appendix-B
Route-Filtering
When importing routes using MP-BGP it is possible to filter a subset of them before are injected in the BGP table. One
of the most common case is to use a route-map with an prefix-list.
• Configuration
We create a prefix-list first and add all the routes we need to.
Then add a route-map and reference to above prefix. Consider that the actions taken inside the prefix will MATCH the
routes that will be affected by the actions inside the rules of the route-map.
We are using a “white list” approach by allowing only what is necessary. In case that need to implement a “black list”
approach then you will need to change the action in the route-map for a deny BUT you need to add a rule that permits
the rest due to the implicit deny in the route-map.
Then we need to attach the policy to the BGP process. This needs to be under the import statement in the vrf we need
to filter.
set vrf name LAN2 protocols bgp address-family ipv4-unicast route-map vpn import 'LAN2-
˓→Internet'
set vrf name LAN2 protocols bgp address-family ipv6-unicast route-map vpn import 'LAN2-
˓→Internet-v6'
• Verification
B>* 10.0.0.0/24 [20/0] via 10.1.1.2, eth0 (vrf LAN1), weight 1, 00:45:28
S>* 172.16.0.0/24 [1/0] via 172.16.2.2, eth1, weight 1, 00:45:32
C>* 172.16.2.0/30 is directly connected, eth1, 00:45:39
B>* 192.0.2.0/24 [20/0] via 10.2.2.2, eth3 (vrf Internet), weight 1, 00:45:24
B>* 192.168.0.0/24 [20/0] via 192.168.3.2, eth2 (vrf Managment), weight 1, 00:45:27
B>* 198.51.100.0/24 [20/0] via 10.2.2.2, eth3 (vrf Internet), weight 1, 00:45:24
B>* 2001:db8:2::/48 [20/0] via fe80::5200:ff:fe02:3, eth3 (vrf Internet), weight 1,␣
˓→00:46:13
As we can see even if both VRF LAN1 and LAN2 has the same import RTs we are able to select which routes are
effectively imported and installed.
In this case, we’ll try to make a simple lab using QoS and the general ability of the VyOS system. We recommend you
to go through the main article about QoS first.
Using the general schema for example:
We have four hosts on the local network 172.17.1.0/24. All hosts are labeled CS0 by default. We need to replace labels
on all hosts except vpc8. We will replace the labels on the nearest router “VyOS3” using the IP addresses of the sources.
• 172.17.1.2 CS0 -> CS4
• 172.17.1.3 CS0 -> CS5
• 172.17.1.4 CS0 -> CS6
• 172.17.1.40 CS0 by default
Next, we will replace only all CS4 labels on the “VyOS2” router.
• CS4 -> CS5
In the end, we will configure the traffic shaper using QoS mechanisms on the “VYOS2” router.
12.12.2 Configuration:
Set IP addresses on all VPCs and a default gateway 172.17.1.1. We’ll use in this case only static routes. On the VyOS3
router, we need to change the ‘dscp’ labels for the VPCs. To do this, we use this configuration.
Main rules:
• ADDRESS10 change CS0 -> CS4 source 172.17.1.2/32
• ADDRESS20 change CS0 -> CS5 source 172.17.1.3/32
• ADDRESS30 change CS0 -> CS6 source 172.17.1.4/32
Check the result
On the router, VyOS4 set all traffic as CS4. We have to configure the default class and class for changing all labels
from CS0 to CS4
Next on the router VyOS2 we will change labels on all incoming traffic only from CS4-> CS6
• 172.17.1.2/24 CS0
In the end, on the router “VyOS2” we will set outgoing bandwidth limits between the “VyOS3” and “VyOS1” routers.
Let’s set a limit for IP 10.1.1.100 = 5 Mbps(Tx). We will check the result of the work with the help of the “iPerf” utility.
Set up bandwidth limits on the eth2 interface of the router “VyOS2”.
As we see shaper is working and the traffic will not work over 5 Mbit/s.
When utilizing VyOS in an environment with Cisco IOS-XR gear you can use this blue print as an initial setup to get
MPLS ISIS-SR working between those two devices.The lab was build using EVE-NG.
The below configuration is used as example where we keep focus on VyOS-P1/VyOS-P2/XRv-P3 which we share the
settings.
12.13.1 Configuration
• VyOS-P1:
set interfaces dummy dum0 address '192.0.2.1/32'
set interfaces ethernet eth1 address '192.0.2.5/30'
set interfaces ethernet eth1 mtu '8000'
set interfaces ethernet eth3 address '192.0.2.21/30'
set interfaces ethernet eth3 mtu '8000'
set protocols isis interface dum0 passive
set protocols isis interface eth1 network point-to-point
set protocols isis interface eth3 network point-to-point
set protocols isis level 'level-2'
set protocols isis log-adjacency-changes
set protocols isis metric-style 'wide'
set protocols isis net '49.0000.0000.0000.0001.00'
set protocols isis segment-routing maximum-label-depth '8'
set protocols isis segment-routing prefix 192.0.2.1/32 index value '1'
set protocols mpls interface 'eth1'
set protocols mpls interface 'eth3'
set system host-name 'P1-VyOS'
• XRv-P3:
hostname P3-VyOS
interface Loopback0
ipv4 address 192.0.2.3 255.255.255.255
!
interface GigabitEthernet0/0/0/1
mtu 8014
ipv4 address 192.0.2.6 255.255.255.252
!
interface GigabitEthernet0/0/0/2
mtu 8014
ipv4 address 192.0.2.18 255.255.255.252
!
router isis VyOS
is-type level-2-only
net 49.0000.0000.0000.0003.00
log adjacency changes
address-family ipv4 unicast
metric-style wide
segment-routing mpls
!
interface Loopback0
passive
address-family ipv4 unicast
prefix-sid index 3
!
!
interface GigabitEthernet0/0/0/1
point-to-point
address-family ipv4 unicast
!
(continues on next page)
• VyOS-P2:
IS-IS L2 SR-Nodes:
IS-IS L2 SR-Nodes:
Here is the routing tables showing the MPLS segment routing label operations:
I>* 192.0.2.2/32 [115/30] via 192.0.2.6, eth1, label 16002, weight 1, 1d03h18m
I>* 192.0.2.3/32 [115/10] via 192.0.2.6, eth1, label implicit-null, weight 1, 1d03h18m
I 192.0.2.4/30 [115/20] via 192.0.2.6, eth1 inactive, weight 1, 1d03h18m
I>* 192.0.2.11/32 [115/20] via 192.0.2.22, eth3, label implicit-null, weight 1, 1d02h47m
I>* 192.0.2.16/30 [115/20] via 192.0.2.6, eth1, weight 1, 1d03h18m
(continues on next page)
I>* 192.0.2.1/32 [115/30] via 192.0.2.18, eth2, label 16001, weight 1, 1d03h17m
I>* 192.0.2.3/32 [115/10] via 192.0.2.18, eth2, label implicit-null, weight 1, 1d03h17m
I>* 192.0.2.4/30 [115/20] via 192.0.2.18, eth2, weight 1, 1d03h17m
I>* 192.0.2.11/32 [115/40] via 192.0.2.18, eth2, label 16011, weight 1, 1d02h47m
I 192.0.2.16/30 [115/20] via 192.0.2.18, eth2 inactive, weight 1, 1d03h17m
I>* 192.0.2.20/30 [115/30] via 192.0.2.18, eth2, weight 1, 1d03h17m
Consider how to quickly set up NMP and VyOS for monitoring. NMP is multi-vendor network monitoring from
‘SolarWinds’ built to scale and expand with the needs of your network.
First prepare our VyOS router for connection to NMP. We have to set up the SNMP protocol and connectivity between
the router and NMP.
In the end, you’ll get a powerful instrument for monitoring the VyOS systems.
In this example, we will set up a simple use of Ansible to configure multiple VyoS routers. We have four pre-configured
routers with this configuration:
Using the general schema for example:
• vyos7 - 192.0.2.105
• vyos8 - 192.0.2.106
• vyos9 - 192.0.2.107
• vyos10 - 192.0.2.108
# ansible --version
ansible 2.10.8
config file = None
configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/
˓→plugins/modules']
# nano /root/ansible.cfg
[defaults]
host_key_checking = no
# nano /root/hosts
[vyos_hosts]
vyos7 ansible_ssh_host=192.0.2.105
vyos8 ansible_ssh_host=192.0.2.106
vyos9 ansible_ssh_host=192.0.2.107
vyos10 ansible_ssh_host=192.0.2.108
# mkdir /root/group_vars/
# nano /root/group_vars/vyos_hosts
ansible_python_interpreter: /usr/bin/python3
ansible_network_os: vyos
ansible_connection: network_cli
ansible_user: vyos
ansible_ssh_pass: vyos
12.15.8 Add a simple playbook with the tasks for each router:
# nano /root/main.yml
---
- hosts: vyos_hosts
gather_facts: 'no'
tasks:
- name: Configure general settings for the vyos hosts group
vyos_config:
lines:
- set system name-server 8.8.8.8
- set interfaces ethernet eth0 description '#WAN#'
- set interfaces ethernet eth1 description '#LAN#'
- set interfaces ethernet eth2 disable
- set interfaces ethernet eth3 disable
- set system host-name {{ inventory_hostname }}
save:
true
TASK [Configure general settings for the vyos hosts group] *********************
ok: [vyos9]
ok: [vyos10]
ok: [vyos7]
ok: [vyos8]
12.15.11 The simple way without configuration of the hostname (one task for all
routers):
# nano /root/hosts_v2
[vyos_hosts_group]
vyos7 ansible_ssh_host=192.0.2.105
vyos8 ansible_ssh_host=192.0.2.106
vyos9 ansible_ssh_host=192.0.2.107
vyos10 ansible_ssh_host=192.0.2.108
[vyos_hosts_group:vars]
ansible_python_interpreter=/usr/bin/python3
ansible_user=vyos
ansible_ssh_pass=vyos
ansible_network_os=vyos
ansible_connection=network_cli
# nano /root/main_v2.yml
---
- hosts: vyos_hosts_group
connection: network_cli
gather_facts: 'no'
tasks:
- name: Configure remote vyos_hosts_group
vyos_config:
lines:
- set system name-server 8.8.8.8
- set interfaces ethernet eth0 description WAN
- set interfaces ethernet eth1 description LAN
- set interfaces ethernet eth2 disable
- set interfaces ethernet eth3 disable
save:
true
In the next chapter of the example, we’ll use Ansible with jinja2 templates and variables.
This guide shows an example policy-based IKEv2 site-to-site VPN between two VyOS routers, and firewall configura-
tion.
For simplicity, configuration and tests are done only using IPv4, and firewall configuration is done only on one router.
12.16.2 Configuration
# LEFT router:
set interfaces ethernet eth0 address '198.51.100.14/30'
set interfaces ethernet eth1 vif 111 address '10.1.11.1/24'
set interfaces ethernet eth2 vif 112 address '10.1.12.1/24'
set protocols static route 0.0.0.0/0 next-hop 198.51.100.13
# RIGHT router:
set interfaces ethernet eth0 address '192.0.2.130/30'
set interfaces ethernet eth1 vif 221 address '10.2.21.1/24'
set interfaces ethernet eth2 vif 222 address '10.2.22.1/24'
IPSec configuration:
# LEFT router:
set vpn ipsec authentication psk RIGHT id '198.51.100.14'
set vpn ipsec authentication psk RIGHT id '192.0.2.130'
set vpn ipsec authentication psk RIGHT secret 'p4ssw0rd'
set vpn ipsec esp-group ESP-GROUP mode 'tunnel'
set vpn ipsec esp-group ESP-GROUP proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-GROUP proposal 1 hash 'sha256'
set vpn ipsec ike-group IKE-GROUP key-exchange 'ikev2'
set vpn ipsec ike-group IKE-GROUP proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-GROUP proposal 1 encryption 'aes256'
(continues on next page)
# RIGHT router:
set vpn ipsec authentication psk LEFT id '192.0.2.130'
set vpn ipsec authentication psk LEFT id '198.51.100.14'
set vpn ipsec authentication psk LEFT secret 'p4ssw0rd'
set vpn ipsec esp-group ESP-GROUP mode 'tunnel'
set vpn ipsec esp-group ESP-GROUP proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-GROUP proposal 1 hash 'sha256'
set vpn ipsec ike-group IKE-GROUP key-exchange 'ikev2'
set vpn ipsec ike-group IKE-GROUP proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-GROUP proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-GROUP proposal 1 hash 'sha256'
set vpn ipsec interface 'eth0'
set vpn ipsec site-to-site peer LEFT authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer LEFT connection-type 'respond'
set vpn ipsec site-to-site peer LEFT default-esp-group 'ESP-GROUP'
set vpn ipsec site-to-site peer LEFT ike-group 'IKE-GROUP'
set vpn ipsec site-to-site peer LEFT local-address '192.0.2.130'
set vpn ipsec site-to-site peer LEFT remote-address '198.51.100.14'
set vpn ipsec site-to-site peer LEFT tunnel 0 local prefix '10.2.21.0/24'
set vpn ipsec site-to-site peer LEFT tunnel 0 remote prefix '10.1.11.0/24'
set vpn ipsec site-to-site peer LEFT tunnel 1 local prefix '10.2.22.0/24'
set vpn ipsec site-to-site peer LEFT tunnel 1 remote prefix '10.1.11.0/24'
set vpn ipsec site-to-site peer LEFT tunnel 2 local prefix '10.2.21.0/24'
set vpn ipsec site-to-site peer LEFT tunnel 2 remote prefix '10.1.12.0/24'
set vpn ipsec site-to-site peer LEFT tunnel 3 local prefix '10.2.22.0/24'
set vpn ipsec site-to-site peer LEFT tunnel 3 remote prefix '10.1.12.0/24'
Firewall Configuration:
# Firewall Groups:
set firewall group network-group LOCAL-NETS network '10.1.11.0/24'
set firewall group network-group LOCAL-NETS network '10.1.12.0/24'
set firewall group network-group REMOTE-NETS network '10.2.21.0/24'
set firewall group network-group REMOTE-NETS network '10.2.22.0/24'
set firewall group network-group TRUSTED network '198.51.100.125/32'
(continues on next page)
After some testing, we can check IPSec status, and counter on every tunnel:
---------------------------------
IPv4 Firewall "forward filter"
---------------------------------
IPv4 Firewall "input filter"
vyos@LEFT:~$
vyos@LEFT:~$ show firewall statistics
Rulesets Statistics
---------------------------------
IPv4 Firewall "forward filter"
---------------------------------
IPv4 Firewall "input filter"
vyos@LEFT:~$
This guide shows a sample configuration for FlexVPN site-to-site Internet Protocol Security (IPsec)/Generic Routing
Encapsulation (GRE) tunnel.
FlexVPN is a newer “solution” for deployment of VPNs and it utilizes IKEv2 as the key exchange protocol. The result
is a flexible and scalable VPN solution that can be easily adapted to fit various network needs. It can also support a
variety of encryption methods, including AES and 3DES.
The lab was built using EVE-NG.
12.17.1 Configuration
VyOS
• GRE:
• IPsec:
Cisco
aaa new-model
!
!
aaa authorization network default local
!
crypto ikev2 name-mangler GET_DOMAIN
fqdn all
email all
!
!
crypto ikev2 authorization policy vyos
pool mypool
aaa attribute list mylist
route set interface
route accept any tag 100 distance 5
!
crypto ikev2 keyring mykeys
peer peer1
identity fqdn vyos.net
pre-shared-key local secret
pre-shared-key remote secret
crypto ikev2 profile my_profile
match identity remote fqdn vyos.net
(continues on next page)
Since the tunnel is a point-to-point GRE tunnel, it behaves like any other point-to-point interface (for example: serial,
dialer), and it is possible to run any Interior Gateway Protocol (IGP)/Exterior Gateway Protocol (EGP) over the link in
order to exchange routing information
12.17.2 Verification
THIRTEEN
Testdate: 2023-05-11
Version: 1.4-rolling-202305100734
This simple structure shows how to configure a DHCP Relay over a GRE Bridge interface.
13.1.1 Topology
The topology has 3 VyOS routers and one client. Between the DHCP Server and the DHCP Relay is a GRE tunnel.
The transport VyOS represent a large Network.
1239
VyOS Documentation, Release 1.5.x (circinus)
13.1.2 Configuration
DHCP-Server
DHCP-Relay
After this, we need the DHCP-Server and Relay configuration. To get a testable result, we just have one IP in the DHCP
range. Expand it as you need it.
DHCP-Server
DHCP-Relay
Testdate: 2024-01-13
Version: 1.5-rolling-202401121239
This guide walks through the setup of https://www.tunnelbroker.net/ for an IPv6 Tunnel.
13.2.1 Prerequisites
• A public, routable IPv4 address. This does not necessarily need to be static, but you will need to update the
tunnel endpoint when/if your IP address changes, which can be done with a script and a scheduled task.
• Account at https://www.tunnelbroker.net/
• Requested a “Regular Tunnel”. You want to choose a location that is closest to your physical location for the best
response time.
Topology
The example topology has 2 VyOS routers. One as The WAN Router and on as a Client, to test a single LAN setup
Configuration
Note: The source-address is the Tunnelbroker client IPv4 address or if there is NAT the current WAN interface
address.
If source-address is dynamic, the tunnel will cease working once the address changes. To avoid having to manually
update source-address each time the dynamic IP changes, an address of ‘0.0.0.0’ can be specified.
Assuming the pings are successful, you need to add some DNS servers. Some options:
LAN Configuration
At this point, your VyOS install should have full IPv6, but now your LAN devices need access.
With Tunnelbroker.net, you have two options:
• Routed /64. This is the default assignment. In IPv6-land, it’s good for a single “LAN”, and is somewhat equiva-
lent to a /24.
• Routed /48. This is something you can request by clicking the “Assign /48” link in the Tunnelbroker.net tunnel
config. It allows you to have up to 65k
Unlike IPv4, IPv6 is really not designed to be broken up smaller than /64. So if you ever want to have multiple LANs,
VLANs, DMZ, etc, you’ll want to ignore the assigned /64, and request the /48 and use that.
Single LAN setup where eth2 is your LAN interface. Use the Tunnelbroker Routed /64 prefix:
Please note, ‘autonomous-flag’ and ‘on-link-flag’ are enabled by default, ‘valid-lifetime’ and ‘preferred-lifetime’ are
set to default values of 30 days and 4 hours respectively.
And the client to receive an IPv6 address with stateless autoconfig.
That’s how you can expand the example above. Use the Routed /48 information. This allows you to assign a different
/64 to every interface, LAN, or even device. Or you could break your network into smaller chunks like /56 or /60.
The format of these addresses:
• 2001:470:xxxx::/48: The whole subnet. xxxx should come from Tunnelbroker.
• 2001:470:xxxx:1::/64: A subnet suitable for a LAN
• 2001:470:xxxx:2::/64: Another subnet
• 2001:470:xxxx:ffff:/64: The last usable /64 subnet.
In the above examples, 1,2,ffff are all chosen by you. You can use 1-ffff (1-65535).
So, when your LAN is eth1, your DMZ is eth2, your cameras are on eth3, etc:
Please note, ‘autonomous-flag’ and ‘on-link-flag’ are enabled by default, ‘valid-lifetime’ and ‘preferred-lifetime’ are
set to default values of 30 days and 4 hours respectively.
13.2.4 Firewall
Finally, don’t forget the firewall. The usage is identical, except for instead of set firewall name NAME, you would use
set firewall ipv6-name NAME.
Similarly, to attach the firewall, you would use set interfaces ethernet eth0 firewall in ipv6-name or set firewall zone
LOCAL from WAN firewall ipv6-name.
Testdate: 2023-05-11
Version: 1.4-rolling-202305100734
I spun up a new lab in EVE-NG, which represents this as the “Foo Bar - Service Provider Inc.” that has 3 points of
presence (PoP) in random datacenters/sites named PE1, PE2, and PE3. Each PoP aggregates at least two customers.
I named the customers blue, red and green which is common practice in VRF (Virtual Routing and Forwarding) docu-
mentation scenarios.
• PE1 is located in an industrial area that holds multiple office buildings. All customers have a site in this area.
• PE2 is located in a smaller area where by coincidence two customers (blue and red) share an office building.
• PE3 is located in a smaller area where by coincidence two customers (blue and green) are located.
A brief excursion into VRFs: This has been one of the longest-standing feature requests of VyOS (dating back to 2016)
which can be described as “a VLAN for layer 2 is what a VRF is for layer 3”. With VRFs, a router/system can hold
multiple, isolated routing tables on the same system. If you wonder what’s the difference between multiple tables that
people used for policy-based routing since forever, it’s that a VRF also isolates connected routes rather than just static
and dynamically learned routes, so it allows NICs in different VRFs to use conflicting network ranges without issues.
VyOS 1.3 added initial support for VRFs (including IPv4/IPv6 static routing) and VyOS 1.4 now enables full dynamic
routing protocol support for OSPF, IS-IS, and BGP for individual VRFs.
The lab I built is using a VRF (called mgmt) to provide out-of-band SSH access to the PE (Provider Edge) routers.
13.3.2 Topology
I chose to run OSPF as the IGP (Interior Gateway Protocol). All required BGP sessions are established via a dummy
interfaces (similar to the loopback, but in Linux you can have only one loopback, while there can be many dummy
interfaces) on the PE routers. In case of a link failure, traffic is diverted in the other direction in this triangle setup and
BGP sessions will not go down. One could even enable BFD (Bidirectional Forwarding Detection) on the links for a
faster failover and resilience in the network.
Regular VyOS users will notice that the BGP syntax has changed in VyOS 1.4 from even the prior post about this
subject. This is due to T1711, where it was finally decided to get rid of the redundant BGP ASN (Autonomous System
Number) specification on the CLI and move it to a single leaf node (set protocols bgp local-as).
It’s important to note that all your existing configurations will be migrated automatically on image upgrade. Nothing
to do on your side.
PE1
PE2
set interfaces dummy dum0 address '172.29.255.2/32'
PE3
Once all routers can be safely remotely managed and the core network is operational, we can now setup the tenant
networks.
Every tenant is assigned an individual VRF that would support overlapping address ranges for customers blue, red and
green. In our example, we do not use overlapping ranges to make it easier when showing debug commands.
Thus you can easily match it to one of the devices/networks below.
Every router that provides access to a customer network needs to have the customer network (VRF + VNI) configured.
To make our own lives easier, we utilize the same VRF table id (local routing table number) and VNI (Virtual Network
Identifier) per tenant on all our routers.
• blue uses local routing table id and VNI 2000
• red uses local routing table id and VNI 3000
• green uses local routing table id and VNI 4000
PE1
set vrf name blue protocols bgp address-family ipv4-unicast redistribute connected
set vrf name blue protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set vrf name blue protocols bgp system-as '100'
set vrf name blue table '2000'
set vrf name blue vni '2000'
set vrf name red protocols bgp address-family ipv4-unicast redistribute connected
set vrf name red protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set vrf name red protocols bgp system-as '100'
set vrf name red table '3000'
set vrf name red vni '3000'
set vrf name green protocols bgp address-family ipv4-unicast redistribute connected
set vrf name green protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set vrf name green protocols bgp system-as '100'
set vrf name green table '4000'
set vrf name green vni '4000'
(continues on next page)
PE2
set vrf name blue protocols bgp address-family ipv4-unicast redistribute connected
set vrf name blue protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set vrf name blue protocols bgp system-as '100'
set vrf name blue table '2000'
set vrf name blue vni '2000'
set vrf name red protocols bgp address-family ipv4-unicast redistribute connected
set vrf name red protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set vrf name red protocols bgp system-as '100'
set vrf name red table '3000'
set vrf name red vni '3000'
set vrf name green protocols bgp address-family ipv4-unicast redistribute connected
set vrf name green protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set vrf name green protocols bgp system-as '100'
set vrf name green table '4000'
set vrf name green vni '4000'
PE3
set vrf name blue protocols bgp address-family ipv4-unicast redistribute connected
set vrf name blue protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set vrf name blue protocols bgp system-as '100'
set vrf name blue table '2000'
set vrf name blue vni '2000'
set vrf name red protocols bgp address-family ipv4-unicast redistribute connected
set vrf name red protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set vrf name red protocols bgp system-as '100'
set vrf name red table '3000'
set vrf name red vni '3000'
set vrf name green protocols bgp address-family ipv4-unicast redistribute connected
set vrf name green protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set vrf name green protocols bgp system-as '100'
set vrf name green table '4000'
set vrf name green vni '4000'
You managed to come this far, now we want to see the network and routing tables in action.
Show routes for all VRFs
VRF blue:
C>* 10.1.1.0/24 is directly connected, br2000, 00:01:13
B>* 10.1.2.0/24 [200/0] via 172.29.255.2, br2000 onlink, weight 1, 00:00:49
B>* 10.1.3.0/24 [200/0] via 172.29.255.3, br2000 onlink, weight 1, 00:00:49
VRF default:
O 172.29.0.2/31 [110/1] is directly connected, eth1, weight 1, 00:01:09
C>* 172.29.0.2/31 is directly connected, eth1, 00:01:12
O>* 172.29.0.4/31 [110/2] via 172.29.0.3, eth1, weight 1, 00:00:46
* via 172.29.0.7, eth3, weight 1, 00:00:46
O 172.29.0.6/31 [110/1] is directly connected, eth3, weight 1, 00:01:09
C>* 172.29.0.6/31 is directly connected, eth3, 00:01:12
(continues on next page)
VRF green:
C>* 10.3.1.0/24 is directly connected, br4000, 00:01:13
B>* 10.3.3.0/24 [200/0] via 172.29.255.3, br4000 onlink, weight 1, 00:00:49
VRF mgmt:
S>* 0.0.0.0/0 [210/0] via 10.100.0.1, eth0, weight 1, 00:01:45
C>* 10.100.0.0/24 is directly connected, eth0, 00:01:45
VRF red:
C>* 10.2.1.0/24 is directly connected, br3000, 00:01:13
B>* 10.2.2.0/24 [200/0] via 172.29.255.2, br3000 onlink, weight 1, 00:00:49
If we need to retrieve information about a specific host/network inside the EVPN network we need to run
13.4 Wireguard
Testdate: 2024-01-13
Version: 1.5-rolling-202401121239
This simple structure show how to connect two offices. One remote branch and the central office.
13.4.1 Topology
The topology have a central and a branch VyOS router and one client, to test, in each site.
13.4.2 Configuration
Set the local subnet on eth2 and the public ip address eth1 on each site.
Central
Branch
Next thing to do, is to create a wireguard keypair on each side. After this, the public key can be displayed, to save for
later.
After you have each public key. The wireguard interfaces can be setup.
Central
Branch
To reach the network, a route must be set on each VyOS host. In this structure, a static interface route will fit the
requirements.
Central
Branch
After all is done and commit, let’s take a look if the Wireguard interface is up and running.
And ping the Branch PC from your central router to check the response.
Testdate: 2023-05-11
Version: 1.4-rolling-202305100734
This LAB shows how to use OpenVPN with a Active Directory authentication method.
Topology consists of:
• Windows Server 2019 with a running Active Directory
• VyOS as a OpenVPN Server
• VyOS as Client
The lab assumes a full running Active Directory on the Windows Server. Here are some PowerShell commands to
quickly add a Test Active Directory.
In this example OpenVPN will be setup with a client certificate and username / password authentication.
First a CA, a signed server and client ceftificate and a Diffie-Hellman parameter musst be generated and installed.
Please look here for more information.
<LDAP>
URL ldap://192.168.1.10
(continues on next page)
˓→az1C22Sbp3wPJLfgOmy0K3TA5qVsx/c/8gatsatMkCsekGnK5BPzCDd5eCCLo//
˓→B25HFO6fBYRNvHvVyCUx7QEXw4FHFNG88zCIizx114AGtVwZfGGG9xCc53xjLPUpH6iqTXme41cCFFQlqXwZ7fuySieSdoV8SAsJTT
˓→EyauQMY/
˓→LC4tLc6moPaNlTwA9HJv8s6xUqpzNptDoUHKOqKuw2JRFnno5SCQ788KkKNgVWBy2o3BGoewfHFhAdR61CXeLpmuneuhi96GcM031g
˓→RchtHRC6rtFavHJjB2cUcCkhhQofUE6IR2dYJZ1cw0Wy5CI3bXHf43BpvDGmuxIlNGirTq8wf5RCWzDJJgmkQpYhUYe8x4faF4gTo0
˓→QD+EIV9xXgOk14+BbnHKWbZ7Ou5emewFuE/
˓→bjl79oNJklpXdc4soRkCPCTEGK3zDBdmUtCYk1DwIDAQABo2EwXzAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/
˓→wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwHQYDVR0OBBYEFP5NDac/
˓→yC+mQmaTpZDUv9GZMGMBMA0GCSqGSIb3DQEBCwUAA4ICAQDEqpF2ibwYFxsF1XDIPS5/
˓→Gs0sZTZBuByNm5d2+jTyO7d5alZUdbvobbwhxZOhWasmFNyPLr4TYmZm5zF+efFsiOxjyRuEoVU+Fe8rZmpRIF/
˓→+6+nYX5r9vMI4QxGjeeyP20OHJ85Kvz182CTsITrM15Vw/kVVjAVzFI5Gm/
˓→QolalAoFQza9rAL4kDqaUszjHjPbysvDpGF+NLPjiYDHXcty/
˓→BC48bnuzAeEM60SGZ7EXvf8l0X8YsO7z39w6780A/3rbZvFhCYMKp/
˓→+p5xBRDjnX91dM6DJw73RwYQ1KHbHk9wWUwnL1giL71jzp/
˓→y4Oj6SSK2PQv+OnO80J6Zg06WIQx9xYcxr108Xh9FotUrlG7GYPI3Udf95t6SjuydDhULAVD0lMBxlDe9DHW1k1q1pOXaHZg926tY6
˓→lda6dcuwJjA2Dx5JI6L0u9ureQmQAtxvnoTCtf+hR1iX/IkskZCKs34SjNiCnBuw/
˓→DNfdOpfaABm7y+tWiXBwnu5l/
˓→K8poXcQYQByyZj6YMmpgsbVPr5KNsLWOgRA81M6IPof8qxvnFrkazhiQWh1YHSjnaHtA3z5/
˓→BdgwHVICuFyrIOlbkKyJOjKcKBsDdMwIV0tsnpnyli2xEPZKu1tAQFAavXrK/RGYYhOZ3e0aRSV8hlP8i/
˓→mf7p0I45cJiBCqPg=='
˓→EyauQMY/
˓→LC4tLc6moPaNlTwA9HJv8s6xUqpzNptDoUHKOqKuw2JRFnno5SCQ788KkKNgVWBy2o3BGoewfHFhAdR61CXeLpmuneuhi96GcM031g
˓→RchtHRC6rtFavHJjB2cUcCkhhQofUE6IR2dYJZ1cw0Wy5CI3bXHf43BpvDGmuxIlNGirTq8wf5RCWzDJJgmkQpYhUYe8x4faF4gTo0
˓→QD+EIV9xXgOk14+BbnHKWbZ7Ou5emewFuE/
˓→bjl79oNJklpXdc4soRkCPCTEGK3zDBdmUtCYk1DwIDAQABAoICACVsewzYmD6RU2pKJYSPX4pl1aO6ADqNZHZi0GR4K+FyXUqDiHTw
˓→WWeUC6j5ZcH4XH+Gg0yumfCgNsnyNhDlyUNHIjPZBT4Cywvg/QTwEfK8//
˓→wEHYudT6aam0IIF1O12UW8VgmEiAwMN5Kz476lNQjbgg3efujmJaQhpnULKE2q3V51BC8qhe05JdafDOEE11vOmGj/
˓→ARYcbCQhoFJQpDzyTLB8RuEj0cTCe7oVXwwTUF1O4wcmoMCHNvsJxqKwFrER5m+giu83NcKTT13yRlg9LVg094XoGDFtRgmW1dD6ON
˓→2/mHh6kjv7pvppWdDhjkf+dWZ0frx2YyF5/dUgGG6e94hzOwRunEu4JVKl0Qr+Vfsqt/
˓→STVDA3vbhaMdMuIR2Ir0OkoYiqGBdiEGVx82lf4uDy2TXveqKUADXU5SchjP0JZpBANO4RVoxFpY2r1tEh/
˓→sRBu9wY+Fjk4FqdjjOmsbmFwhyG/j2VvKkVsq5itsxG/
˓→Rg1nTThE2LN+R6LUquujtn94rIaz6lukEr7Yq9qy14Prj5A7tYnuHbcN36b0A3xN7bxxeX6w12naVp0KZPmey6W4HNeNOOfTLh8BpG
˓→X0THkcDiozCy1IJchL4+GxxA0dp+NBispflvbFWZFAHMnbJx4cc7qMR9k8DDSHNQVgfV6nBa4xBvjBp+sanOOOLV4p+fQZW+n6VMzC
˓→s2bl6P8Mldpik2WhW0GdxHyK3sgZWXIrnkTlQg3EMPb2sPhFZm6pQKpxXwl8gGgFzEx4mEpHxHm/
˓→igZPVRTnYfGwkPmHu3caF59IWHq4jsUAxRQperRgStAoIBAQDjnJ4dZgcnI4PxiDKDKXeb5ZgjnIL0eyxMZoLtaVYnO2lLG0uMlACU
˓→vmpiYFdPo9aGaVR/fr+yPZ0h4S9wFShRBtDZapjAlds68ROQsvF/
˓→fdU4kqtfyIAst1lwtqMPeTmiZJxVubE0h2YEXOpwIEFcu3+MUvqtCd8X/
˓→T+VyF4ZQqn64NvYvkoWpfIiKmOGsCBc4agYuPs4Cy1QvN6oLXp+0b8mSzp+ot35n1lBGTSY2l4/
˓→9k6sIzWY7x23GS2g3AUJ2kYUTpQIq2pow8Sc8ptxLwZSQZwrAoIBABqhW7E3UDp8DO9XmHidVDR1dbCOdiyBvuKn8Fm2jABGCtwSN7
˓→8mRbQU31usnfAkb25ccI3SwhZ2vtVPGiJSqae1j0yZoDWg2gO2UDZ+xiqFFFQrUa2hirmBPj8y2rDT3ArN2CQfkWweSNVzcQmxXwC3
˓→ECggEBAIHl7i7k/YwOrsx3aCyGy+ZC39LjDbGtYhiwIGSRy0NUmsDscO9nv/
˓→TB23FHeufoPaSaKNJnzEvMH8TSYcskBop2NclK0ptvO8hEQ8MADu3uZHRVna1LQkkHPfUzw6+HjKuSkky1kTcsO/
˓→gSJbsPJOI0JAu9becU2NJj4/4HZpqheNUMRpUXBnRcQNI3DSm3cjSCWWyAAqO/JM5hi2dwK/
˓→P5QEMWmuVGlr1f2FZ/YbiO0QWf61IoUuiZN78KYb7KQ0U2y8PaJlBgtBoQZkDaiiWfmYNOt8d5NRVO+p8SWM/
˓→QwFPpk1Hdora9GnsHARuxxLY17eKgZ2MS6jdsGPV00EUCggEBAPuNZ3peHYhIo2EMb6wpnAFV2fAUajymwenr+Bmv5BlAnW7bE2bSN
˓→GedKiUyxP2UnaFS24mWpe44X3UlC+KJLqJG+zVGXryC7bvhS3N1KlI6H2pRY1fPAhlfUk2KAe+ZP5C7iWwtR6FlPpjB3JoS77qFVhn
˓→NA1CW3iFWIyG57oFMX1td3i3xJwhjd40M='
˓→tacaRHvpchBKLigJ5FlqNNfJ2vnP87KfCmTA5tkWF7MtuY990tHZtl1vQ3Pim4d6XBOngiQmaw7tZeWAIrv1L2/
˓→VBjORUrLrQhkkg9nSpcYFxoyUQzukTY75PcwhYLkS6ZO/vPPSBuh97f3XR645Aauf7ZIk2NsUidP2uGZz/
˓→Sr5VC7ovH2l3zz1kIHPCinfvpPEVb5oTt7qEffk4vnKjy9RY+H1hZowvcAp1zfLaOt/
˓→dXaK6vfNutbmwDHbYAlIals0EcjtTr+63ymxmupn7RBjgWtK7MgocGZnt6HKJ4J6teP3WgiSd+I9pdFG4wHZOSVL3axf3rBx7q09DM
˓→Snvfbly+SlhXw9Ebk368J6j6rhNUkxo/
˓→M9fbfgxS0JnNjHInRNAvRQW5CgQfT9KyUdxR63BeSnngk2XYX+bDinb0ig+VDpZcr6PgOBR8aNFsCPbXRwDy0bmuFnFYMzs/
˓→7ZmFQhzE6rQykHvVvAsyv7FYrlW0E02H4+Xe6bEVpE1fLcH8OCGY2cfuTfq1Ax6R4r+tdHYW1kzFLjwdh3uqTLF11zcbkAwd78E/
˓→ItrfEadvgxrYR9gfhX79AkK0VHmZ/
˓→hzrLFeGznnVcqoTKgq21dfMfQG2P13QvqS7tCE5swM9N09ASVrifyVDuoL6jaW96wgeqR6eHMECAwEAAaN1MHMwDAYDVR0TAQH/
˓→BAIwADAOBgNVHQ8BAf8EBAMCB4AwEwYDVR0lBAwwCgYIKwYBBQUHAwEwHQYDVR0OBBYEFE1U3Zamfuv6ocYiF9q7H/
˓→/U8h+AMB8GA1UdIwQYMBaAFP5NDac/yC+mQmaTpZDUv9GZMGMBMA0GCSqGSIb3DQEBCwUAA4ICAQBZwHvGj/
˓→jziNFwXS2W1Q11I12YANmVhISP39AA7DNhXR+E1hXFs+U52ehurZoLTi5YTjd8PD0KcE58mw8CLsFQB/
˓→+pni9EwJuAhpMb6XsmYEp0PeOH7C/q5eOc4TB/
˓→NBsvEa5IdTmUoewmjubKeJ8OHdRBMI77Me53lSC6iskc9DGyixSLqQogQW4aiTposFJOW/
˓→YugBy7kiuygmFNJv4luDbyRBb9131zH0qSSishLT4Bp5lXQNYWI4AU0JeyQcYaSHWCr0h6H9GN3QOf/emc3/
˓→2Tee40FcEMsszJBRnQ3IISzU5xVLlfU02SJMpjvFT2MGfHAs7obrNbwiFeoLZ6fQeGLe53aOQ5M9XeW5bdIeR2ZrLoO1hW33x5jYI8
˓→mjwfdrTsGChFzsLasB0Tj++mGMOXw3DSusppub17AE2bO2uO6J9XMlbkOC8EmDCF1Hetija4D3aunhtu6jRBOcR8DHVBqNae2YgUk1
˓→wzcBLjZaO8KBCtrmTdr1wMXizPT+XcjAlzRNXvHiZFq0NG5Rnim+LH9tp90EHzO7EeVXV+LegnIKQqboIrY3KOw5Qx8ska+t1WrWHp
˓→'
˓→a4ZnP9KvlULui8faXfPPWQgc8KKd++k8RVvmhO3uoR9+Ti+cqPL1Fj4fWFmjC9wCnXN8to6391dorq98261ubAMdtgCUhqWzQRyO1O
˓→daCJJ34j2l0UbjAdk5JUvdrF/
˓→esHHurT0Myf9Ke99uXL5KWFfD0RuTfrwnqPquE1STGj8z19t+DFLQmc2McidE0C9FBbkKBB9P0rJR3FHrcF5KeeCTZdhf5sOKdvSKD
˓→tmYVCHMTqtDKQe9W8CzK/
˓→sViuVbQTTYfj5d7psRWkTV8twfw4IZjZx+5N+rUDHpHiv610dhbWTMUuPB2He6pMsXXXNxuQDB3vwT8i2t8Rp2+DGthH2B+Ffv0CQr
˓→XdC+pLu0ITmzAz03T0BJWuJ/
˓→JUO6gvqNpb3rCB6pHp4cwQIDAQABAoICAQCgNLAZhFX0E8hNbplnBUltek0VGQUFnuLKaVlLZXwn8zXNCx1UW6l9N9e9eSw1uXzhue
˓→61JN9LxK1SvX3gO0g4Jipq0MgvokeF5mdyuvqaC8PWU1k+vo9PaVwsguqy5cSDZbz3F6BcE4Lj693cavRmb5F52+E9yDI/
˓→P4IhCLKIt4QCgmxiC3XgA43fq75+SV21LUTjzc/
˓→0mY+VoO9CmzJcQ0vDrclzJnyFfCwBAPZweL5iBc0zAGcNxTA5/
˓→k86ejHdLlASH0dRf55F8ALeO22um21F7cEqOSYBtl009LDvpHte9wKWp9MpHABeDCigYMc05/
˓→IgVPQemtd6NtQ0ZVWHWUiWWqh5cY4v8d0CHWAv4HJZI5JuGWdWUc1QufMfu9UbTuNJe0RGQ/
˓→N9OJZzzwX+Vpuflrg9K0CT47Yo3NGFbYOuxn12JQBEYDNl5VHWZGAe1x/
˓→ljD0OjWmw3xkLNyRqwZnSTTJ4salCSW6qLrsqHWEeNyx+J4t2gBY0TNoylQ8hECxozFu/
˓→CYNIlY7+dJjFFe29r+FNBK+WOuUcSoyrABbqCkQH3iXOC97SQSyxdXMNvkkl9X8gvQQKCAQEA2VKt5k7HqvUTC26DNswNQGfd89GcQ
˓→2rWhCeBGVqJKQ+qRjgk0KeVTcnTGzyujaHN1akUA1CRKEqtrCCspZjollWhxDygevMbXs/
˓→0QlDkUxaflPOzit6B5vDJqLGJUgvPI3Hc+9eDZXeCyCCdXOVGY8FUxMQ84RnDO8sVOthgahHsdbxjdUb0KcgaV5xNuMyuYsA++QG7f
˓→EmTp2OXKq+cuZHRZWaBtm3zDwfOz3FLVBXi3JGX9M6Hv6q/
˓→2cgLDudYiE3LCNagNkI7rRRO8Gfqd2i9KVRQHWCTl4mpTOwwmKWONNgS34aTPjD5UptNUzTvIItGGSMfg/
˓→DNrYg6G9HA666aIqpvodSfUv1ryJViml/
˓→3NtvmlRmRKEYe03txKhAN1Reuq30BoOGs4Tu5Hy8ijws9hOSCdZbOyte4EhDRSNyZB45YXooJOHEWTLjrZZqgGH3B/
˓→uUAUmyHbutPF/Wkep7M1LVeU8KS4HeVmwMRgPL10nxoHPE/
˓→UGBuqL09p4a1muXQ+TMHvnI59Shkn9cEiQKCAQEA10v/l/BoAse0TFj5iSnx3uKHkmsQX8P2UcsoRmPFW3RJd/
˓→7v2EJrTrwlxVqYMdpLDJIkB0MyIfry7H8QjNuUOqgAmazBToq08xCDD4GEXMpVkcgKuKRuU53ukNb26c+Ozshs4bqktMHQPGmZ5wgP
˓→YwLF0Y9cMO+noKHgdhwVbMIehXvRL2fBezLqKs17FDyD3rJyEQKCAQAdwFtHShJGe4qaVFcL2bbhU+xBDGMnDAI2bZ0BiwtrA3LBOi
˓→RcKV/u22j3G8OXqzS/
˓→ABT5ZX1Z42IDv08mYaH3cquSALJG7yT4+M4AHSmFZ06IuNpTZaePbWd+HJXkzdWmJFPmKpx7c5cjl6sb5q0XGgVt0spN3Dahabi2Zf
˓→OCSX1AkI3b5hdt/
˓→WJwDCFUmXfKmYZLvV+JSMsRHUWsBAoIBAC2ZuZ3hYmSFMq+rZme72lIl3PUiOWPO9VVbs+PsRk58/
˓→ceCWnGCO647+KGb4jFw0vKPwP5RKmPny9a6ZSpYB2jsgWItKewdah+VPEOSLZQT/
˓→aPB5f61eiazCnuUuWrrycQVyLlELD0pj29mMxAJ0Nr1CIVboYp+YYA7dWNVSUT6T+EV6ASEC6jflb//
˓→UUUmCjOfxILGMkqvNJ2T7WguaPLOw21wLx0eDvQA/N8ZTiyKmE+GVRkDwGzC/
˓→yLeelgzyBgmyr15hfo7Q41VtAso6rzzExc4GasmgQe8z4Y0Gm7t3RDL3GXxBmonZtxNZt0vwvVyS/
˓→kAJedmPgcfxJunPnM='
˓→XLYJ1xIpcYTRXTut2CTGRar7fZZicu7x0yoK4TzrHvGVf1o4NC4NSGV5RX6kwRdrfWBmvpIkjSLGtCREFyhb+PHDpnsIS7cfN9udC0
˓→xM/sfcP6Vja/uFp+9TQcneJIxYw34zkF+TtOVbE3pP5VxU7ZAj8F5/q1ONhTMdzG4Ol4/
˓→0nBqZfdYA3LVDeSSNIJNF5jlaKXXFHz1EJRemTYDx+f5bfCVcK2Qs8fU9jCFBlATjMu9O5rgk6nMLRwEnJZuZ1gj2tWQvz4e9yo5yU
˓→j4o194mQ/Dt/Et+/Qn/DUFk2FB0rTMcQwJLTEAzxtTdmBJeJpipIPDR0u7UMZLNh/
˓→raQ8s3FsbY4uYORt2f5YQlCVHbth4dRa9xa+oRbm7eomNACIbWfkLh5Bzud1+qIfdBMZKaZbnf0HEeuH0J5LBJeova8EPxWbYMJPrR
˓→z+4wwLxtzq/c2xKw9yrOZ46ZVLwGDFq8rPwp7/
˓→P9r6mDKsbn6jIvGOeH71dMZvoc4lCaClw+hKIzLAgMBAAGjdTBzMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/
˓→BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBS6j30FmL6kZW7rDH8QjRMoWoA/
˓→njAfBgNVHSMEGDAWgBT+TQ2nP8gvpkJmk6WQ1L/
˓→RmTBjATANBgkqhkiG9w0BAQsFAAOCAgEANW2Y4bgaB9oexEjj6rkGvePtQmXRkF/
˓→adVQREY9iZDGTe72ePybVzrfMkZHjse3o7JvXWRIVVztWSzEpv5noIOX7lAioGG3wsFTHotTFR0zrYJHXHBcV2Neq4Kx2Ta/
˓→TZwD8QnZHAAxEQ1pYb4fxwN/
˓→A60VElAZoz9zYsbrJyVrfuHDL9queQxPFzqis+7W1BiVIcv4rn0DMQ560jTGh4t4rImOSu5gUsUrQaih85XDdOBPxViSNwfVdZJIgb
˓→uCjcxpNnzIp0rhyYmDeqVat4GnTV7Sy48e/Uvcq71ZWbBYJF4+yW4pylIU2Sh/
˓→vpoN+VusD/XEv2V0Ixm10YybA7BI/tixh9vwj3fdQXVLy3jSYjVBd5WOFPizbQZeD10ElvlLqZZyWrP/
˓→Wre7Nmi/gEOnhBXXmo034fFF/vXf0JRpQsd2oDs24+4XwZYb8mbM31j7Nx8YvhR+64='
˓→jxw6Z7CEu3HzfbnQtL6HKlZcf8TP7H3D+lY2v7hafvU0HJ3iSMWMN+M5Bfk7TlWxN6T+VcVO2QI/
˓→Bef6tTjYUzHcxuDpeP9JwamX3WANy1Q3kkjSCTReY5Wil1xR89RCUXpk2A8fn+W3wlXCtkLPH1PYwhQZQE4zLvTua4JOpzC0cBJyWb
˓→gpMYECWpej9wK96uIn7SYodyvv4+KNfeJkPw7fxLfv0J/
˓→w1BZNhQdK0zHEMCS0xAM8bU3ZgSXiaYqSDw0dLu1DGSzYf62kPLNxbG2OLmDkbdn+WEJQlR27YeHUWvcWvqEW5u3qJjQAiG1n5C4eQ
˓→DRLWEoayFW4nHTDUiN6TkEetDBYZB8AY0lNpf8/uMMC8bc6v3NsSsPcqzmeOmVS8BgxavKz8Ke/z/
˓→a+pgyrG5+oyLxjnh+9XTGb6HOJQmgpcPoSiMywIDAQABAoICACNXi396uWyCpXVBGSyi8LfKw2GupBmBxiI1Mkj4H2LP2G+nVS1Ye7
˓→jd23bqFYRERPgLUtPWNB0UQyMQsvNpVISm8JR45Sg0xq+bwEXabB7SyYLkZDKgsehxkuCJxZd625pl53vGMCKyzst0MBt4qCEsZQM7
˓→MpWFjnGSr4XDttXqz1YghTMHlWNpDCYtPN+3BO4iPnj+h0qCdXZ28jlLEczAc+oDKtzPqEmv/
˓→TDaKE6Qu6x+VbkBPmG+mkoX4qfokRwCs19CGheR38PxdDx7AgySv7K8hM8gFC0XEqNdjt86KG+N1Ps5Sru4QMrf8j9XXNPUvt0M8ws
˓→h0HIEROOFpEFbzWnhBChPVvFObuuEjl5Jnj3KUEnckQFU07mPP/BpysHo3v/
˓→p+VTVoo2UkfVvjamnwQOUt3cVlPVC4FzVgkswJa4f75nGmDv8dafyPrCYciOh0qyhD5Pw/
˓→EBJkKtDBYHaoxtAw9Ann4A5rvZAveLNTPESOMo90pJwJbQcZyq9H+UGVnde39I4m5vHB5izZJI24Yd3fjRRkRf+/
˓→68VYKrkI5B7oH73Z/cl/xgEdI1hag4MLv1gon8wna4yCX/
˓→321YPTrDABAoIBAQDpHtvnvpOaoSjkJHUx4EGJkrp5R/
˓→mPfEbzzU2Ov5pNIcufv++2lsoUVCTDwgp4+7GngqYO5vVyW/AS4pSrDx7kdWpFaUtJUUCcCHk/
˓→5hYcvvourYtW1NR+XPiI28IqRp1P0L1+P0mUaRgpEcw6nEnc37XEujvTB1M/
˓→yF2y6xc+kZGjrZTmJeu0V5kkaGcXlAqUv2k0Lj3tEPQR/
˓→qj+kMX5hidROGuybNBESgA5ELY6QVnpcOyNDyniWq+RIUyBOuXp7DpUbmUANFEEP8lwjZX+HqwTpSjTSFdcPrsmorc9FpTXA9ktt1Z
˓→XOpXlpNHx2ehrGWp/BbmlmrnQaRcbLPJaRtWSEywbWnG77g+zj0w+4BdsYyTtGGFj4tXVZhPPo/
˓→DID3FPLn9cSv8MIVWjzg1G/BZcxtCDBDRBhwhZHCPOfd0K/S7rvRBq7IsNNHMTGswWGRMaF+M/
˓→trZw7TsQ0BX+5zZUyO8VNBi/
˓→NgTV3yoQ8ynBefRt1dmNa2CKXPT+5R19cBtecFEyhc3yo8ryTtM22JzndzA8agQmNPnWmYGivvcNHNikTQ2qUvvcd7Siny6j0+CmFd
˓→1OyShRO+myPsql+U0kQQ8Zeh0kPWTJclFboMf7MePfJLj3waMvaZxfS9s9CvvKaCSY2YKtL7Sle5bWozCff27Q05jAgszwnkRGxj/
˓→AzAwpjnCft40UkL7majm2vk+pm6aPjcYPXnqKbcOmBjxJWIoNRkLCDKqw6IOs+zQDRNwPKNb5GhFGeA1pKjfGJddg6+u95uEVmPcRB
˓→5hUAoBUAW7jNNE5mHmZBO8DPwCotUc82bCojNVkxLxsKPE2VWtWdq+1t9SoevBVZItl2zgWpATHndhQlOgdONoWUgRT1J3x1HYewrg
˓→GypC17WV4Vw5FS6wopg71BAoIBAQC63vDgTGpauk0pOVyab1tSmNzhM2dn4BhMIcU+eqzAzTkO13sKBGrQJQ3cODoxDbSKSE61QN9D
˓→nTnCg0Q/P0g3QZTZyzsEb1/slYH9jKRnErl+eEdDXu0sB2qIBAa6Th2ojMM7q/
˓→RrF3HD6Qo20ZpQb951bnZsJ48j2WDCCGAdnLCsNe9zuqQsphNOf9BUbXYpGcKgSquPJfxXXvjgYdVcvJyIfc+GNAZQaS750bY6eYdL
˓→3zAoIBAQC8/7DglQGMcKnk4zX+7jCuc0p+qMcd5RdnfBKlRhcWYNRPup9jyDefdkXCBTumCHXrIil/
˓→rJzP6b1IZZdC4xkheQpLXNUcceAidRWIrTypaXKkmhR0D74uckGiLXB4S84HYmIdw89ZiF0gB0yyZH5mZnqVMojwnGmWqcM2sr2N44
˓→rVl26BXtRPiNPimfwWKrYNYhESN7A5/
˓→hWcrNUhE4PI+Pjd74npimqs5TDSst2Jc6DiahdaZ6JNNzp2PMUXNbfsMCVgZx+qtVNnVxVMiEngPRl'
˓→7uNfEPjDZ4X6csD3X6zAWxtSuWeNuml9Yuy+tS8gI7d0FlbQRAFO/
˓→9GIlRuVdMcbCtEhg8ja7Y0g3fQjOSQJ9mqFo7sRoXyYQALD+MDEJOxhnV7neCrgDi1pqnN4xZLoR9DLARp0ad30VIvnv0ay55wxFWA
˓→J8Q+7YXmk4cN9tiVX4xR92edVO4z/vhMkjsGKLSDm/
˓→E6EMusX+N0UhQ3dv7qDgeSS8vDsqBm8XJonumNZLvFbYt2ARGRZYL6DUwIBAg=='
Once all the required certificates and keys are installed, the remaining OpenVPN Server configuration can be carried
out.
One advantage of having the client certificate stored is the ability to create the client configuration.
save the output to a file and import it in nearly all openvpn clients.
client
nobind
remote 198.51.100.254 1194
remote-cert-tls server
proto udp
dev tun
dev-type tun
persist-key
persist-tun
verb 3
# Encryption options
keysize 256
comp-lzo no
<ca>
-----BEGIN CERTIFICATE-----
MIIFnTCCA4WgAwIBAgIUIPFIXvCxYdavCnSPFNjr6lUtlsswDQYJKoZIhvcNAQEL
BQAwVzELMAkGA1UEBhMCR0IxEzARBgNVBAgMClNvbWUtU3RhdGUxEjAQBgNVBAcM
CVNvbWUtQ2l0eTENMAsGA1UECgwEVnlPUzEQMA4GA1UEAwwHdnlvcy5pbzAeFw0y
MzA1MTExMjM4MjJaFw0zMzA1MDgxMjM4MjJaMFcxCzAJBgNVBAYTAkdCMRMwEQYD
VQQIDApTb21lLVN0YXRlMRIwEAYDVQQHDAlTb21lLUNpdHkxDTALBgNVBAoMBFZ5
T1MxEDAOBgNVBAMMB3Z5b3MuaW8wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQDg45vAzS6xNqU+Pa7wk1Imt1/az1C22Sbp3wPJLfgOmy0K3TA5qVsx/c/8
gatsatMkCsekGnK5BPzCDd5eCCLo//B25HFO6fBYRNvHvVyCUx7QEXw4FHFNG88z
CIizx114AGtVwZfGGG9xCc53xjLPUpH6iqTXme41cCFFQlqXwZ7fuySieSdoV8SA
sJTTOsGCEUEcDEnNPn6tX3KWTzNuyFPECy8WCmNgWNyG2nmH+U7WRTX0ehZ5dZyU
5au7TxpRN4a+JtE0gNqcWJ+nh1A543q2pcRoQpPAzHFclgj8wG/EyauQMY/LC4tL
(continues on next page)
</ca>
<cert>
-----BEGIN CERTIFICATE-----
MIIFsDCCA5igAwIBAgIUSzQgwzGsfJFecGxCwLXVsGCLMkAwDQYJKoZIhvcNAQEL
BQAwVzELMAkGA1UEBhMCR0IxEzARBgNVBAgMClNvbWUtU3RhdGUxEjAQBgNVBAcM
CVNvbWUtQ2l0eTENMAsGA1UECgwEVnlPUzEQMA4GA1UEAwwHdnlvcy5pbzAeFw0y
MzA1MTExMjM4MzlaFw0zMzA1MDgxMjM4MzlaMFYxCzAJBgNVBAYTAkdCMRMwEQYD
VQQIDApTb21lLVN0YXRlMRIwEAYDVQQHDAlTb21lLUNpdHkxDTALBgNVBAoMBFZ5
T1MxDzANBgNVBAMMBmNsaWVudDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoC
ggIBANHNJOSwcDbRqziL1gXYnHIq7P7vEUFvS8d/XLYJ1xIpcYTRXTut2CTGRar7
fZZicu7x0yoK4TzrHvGVf1o4NC4NSGV5RX6kwRdrfWBmvpIkjSLGtCREFyhb+PHD
pnsIS7cfN9udC0vocqVlx/xM/sfcP6Vja/uFp+9TQcneJIxYw34zkF+TtOVbE3pP
5VxU7ZAj8F5/q1ONhTMdzG4Ol4/0nBqZfdYA3LVDeSSNIJNF5jlaKXXFHz1EJRem
TYDx+f5bfCVcK2Qs8fU9jCFBlATjMu9O5rgk6nMLRwEnJZuZ1gj2tWQvz4e9yo5y
Uqf1PUhOrn3c81MRliUNHKr+CkxgQJal6P3Ar3q4iftJih3K+/j4o194mQ/Dt/Et
+/Qn/DUFk2FB0rTMcQwJLTEAzxtTdmBJeJpipIPDR0u7UMZLNh/raQ8s3FsbY4uY
ORt2f5YQlCVHbth4dRa9xa+oRbm7eomNACIbWfkLh5Bzud1+qIfdBMZKaZbnf0HE
euH0J5LBJeova8EPxWbYMJPrRHzu5gowkIKl+uIxcy8IiNTA9YEoJVonCjmlr8NE
tYShrIVbicdMNSI3pOQR60MFhkHwBjSU2l/z+4wwLxtzq/c2xKw9yrOZ46ZVLwGD
Fq8rPwp7/P9r6mDKsbn6jIvGOeH71dMZvoc4lCaClw+hKIzLAgMBAAGjdTBzMAwG
A1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMC
MB0GA1UdDgQWBBS6j30FmL6kZW7rDH8QjRMoWoA/njAfBgNVHSMEGDAWgBT+TQ2n
P8gvpkJmk6WQ1L/RmTBjATANBgkqhkiG9w0BAQsFAAOCAgEANW2Y4bgaB9oexEjj
6rkGvePtQmXRkF/adVQREY9iZDGTe72ePybVzrfMkZHjse3o7JvXWRIVVztWSzEp
v5noIOX7lAioGG3wsFTHotTFR0zrYJHXHBcV2Neq4Kx2Ta/TZwD8QnZHAAxEQ1pY
b4fxwN/A60VElAZoz9zYsbrJyVrfuHDL9queQxPFzqis+7W1BiVIcv4rn0DMQ560
jTGh4t4rImOSu5gUsUrQaih85XDdOBPxViSNwfVdZJIgbvamudpfEaKsIun/uCjc
xpNnzIp0rhyYmDeqVat4GnTV7Sy48e/Uvcq71ZWbBYJF4+yW4pylIU2Sh/Uy2sAz
4C2M71FlFB7qsmcnPRsFFHf+r1NyD1lkVI9k2371fTG/Kub9V0rOz4pvKz4Em5b4
(continues on next page)
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDRzSTksHA20as4
i9YF2JxyKuz+7xFBb0vHf1y2CdcSKXGE0V07rdgkxkWq+32WYnLu8dMqCuE86x7x
lX9aODQuDUhleUV+pMEXa31gZr6SJI0ixrQkRBcoW/jxw6Z7CEu3HzfbnQtL6HKl
Zcf8TP7H3D+lY2v7hafvU0HJ3iSMWMN+M5Bfk7TlWxN6T+VcVO2QI/Bef6tTjYUz
HcxuDpeP9JwamX3WANy1Q3kkjSCTReY5Wil1xR89RCUXpk2A8fn+W3wlXCtkLPH1
PYwhQZQE4zLvTua4JOpzC0cBJyWbmdYI9rVkL8+HvcqOclKn9T1ITq593PNTEZYl
DRyq/gpMYECWpej9wK96uIn7SYodyvv4+KNfeJkPw7fxLfv0J/w1BZNhQdK0zHEM
CS0xAM8bU3ZgSXiaYqSDw0dLu1DGSzYf62kPLNxbG2OLmDkbdn+WEJQlR27YeHUW
vcWvqEW5u3qJjQAiG1n5C4eQc7ndfqiH3QTGSmmW539BxHrh9CeSwSXqL2vBD8Vm
2DCT60R87uYKMJCCpfriMXMvCIjUwPWBKCVaJwo5pa/DRLWEoayFW4nHTDUiN6Tk
EetDBYZB8AY0lNpf8/uMMC8bc6v3NsSsPcqzmeOmVS8BgxavKz8Ke/z/a+pgyrG5
+oyLxjnh+9XTGb6HOJQmgpcPoSiMywIDAQABAoICACNXi396uWyCpXVBGSyi8LfK
w2GupBmBxiI1Mkj4H2LP2G+nVS1Ye7C2NcY311AeBX56/jd23bqFYRERPgLUtPWN
B0UQyMQsvNpVISm8JR45Sg0xq+bwEXabB7SyYLkZDKgsehxkuCJxZd625pl53vGM
CKyzst0MBt4qCEsZQM7jpQr9ZLS1DSQV05InI1wKcnp1k2hX2WSZ0nZp7qYbjyyQ
6DsS4D/MpWFjnGSr4XDttXqz1YghTMHlWNpDCYtPN+3BO4iPnj+h0qCdXZ28jlLE
czAc+oDKtzPqEmv/TDaKE6Qu6x+VbkBPmG+mkoX4qfokRwCs19CGheR38PxdDx7A
gySv7K8hM8gFC0XEqNdjt86KG+N1Ps5Sru4QMrf8j9XXNPUvt0M8wsPVeWa5ubkV
7/h0HIEROOFpEFbzWnhBChPVvFObuuEjl5Jnj3KUEnckQFU07mPP/BpysHo3v/p+
VTVoo2UkfVvjamnwQOUt3cVlPVC4FzVgkswJa4f75nGmDv8dafyPrCYciOh0qyhD
5Pw/EBJkKtDBYHaoxtAw9Ann4A5rvZAveLNTPESOMo90pJwJbQcZyq9H+UGVnde3
9I4m5vHB5izZJI24Yd3fjRRkRf+/68VYKrkI5B7oH73Z/cl/xgEdI1hag4MLv1go
n8wna4yCX/321YPTrDABAoIBAQDpHtvnvpOaoSjkJHUx4EGJkrp5R/mPfEbzzU2O
v5pNIcufv++2lsoUVCTDwgp4+7GngqYO5vVyW/AS4pSrDx7kdWpFaUtJUUCcCHk/
5hYcvvourYtW1NR+XPiI28IqRp1P0L1+P0mUaRgpEcw6nEnc37XEujvTB1M/yF2y
6xc+kZGjrZTmJeu0V5kkaGcXlAqUv2k0Lj3tEPQR/qj+kMX5hidROGuybNBESgA5
ELY6QVnpcOyNDyniWq+RIUyBOuXp7DpUbmUANFEEP8lwjZX+HqwTpSjTSFdcPrsm
orc9FpTXA9ktt1Z0ZxBzUvdcWbUeVsFqL0yICiShE7UxlOPBAoIBAQDmZGQ5roSK
KY+VnmjIq2+gx8zsMYeliQm0hnKrFw9MM8U+/XOpXlpNHx2ehrGWp/BbmlmrnQaR
cbLPJaRtWSEywbWnG77g+zj0w+4BdsYyTtGGFj4tXVZhPPo/DID3FPLn9cSv8MIV
Wjzg1G/BZcxtCDBDRBhwhZHCPOfd0K/S7rvRBq7IsNNHMTGswWGRMaF+M/trZw7T
sQ0BX+5zZUyO8VNBi/NgTV3yoQ8ynBefRt1dmNa2CKXPT+5R19cBtecFEyhc3yo8
ryTtM22JzndzA8agQmNPnWmYGivvcNHNikTQ2qUvvcd7Siny6j0+CmFdT9bl64VP
yRJrFCw3jaOLAoIBAQCQ/1OyShRO+myPsql+U0kQQ8Zeh0kPWTJclFboMf7MePfJ
Lj3waMvaZxfS9s9CvvKaCSY2YKtL7Sle5bWozCff27Q05jAgszwnkRGxj/AzAwpj
nCft40UkL7majm2vk+pm6aPjcYPXnqKbcOmBjxJWIoNRkLCDKqw6IOs+zQDRNwPK
Nb5GhFGeA1pKjfGJddg6+u95uEVmPcRBqQ79/5hUAoBUAW7jNNE5mHmZBO8DPwCo
tUc82bCojNVkxLxsKPE2VWtWdq+1t9SoevBVZItl2zgWpATHndhQlOgdONoWUgRT
1J3x1HYewrg1suYOd/GypC17WV4Vw5FS6wopg71BAoIBAQC63vDgTGpauk0pOVya
b1tSmNzhM2dn4BhMIcU+eqzAzTkO13sKBGrQJQ3cODoxDbSKSE61QN9D92nmVQzi
WKnxxmb1zS5sw7g15/nTnCg0Q/P0g3QZTZyzsEb1/slYH9jKRnErl+eEdDXu0sB2
(continues on next page)
</key>
13.5.4 Monitoring
FOURTEEN
BUILD VYOS
14.1 Prerequisites
Note: Starting with VyOS 1.2 the release model of VyOS has changed. VyOS is now free as in speech, but not as in
beer. This means that while VyOS is still an open source project, the release ISOs are no longer free and can only be
obtained via subscription, or by contributing to the community.
The source code remains public and an ISO can be built using the process outlined in this chapter.
The following includes the build process for VyOS 1.2 to the latest version.
This will guide you through the process of building a VyOS ISO using Docker. This process has been tested on clean
installs of Debian Jessie, Stretch, and Buster.
To build VyOS natively you require a properly configured build host with the following Debian versions installed:
• Debian Jessie for VyOS 1.2 (crux)
• Debian Buster for VyOS 1.3 (equuleus)
• Debian Bookworm for VyOS 1.4 (sagitta)
• Debian Bookworm for the upcoming VyOS 1.5/circinus/current (subject to change) - aka the rolling release
To start, clone the repository to your local machine:
1266
VyOS Documentation, Release 1.5.x (circinus)
$ cd vyos-build
For the packages required, you can refer to the docker/Dockerfile file in the repository. The ./build-vyos-image
script will also warn you if any dependencies are missing.
This will guide you through the process of building a VyOS ISO using Docker. This process has been tested on clean
installs of Debian Bullseye (11) and Bookworm (12).
14.1.2 Docker
Hint: Due to the updated version of Docker, the following examples may become invalid.
To be able to use Docker without sudo, the current non-root user must be added to the docker group by calling: sudo
usermod -aG docker yourusername.
Hint: Doing so grants privileges equivalent to the root user! It is recommended to remove the non-root user from
the docker group after building the VyOS ISO. See also Docker as non-root.
Note: The build process needs to be built on a local file system, building on SMB or NFS shares will result in the
container failing to build properly! VirtualBox Drive Share is also not an option as block device operations are not
implemented and the drive is always mounted as “nodev”
Build Container
The container can be built by hand or by fetching the pre-built one from DockerHub. Using the pre-built containers
from the VyOS DockerHub organisation will ensure that the container is always up-to-date. A rebuild is triggered once
the container changes (please note this will take 2-3 hours after pushing to the vyos-build repository).
Dockerhub
$ cd vyos-build
$ docker build -t vyos/vyos-build:crux docker # For VyOS 1.2
$ docker build -t vyos/vyos-build:equuleus docker # For VyOS 1.3
$ docker build -t vyos/vyos-build:sagitta docker # For VyOS 1.4
$ docker build -t vyos/vyos-build:current docker # For VyOS 1.5 rolling release
Note: VyOS has switched to Debian (12) Bookworm in its current branch, Due to software version updates, it is
recommended to use the official Docker Hub image to build VyOS ISO.
You can create yourself some handy Bash aliases to always launch the latest - per release train (current or crux) -
container. Add the following to your .bash_aliases file:
Now you are prepared with two new aliases vybld and vybld_crux to spawn your development containers in your
current working directory.
Note: Some VyOS packages (namely vyos-1x) come with build-time tests which verify some of the internal library
calls that they work as expected. Those tests are carried out through the Python Unittest module. If you want to build
the vyos-1x package (which is our main development package) you need to start your Docker container using the
following argument: --sysctl net.ipv6.conf.lo.disable_ipv6=0, otherwise those tests will fail.
Now as you are aware of the prerequisites we can continue and build our own ISO from source. For this we have to
fetch the latest source code from GitHub. Please note as this will differ for both current and crux.
Now a fresh build of the VyOS ISO can begin. Change directory to the vyos-build directory and run:
$ cd vyos-build
# For VyOS 1.2 (crux)
$ docker run --rm -it --privileged -v $(pwd):/vyos -w /vyos vyos/vyos-build:crux bash
When the build is successful, the resulting iso can be found inside the build directory as
live-image-[architecture].hybrid.iso.
Good luck!
Hint: Building VyOS on Windows WSL2 with Docker integrated into WSL2 will work like a charm. No problems
are known so far!
14.2.1 Customize
This ISO can be customized with the following list of configure options. The full and current list can be generated with
./build-vyos-image --help:
positional arguments:
build_flavor Build flavor
optional arguments:
-h, --help show this help message and exit
--architecture ARCHITECTURE
Image target architecture (amd64 or arm64)
--build-by BUILD_BY Builder identifier (e.g. [email protected])
--debian-mirror DEBIAN_MIRROR
Debian repository mirror
--debian-security-mirror DEBIAN_SECURITY_MIRROR
Debian security updates mirror
--pbuilder-debian-mirror PBUILDER_DEBIAN_MIRROR
Debian repository mirror for pbuilder env bootstrap
--vyos-mirror VYOS_MIRROR
VyOS package mirror
--build-type BUILD_TYPE
Build type, release or development
--version VERSION Version number (release builds only)
--build-comment BUILD_COMMENT
Optional build comment
--debug Enable debug output
--dry-run Check build configuration and exit
--custom-apt-entry CUSTOM_APT_ENTRY
Custom APT entry
--custom-apt-key CUSTOM_APT_KEY
Custom APT key file
--custom-package CUSTOM_PACKAGE
Custom package to install from repositories
There are (rare) situations where building an ISO image is not possible at all due to a broken package feed in the
background. APT is not very good at reporting the root cause of the issue. Your ISO build will likely fail with a more
or less similar looking error message:
To debug the build process and gain additional information of what could be the root cause, you need to use chroot to
change into the build directory. This is explained in the following step by step procedure:
We now are free to run any command we would like to use for debugging, e.g. re-installing the failed package after
updating the repository.
Now it’s time to fix the package mirror and rerun the last step until the package installation succeeds again!
The Linux kernel used by VyOS is heavily tied to the ISO build process. The file data/defaults.json hosts a JSON
definition of the kernel version used kernel_version and the kernel_flavor of the kernel which represents the
kernel’s LOCAL_VERSION. Both together form the kernel version variable in the system:
vyos@vyos:~$ uname -r
6.1.52-amd64-vyos
• Accel-PPP
• Intel NIC drivers
• Intel QAT
Each of those modules holds a dependency on the kernel version and if you are lucky enough to receive an ISO build
error which sounds like:
The kernel build is quite easy, most of the required steps can be found in the vyos-build/packages/linux-kernel/
Jenkinsfile but we will walk you through it.
Clone the kernel source to vyos-build/packages/linux-kernel/ :
$ cd vyos-build/packages/linux-kernel/
$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Check out the required kernel version - see vyos-build/data/defaults.json file (example uses kernel 4.19.146):
$ cd vyos-build/packages/linux-kernel/linux
$ git checkout v4.19.146
Checking out files: 100% (61536/61536), done.
Note: checking out 'v4.19.146'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
Now we can use the helper script build-kernel.sh which does all the necessary voodoo by applying
required patches from the vyos-build/packages/linux-kernel/patches folder, copying our kernel configuration
x86_64_vyos_defconfig to the right location, and finally building the Debian packages.
Note: Building the kernel will take some time depending on the speed and quantity of your CPU/cores and disk speed.
Expect 20 minutes (or even longer) on lower end hardware.
SYSTBL arch/x86/include/generated/asm/syscalls_32.h
...
dpkg-genbuildinfo --build=binary
dpkg-genchanges --build=binary >../linux-4.19.146-amd64-vyos_4.19.146-1_amd64.changes
dpkg-genchanges: warning: package linux-image-4.19.146-amd64-vyos-dbg in control file␣
˓→but not in files list
In the end you will be presented with the kernel binary packages which you can then use in your custom ISO build
process, by placing all the *.deb files in the vyos-build/packages folder where they will be used automatically when
building VyOS as documented above.
Firmware
If you upgrade your kernel or include new drivers you may need new firmware. Build a new vyos-linux-firmware
package with the included helper scripts.
$ cd vyos-build/packages/linux-kernel
$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
$ ./build-linux-firmware.sh
$ cp vyos-linux-firmware_*.deb ../
This tries to automatically detect which blobs are needed based on which drivers were built. If it fails to find the correct
files you can add them manually to vyos-build/packages/linux-kernel/build-linux-firmware.sh:
ADD_FW_FILES="iwlwifi* ath11k/QCA6390/*/*.bin"
Building the kernel is one part, but now you also need to build the required out-of-tree modules so everything is lined up
and the ABIs match. To do so, you can again take a look at vyos-build/packages/linux-kernel/Jenkinsfile
to see all of the required modules and their selected versions. We will show you how to build all the current required
modules.
Accel-PPP
First, clone the source code and check out the appropriate version by running:
$ cd vyos-build/packages/linux-kernel
$ git clone https://github.com/accel-ppp/accel-ppp.git
We again make use of a helper script and some patches to make the build work. Just run the following command:
$ ./build-accel-ppp.sh
I: Build Accel-PPP Debian package
CMake Deprecation Warning at CMakeLists.txt:3 (cmake_policy):
The OLD behavior for policy CMP0003 will be removed from a future version
of CMake.
...
After compiling the packages you will find yourself the newly generated *.deb binaries in vyos-build/packages/
linux-kernel from which you can copy them to the vyos-build/packages folder for inclusion during the ISO
build.
Intel NIC
The Intel NIC drivers do not come from a Git repository, instead we just fetch the tarballs from our mirror and compile
them.
Simply use our wrapper script to build all of the driver modules.
./build-intel-drivers.sh
% Total % Received % Xferd Average Speed Time Time Time Current
(continues on next page)
...
After compiling the packages you will find yourself the newly generated *.deb binaries in vyos-build/packages/
linux-kernel from which you can copy them to the vyos-build/packages folder for inclusion during the ISO
build.
Intel QAT
The Intel QAT (Quick Assist Technology) drivers do not come from a Git repository, instead we just fetch the tarballs
from 01.org, Intel’s open-source website.
Simply use our wrapper script to build all of the driver modules.
$ ./build-intel-qat.sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5065k 100 5065k 0 0 1157k 0 0:00:04 0:00:04 --:--:-- 1157k
I: Compile Kernel module for Intel qat driver
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
...
After compiling the packages you will find yourself the newly generated *.deb binaries in vyos-build/packages/
linux-kernel from which you can copy them to the vyos-build/packages folder for inclusion during the ISO
build.
14.2.3 Packages
If you are brave enough to build yourself an ISO image containing any modified package from our GitHub organisation
- this is the place to be.
Any “modified” package may refer to an altered version of e.g. vyos-1x package that you would like to test before filing
a pull request on GitHub.
Building an ISO with any customized package is in no way different than building a regular (customized or not) ISO
image. Simply place your modified *.deb package inside the packages folder within vyos-build. The build process will
then pickup your custom package and integrate it into your ISO.
14.2.4 Troubleshooting
Debian APT is not very verbose when it comes to errors. If your ISO build breaks for whatever reason and you suspect
it’s a problem with APT dependencies or installation you can add this small patch which increases the APT verbosity
during ISO build.
+ -oDebug::pkgDepCache::Marker=true -
˓→oDebug::pkgProblemResolver=true -oDebug::Acquire::gpgv=true" \
--apt-indices false
"${@}"
"""
QEMU
$ make qemu
VMware
$ make vmware
14.3 Packages
VyOS itself comes with a bunch of packages that are specific to our system and thus cannot be found in any Debian
mirror. Those packages can be found at the VyOS GitHub project in their source format can easily be compiled into a
custom Debian (*.deb) package.
The easiest way to compile your package is with the above mentioned Docker container, it includes all required depen-
dencies for all VyOS related packages.
Assume we want to build the vyos-1x package on our own and modify it to our needs. We first need to clone the
repository from GitHub.
14.3.1 Build
# Build DEB
$ dpkg-buildpackage -uc -us -tc -b
After a minute or two you will find the generated DEB packages next to the vyos-1x source directory:
# ls -al ../vyos-1x*.deb
-rw-r--r-- 1 vyos_bld vyos_bld 567420 Aug 3 12:01 ../vyos-1x_1.3dev0-1847-gb6dcb0a8_all.
˓→deb
14.3.2 Install
To take your newly created package on a test drive you can simply SCP it to a running VyOS instance and install the
new *.deb package over the current running one.
Just install using the following commands:
You can also place the generated *.deb into your ISO build environment to include it in a custom iso, see Linux Kernel
for more information.
Warning: Any packages in the packages directory will be added to the iso during build, replacing the upstream
ones. Make sure you delete them (both the source directories and built deb packages) if you want to build an iso
from purely upstream packages.
FIFTEEN
DEVELOPMENT
All VyOS source code is hosted on GitHub under the VyOS organization which can be found here: https://github.com/
vyos
Our code is split into several modules. VyOS is composed of multiple individual packages, some of them are forks of
upstream packages and are periodically synced with upstream, so keeping the whole source under a single repository
would be very inconvenient and slow. There is now an ongoing effort to consolidate all VyOS-specific framework/config
packages into vyos-1x package, but the basic structure is going to stay the same, just with fewer and fewer packages
while the base code is rewritten from Perl/BASH into Python using and XML based interface definition for the CLI.
The repository that contains all the ISO build scripts is: https://github.com/vyos/vyos-build
The README.md file will guide you to use the this top level repository.
Patches are always more than welcome. To have a clean and easy to maintain repository we have some guidelines when
working with Git. A clean repository eases the automatic generation of a changelog file.
A good approach for writing commit messages is actually to have a look at the file(s) history by invoking git log
path/to/file.txt.
In a big system, such as VyOS, that is comprised of multiple components, it’s impossible to keep track of all the changes
and bugs/feature requests in one’s head. We use a bugtracker known as Phabricator for it (“issue tracker” would be a
better term, but this one stuck).
The information is used in three ways:
• Keep track of the progress (what we’ve already done in this branch and what we still need to do).
• Prepare release notes for upcoming releases
• Help future maintainers of VyOS (it could be you!) to find out why certain things have been changed in the
codebase or why certain features have been added
To make this approach work, every change must be associated with a task number (prefixed with T) and a component.
If there is no bug report/feature request for the changes you are going to make, you have to create a Phabricator task
first. Once there is an entry in Phabricator, you should reference its id in your commit message, as shown below:
• ddclient: T1030: auto create runtime directories
• Jenkins: add current Git commit ID to build description
1282
VyOS Documentation, Release 1.5.x (circinus)
If there is no Phabricator reference in the commits of your pull request, we have to ask you to amend the commit
message. Otherwise we will have to reject it.
The format should be and is inspired by: https://git-scm.com/book/ch5-2.html It is also worth reading https://chris.
beams.io/posts/git-commit/
• A single, short, summary of the commit (recommended 50 characters or less, not exceeding 80 characters) con-
taining a prefix of the changed component and the corresponding Phabricator reference e.g. snmp: T1111: or
ethernet: T2222: - multiple components could be concatenated as in snmp: ethernet: T3333
• In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can
get confused if you run the two together.
• Followed by a message which describes all the details like:
– What/why/how something has been changed, makes everyone’s life easier when working with git bisect
– All text of the commit message should be wrapped at 72 characters if possible which makes reading commit
logs easier with git log on a standard terminal (which happens to be 80x25)
– If applicable a reference to a previous commit should be made linking those commits nicely when brows-
ing the history: After commit abcd12ef ("snmp: this is a headline") a Python import
statement is missing, throwing the following exception: ABCDEF
• Always use the -x option to the git cherry-pick command when back or forward porting an individual
commit. This automatically appends the line: (cherry picked from commit <ID>) to the original authors
commit message making it easier when bisecting problems.
• Every change set must be consistent (self containing)! Do not fix multiple bugs in a single commit. If you already
worked on multiple fixes in the same file use git add –patch to only add the parts related to the one issue into
your upcoming commit.
Limits:
• We only accept bugfixes in packages other than https://github.com/vyos/vyos-1x as no new functionality should
use the old style templates (node.def and Perl/BASH code. Use the new style XML/Python interface instead.
Please submit your patches using the well-known GitHub pull-request against our repositories found in the VyOS
GitHub organisation at https://github.com/vyos
Suppose you want to make a change in the webproxy script but yet you do not know which of the many VyOS packages
ship this file. You can determine the VyOS package name in question by using Debian’s dpkg -S command of your
running VyOS installation.
Forking the repository and submitting a GitHub pull-request is the preferred way of submitting your changes to VyOS.
You can fork any VyOS repository to your very own GitHub account by just appending /fork to any repository’s
URL on GitHub. To e.g. fork the vyos-1x repository, open the following URL in your favourite browser: https:
//github.com/vyos/vyos-1x/fork
You then can proceed with cloning your fork or add a new remote to your local repository:
• Clone: git clone https://github.com/<user>/vyos-1x.git
• Fork: git remote add myfork https://github.com/<user>/vyos-1x.git
In order to record you as the author of the fix please identify yourself to Git by setting up your name and email. This
can be done local for this one and only repository git config or globally using git config --global.
Make your changes and save them. Do the following for all changes files to record them in your created Git commit:
• Add file to Git index using git add myfile, or for a whole directory: git add somedir/*
• Commit the changes by calling git commit. Please use a meaningful commit headline (read above) and don’t
forget to reference the Phabricator ID.
• Submit the patch git push and create the GitHub pull-request.
Follow the above steps on how to “Fork repository to submit a Patch”. Instead of uploading “pushing” your changes
to GitHub you can export the patches/ commits and send it to [email protected] or attach it directly to the bug
(preferred over email)
• Export last commit to patch file: git format-patch or export the last two commits into its appropriate patch
files: git format-patch -2
Like any other project we have some small guidelines about our source code, too. The rules we have are not there to
punish you - the rules are in place to help us all. By having a consistent coding style it becomes very easy for new and
also longtime contributors to navigate through the sources and all the implied logic of any one source file..
Python 3 shall be used. How long can we keep Python 2 alive anyway? No considerations for Python 2 compatibility
should be taken at any time.
15.2.1 Formatting
• Python: Tabs shall not be used. Every indentation level should be 4 spaces
• XML: Tabs shall not be used. Every indentation level should be 2 spaces
Note: There are extensions to e.g. VIM (xmllint) which will help you to get your indention levels correct. Add to
following to your .vimrc file: au FileType xml setlocal equalprg=xmllint\ --format\ --recover\ -\
2>/dev/null now you can call the linter using gg=G in command mode.
Text generation
Template processor should be used for generating config files. Built-in string formatting may be used for simple
line-oriented formats where every line is self-contained, such as iptables rules. Template processor must be used for
structured, multi-line formats such as those used by ISC DHCPd.
The default template processor for VyOS code is Jinja2.
15.2.2 Summary
When modifying the source code, remember these rules of the legacy elimination campaign:
• No new features in Perl
• No old style command definitions
• No code incompatible with Python3
15.3 Python
The switch to the Python programming language for new code is not merely a change of the language, but a chance to
rethink and improve the programming approach.
Let’s face it: VyOS is full of spaghetti code where logic for reading the VyOS config, generating daemon configs, and
restarting processes is all mixed up.
Python (or any other language, for that matter) does not provide automatic protection from bad design, so we need to
also devise design guidelines and follow them to keep the system extensible and maintainable.
But we are here to assist you and want to guide you through how you can become a good VyOS contributor. The rules
we have are not there to punish you - the rules are in place to help us all. What does it mean? By having a consistent
coding style it becomes very easy for new contributors and also longtime contributors to navigate through the sources
and all the implied logic of the spaghetti code.
Please use the following template as good starting point when developing new modules or even rewrite a whole bunch
of code in the new style XML/Python interface.
Your configuration script or operation mode script which is also written in Python3 should have a line break on 80
characters. This seems to be a bit odd nowadays but as some people also work remotely or program using vi(m) this is
a fair good standard which I hope we can rely on.
In addition this also helps when browsing the GitHub codebase on a mobile device if you happen to be a crazy scientist.
#!/usr/bin/env python3
#
# Copyright (C) 2020 VyOS maintainers and contributors
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 or later as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
import sys
def get_config():
if config:
conf = config
else:
conf = Config()
def verify(config):
# Verify that configuration is valid
if invalid:
raise ConfigError("Descriptive message")
return True
def generate(config):
# Generate daemon configs
pass
def apply(config):
# Apply the generated configs to the live system
pass
(continues on next page)
try:
c = get_config()
verify(c)
generate(c)
apply(c)
except ConfigError as e:
print(e)
sys.exit(1)
The get_config() function must convert the VyOS config to an abstract, internal representation. No other function
is allowed to call the vyos.config. Config object method directly. The rationale for it is that when config reads are
mixed with other logic, it’s very hard to change the config syntax since you need to weed out every occurrence of the
old syntax. If syntax-specific code is confined to a single function, the rest of the code can be left untouched as long
as the internal representation remains compatible.
Another advantage is testability of the code. Mocking the entire config subsystem is hard, while constructing an internal
representation by hand is way simpler.
The verify() function takes your internal representation of the config and checks if it’s valid, otherwise it must raise
ConfigError with an error message that describes the problem and possibly suggests how to fix it. It must not make
any changes to the system. The rationale for it is again testability and, in the future when the config backend is ready
and every script is rewritten in this fashion, ability to execute commit dry run (“commit test” like in JunOS) and abort
commit before making any changes to the system if an error is found in any component.
The generate() function generates config files for system components.
The apply() function applies the generated configuration to the live system. It should use non-disruptive reload
whenever possible. It may execute disruptive operations such as daemon process restart if a particular component
does not support non-disruptive reload, or when the expected service degradation is minimal (for example, in case of
auxiliary services such as LLDPd). In case of high impact services such as VPN daemon and routing protocols, when
non- disruptive reload is supported for some but not all types of configuration changes, scripts authors should make
effort to determine if a configuration change can be done in a non-disruptive way and only resort to disruptive restart
if it cannot be avoided.
Unless absolutely necessary, configuration scripts should not modify the active configuration of system components
directly. Whenever at all possible, scripts should generate a configuration file or files that can be applied with a single
command such as reloading a service through systemd init. Inserting statements one by one is particularly discouraged,
for example, when configuring netfilter rules, saving them to a file and loading it with iptables-restore should always
be preferred to executing iptables directly.
The apply() and generate() functions may raise ConfigError if, for example, the daemon failed to start with
the updated config. It shouldn’t be a substitute for proper config checking in the verify() function. All reasonable
effort should be made to verify that generated configuration is valid and will be accepted by the daemon, including,
when necessary, cross- checks with other VyOS configuration subtrees.
Exceptions, including VyOSError (which is raised by vyos.config.Config on improper config operations, such as
trying to use list_nodes() on a non-tag node) should not be silenced or caught and re-raised as config error. Sure
this will not look pretty on user’s screen, but it will make way better bug reports, and help users (and most VyOS users
are IT professionals) do their own debugging as well.
For easy orientation we suggest you take a look on the ntp.py or interfaces-bonding.py (for tag nodes) imple-
mentation. Both files can be found in the vyos-1x repository.
The bash (or better vbash) completion in VyOS is defined in templates. Templates are text files (called node.def)
stored in a directory tree. The directory names define the command names, and template files define the command
behaviour. Before VyOS 1.2 (crux) this files were created by hand. After a complex redesign process the new style
template are automatically generated from a XML input file.
XML interface definitions for VyOS come with a RelaxNG schema and are located in the vyos-1x module. This schema
is a slightly modified schema from VyConf alias VyOS 2.0 So VyOS 1.2.x interface definitions will be reusable in
Nextgen VyOS Versions with very minimal changes.
The great thing about schemas is not only that people can know the complete grammar for certain, but also that it can
be automatically verified. The scripts/build-command-templates script that converts the XML definitions to old style
templates also verifies them against the schema, so a bad definition will cause the package build to fail. I do agree that
the format is verbose, but there is no other format now that would allow this. Besides, a specialized XML editor can
alleviate the issue with verbosity.
Example:
<?xml version="1.0"?>
<!-- Cron configuration -->
<interfaceDefinition>
<node name="system">
<children>
<node name="task-scheduler">
<properties>
<help>Task scheduler settings</help>
</properties>
<children>
<tagNode name="task" owner="${vyos_conf_scripts_dir}/task_scheduler.py">
<properties>
<help>Scheduled task</help>
<valueHelp>
<format><string></format>
<description>Task name</description>
</valueHelp>
<priority>999</priority>
</properties>
<children>
<leafNode name="crontab-spec">
<properties>
<help>UNIX crontab time specification string</help>
</properties>
</leafNode>
<leafNode name="interval">
<properties>
<help>Execution interval</help>
<valueHelp>
<format><minutes></format>
<description>Execution interval in minutes</description>
</valueHelp>
<valueHelp>
<format><minutes>m</format>
<description>Execution interval in minutes</description>
(continues on next page)
Command definitions are purely declarative, and cannot contain any logic. All logic for generating config files for
target applications, restarting services and so on is implemented in configuration scripts instead.
XML interface definition files use the xml.in file extension which was implemented in T1843. XML interface definitions
tend to have a lot of duplicated code in areas such as:
• VIF (incl. VIF-S/VIF-C)
• Address
• Description
• Enabled/Disabled
Instead of supplying all those XML nodes multiple times there are now include files with predefined features. Brief
overview:
• IPv4, IPv6 and DHCP(v6) address assignment
• IPv4, IPv6 address assignment
• VLAN (VIF) definition
• MAC address assignment
All interface definition XML input files (.in suffix) will be sent to the GCC preprocess and the output is stored in the
build/interface-definitions folder. The previously mentioned scripts/build-command-templates script operates on the
build/interface-definitions folder to generate all required CLI nodes.
$ make interface_definitions
install -d -m 0755 build/interface-definitions
install -d -m 0755 build/op-mode-definitions
Generating build/interface-definitions/intel_qat.xml from interface-definitions/intel_
˓→qat.xml.in
[...]
15.4.2 Guidelines
Use of numbers
Use of numbers in command names should be avoided unless a number is a part of a protocol name or similar. Thus,
protocols ospfv3 is perfectly fine, but something like server-1 is questionable at best.
Help String
To ensure uniform look and feel, and improve readability, we should follow a set of guidelines consistently.
The first word of every help string must be capitalized. There must not be a period at the end of help strings.
Rationale: this seems to be the unwritten standard in network device CLIs, and a good aesthetic compromise.
Examples:
• Good: “Frobnication algorithm”
• Bad: “frobnication algorithm”
• Bad: “Frobnication algorithm.”
Use of verbs
Prefer infinitives
The CLI parser used in VyOS is a mix of bash, bash-completion helper and the C++ backend library [vyatta-cfg](https:
//github.com/vyos/vyatta-cfg). This section is a reference of common CLI commands and the respective entry point in
the C/C++ code.
• set
– https://github.com/vyos/vyatta-cfg/blob/0f42786a0b3/src/cstore/cstore.cpp#L352
– https://github.com/vyos/vyatta-cfg/blob/0f42786a0b3/src/cstore/cstore.cpp#L2549
• commit
– https://github.com/vyos/vyatta-cfg/blob/0f42786a0b3/src/commit/commit-algorithm.cpp#L1252
VyOS makes use of Jenkins as our Continuous Integration (CI) service. Our VyOS CI server is publicly accessible
here: https://ci.vyos.net. You can get a brief overview of all required components shipped in a VyOS ISO.
To build our modules we utilize a CI/CD Pipeline script. Each and every VyOS component comes with it’s own
Jenkinsfile which is (more or less) a copy. The Pipeline utilizes the Docker container from the Build ISO section -
but instead of building it from source on every run, we rather always fetch a fresh copy (if needed) from Dockerhub.
Each module is build on demand if a new commit on the branch in question is found. After a successful run the
resulting Debian Package(s) will be deployed to our Debian repository which is used during build time. It is located
here: http://dev.packages.vyos.net/repositories/.
SIXTEEN
ISSUES/FEATURE REQUESTS
Issues or bugs are found in any software project. VyOS is not an exception.
All issues should be reported to the developers. This lets the developers know what is not working properly. Without
this sort of feedback every developer will believe that everything is working correctly.
When you believe you have found a bug, it is always a good idea to verify the issue prior to opening a bug request.
• Consult the documentation to ensure that you have configured your system correctly
• Get community support via Slack or our Forum
1294
VyOS Documentation, Release 1.5.x (circinus)
In order to open up a bug-report/feature request you need to create yourself an account on VyOS Phabricator. On
the left side of the specific project (VyOS 1.2 or VyOS 1.3) you will find quick-links for opening a bug-report/feature
request.
• Provide as much information as you can
• Which version of VyOS are you using? run show version
• How can we reproduce this Bug?
You have an idea of how to make VyOS better or you are in need of a specific feature which all users of VyOS would
benefit from? To send a feature request please search Phabricator to check if there is already a request pending. You
can enhance it or if you don’t find one, create a new one by use the quick link in the left side under the specific project.
You must create a task before you start working on a feature. Yes, even if it’s a tiny feature — we use the task tracker
to generate release notes, so it’s essential that everything is reflected there.
You must include at least the following:
• A reasonably detailed description of the feature: what it is, how it’s supposed to work, and how you’d use it. The
maintainers aren’t familiar with every feature of every protocol and tool, and community contributors who are
looking for tasks to work on will also appreciate more information that helps them implement and test a feature.
• Proposed CLI syntax, if the feature requires new commands. Please include both configuration and operational
mode commands, if both are required.
You should include the following information:
• Is the feature supported by the underlying component (FreeRangeRouting, nftables, Kea. . . ) already?
• How you’d configure it by hand there?
• Are there any limitations (hardware support, resource usage)?
• Are there any adverse or non-obvious interactions with other features? Should it be mutually exclusive with
anything?
It’s fine if you cannot provide some of that information, but if you can, it makes the work of developers considerably
simpler, so try to do the research to answer those questions.
There is a special status for tasks where all work on the side of maintainers and contributors is complete: “Needs
reporter action”.
We assign that status to:
• Feature requests that do not include required information and need clarification.
• Bug reports that lack reproducing procedures.
• Tasks that are implemented and tested by the implementation author, but require testing in the real-world envi-
ronment that only the reporter can replicate (e.g., hardware we do not have, specific network conditions. . . ).
This is what will happen when a task is set to “Needs reporter action”:
• If there is no response from the reporter within two weeks, the task bot will add a comment (“Any news?”) to
remind the reporter to reply.
• If there is no response after further two weeks, the task will be automatically closed.
We will not auto-close tasks with any other status and will not close tasks for the lack of maintainer activity!
SEVENTEEN
UPSTREAM PACKAGES
Many base system packages are pulled straight from Debian’s main and contrib repositories, but there are exceptions.
This chapter lists those exceptions and gives you a brief overview what we have done on those packages. If you only
want to build yourself a fresh ISO you can completely skip this chapter. It may become interesting once you have a
VyOS deep dive.
17.1 vyos-netplug
Due to issues in the upstream version that sometimes set interfaces down, a modified version is used.
The source is located at https://github.com/vyos/vyos-netplug
In the future, we may switch to using systemd infrastructure instead. Building it doesn’t require a special procedure.
17.2 keepalived
Keepalived normally isn’t updated to newer feature releases between Debian versions, so we are building it from source.
Debian does keep their package in git, but it’s upstream tarball imported into git without its original commit history.
To be able to merge new tags in, we keep a fork of the upstream repository with packaging files imported from Debian
at https://github.com/vyos/keepalived-upstream
17.3 strongswan
1297
VyOS Documentation, Release 1.5.x (circinus)
2. ./configure –enable-python-eggs
3. cd src/libcharon/plugins/vici/python
4. make
5. python3 setup.py –command-packages=stdeb.command bdist_deb
The package ends up in deb_dist dir.
17.4 mdns-repeater
17.5 udp-broadcast-relay
17.6 hvinfo
EIGHTEEN
DEBUGGING
There are two flags available to aid in debugging configuration scripts. Since configuration loading issues will manifest
during boot, the flags are passed as kernel boot parameters.
When having trouble compiling your own ISO image or debugging Jenkins issues you can follow the steps at ISO Build
Issues.
The system startup can be debugged (like loading in the configuration file from /config/config.boot. This can be
achieve by extending the Kernel command-line in the bootloader.
18.2.1 Kernel
• vyos-debug - Adding the parameter to the linux boot line will produce timing results for the execution of
scripts during commit. If one is seeing an unexpected delay during manual or boot commit, this may be useful
in identifying bottlenecks. The internal flag is VYOS_DEBUG, and is found in vyatta-cfg. Output is directed to
/var/log/vyatta/cfg-stdout.log.
• vyos-config-debug - During development, coding errors can lead to a commit failure on boot, possibly result-
ing in a failed initialization of the CLI. In this circumstance, the kernel boot parameter vyos-config-debug will
ensure access to the system as user vyos, and will log a Python stack trace to the file /tmp/boot-config-trace.
File boot-config-trace will generate only if config loaded with a failure status.
A number of flags can be set up to change the behaviour of VyOS at runtime. These flags can be toggled using either
environment variables or creating files.
For each feature, a file called vyos.feature.debug can be created to toggle the feature on. If a parameter is required
it can be placed inside the file as its first line.
The file can be placed in /tmp for one time debugging (as the file will be removed on reboot) or placed in ‘/config’ to
stay permanently.
For example, /tmp/vyos.ifconfig.debug can be created to enable interface debugging.
1299
VyOS Documentation, Release 1.5.x (circinus)
It is also possible to set up the debugging using environment variables. In that case, the name will be (in uppercase)
VYOS_FEATURE_DEBUG.
For example running, export VYOS_IFCONFIG_DEBUG="" on your vbash, will have the same effect as touch /tmp/
vyos.ifconfig.debug.
• ifconfig - Once set, all commands used, and their responses received from the OS, will be presented on the
screen for inspection.
• command - Once set, all commands used, and their responses received from the OS, will be presented on the
screen for inspection.
• developer - Should a command fail, instead of printing a message to the user explaining how to report issues,
the python interpreter will start a PBD post-mortem session to allow the developer to debug the issue. As the
debugger will wait from input from the developer, it has the capacity to prevent a router to boot and therefore
should only be permanently set up on production if you are ready to see the OS fail to boot.
• log - In some rare cases, it may be useful to see what the OS is doing, including during boot. This option sends
all commands used by VyOS to a file. The default file is /tmp/full-log but it can be changed.
Note: In order to retrieve the debug output on the command-line you need to disable vyos-configd in addition. This
can be run either one-time by calling sudo systemctl stop vyos-configd or make this reboot-safe by calling
sudo systemctl disable vyos-configd.
18.3.1 FRR
Recent versions use the vyos.frr framework. The Python class is located inside our vyos-1x:python/vyos/frr.
py. It comes with an embedded debugging/ (print style) debugger as vyos.ifconfig does.
To enable debugging just run: $ touch /tmp/vyos.frr.debug
Sometimes it might be useful to debug Python code interactively on the live system rather than a IDE. This can be
achieved using pdb.
Let us assume you want to debug a Python script that is called by an op-mode command. After you found the script by
looking up the op-mode-defitions you can edit the script in the live system using e.g. vi: vi /usr/libexec/vyos/
op_mode/show_xyz.py
Insert the following statement right before the section where you want to investigate a problem (e.g. a statement you
see in a backtrace): import pdb; pdb.set_trace() Optionally you can surrounded this statement by an if which
only triggers under the condition you are interested in.
Once you run show xyz and your condition is triggered you should be dropped into the python debugger:
> /usr/libexec/vyos/op_mode/show_nat_translations.py(109)process()
-> rule_type = rule.get('type', '')
(Pdb)
You can type help to get an overview of the available commands, and help command to get more information on each
command.
Useful commands are:
• examine variables using pp(var)
When writing a new configuration migrator it may happen that you see an error when you try to invoke it manually on
a development system. This error will look like:
The reason is that the configuration migration backend is rewritten and uses a new form of “magic string” which is
applied on demand when real config migration is run on boot. When running individual migrators for testing, you need
to convert the “magic string” on your own by:
Being brave and running the latest rolling releases will sometimes trigger bugs due to corner cases we missed in our
design. Those bugs should be filed via Phabricator but you can help us to narrow down the issue. Login to your VyOS
system and change into configuration mode by typing configure. Now re-load your boot configuration by simply
typing load followed by return.
You should now see a Python backtrace which will help us to handle the issue, please attach it to the Phabricator task.
During the migration and extensive rewrite of functionality from Perl into Python a significant increase in the overall
system boottime was noticed. The system boot time can be analysed and a graph can be generated in the end which
shows in detail who called whom during the system startup phase.
This is done by utilizing the systemd-bootchart package which is now installed by default on the VyOS 1.3 (equ-
uleus) branch. The configuration is also versioned so we get comparable results. systemd-bootchart is configured
using this file: bootchart.conf
To enable boot time graphing change the Kernel commandline and add the following string: init=/usr/lib/
systemd/systemd-bootchart
This can also be done permanently by changing /boot/grub/grub.cfg.
18.4 Priorities
VyOS CLI is all about priorities. Every CLI node has a corresponding node.def file and possibly an attached script
that is executed when the node is present. Nodes can have a priority, and on system bootup - or any other commit to
the config all scripts are executed from lowest to highest priority. This is good as this gives a deterministic behavior.
To debug issues in priorities or to see what’s going on in the background you can use the /opt/vyatta/sbin/
priority.pl script which lists to you the execution order of the scripts.
NINETEEN
TESTING
One of the major advantages introduced in VyOS 1.3 is an automated test framework. When assembling an ISO image
multiple things can go wrong badly and publishing a faulty ISO makes no sense. The user is disappointed by the quality
of the image and the developers get flodded with bug reports over and over again.
As the VyOS documentation is not only for users but also for the developers - and we keep no secret documentation -
this section describes how the automated testing works.
19.1 Jenkins CI
Our VyOS CI system is based on Jenkins and builds all our required packages for VyOS 1.2 to 1.4. In addition to
the package build, there is the vyos-build Job which builds and tests the VyOS ISO image which is published after a
successful test drive.
We differentiate in two independent tests, which are both run in parallel by two separate QEmu instances which are
launched via make test and make testc from within the vyos-build repository.
19.2 Smoketests
Smoketests executes predefined VyOS CLI commands and checks if the desired daemon/service configuration is rendert
- that is how to put it “short”.
When and ISO image is assembled by the VyOS CI, the BUILD_SMOKETEST parameter is enabled by default, which
will extend the ISO configuration line with the following packages:
So if you plan to build your own custom ISO image and want to make use of our smoketests, ensure that you have the
vyos-1x-smoketest package installed.
The make test command from the vyos-build repository will launch a new QEmu instance and the ISO image is first
installed to the virtual harddisk.
After its first boot into the newly installed system the main Smoketest script is executed, it can be found here:
/usr/bin/vyos-smoketest
The script only searches for executable “test-cases” under /usr/libexec/vyos/tests/smoke/cli/ and executes
them one by one.
1303
VyOS Documentation, Release 1.5.x (circinus)
Note: As Smoketests will alter the system configuration and you are logged in remote you may loose your connection
to the system.
Note: To enable smoketest debugging (print of the CLI set commands used) you can run: touch /tmp/vyos.
smoketest.debug.
On the other hand - as each test is contain in its own file - one can always execute a single Smoketest by hand by simply
running the Python test scripts.
Example:
vyos@vyos:~$ /usr/libexec/vyos/tests/smoke/cli/test_protocols_bgp.py
test_bgp_01_simple (__main__.TestProtocolsBGP) ... ok
test_bgp_02_neighbors (__main__.TestProtocolsBGP) ... ok
test_bgp_03_peer_groups (__main__.TestProtocolsBGP) ... ok
test_bgp_04_afi_ipv4 (__main__.TestProtocolsBGP) ... ok
test_bgp_05_afi_ipv6 (__main__.TestProtocolsBGP) ... ok
test_bgp_06_listen_range (__main__.TestProtocolsBGP) ... ok
test_bgp_07_l2vpn_evpn (__main__.TestProtocolsBGP) ... ok
test_bgp_08_zebra_route_map (__main__.TestProtocolsBGP) ... ok
test_bgp_09_distance_and_flowspec (__main__.TestProtocolsBGP) ... ok
test_bgp_10_vrf_simple (__main__.TestProtocolsBGP) ... ok
test_bgp_11_confederation (__main__.TestProtocolsBGP) ... ok
test_bgp_12_v6_link_local (__main__.TestProtocolsBGP) ... ok
test_bgp_13_solo (__main__.TestProtocolsBGP) ... ok
----------------------------------------------------------------------
Ran 13 tests in 348.191s
OK
Our smoketests not only test daemons and serives, but also check if what we configure for an interface works. Thus there
is a common base classed named: base_interfaces_test.py which holds all the common code that an interface
supports and is tested.
Those common tests consists out of:
• Add one or more IP addresses
• DHCP client and DHCPv6 prefix delegation
• MTU size
• IP and IPv6 options
• Port description
• Port disable
Note: When you are working on interface configuration and you also want to test if the Smoketests pass you would
normally loose the remote SSH connection to your DUT (Device Under Test). To handle this issue, some of the interface
based tests can be called with an environment variable beforehand to limit the number of interfaces used in the test. By
default all interface e.g. all Ethernet interfaces are used.
----------------------------------------------------------------------
Ran 23 tests in 244.694s
OK
This will limit the bond interface test to only make use of eth1 and eth2 as member ports.
The other part of our tests are called “config load tests”. The config load tests will load - one after another - arbitrary
configuration files to test if the configuration migration scripts work as designed and that a given set of functionality
still can be loaded with a fresh VyOS ISO image.
The configurations are all derived from production systems and can not only act as a testcase but also as reference if
one wants to enable a certain feature. The configurations can be found here: https://github.com/vyos/vyos-1x/tree/
current/smoketest/configs
The entire test is controlled by the main wrapper script /usr/bin/vyos-configtest which behaves in the same way
as the main smoketest script. It scans the folder for potential configuration files and issues a load command one after
another.
One is not bound to load all configurations one after another but can also load individual test configurations on his own.
vyos@vyos:~$ configure
load[edit]
vyos@vyos# commit
vyos@vyos#
Note: Some of the configurations have preconditions which need to be met. Those most likely include generation of
crypographic keys before the config can be applied - you will get a commit error otherwise. If you are interested how
those preconditions are fulfilled check the vyos-build repository and the scripts/check-qemu-install file.
TWENTY
WRITE DOCUMENTATION
We encourage every VyOS user to help us improve our documentation as we have a deficit like most software projects.
This not only helps you when reading but also everyone else.
If you are willing to contribute to our documentation this is the definite guide how to do so.
Note: In contrast to submitting code patches, there is no requirement that you open up a Phabricator task prior to
submitting a Pull-Request to the documentation.
VyOS documentation is written in reStructuredText and generated to Read the Docs pages with Sphinx, as per the
Python tradition. We welcome all sorts of contributions to the documentation. Not just new additions but also correc-
tions to existing documentation.
The documentation source is kept in the Git repository at https://github.com/vyos/vyos-documentation and you can
follow the instructions in the README.md to build and test your changes.
You can either install Sphinx and build the documentation locally, or use the Dockerfile to build it in a container.
20.1 Guidelines
There are a few things to keep in mind when contributing to the documentation, for the sake of consistency and read-
ability.
The following is a quick summary of the rules:
• Use American English at all times. It’s always a good idea to run your text through a grammar and spell checker,
such as Grammarly.
• Don’t forget to update index.rst when adding a new node.
• Try not to exceed 80 characters per line, but don’t break URLs over this.
• Properly quote commands, filenames and brief code snippets with double backticks.
• Use literal blocks for longer snippets.
• Leave a newline before and after a header.
• Indent with two spaces.
• When in doubt, follow the style of existing documentation.
And finally, remember that the reStructuredText files aren’t exclusively for generating HTML and PDF. They should be
human-readable and easily perused from a console.
1307
VyOS Documentation, Release 1.5.x (circinus)
All RST files must follow the same TOC Level syntax and have to start with
#####
Title
#####
The configuration mode folder and the articles cover the specific level of the commands. The exact level depends on
the command. This should provide stability for URLs used in the forum or blogpost.
For example:
• set firewall zone is written in firewall/zone.rst
• set interfaces ethernet is written in interfaces/ethernet.rst
In the configuration part of the page, all possible configuration options should be documented. Use .. cfgcmd::
described above.
Related operation command must be documented in the next part of the article. Use ::opcmd.. for these commands.
Each page must contain the following parts:
Theoretical information required for users to understand the next document sections:
• a simple explanation of what is this page about, why or when it is required to be used
• references to standards, RFCs
Describe CLI items related to the service or use case. Each config line or section must be explained, using
information provided in the 1st part of the page.
Practical examples of the service or use case configuration. They must contain topology maps (if applica-
ble) and short descriptions.
20.2.5 5. Debugging
TOC Level
#####
Title
#####
********
Chapters
********
Sections
========
Subsections
-----------
Subsubsections
^^^^^^^^^^^^^^
Paragraphs
""""""""""
Cross-References
A plugin will be used to generate a reference label for each headline. To reference a page or a section in the documen-
tation use the :ref: command.
For example, you want to reference the headline VLAN in the ethernet.rst page. The plugin generates the label based
on the headline and the file path.
:ref:`configuration/interfaces/ethernet:vlan
to use an alternative hyperlink use it this way:
:ref:`Check out VLAN<configuration/interfaces/ethernet:vlan>
The plugin will warn on build if a headline has a duplicate name in the same document. To prevent this warning, you
have to put a custom link on top of the headline.
Section A
==========
Example
-------
Section B
==========
.. _section B example:
Example
-------
Address space
Note the following RFCs (RFC 5737, RFC 3849, RFC 5389 and RFC 7042), which describe the reserved public IP
addresses and autonomous system numbers for the documentation:
• 192.0.2.0/24
• 198.51.100.0/24
• 203.0.113.0/24
• 2001:db8::/32
• 16bit ASN: 64496 - 64511
• 32bit ASN: 65536 - 65551
• Unicast MAC Addresses: 00-53-00 to 00-53-FF
• Multicast MAC-Addresses: 90-10-00 to 90-10-FF
Please do not use other public address space.
Line length
Autolinter
Each GitHub pull request is automatically linted to check the address space and line length.
Sometimes it is necessary to provide real IP addresses like in the Configuration Blueprints. For this, please use the
sphinx comment syntax .. stop_vyoslinter to stop the linter and .. start_vyoslinter to start.
Custom commands have been developed for writing the documentation. Please make yourself comfortable with those
commands as this eases the way we render the documentation.
cfgcmd
When documenting CLI commands, use the .. cfgcmd:: directive for all configuration mode commands. An expla-
nation of the described command should be added below this statement. Replace all variable contents with <value> or
something similar.
With those custom commands, it will be possible to render them in a more descriptive way in the resulting HTML/PDF
manual.
To extract a defaultvalue from the XML definitions add a :defaultvalue: to .. cfgcmd:: directive. To have this
feature locally, the vyos-1x submodule must be initialized before. Please be aware to not update the submodule in your
PR.
The connection tracking table contains one entry for each connection being
tracked by the system.
opcmd
When documenting operational level commands, use the .. opcmd:: directive. An explanation of the described
command should be added below this statement.
With those custom commands, it is possible to render them in a more descriptive way in the resulting HTML/PDF
manual.
Display all known ARP table entries spanning across all interfaces
cmdinclude
To minimize redundancy, there is a special include directive. It includes a txt file and replace the {{ var0 }} - {{
var9 }} with the correct value.
.. cmdinclude:: /_include/interface-address.txt
:var0: ethernet
:var1: eth1
Example:
.. code-block:: none
vytask
When referencing to VyOS Phabricator Tasks, there is a custom Sphinx Markup command called vytask that auto-
matically renders to a proper Phabricator URL. This is heavily used in the Changelog section.
The Forking Workflow is fundamentally different from other popular Git workflows. Instead of using a single server-
side repository to act as the “central” codebase, it gives every developer their own server-side repository. This means
that each contributor has not one, but two Git repositories: a private local one and a public server-side one.
The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to
push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer
can push to the official repository. This allows the maintainer to accept commits from any developer without giving
them write access to the official codebase.
Note: Updates to our documentation should be delivered by a GitHub pull-request. This requires you already have a
GitHub account.
• Once pull requests have been approved, you may want to locally update your forked repository too. First
you’ll have to add a second remote called upstream which points to our main repository. $ git remote add
upstream https://github.com/vyos/vyos-documentation.git
Check your configured remote repositories:
$ git remote -v
origin https://github.com/<username>/vyos-documentation.git (fetch)
origin https://github.com/<username>/vyos.documentation.git (push)
upstream https://github.com/vyos/vyos-documentation.git (fetch)
upstream https://github.com/vyos/vyos-documentation.git (push)
Your remote repo on Github is called origin, while the original repo you have forked is called upstream. Now
you can locally update your forked repo.
• If you also want to update your fork on GitHub, use the following: $ git push origin current
TWENTYONE
COVERAGE
Overview over all commands, which are documented in the .. cfgcmd:: or .. opcmd:: Directives.
The build process take all xml definition files from vyos-1x and a periodical export of all VyOS commands and extract
each leaf command or executable command. After this the commands are compare and shown in the following two
tables. The script compare only the fixed part of a command. All varables or values will be erase and then compare:
for example there are these two commands:
• documentation: interfaces ethernet <interface> address <address | dhcp | dhcpv6>
• xml: interfaces ethernet <ethernet> address <address>
• VyOS: interfaces ethernet <text> address <value>
Now the script earse all in between < and > and simply compare the strings.
There are 3 kind of problems:
Not documented yet
• A XML command are not found in .. cfgcmd:: or .. opcmd:: Commands
• The command should be documented
Nothing found in XML Definitions
• .. cfgcmd:: or .. opcmd:: Command are not found in a XML command
• Maybe the command where changed in the XML Definition, the feature is not anymore in VyOS, or there is a
typo
Nothing found in VyOS
• .. cfgcmd:: or .. opcmd:: Command are not found in a VyOS command
• Maybe the command where changed, the feature is not anymore in VyOS, or there is a typo
1315
VyOS Documentation, Release 1.5.x (circinus)