Network Gateway devices - Vyatta

Vyatta Network Gateway devices provide performance, ease of configuration, and the maintenance advantages of running on normal server hardware. The hardware is sized to handle the routing load for multiple VLANs and can be ordered with RAID arrays to provide redundancy to the disk subsystem.   For an overview of the benefits and functionality of Network Gateway devices please see the article at http://knowledgelayer.softlayer.com/faqs/265#1061.

As the administrator of your Network Gateway, you are able to configure the gateway to enable the kind of connectivity you want for the VLANs which you elect to route through the Network Gateway. Some of the more prominent options include:

  •          Firewall a VLAN.
  •          Remove firewall protection from a VLAN.
  •          Use NAT on a VLAN.
  •          Configure IPSec tunnels and routing between them.
  •      Shape traffic on a VLAN.

What follows are notes on the operation of a Vyatta system. Additional sources of information include vyatta.com, vyatta.org and our support department.

Terminology



Configuration mode


Invoked with the use of the ‘configure’ command, configuration mode is where configuration of the Vyatta system is done.


Operational mode


The initial mode on logging into a Vyatta system where “show” commands can be run to query information on the running state of the system. The system can also be restarted from here.

 

Basics

The Vyatta system is configured using either the web GUI or a remote console session through SSH or telnet. Telnet is not an encrypted protocol and is not secure so this guide will focus on the remote console option SSH.

This is just Linux, isn’t it?

While it's true that Vyatta is built on top of a Linux implementation, it's also important to remember that Vyatta installations have more running under the hood than a Linux stack. Configuring Vyatta outside of the Vyatta shell and interfaces may produce unexpected results.

Accessing the device

To initially access the Vyatta Network Gateway you will need an SSH client. Most Unix-based operating systems such as Linux, BSD, and Mac OSX will generally have OpenSSH clients included with their default installations. Windows users will need to download an SSH client such as PuTTy for use with the system.

Within the customer portal, you will find the IP addresses, login username, and password for the device. You will need to use the Vyatta account to login via SSH, as root access is disabled for SSH logins by default:

ssh vyatta@<IP>

Once you've logged in, your SSH client will be connected to the system via the Vyatta shell.  Please note that connections to private IPs will generally require connecting either from another machine you have with us or by connecting to our backend management VPN.

Rather than edit the SSH configuration file, Vyatta installations can use the following command to enable root access via SSH:

                set service ssh allow-root

Command exploration

The Vyatta command shell includes tab completion capabilities. If you are curious about what commands are available, press the tab key for a list showing the possible commands and a short explanation of them. This works at the shell prompt and within the middle of typing a command.

$ show log dns <TAB>
Possible completions:
  dynamic       Show log for Dynamic DNS
  forwarding    Show log for DNS Forwarding

Operational mode/Configuration mode

Vyatta's shell is a modal interface, with several modes of operation. The primary/default mode is "Operational", and this will be the mode presented upon login. In operational mode you can view information and issue commands which impact the current run of the system such as setting the date/time and rebooting the device.

The command “configure” will place the user into configuration mode where edits to the configuration can be performed. It is important to understand that configuration changes do not take place immediately; they must be committed and saved. As commands are entered they go into a configuration buffer. Once all the necessary commands are entered the user has to run the “commit” command to make those changes live.

To save commands permanently in the configuration file it is necessary to do “save” after “commit”.

Operational mode commands can be run from configuration mode by starting the command with the word run. An example:

# run show configuration commands | grep name-server
set system name-server '10.0.80.11'
set system name-server '10.0.80.12'

The # mark indicates I am in configuration mode. I start the command with the word run to let the Vyatta shell know I’m sending it an operational mode command. This example also shows the handy feature of being able to grep against the output of commands.

The configuration

The Vyatta configuration is laid out in a hierarchical pattern of nodes. As an example, consider this static route block:

protocols {

     static {

         route 10.0.0.0/8 {

             next-hop 10.60.63.193 {

             }

         }

         route 192.168.1.0/24 {

             next-hop 10.0.0.1 {

             }

         }

     }

 }

This would be generated by the commands

