开源网络操作系统--VyOS

User Guide

Jump to: navigation, search

Contents

• 1 Introduction
• 2 Installation
• 3 Using the Command-Line Interface
• 4 Quick Start Guide
• 5 Configuration
• 5.1 Network Interfaces
• 5.1.1 Physical Ethernet Interfaces
• 5.1.2 802.1Q VLAN Interfaces
• 5.1.3 Bridging
• 5.1.4 Bonding
• 5.1.5 Tunnel Interfaces
• 5.2 Routing
• 5.2.1 Static
• 5.2.2 RIP
• 5.2.3 OSPF
• 5.2.4 BGP
• 5.2.4.1 IPv4
• 5.2.4.2 IPv6
• 5.2.4.3 Route-map
• 5.2.5 Route Redistribution and Policy Engine
• 5.3 Firewall
• 5.3.1 Groups
• 5.3.2 Rule-Sets
• 5.3.3 Applying a Rule-Set to an Interface
• 5.3.4 Applying a Rule-Set to a Zone
• 5.3.5 Zone-based Firewall Policy
• 5.4 NAT
• 5.4.1 Source NAT
• 5.4.2 Destination NAT
• 5.4.3 1-to-1 NAT
• 5.4.3.1 1-to-1 NAT example
• 5.4.4 NPTv6 (RFC6296)
• 5.5 VPN
• 5.6 Traffic Policy
• 5.7 DHCP Server
• 5.8 DHCP Relay
• 5.9 DNS Forwarder
• 5.10 Dynamic DNS Updater
• 5.11 System Configuration
• 5.11.1 System Users
• 5.11.1.1 Creating Login User Accounts
• 5.11.1.2 Configuring for SSH Access using Shared Public Keys
• 5.12 IPv6
• 6 System Image Management

The VyOS User Guide is focused on providing a general overview of the installation, configuration, and operation of the VyOS network operating system.

Introduction

VyOS is a Linux-based network operating system that provides software-based network routing, firewall, and VPN functionality.

The VyOS project was started in late 2013 as a community fork of the GPL portions of Vyatta Core 6.6R1 with the goal of maintaining a free and open source network operating system in response to the decision to discontinue the community edition of Vyatta.

VyOS is primarily based on Debian GNU/Linux and the Quagga routing engine. Its configuration syntax and command-line interface are loosely derived from Juniper JUNOS as modeled by the XORP project (which was the original routing engine Vyatta was based upon). Vyatta changed to the Quagga routing engine for release 4.0.

Installation

The latest ISO image for VyOS can be downloaded at www.vyos.net.

The recommended system requirements are 512MB RAM and 2GB storage.

The VyOS ISO is a Live CD and will boot to a functional VyOS image. To login to the system, use the default username:password of: vyos:vyos

Linux vyatta 3.3.8-1-amd64-vyatta #1 SMP Wed Oct 30 22:54:40 CET 2013 x86_64

Welcome to VyOS.

This system is open-source software. The exact distribution terms for

each module comprising the full system are described in the individual

files in /usr/share/doc/*/copyright.

Last login: Wed Dec 11 17:33:09 2013

vyos@vyos:~$

There are two installation options: install image and install system.

The system install mirrors a traditional Linux installation and installs VyOS on the storage device selected.

The image install is the recommended installation method for VyOS. Using the image-based install, each VyOS release is self-contained within a directory on the selected storage device. Allowing multiple images to be installed on the same system, providing a predictable environment upon boot, and allowing for the quick rollback of an upgrade to a new release.

Typing either command will initiate the appropriate installer:

vyos@vyos:~$ install image

Welcome to the VyOS install program.  This script

will walk you through the process of installing the

VyOS image to a local hard drive.

Would you like to continue? (Yes/No) [Yes]: [return]

Probing drives: OK

Looking for pre-existing RAID groups...none found.

The VyOS image will require a minimum 1000MB root.

Would you like me to try to partition a drive automatically

or would you rather partition it manually with parted?  If

you have already setup your partitions, you may skip this step

Partition (Auto/Parted/Skip) [Auto]: [return]

I found the following drives on your system:

sda  2147MB

Install the image on? [sda]: [return]

This will destroy all data on /dev/sda.

Continue? (Yes/No) [No]: Yes

How big of a root partition should I create? (1000MB - 2147MB) [2147]MB: [return]

Creating filesystem on /dev/sda1: OK

Done!

Mounting /dev/sda1...

What would you like to name this image? [VyOS_999.hydrogen.11291501]:

OK.  This image will be named: VyOS_999.hydrogen.11291501

Copying squashfs image...

Copying kernel and initrd images...

Done!

I found the following configuration files:

/config/config.boot

/opt/vyatta/etc/config.boot.default

Which one should I copy to sda? [/config/config.boot]: [return]

Copying /config/config.boot to sda.

Enter password for administrator account

Enter password for user 'vyos': <removed>

Retype password for user 'vyos': <removed>

I need to install the GRUB boot loader.

I found the following drives on your system:

sda  2147MB

Which drive should GRUB modify the boot partition on? [sda]: [return]

Setting up grub: OK

Done!

vyos@vyos:~$

After the installation is complete, remove the Live CD and reboot the system:

vyos@vyos:~$ reboot

Proceed with reboot? (Yes/No) [No] Yes

vyos@vyos:~$

Using the Command-Line Interface

The VyOS CLI is comprised of an operational mode 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

vyos@vyos:~$

Example showing possible show commands:

vyos@vyos:~$ show [tab]

Possible completions:

arp           Show Address Resolution Protocol (ARP) information

bridge        Show bridging information

cluster       Show clustering information

configuration Show running configuration

conntrack     Show conntrack entries in the conntrack table

conntrack-sync

Show connection syncing information

date          Show system date and time

dhcp          Show Dynamic Host Configuration Protocol (DHCP) information

dhcpv6        Show status related to DHCPv6

disk          Show status of disk device

dns           Show Domain Name Server (DNS) information

file          Show files for a particular image

firewall      Show firewall information

flow-accounting

Show flow accounting statistics

hardware      Show system hardware details

history       show command history

host          Show host information

incoming      Show ethernet input-policy information

: q

vyos@vyos:~$

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.

To enter configuration mode use the configure command:

vyos@vyos:~$ configure

[edit]

vyos@vyos:~#

Note that the prompt changes from $ to #. To exit configuration mode, type exit.

vyos@vyos:~# exit

exit

vyos@vyos:~$

See the configuration section of this document for more information on configuration mode.

Quick Start Guide

Below is a very basic configuration example that will provide a NAT gateway for a device with two interfaces.

Enter configuration mode:

vyos@vyos$ configure

vyos@vyos#

Configure network interfaces:

set interfaces ethernet eth0 address dhcp

set interfaces ethernet eth0 description 'OUTSIDE'

set interfaces ethernet eth1 address '192.168.0.1/24'

set interfaces ethernet eth1 description 'INSIDE'

Enable SSH for remote management:

set service ssh port '22'

Configure Source NAT for our "Inside" network.

set nat source rule 100 outbound-interface 'eth0'

set nat source rule 100 source address '192.168.0.0/24'

set nat source rule 100 translation address masquerade

Configure a DHCP Server:

set service dhcp-server disabled 'false'

set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 default-router '192.168.0.1'

set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 dns-server '192.168.0.1'

set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 domain-name 'internal-network'

set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 lease '86400'

set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 start 192.168.0.9 stop '192.168.0.254'

And a DNS forwarder:

set service dns forwarding cache-size '0'

set service dns forwarding listen-on 'eth1'

set service dns forwarding name-server '8.8.8.8'

set service dns forwarding name-server '8.8.4.4'

Add a set of firewall policies for our "Outside" interface:

set firewall name OUTSIDE-IN default-action 'drop'

set firewall name OUTSIDE-IN rule 10 action 'accept'

set firewall name OUTSIDE-IN rule 10 state established 'enable'

set firewall name OUTSIDE-IN rule 10 state related 'enable'

set firewall name OUTSIDE-LOCAL default-action 'drop'

set firewall name OUTSIDE-LOCAL rule 10 action 'accept'

set firewall name OUTSIDE-LOCAL rule 10 state established 'enable'

set firewall name OUTSIDE-LOCAL rule 10 state related 'enable'

set firewall name OUTSIDE-LOCAL rule 20 action 'accept'

set firewall name OUTSIDE-LOCAL rule 20 icmp type-name 'echo-request'

set firewall name OUTSIDE-LOCAL rule 20 protocol 'icmp'

set firewall name OUTSIDE-LOCAL rule 20 state new 'enable'

set firewall name OUTSIDE-LOCAL rule 30 action 'drop'

set firewall name OUTSIDE-LOCAL rule 30 destination port '22'

set firewall name OUTSIDE-LOCAL rule 30 protocol 'tcp'

set firewall name OUTSIDE-LOCAL rule 30 recent count '4'

set firewall name OUTSIDE-LOCAL rule 30 recent time '60'

set firewall name OUTSIDE-LOCAL rule 30 state new 'enable'

set firewall name OUTSIDE-LOCAL rule 31 action 'accept'

set firewall name OUTSIDE-LOCAL rule 31 destination port '22'

set firewall name OUTSIDE-LOCAL rule 31 protocol 'tcp'

set firewall name OUTSIDE-LOCAL rule 31 state new 'enable'

Apply the firewall policies:

set interfaces ethernet eth0 firewall in name 'OUTSIDE-IN'

set interfaces ethernet eth0 firewall local name 'OUTSIDE-LOCAL'

Commit 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$

Configuration

VyOS makes use of a unified configuration file for all system configuration: config.boot. This allows for easy template creation, backup, and replication of system configuration.

The current configuration can be viewed using the show configuration command.

vyos@vyos:~$  show configuration

interfaces {

ethernet eth0 {

address dhcp

hw-id 00:0c:29:44:3b:0f

}

loopback lo {

}

}

service {

ssh {

port 22

}

}

system {

config-management {

commit-revisions 20

}

console {

device ttyS0 {

speed 9600

}

}

login {

user vyos {

authentication {

encrypted-password ****************

}

level admin

}

}

ntp {

server 0.pool.ntp.org {

}

server 1.pool.ntp.org {

}

server 2.pool.ntp.org {

}

}

package {

repository community {

components main

distribution hydrogen

url http://packages.vyos.net/vyos

}

}

syslog {

global {

facility all {

level notice

}

facility protocols {

level debug

}

}

}

}

vyos@vyos:~$

Because configuration changes are made using set and delete commands, the commands to generate the active configuration can also be displayed using the show configuration commands command.

vyos@vyos:~$ show configuration commands

set interfaces ethernet eth0 address 'dhcp'

set interfaces ethernet eth0 hw-id '00:0c:29:44:3b:0f'

set interfaces loopback 'lo'

set service ssh port '22'

set system config-management commit-revisions '20'

set system console device ttyS0 speed '9600'

set system login user vyos authentication encrypted-password '<removed>'

set system login user vyos level 'admin'

set system ntp server '0.pool.ntp.org'

set system ntp server '1.pool.ntp.org'

set system ntp server '2.pool.ntp.org'

set system package repository community components 'main'

set system package repository community distribution 'stable'

set system package repository community url 'http://packages.vyos.net/vyos'

set system syslog global facility all level 'notice'

set system syslog global facility protocols level 'debug'

vyos@vyos:~$

Configuration changes made do 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.

exit

vyos@vyos:~$

In order to preserve configuration changes upon reboot, the configuration must also be saved once applied. This is done using the save command in configuration mode.

vyos@vyos# save

Saving configuration to '/config/config.boot'...

Done

[edit]

vyos@vyos#

The show command within configuration mode will show the current configuration indicating line changes with a + for additions and a - for deletions.

vyos@vyos:~$ configure

[edit]

vyos@vyos# show interfaces

ethernet eth0 {

address dhcp

hw-id 00:0c:29:44:3b:0f

}

loopback lo {

}

[edit]

vyos@vyos# set interfaces ethernet eth0 description 'OUTSIDE'

[edit]

vyos@vyos# show interfaces

ethernet eth0 {

address dhcp

+    description OUTSIDE

hw-id 00:0c:29:44:3b:0f

}

loopback lo {

}

[edit]

vyos@vyos#

Configuration mode can not be exited while uncommitted changes exist. To exit configuration mode without applying changes, the exit discard command can be used.

vyos@vyos# exit

Cannot exit: configuration modified.

Use 'exit discard' to discard the changes and exit.

[edit]

vyos@vyos# exit discard

exit

vyos@vyos:~$

VyOS also maintains backups of previous configurations. To compare configuration revisions in configuration mode, use the compare command:

vyos@vyos# compare [tab]

Possible completions:

<Enter>      Compare working & active configurations

saved        Compare working & saved configurations

<N>          Compare working with revision N

<N> <M>      Compare revision N with M

Revisions:

0   2013-12-17 20:01:37 root by boot-config-loader

1   2013-12-13 15:59:31 root by boot-config-loader

2   2013-12-12 21:56:22 vyos by cli

3   2013-12-12 21:55:11 vyos by cli

4   2013-12-12 21:27:54 vyos by cli

5   2013-12-12 21:23:29 vyos by cli

6   2013-12-12 21:13:59 root by boot-config-loader

7   2013-12-12 16:25:19 vyos by cli

8   2013-12-12 15:44:36 vyos by cli

9   2013-12-12 15:42:07 root by boot-config-loader

10  2013-12-12 15:42:06 root by init

[edit]

vyos@vyos#

You can rollback configuration using the rollback command, however this command will currently trigger a system 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!

[edit]

vyos@vyos#

VyOS also supports saving and loading configuration remotely using SCP, FTP, or
TFTP.

vyos@vyos# save [tab]

Possible completions:

<Enter>       Save to system
config file

<file>        Save to file on local machine

scp://<user>:<passwd>@<host>/<file> Save to file
on remote machine

ftp://<user>:<passwd>@<host>/<file>
Save to file on remote machine

tftp://<host>/<file>      Save to file on remote machine

vyos@vyos# save
tftp://192.168.0.100/vyos-test.config.boot

Saving configuration to
'tftp://192.168.0.100/vyos-test.config.boot'...

########################################################################
100.0%

Done

Network Interfaces

Configured interfaces on a VyOS system can be displayed using the show
interfaces command.

vyos@vyos:~$ show interfaces

Codes: S - State, L - Link, u - Up, D - Down, A - Admin
Down

Interface        IP
Address                        S/L 
Description

---------       
----------                       
---  -----------

eth0            
172.16.51.129/24                 
u/u  OUTSIDE

eth1            
192.168.0.1/24                   
u/u  INSIDE

lo              
127.0.0.1/8                       u/u

::1/128

vyos@vyos:~$

A specific interface can be shown using the show interfaces
<type> <name> command.

vyos@vyos:~$ show interfaces ethernet eth0

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc pfifo_fast state UP qlen 1000

link/ether
00:0c:29:44:3b:0f brd ff:ff:ff:ff:ff:ff

inet
172.16.51.129/24 brd 172.16.51.255 scope global eth0

inet6
fe80::20c:29ff:fe44:3b0f/64 scope link

valid_lft
forever preferred_lft forever

Description:
OUTSIDE

RX:  bytes   
packets     errors    dropped   
overrun      mcast

274397       3064          0          0          0          0

TX:  bytes   
packets     errors    dropped   
carrier collisions

257276       1890          0          0          0          0

vyos@vyos:~$

Each interface can be configured with a description and address.

set interfaces ethernet eth0 description 'OUTSIDE'

set interfaces ethernet eth0 address 'dhcp'

Different network interfaces provide type-specific configuration. Ethernet
interfaces, for example, allow the configuration of speed and duplex.

Many services, such as network routing, firewall, and traffic policy also
maintain interface-specific configuration. These will be covered in their
respective sections.

Physical Ethernet Interfaces

Ethernet interfaces allow for the configuration of speed, duplex, and
hw-id (MAC address). Below is an example configuration:

set interfaces ethernet eth1 address '192.168.0.1/24'

set interfaces ethernet eth1 description 'INSIDE'

set interfaces ethernet eth1 duplex 'auto'

set interfaces ethernet eth1 speed 'auto'

Resulting in:

ethernet eth1 {

address
192.168.0.1/24

description
INSIDE

duplex auto

hw-id
00:0c:29:44:3b:19

smp_affinity
auto

speed auto

}

In addition, Ethernet interfaces provide the extended operational commands
show interfaces ethernet <name> physical and show interfaces
ethernet <name> statistics. Statistics available are driver
dependent.

vyos@vyos:~$ show interfaces ethernet eth0 physical

Settings for eth0:

Supported
ports: [ TP ]

Supported
link modes:   10baseT/Half 10baseT/Full

100baseT/Half
100baseT/Full

1000baseT/Full

Supports
auto-negotiation: Yes

Advertised
link modes:  10baseT/Half 10baseT/Full

100baseT/Half
100baseT/Full

1000baseT/Full

Advertised
pause frame use: No

Advertised auto-negotiation:
Yes

Speed:
1000Mb/s

Duplex:
Full

Port:
Twisted Pair

PHYAD: 0

Transceiver: internal

Auto-negotiation: on

MDI-X:
Unknown

Supports
Wake-on: d

Wake-on: d

Current message
level: 0x00000007 (7)

Link
detected: yes

driver: e1000

version: 7.3.21-k8-NAPI

firmware-version:

bus-info: 0000:02:01.0

vyos@vyos:~$

vyos@vyos:~$ show interfaces ethernet eth0 statistics

NIC statistics:

rx_packets:
3530

tx_packets:
2179

[...]

802.1Q VLAN Interfaces

802.1Q VLAN interfaces are represented as virtual sub-interfaces in VyOS.
The term used for this is vif. Configuration of a tagged sub-interface
is accomplished using the configuration command set interfaces ethernet
<name> vif <vlan-id>.

set interfaces ethernet eth1 vif 100 description 'VLAN
100'

set interfaces ethernet eth1 vif 100 address
'192.168.100.1/24'

Resulting:

ethernet eth1 {

address
192.168.0.1/24

description
INSIDE

duplex auto

hw-id 00:0c:29:44:3b:19

smp_affinity
auto

speed auto

vif 100 {

address
192.168.100.1/24

description "VLAN 100"

}

}

VLAN interfaces are shown as <name>.<vlan-id>, e.g. eth1.100:

vyos@vyos:~$ show interfaces

Codes: S - State, L - Link, u - Up, D - Down, A - Admin
Down

Interface        IP
Address                        S/L  Description

---------       
----------                       
---  -----------

eth0            
172.16.51.129/24                  u/u 
OUTSIDE

eth1            
192.168.0.1/24                   
u/u  INSIDE

eth1.100        
192.168.100.1/24                 
u/u  VLAN 100

lo              
127.0.0.1/8                      
u/u

::1/128

vyos@vyos:~$

Bridging

Interfaces in VyOS can be bridged together to provide software switching
of Layer-2 traffic.

A bridge is created when a bridge interface is defined. In the example
below we will be creating a bridge for VLAN 100 and assigning a VIF to the
bridge.

set interfaces bridge 'br100'

set interfaces ethernet eth1 vif 100 bridge-group bridge
br100

Interfaces assigned to a bridge-group do not have address configuration.
An IP address can be assigned to the bridge interface itself, however, like any
normal interface.

set interfaces bridge br100 address '192.168.100.1/24'

Example Result:

bridge br100 {

address
192.168.100.1/24

}

[...]

ethernet eth1 {

[...]

vif 100 {

bridge-group {

bridge br100

}

}

}

In addition to normal IP interface configuration, bridge interfaces
support Spanning-Tree Protocol. STP is disabled by default.

NOTE: Please use caution when
introducing spanning-tree protocol on a network as it may result in topology
changes.

To enable spanning-tree use the set interfaces bridge <name> stp
true command:

set interfaces bridge br100 stp true

STP priority, forwarding-delay, hello-time, and max-age
can be configured for the bridge-group. The MAC aging time can also be
configured using the aging directive.

For member interfaces, the bridge-group priority and cost
can be configured.

The show bridge operational command can be used to display
configured bridges:

vyos@vyos:~$ show bridge

bridge name    
bridge id               STP
enabled     interfaces

br100          
0000.000c29443b19       yes             eth1.100

vyos@vyos:~$

If spanning-tree is enabled, the show bridge <name> spanning-tree
command can be used to show STP configuration:

vyos@vyos:~$ show bridge br100 spanning-tree

br100

bridge id              0000.000c29443b19

designated
root        0000.000c29443b19

root port                 0                    path cost                  0

max age                  20.00                 bridge max age            20.00

hello time                2.00                 bridge hello time          2.00

forward delay            15.00                 bridge forward delay      15.00

ageing time             300.00

hello timer               0.47                 tcn timer                  0.00

topology change
timer     0.00                 gc timer                  64.63

flags

eth1.100 (1)

port id                8001                    state                forwarding

designated
root        0000.000c29443b19       path cost                  4

designated
bridge      0000.000c29443b19       message age timer          0.00

designated
port        8001                    forward delay timer        0.00

designated
cost           0                    hold timer                 0.00

flags

vyos@vyos:~$

The MAC address-table for a bridge can be displayed using the show
bridge <name> macs command:

vyos@vyos:~$ show bridge br100 macs

port no mac addr                is local?       ageing timer

1     00:0c:29:44:3b:19       yes                0.00

vyos@vyos:~$

Bonding

You can combine (aggregate) 2 or more physical interfaces into a single
logical one. It's called bonding, or LAG, or etherchannel, or portchannel.

Create interface bondX, where X is just a number:

set interfaces bonding bond0 description 'my-sw1 int 23
and 24'

You are able to choose a hash policy:

vyos@vyos# set interfaces bonding bond0 hash-policy

Possible completions:

layer2       use MAC addresses to generate the hash
(802.3ad)

layer2+3     combine MAC address and IP address to make
hash

layer3+4     combine IP address and port to make hash

For example:

set interfaces bonding bond0 hash-policy 'layer2'

You may want to set IEEE 802.3ad Dynamic link aggregation (802.3ad) AKA
LACP (don't forget to setup it on the other end of these links):

set interfaces bonding bond0 mode '802.3ad'

or some other modes:

vyos@vyos# set interfaces bonding bond0 mode

Possible completions:

802.3ad      IEEE 802.3ad Dynamic link aggregation
(Default)

active-backup

Fault tolerant: only one slave in the bond is active

broadcast    Fault tolerant: transmits everything on all
slave interfaces

round-robin  Load balance: transmit packets in sequential
order

transmit-load-balance

Load balance: adapts based on
transmit load and speed

adaptive-load-balance

Load
balance: adapts based on transmit and receive plus ARP

xor-hash     Load balance: distribute based on MAC
address

Now bond some physical interfaces into bond0:

set interfaces ethernet eth0 bond-group 'bond0'

set interfaces ethernet eth0 description 'member of
bond0'

set interfaces ethernet eth1 bond-group 'bond0'

set interfaces ethernet eth1 description 'member of
bond0'

After a commit you may treat bond0 as almost a physical interface (you
can't change its` duplex, for example) and assign IPs or VIFs on it.

You may check the result:

vyos@vyos# run sh interfaces bonding

Codes: S - State, L - Link, u - Up, D - Down, A - Admin
Down

Interface        IP
Address                        S/L  Description

---------       
----------                       
---  -----------

bond0           
-                                
u/u  my-sw1 int 23 and 24

bond0.10        
192.168.0.1/24                   
u/u  office-net

bond0.100       
10.10.10.1/24                    
u/u  management-net

Tunnel Interfaces

Set Virtual Tunnel interface

set interfaces vti vti0 address 192.168.2.249/30

vyos@vyos# show interfaces vti

vti vti0 {

address
192.168.2.249/30

description
"Description"

}

[edit]

Routing

Routing is simple sending a packet from one network to another.

Static

Static routes are manually configured network routes.

A typical use for a static route is a static default route for systems
that do not make use of DHCP or dynamic routing protocols:

set protocols static route 0.0.0.0/0 next-hop 203.0.113.1
distance '1'

Producing the following configuration:

static {

route 0.0.0.0/0
{

next-hop
203.0.113.1 {

distance 1

}

}

}

Another common use of static routes is to blackhole (drop) traffic. In the
example below, RFC 1918
private IP networks are set as blackhole routes. This does not prevent networks
within these segments from being used, since the most specific route is always
used. It does, however, prevent traffic to unknown private networks from
leaving the router. Commonly refereed to as leaking.

set protocols static route 10.0.0.0/8 blackhole distance
'254'

set protocols static route 172.16.0.0/12 blackhole
distance '254'

set protocols static route 192.168.0.0/16 blackhole
distance '254'

Resulting configuration:

route 10.0.0.0/8 {

blackhole {

distance
254

}

}

route 172.16.0.0/12 {

blackhole {

distance 254

}

}

route 192.168.0.0/16 {

blackhole {

distance
254

}

}

Note that routes with a distance of 255 are effectively disabled and not
installed into the kernel.

RIP

Simple RIP configuration using 2 nodes and redistributing connected
interfaces.

Node 1:

set interfaces loopback address 1.1.1.1/32

set protocols rip network 192.168.0.0/24

set protocols rip redistribute connected

Node 2:

set interfaces loopback address 2.2.2.2/32

set protocols rip network 192.168.0.0/24

set protocols rip redistribute connected

Resulting configuration:

Node 1:

rip{

    network
192.168.1.0/24

    redistribute {

      connected {

        }

    }

}

Node 2:

rip{

    network
192.168.1.0/24

    redistribute {

      connected {

        }

    }

}

OSPF

A typical configuration using 2 nodes, redistribute loopback address and
the node 1 sending the default route:

Node 1:

set interfaces loopback lo address 1.1.1.1/32

set protocols ospf area 0 network 192.168.0.0/24

set protocols ospf default-information originate always

set protocols ospf default-information originate metric
10

set protocols ospf default-information originate
metric-type 2

set protocols ospf log-adjacency-changes

set protocols ospf parameters router-id 1.1.1.1

set protocols ospf redistribute connected metric-type 2

set protocols ospf redistribute connected route-map
CONNECT

set policy route-map CONNECT rule 10 action permit

set policy route-map CONNECT rule 10 match interface lo

Node 2:

set interfaces loopback lo address 2.2.2.2/32

set protocols ospf area 0 network 192.168.0.0/24

set protocols ospf log-adjacency-changes

set protocols ospf parameters router-id 2.2.2.2

set protocols ospf redistribute connected metric-type 2

set protocols ospf redistribute connected route-map
CONNECT

set policy route-map CONNECT rule 10 action permit

set policy route-map CONNECT rule 10 match interface lo

Resulting configuration:

Node 1:

ospf {

    area 0 {

         network
192.168.0.0/24

     }

    
default-information {

         originate
{

             always

             metric
10

            
metric-type 2

         }

     }

    
log-adjacency-changes {

     }

     parameters {

         router-id
1.1.1.1

     }

     redistribute {

         connected
{

             metric-type 2

            
route-map CONNECT

         }

     }

 } 

route-map CONNECT {

    rule 10 {

        action
permit

        match {

          
interface lo

       }

  }

 }

Node 2:

ospf {

    area 0 {

         network
192.168.0.0/24

     }

    
log-adjacency-changes {

     }

     parameters {

         router-id
2.2.2.2

     }

     redistribute {

         connected
{

            
metric-type 2

            
route-map CONNECT

         }

     }

 } 

route-map CONNECT {

    rule 10 {

        action
permit

        match {

          
interface lo

       }

  }

 }

BGP

IPv4

A simple eBGP configuration:

Node 1:

set protocols bgp 65536 neighbor 192.168.0.2
ebgp-multihop '2'

set protocols bgp 65536 neighbor 192.168.0.2 remote-as '65537'

set protocols bgp 65536 neighbor 192.168.0.2
update-source ‘192.168.0.1

set protocols bgp 65536 network '1.0.0.0/16'

set protocols bgp 65536 parameters router-id ‘192.168.0.1

Node 2:

set protocols bgp 65537 neighbor 192.168.0.1
ebgp-multihop '2'

set protocols bgp 65537 neighbor 192.168.0.1 remote-as
'65536’

set protocols bgp 65537 neighbor 192.168.0.1
update-source ‘192.168.0.2

set protocols bgp 65537 network 2.0.0.0/16'

set protocols bgp 65537 parameters router-id ‘192.168.0.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:

set protocols static route 1.0.0.0/16 blackhole distance
'254'

Node 2:

set protocols static route 2.0.0.0/16 blackhole distance
'254'

Resulting configuration:

Node 1:

bgp 65536 {

     neighbor
192.168.0.2 {

        
ebgp-multihop 2

         remote-as
65537

        
update-source 192.168.0.1

     }

     network
1.0.0.0/16 {

     }

     parameters {

         router-id
192.168.0.1

     }

 }

static {

     route
1.0.0.0/16 {

        blackhole {

           distance
254

         }

     }

Node 2:

bgp 65537 {

     neighbor
192.168.0.1 {

        
ebgp-multihop 2

         remote-as 65536

        
update-source 192.168.0.2

     }

     network
2.0.0.0/16 {

     }

     parameters {

         router-id
192.168.0.2

     }

 }

static {

     route
2.0.0.0/16 {

        blackhole {

           distance
254

         }

     }

IPv6

A simple BGP configuration, but over IPv6.

Node 1:

set protocols bgp 65536 neighbor 2a00:100::2
ebgp-multihop '2'

set protocols bgp 65536 neighbor 2a00:100::2 remote-as
'65537'

set protocols bgp 65536 neighbor 2a00:100::2 update-source
‘2a00:100::1

set protocols bgp 65536 neighbor 2a00:100::2
address-family ipv6-unicast

set protocols bgp 65536 address-family ipv6-unicast
network '2a00:100:1::/48'

set protocols bgp 65536 parameters router-id ‘2a00:100::1

Node 2:

set protocols bgp 65537 neighbor 2a00:100::1
ebgp-multihop '2'

set protocols bgp 65537 neighbor 2a00:100::1 remote-as
'65536’

set protocols bgp 65537 neighbor 2a00:100::1
update-source ‘2a00:100::2

set protocols bgp 65536 neighbor 2a00:100::1
address-family ipv6-unicast

set protocols bgp 65537 address-family ipv6-unicast
network '2a00:100:2::/48'

set protocols bgp 65537 parameters router-id ‘2a00:100::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:

set protocols static route6 2a001:100:1::/48 blackhole
distance '254'

Node 2:

set protocols static route6 2a00:100:2::/48 blackhole
distance '254'

Resulting configuration:

Node 1:

bgp 65536 {

     neighbor
2a00:100::2 {

        
address-family {

            
ipv6-unicast {

            }

         }

        
ebgp-multihop 2

         remote-as
65537

        
update-source 2a00:100::1

     }

     network
2a00:100:1::/48 {

     }

     parameters {

         router-id
2a00:100::1

     }

 }

static {

     route6
2a00:100:1::/48 {

        blackhole {

           distance
254

         }

     }

Node 2:

bgp 65537 {

     neighbor
2a00:100::1 {

        
address-family {

             ipv6-unicast {

            }

         }

        
ebgp-multihop 2

         remote-as
65536

        
update-source 2a00:100::2

     }

     network
2a00:100:2::/48 {

     }

     parameters {

         router-id
2a00:100::2

     }

 }

static {

     route6
2a00:100:2::/48 {

        blackhole {

           distance
254

         }

     }

Route-map

If you also want remote-map this is fairly simple to implement.

Node1:

set policy prefix-list AS65537-IN rule 10 action 'permit'

set policy prefix-list AS65537-IN rule 10 prefix
'2.0.0.0/16'

set policy prefix-list AS65537-OUT rule 10 action 'deny'

set policy prefix-list AS65537-OUT rule 10 prefix
'2.0.0.0/16'

set policy prefix-list6 AS65537-IN rule 10 action
'permit'

set policy prefix-list6 AS65537-IN rule 10 prefix
'2a00:100:2::/48'

set policy prefix-list6 AS65537-OUT rule 10 action 'deny'

set policy prefix-list6 AS65537-OUT rule 10 prefix
'2a00:100:2::/48'

set policy route-map AS65537-IN rule 10 action 'permit'

set policy route-map AS65537-IN rule 10 match ip address
prefix-list 'AS65537-IN'

set policy route-map AS65537-IN rule 10 match ipv6
address prefix-list 'AS65537-IN'

set policy route-map AS65537-IN rule 20 action 'deny'

set policy route-map AS65537-OUT rule 10 action 'deny'

set policy route-map AS65537-OUT rule 10 match ip address
prefix-list 'AS65537-OUT'

set policy route-map AS65537-OUT rule 10 match ipv6
address prefix-list 'AS65537-OUT'

set policy route-map AS65537-OUT rule 20 action 'permit'

set protocols bgp 65536 neighbor 2a00:100::2 route-map
export 'AS65537-OUT'

set protocols bgp 65536 neighbor 2a00:100::2 route-map
import 'AS65537-IN'

Node2:

set policy prefix-list AS65536-IN rule 10 action 'permit'

set policy prefix-list AS65536-IN rule 10 prefix
'1.0.0.0/16'

set policy prefix-list AS65536-OUT rule 10 action 'deny'

set policy prefix-list AS65536-OUT rule 10 prefix
'1.0.0.0/16'

set policy prefix-list6 AS65536-IN rule 10 action
'permit'

set policy prefix-list6 AS65536-IN rule 10 prefix
'2a00:100:1::/48'

set policy prefix-list6 AS65536-OUT rule 10 action 'deny'

set policy prefix-list6 AS65536-OUT rule 10 prefix
'2a00:100:1::/48'

set policy route-map AS65536-IN rule 10 action 'permit'

set policy route-map AS65536-IN rule 10 match ip address
prefix-list 'AS65536-IN'

set policy route-map AS65536-IN rule 10 match ipv6
address prefix-list 'AS65536-IN'

set policy route-map AS65536-IN rule 20 action 'deny'

set policy route-map AS65536-OUT rule 10 action 'deny'

set policy route-map AS65536-OUT rule 10 match ip address
prefix-list 'AS65536-OUT'

set policy route-map AS65536-OUT rule 10 match ipv6
address prefix-list 'AS65536-OUT'

set policy route-map AS65536-OUT rule 20 action 'permit'

set protocols bgp 65537 neighbor 2a00:100::1 route-map
export 'AS65536-OUT'

set protocols bgp 65537 neighbor 2a00:100::1 route-map
import 'AS65536-IN'

We could expand on this and also deny link local and multicast in the rule
20 action deny.

Route Redistribution and Policy Engine

Firewall

VyOS makes use of Linux netfilter for
packet filtering.

The firewall supports the creation of groups for ports, addresses, and
networks (implemented using netfilter ipset) and the option of interface or
zone based firewall policy.

Important note on usage of terms: The firewall makes use of the terms in, out, and local for firewall policy. Users experienced with netfilter
often confuse in to be a reference to the INPUT chain, and out the OUTPUT chain from netfilter. This is not the case. These
instead indicate the use of the FORWARD chain and either the input or
output interface. The INPUT chain, which is used for local
traffic to the OS, is a reference to as local with respect to
its input interface.

Groups

Firewall groups represent collections of IP addresses, networks, or ports.
Once created, a group can be referenced by firewall rules as either a source or
destination. Members can be added or removed from a group without changes to or
the need to reload individual firewall rules. Note that groups can also be
referenced by NAT configuration.

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, the network group is recommended.

Here is an example of a network group for the IP networks that make up the
internal network:

set firewall group network-group NET-INSIDE network
192.168.0.0/24

set firewall group network-group NET-INSIDE network
192.168.1.0/24

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 a -.

Here is an example of a port group a server:

set firewall group port-group PORT-TCP-SERVER1 port 80

set firewall group port-group PORT-TCP-SERVER1 port 443

set firewall group port-group PORT-TCP-SERVER1 port
5000-5010

Rule-Sets

A rule-set is a named collection of firewall rules that can be applied to
an interface or zone. Each rule is numbered, has an action to apply if the rule
is matched, and the ability to specify the criteria to match.

Example of a rule-set to filter traffic to the internal network:

set firewall name INSIDE-OUT default-action drop

set firewall name INSIDE-OUT rule 1010 action accept

set firewall name INSIDE-OUT rule 1010 state established
enable

set firewall name INSIDE-OUT rule 1010 state related
enable

set firewall name INSIDE-OUT rule 1020 action drop

set firewall name INSIDE-OUT rule 1020 state invalid
enable

Applying a Rule-Set to an Interface

Once a rule-set is created, it can be applied to an interface. Note only
one rule-set can be applied to each interface for in, out, or local traffic for each protocol (IPv4 and IPv6).

set interfaces ethernet eth1 firewall out name INSIDE-OUT

Applying a Rule-Set to a Zone

A named rule-set can also be applied to a zone relationship (note, zones
must first be created):

set zone-policy zone INSIDE from OUTSIDE firewall name
INSIDE-OUT

Zone-based Firewall Policy

As an alternative to applying policy to an interface directly, a
zone-based firewall can be created to simplify configuration when multiple
interfaces belong to the same security zone.

NAT

Source NAT

Source NAT is typically referred to simply as NAT. To be more correct,
what most people refer to as NAT is actually the process of Port Address
Translation (PAT), or NAT Overload: The process of having many
internal host systems communicate to the Internet using a single or subset of
IP addresses.

To setup SNAT, we need to know:

• The internal
  IP addresses we want to translate
• The outgoing
  interface to perform the translation on
• The external
  IP address to translate to

In the example used for the Quick Start configuration above, we
demonstrate the following configuration:

set nat source rule 100 outbound-interface 'eth0'

set nat source rule 100 source address '192.168.0.0/24'

set nat source rule 100 translation address 'masquerade'

Which generates the following configuration:

rule 100 {

outbound-interface 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 - in the set nat
source rule [n] translation address statement.

set nat source rule 100 translation address
'203.0.113.32-203.0.113.63'

---

Note: Avoiding NAT breakage in the
absence of split-DNS

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 reffered to as NAT Reflection, or Hairpin NAT.

In this example, we will be using the example Quick Start configuration
above as a starting point.

To setup a NAT reflection rule, we need to create a rule to NAT
connections from the internal network to the same internal network to use the
source address of the internal interface.

set nat source rule 110 description 'NAT Reflection:
INSIDE'

set nat source rule 110 destination address
'192.168.0.0/24'

set nat source rule 110 outbound-interface 'eth1'

set nat source rule 110 source address '192.168.0.0/24'

set nat source rule 110 translation address 'masquerade'

Which results in a configuration of:

rule 110 {

description
"NAT Reflection: INSIDE"

destination {

address
192.168.0.0/24

}

outbound-interface eth1

source {

address
192.168.0.0/24

}

translation {

address masquerade

}

}

---

Destination NAT

DNAT is typically referred to as a Port Forward. When using VyOS as
a NAT router and firewall, a common configuration 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: [1]

Our configuration commands would be:

set nat destination rule 10 description 'Port Forward:
HTTP to 192.168.0.100'

set nat destination rule 10 destination port '80'

set nat destination rule 10 inbound-interface 'eth0'

set nat destination rule 10 protocol 'tcp'

set nat destination rule 10 translation address
'192.168.0.100'

Which would generate the following NAT destination configuration:

nat {

destination {

rule 10 {

description "Port Forward: HTTP to 192.168.0.100"

destination {

port 80

}

inbound-interface eth0

protocol tcp

translation {

address 192.168.0.100

}

}

}

}

Note that 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 that 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 policy, we want to allow traffic coming in on the
outside interface, destined for TCP port 80 and the IP address of
192.168.0.100.

set firewall name OUTSIDE-IN rule 20 action 'accept'

set firewall name OUTSIDE-IN rule 20 destination address '192.168.0.100'

set firewall name OUTSIDE-IN rule 20 destination port
'80'

set firewall name OUTSIDE-IN rule 20 protocol 'tcp'

set firewall name OUTSIDE-IN rule 20 state new 'enable'

This would generate the following configuration:

rule 20 {

action accept

destination {

address
192.168.0.100

port 80

}

protocol tcp

state {

new enable

}

}

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.

1-to-1 NAT example

Here's an extract of a simple 1-to-1 NAT configuration with one internal
and one external interface:

set interfaces ethernet eth0 address '192.168.1.1/24'

set interfaces ethernet eth0 description 'Inside
interface'

set interfaces ethernet eth1 address '1.2.3.4/24'

set interfaces ethernet eth1 description 'Outside
interface'

set nat destination rule 2000 description '1-to-1 NAT
example'

set nat destination rule 2000 destination address
'1.2.3.4'

set nat destination rule 2000 inbound-interface 'eth1'

set nat destination rule 2000 translation address
'192.168.1.10'

set nat source rule 2000 description '1-to-1 NAT example'

set nat source rule 2000 outbound-interface 'eth1'

set nat source rule 2000 source address '192.168.1.10'

set nat source rule 2000 translation address '1.2.3.4'

Firewall rules are written as normal, using the internal IP address as the
source of outbound rules and the destination of inbound rules.

NPTv6 (RFC6296)

See here : How_to_do_NPTv6

VPN

Example for configuring a simple L2TP over IPsec VPN for remote access
(works with native Windows and Mac VPN clients):

set vpn ipsec ipsec-interfaces interface eth0

set vpn ipsec nat-traversal enable

set vpn ipsec nat-networks allowed-network 0.0.0.0/0

set vpn l2tp remote-access outside-address 203.0.113.2

set vpn l2tp remote-access client-ip-pool start
192.168.255.1

set vpn l2tp remote-access client-ip-pool stop
192.168.255.255

set vpn l2tp remote-access ipsec-settings authentication
mode pre-shared-secret

set vpn l2tp remote-access ipsec-settings authentication
pre-shared-secret <secret>

set vpn l2tp remote-access authentication mode local

set vpn l2tp remote-access authentication local-users
username <username> password <password>

In the example above an external IP of 203.0.113.2 is assumed.

If a local firewall policy is in place on your external interface you will
need to open:

• UDP port 500
  (IKE)
• IP protocol
  number 50 (ESP)
• UDP port 1701
  for IPsec

In addition when NAT is detected by the VPN client ESP is encapsulated in
UDP for NAT-traversal:

• UDP port 4500
  (NAT-T)

Example:

set firewall name OUTSIDE-LOCAL rule 40 action 'accept'

set firewall name OUTSIDE-LOCAL rule 40 protocol 'esp'

set firewall name OUTSIDE-LOCAL rule 41 action 'accept'

set firewall name OUTSIDE-LOCAL rule 41 destination port
'500'

set firewall name OUTSIDE-LOCAL rule 41 protocol 'udp'

set firewall name OUTSIDE-LOCAL rule 42 action 'accept'

set firewall name OUTSIDE-LOCAL rule 42 destination port
'4500'

set firewall name OUTSIDE-LOCAL rule 42 protocol 'udp'

set firewall name OUTSIDE-LOCAL rule 43 action 'accept'

set firewall name OUTSIDE-LOCAL rule 43 destination port
'1701'

set firewall name OUTSIDE-LOCAL rule 43 ipsec
'match-ipsec'

set firewall name OUTSIDE-LOCAL rule 43 protocol 'udp'

Also note that if you wish to allow the VPN to be used for external access
you will need to add the appropriate source NAT rules to your configuration.

set nat source rule 110 outbound-interface 'eth0'

set nat source rule 110 source address '192.168.255.0/24'

set nat source rule 110 translation address masquerade

Established sessions can be viewed using the show vpn remote-access
operational command.

vyos@vyos:~$ show vpn remote-access

Active remote access VPN sessions:

User           
Proto Iface     Tunnel IP       TX byte RX byte  Time

----           
----- -----     ---------       ------- -------  ----

vyos           
L2TP  l2tp0     192.168.255.1      3.2K   
8.0K  00h06m13s

Traffic Policy

The traffic policy subsystem provides an interface to Linux traffic
control.

One common use of traffic policy is to limit bandwidth for an interface.
In the example below we limit bandwidth for our LAN connection to 200M download
and out WAN connection to 50M upload:

set traffic-policy shaper WAN-OUT bandwidth '50Mbit'

set traffic-policy shaper WAN-OUT default bandwidth '50%'

set traffic-policy shaper WAN-OUT default ceiling '100%'

set traffic-policy shaper WAN-OUT default queue-type
'fair-queue'

set traffic-policy shaper LAN-OUT bandwidth '200Mbit'

set traffic-policy shaper LAN-OUT default bandwidth '50%'

set traffic-policy shaper LAN-OUT default ceiling '100%'

set traffic-policy shaper LAN-OUT default queue-type
'fair-queue'

Resulting in the following configuration:

traffic-policy {

shaper WAN-OUT
{

bandwidth
50Mbit

default {

bandwidth 50%

ceiling
100%

queue-type fair-queue

}

}

shaper LAN-OUT
{

bandwidth
200Mbit

default {

bandwidth 50%

ceiling
100%

queue-type fair-queue

}

}

}

Once defined, a traffic policy can be applied to each interface using the
interface-level traffic-policy directive:

set interfaces ethernet eth0 traffic-policy out 'WAN-OUT'

set interfaces ethernet eth1 traffic-policy out 'LAN-OUT'

Note that a traffic policy can also be defined to match specific traffic
flows using class statements.

VyOS also supports HFSC (included in Lithium).

set traffic-policy shaper-hfsc

See further information on the QoS page.

DHCP Server

Configure a DHCP server on eth0:

set service dhcp-server disabled false

set service dhcp-server shared-network-name 'yournetwork'
subnet '192.168.0.0/24'

set service dhcp-server shared-network-name 'yournetwork'
subnet '192.168.0.0/24' start '192.168.0.5' stop '192.168.0.253'

set service dhcp-server shared-network-name 'yournetwork'
subnet '192.168.0.0/24' default-router '192.168.0.1'

set service dhcp-server shared-network-name 'yournetwork'
subnet '192.168.0.0/24' dns-server '8.8.8.8'

The DNS server parameter is what will be configured on the devices
utilising DHCP. This can also be set to the router address, if for example DNS
server or forwarding functionality is enabled.

The DHCP server can also be kept configured but disabled, by using:

set service dhcp-server disabled true

DHCP Relay

Configure a DHCP relay in eth0 with the DHCP server 192.168.10.1 (attached
to eth1):

set service dhcp‐relay interface eth0

set service dhcp-relay interface eth1

set service dhcp‐relay server 192.168.10.1

Currently dhcp-relay requires also specifying the interface the DHCP
server replies come from. An upstream bug exists for this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648401

DNS Forwarder

Dynamic DNS Updater

set services dns dynamic interface eth0

More information here : Dynamic_DNS

System Configuration

System Users

VyOS supports two levels of users: admin and operator.

The operator level restricts a user to operational commands and prevents
changes to system configuration. This is useful for gathering information about
the state of the system (dhcp leases, vpn connections, routing tables, etc...)
and for manipulating state of the system, such as resetting connections,
clearing counters and bringing up and taking down connection oriented
interfaces.

The admin level has all of the capabilities of the operator level, plus
the ability to change system configuration. The admin level also enables a user
to use the sudo command, which essentially means the user has root access to
the system.

Creating Login User Accounts

Create user account jsmith, with admin level access and the password
"mypassword"

set system login user jsmith full-name "Johan
Smith"

set system login user jsmith authentication
plaintext-password mypassword

set system login user jsmith level admin

commit

The command:

show system login

will show the contents of the system login configuration node:

user jsmith {

authentication
{

encrypted-password
$6$0OQHjuQ8M$AYXVn7jufdfqPrSk4/XXsDBw99JBtNsETkQKDgVLptXogHA2bU9BWlvViOFPBoFxIi.iqjqrvsQdQ./cfiiPT.

plaintext-password ""

}

full-name
"Johan Smith"

level admin

}

Configuring for SSH Access using Shared Public Keys

The following command will load the public key dev.pub for user jsmith

loadkey jsmith dev.pub

Note: this requires uploading the
dev.pub public key to the vyos firewall first. As an alternative you can also
load the ssh public key directly from a remote system:

loadkey jsmith
scp://devuser@dev001.vyos.net/home/devuser/.ssh/dev.pub

IPv6

Advanced IPv6 configuration examples are available on the IPv6 page.

System Image Management

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/VyOS_999.hydrogen.11291501

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.

The default boot image can be set using the set system image
default-boot command in operational mode.

A list of available images can be shown using the show system image
command in operational mode.

vyos@vyos:~$ show system image

The system currently has the following image(s)
installed:

1:
999.hydrogen.12130649 (default boot) (running image)

2:
999.hydrogen.12100644

vyos@vyos:~$

Images no longer needed can be removed using the delete system image
command.

Finally, new system images can be added using the add system image
command. The add image command will extract the image from the release ISO
(either on the local filesystem or remotely if a URL is provided). The image
install process will prompt you to use the current system configuration and SSH
security keys, allowing for the new image to boot using the current
configuration.

Note that 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.

If you need some files from a previous images - take a look inside a /live
directory.