set protocols static route 10.0.0.0/8 next-hop 10.0.0.1
set protocols static route 192.168.1.0/24 next-hop 10.0.0.1

This illustrates that it is possible for a node (static) to have multiple child nodes. To remove the route for 192.168.1.0/24 the command

delete protocols static route 192.168.1.0/24

would be used. If 192.168.1.0/24 was left off the command then both of the route nodes would be marked for deletion. A reminder: the configuration is not actually changed until you issue the “commit” command.

If you are ever unsure of the status of your commands the “compare” command will show a comparison of the running configuration versus the configuration buffer. If you need to flush the buffer and start again use the “discard” command.

Users

User accounts can be configured with two levels of access: admin and operator. Operator level users are able to run show commands to view the running status of the system and issue reset commands to restart services on the device. Understand that operator permissions do not imply read-only access. Admin level users have full access to all configurations and operations for the device. They can view running configurations, change configuration settings for the device, reboot the device, and shutdown on the device.

The users can be configured for password, public key or both authentication styles. Public key authentication is used with SSH and allows the user to login using a key file on their system.

To create an operator user with a password:

set system login user <account> authentication plaintext-password <password>
                set system login user <account> level operator
                commit

Note that without the level specified a user is considered admin. The password (though entered in the clear) ends up encrypted in the configuration file.

VLANs

The Vyatta device is able to route multiple process multiple VLANs over the same network interface (for example, bond1 or eth1). This is accomplished by setting the switch port into trunk mode and configuring virtual interfaces (VIFs) on the Vyatta device.

Example commands:

set interfaces bonding bond0 vif 1432 address 10.0.10.1/24
set interfaces bonding bond0 vif 1693 address 10.0.20.1/24

The two commands above create two virtual interfaces on top of the bond0 interface. The interface bond0.1432 would process traffic for VLAN 1432 while the interface bond0.1693 processes VLAN 1693.

Firewalling

One of the benefits of using a Network Gateway is the ability to configure firewall rules on the device to protect the VLANs routed through the device. In Vyatta firewalling is broken into two parts: defining one or more sets of rules and applying a set of rules to an interface or zone.

It is important to test firewall rules to make sure they work the way you intend. Equally important is making sure that you maintain access to the device. If you are going to be manipulating rules on the eth1 interface it is advisable to connect to the device via eth0. Connecting to the console via the IPMI KVM is also an option.

Firewall groups

Firewall groups are collections of IPs, networks (subnets) or ports which can be referenced in multiple firewall rules. An example of a network group is:

set firewall group network-group RFC1918 description 'Not publically routable networks'
set firewall group network-group RFC1918 network '10.0.0.0/8'
set firewall group network-group RFC1918 network '172.16.0.0/12'
set firewall group network-group RFC1918 network '192.168.0.0/16'

With this group defined these subnets can be referenced in later rules by the name RFC1918. You will find another set of useful network-group definitions for the datacenter services networks at http://knowledgelayer.softlayer.com/faq/what-ip-ranges-do-i-allow-through-firewall.

Firewall rule sets

Firewall rules are grouped together into named sets of rules to make applying the same rules to multiple interfaces easier. Each rule set has a default action associated with it. Consider the default action as a rule at the end of the set which will accept or drop any traffic which was not otherwise resolved by the prior rules in the set.

Consider the example:

set firewall name ALLOW_LEGACY default-action accept
set firewall name ALLOW_LEGACY rule 1 action drop
set firewall name ALLOW_LEGACY rule 1 source group network-group RFC1918
set firewall name ALLOW_LEGACY rule 2 action drop
set firewall name ALLOW_LEGACY rule 2 destination port telnet
set firewall name ALLOW_LEGACY rule 2 log enable
set firewall name ALLOW_LEGACY rule 2 protocol tcp
set firewall name ALLOW_LEGACY rule 2 source group network-group !LEGACYNETS

In this rule set, named ALLOW_LEGACY, there are two rules defined. The first rule drops any traffic sourced from a network-group named RFC1918. The second rule drops (discards) and logs any traffic destined for the telnet port (tcp/23) except for traffic from the network group LEGACYNETS (note the exclamation point indicating negation). The default-action indicates that anything else is accepted.

Allowing datacenter access

We have several IP subnets which are used to provide services and support to systems running within the datacenter. For example, DNS resolver services are running on 10.0.80.11 and 10.0.80.12. Other subnets are used during the provisioning and support process. You can find the IP ranges used in the datacenters at the following location:

http://knowledgelayer.softlayer.com/faq/what-ip-ranges-do-i-allow-through-firewall

Allowing our access is accomplished by placing the proper network-group statements at the beginning of your firewall rule sets with an action of accept. Where precisely the rule set has to be applied will depend on the routing and firewalling design you are implementing with your Vyatta Network Gateway.

In general you will want to place the rules in whatever location causes the least duplication of work. For example, allowing our backend nets inbound on bond0 would be less work than if you try to allow them outbound toward each VLAN virtual interface.

Firewall logging

If you enable logging on firewall rules you can view that logging using the command:

show log firewall name <RULESET NAME>

More general information can be found using the command

                show firewall name <RULESET NAME>

This second command will show the zones and interfaces to which the rule set is bound and the packet/byte counters for the rules of the set.

Per-interface firewalling

One method for firewalling with Vyatta is to apply firewall rule sets to each interface. In this case an interface can be a physical interface (eth0) or a virtual interface (eth0.303). Each interface has three firewall assignments possible.



IN


the firewall is checked against packets which, as they pass through the system, are entering via the interface


OUT


the firewall is checked against packets which, as they pass through the system, are leaving via the interface


LOCAL


the firewall is checked against packets which are destined for the Vyatta itself

 

An interface can have only one rule set applied to an assignment possibility. Each assignment can have a different rule set applied to it. Note that it is not possible to firewall traffic sourcing from the Vyatta device itself using per-interface firewalls.

To assign the ALLOW_LEGACY rule set to the LOCAL option for the eth1 interface you would use the configuration command:

set interfaces ethernet eth1 firewall local name 'ALLOW_LEGACY'

To view the runs and counters associated with them, use the operational mode command:

show firewall name ALLOW_LEGACY

The output is:

-----------------------------
Rulesets Information
-----------------------------
IPv4 Firewall "ALLOW_LEGACY":

 Active on (eth1,LOCAL)
rule  action   proto     packets  bytes
----  ------   -----     -------  -----
1     drop     all       0        0
  condition - saddr 0.0.0.0/0 daddr 0.0.0.0/0 match-set RFC1918 src
2     drop     tcp       16       840
  condition - saddr 0.0.0.0/0 daddr 0.0.0.0/0 ! match-SRC-NTWRK-GROUP LEGACYNETS tcp dpt:23LOG enabled
10000 accept   all       1014     270607
  condition - saddr 0.0.0.0/0 daddr 0.0.0.0/0

The highlight shows the interface and type of the firewall rule set assignment. The same rule set could be active on multiple interfaces.

Zone firewalling

The other firewalling concept in Vyatta is that of zone based firewalling. In zone-based firewall operation an interface is assigned to a zone (only one zone per interface) and firewall rule sets are assigned to the boundaries between zones with the idea that all interfaces within a zone have the same security level and are allowed to route freely. Traffic is only scrutinized when it is passing from one zone into another. Zones drop any traffic coming into them which is not explicitly allowed.

An interface can either belong to a zone or have a per-interface firewall configuration; an interface cannot do both.

Assigning interfaces to zones

Imagine the following scenario:

Department A - VLANs 10 and 20 (interface eth1.10 and eth1.20)
Department B - VLANs 30 and 40 (interface eth1.30 and eth1.40)
Department C - VLAN 50 (interface eth1.50)

A zone can be created for each department and the interfaces for that department can be added to the zone.

set zone-policy zone DEPARTMENTA interface 'eth1.10'
set zone-policy zone DEPARTMENTA interface 'eth1.20'
set zone-policy zone DEPARTMENTB interface 'eth1.30'
set zone-policy zone DEPARTMENTB interface 'eth1.40'
set zone-policy zone DEPARTMENTC interface 'eth1.50'

After committing these commands the zones have been populated with interfaces and the default drop rules means that any traffic trying to enter the zone from the outside the zone is dropped. VLAN 10 and 20 can pass traffic since they are in the same zone but not VLAN 10 and VLAN 30.

The interfaces within each zone are able to pass traffic freely between them and rules can be defined for interaction between the zones.

Configuring rule sets between zones

A rule set is configured from the point of view of entering the zone from another zone. An example of such a configuration is the command:

set zone-policy zone DEPARTMENTB from DEPARTMENTC firewall name ALLOW_PING

This command associates the transition DEPARTMENTC -> DEPARTMENTB with the rule set named ALLOW_PING. Traffic entering the DEPARTMENTB zone from the DEPARTMENTC zone would be checked against this rule set. It is important to understand that this assignment from zone DEPARTMENTC going into zone DEPARTMENTB does not make any statement about the inverse. If there are no rules allowing traffic from zone DEPARTMENTB into zone DEPARTMENTC then replies will not get back to the hosts in DEPARTMENTC.

Local Zone

A note about the Vyatta device: the device itself can be configured to be a local zone. When this is done traffic to the Vyatta device can be limited (as the traffic would be entering the Vyatta local zone).

                set zone-policy zone VYATTALOCAL local-zone

The command above creates a zone called VYATTALOCAL and marks it as a local-zone. Rule sets can be applied to the zone boundary like any other zone in order to lock down access to the device. Be mindful of your connectivity to the device when working with a local zone. The local zone entry will cheerfully lock you out of the device. Fixing this will generally require work with the KVM console or possibly rebooting the device.

Backups

The configuration commands need to be backed up when there is a change to the system. This can be accomplished by running the operational mode command “show configuration commands” and then saving the output (for example by copying/pasting from the SSH session). This would be considered a minimum backup for the configuration.

A more complete backup would be to generate a tech support archive for the system:

$ generate tech-support archive
Saving the archivals...
Saved tech-support archival at /opt/vyatta/etc/config/support/mpatr-vyatta-one.tech-support-archive.2013-08-27-155554.tgz

The generated archive file can then be copied from the Vyatta device to storage of your choice. The archive contains backups of the configuration information, home directories and logging information. It is a much more complete backup of a system.

-rw-r--r--  1 michael  michael    7863 Aug 22 12:46 config.tgz
-rw-r--r--  1 michael  michael     112 Aug 22 12:46 core-dump.tgz
-rw-r--r--  1 michael  michael  716033 Aug 22 12:46 etc.tgz
-rw-r--r--  1 michael  michael    3698 Aug 22 12:46 home.tgz
-rw-r--r--  1 michael  michael    1092 Aug 22 12:46 root.tgz
-rw-r--r--  1 michael  michael    4204 Aug 22 12:46 tmp.tgz
-rw-r--r--  1 michael  michael   82976 Aug 22 12:46 var-log.tgz

Any notes that you create while configuring the device would also be good information to backup in a central location accessible to all of your administration staff.

Potential pitfalls

Lost password

 If there is access to the system, just set a new one:

set system login user <account> authentication plaintext-password <password>

 If there is not access to the system, reboot the device and there is a password recovery option on the GRUB menu for resetting the root user password.

Firewall lock out

Note: the “reboot at <time>” construct can be useful when testing potentially dangerous firewall rules. If the rule works then “reboot cancel” to cancel the reboot; if the rule locks you out just wait for the scheduled reboot to happen.

If there is no access to the system (or you do not care about any unsaved configuration changes) then you can generally recover by rebooting the device so that the configuration file is read again (without the unsaved changes).

If there is access via KVM or shell there are options. Do one of these:

1.       Disable the offending rule by

a.       set firewall name <firewall name> rule <rule number> disable

b.      commit

2.       Unhook the entire named rule set from the necessary interface. Be VERY CAREFUL with this command; incorrect use will wipe out your interface configuration.

a.        delete interfaces ethernet <interface> firewall <type> name <firewall name>

b.       commit

Was this helpful?