Create a Router with Front Firewall using Vyatta on VMware Workstation

Vyatta is a powerful enterprise class software router that has some really incredible features.  It has a CLI (command line interface) as well as a web interface.  I’ve gotten a few requests about configuring it as a front system but until now have only really worked with Vyatta as a pure routing appliance internal to my network.  It has been my traffic cop between my lab subnet, user subnet, and server subnet but now I’ll try to configure it as a front end based on an exchange I had on another thread.

This should be able to give you some examples with getting started using Vyatta as a front firewall.

If you don’t have the software, you can download a free version, called Vyatta Core, from Vyatta’s website.  You have to register, but don’t worry, they won’t spam you and they have extensive documentation on the product that you can pull down after registering.  It’s an excellent resource to learn and practice your routing skills, especially since you can stand up the product on random hardware or in a virtual machine.  Vyatta even has downloads specific to VMware implementations.  Check it out and come back if you’re interested in seeing this post through.  http://www.vyatta.com.

And now for the good part.

I’ll follow the format of entering commands (all CLI based) and explain the commands I entered and why I entered them.  This information comes directly from the Vyatta documentation.  This post just may save you a little time in sorting through docs for what you may need.

There are ready-made virtual appliances for both VMware vSphere and Xen, or you can download the LiveCD iso.  Make sure to download the docs while you are there.

[ad#Google Adsense-1]

I’ll be building this out in a VMware Workstation virtual machine.  The following screenshots represent configuring Vyatta to run in a virtual machine and the settings I used for the VM.  I attempted to import the OVF into the latest version of workstation but it failed to import, so I installed using an ISO that can be downloaded from Vyatta’s website, and is specific to virtualization.

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 018017 

These screenshots don’t have the accompanying text but show the settings that I used.  2GB Hard Drive, 512 MB RAM, Linux –> Other Linux 2.6.x kernel, and I added an extra NIC bringing the total to 2.  One will simulate the WAN and the other will simulate an internal LAN.

This post will show you basic Vyatta configuration along with the paradigm of how Vyatta does things:

  • Installation of the software
  • Base configuration of the software
  • Configuration of the hardware
  • Enabling of management services (SSH and WebGUI)
  • Configuring DHCP for a subnet
  • Setting up simple NAT rules
  • Configuring the firewall for basic Internet access
  • Scenario based firewall examples

Now for the Vyatta configuration.  Start by logging in using vyatta as the username and vyatta as the password.  I ran the install-image command to install vyatta onto the hard drive and follow the prompts.  The text-based wizard will walk you through the installation.  You can accept the defaults for the most part unless you have alternate needs.  After the installation, run the shutdown command and disconnect the ISO and restart the system.

At any point while in Vyatta’s configure mode, type ‘save’ at the prompt to save your configuration.  If you do not do this, your configuration will lost after reboots.

Installation commands and summary:

  • Start vyatta.  When at the vyatta login, use username vyatta and password vyatta.

vyatta@vyatta:~$ install-image
– system will walk you through installation
vyatta@vyatta:~$ shutdown
disconnect the vyatta ISO after shutdown and then start the system again

Now you should have a functioning Vyatta installation on a virtual machine.

We’ll start by configuring the network adapters and some other basic Vyatta systems.  I’ll be using 192.168.20.0/24 for the internal network and 192.168.100.0/24 to simulate the Internet.

vyatta@vyatta:~$ configure
[edit]
vyatta@vyatta:~$ set system host-name R1
[edit]
vyatta@vyatta:~$ set system domain-name lab.local
[edit]
vyatta@vyatta:~$ commit

The above commands enter the configuration mode for the system, set the system’s name and domain, and commits the changes that you’ve made.

[edit]
vyatta@vyatta:~$ set interfaces ethernet eth0 address 192.168.20.10/24
[edit]
vyatta@vyatta:~$ set interfaces ethernet eth0 description Internal
[edit]
vyatta@vyatta:~$ set interfaces ethernet eth1 address dhcp
[edit]
vyatta@vyatta:~$ set interfaces ethernet eth1 description External
[edit]
vyatta@vyatta:~$ commit

These commands set the first interface, eth0 which will be internal, to have a static IP address of 192.168.20.10 with a subnet mask of 255.255.255.0.  It sets the second interface, eth1 which will be internet facing, to use DHCP.  The lines that contain description are to help you identify which NIC is which while looking over the configuration.  If you are assigning a static public IP address, it would be fine to type it in just as the first command.  Again, we commit the changes.

[edit]
vyatta@vyatta:~$ set system name-server 192.168.100.101
[edit]
vyatta@vyatta:~$ set system gateway-address 192.168.100.1
[edit]
vyatta@vyatta:~$ commit
[edit]
vyatta@vyatta:~$ exit
vyatta@vyatta:~$

The next set of commands sets the DNS server that the system will use.  The second sets the default gateway that the system will use if it does not know how to route a request.  Then we commit the changes and exit configuration mode.  At this point you can run the following command to check your network configuration.

vyatta@vyatta:~$ show interfaces

019

vyatta@vyatta:~$ configure
[edit]
vyatta@vyatta:~$ set service ssh
[edit]
vyatta@vyatta:~$ set service https
[edit]
vyatta@vyatta:~$ commit
Restarting OpenBSD Secure Shell server: sshd.
Generating a 1024 bit RSA private key
…………………………………………………..
writing new private key to ‘/etc/lighttpd/server.pem’
—–
Stopping web server: lighttpd.
Starting web server: lighttpd.
Stopping PAGER server
Starting PAGER server
[edit]

These commands enable SSH and the web GUI for Vyatta management.

Now we’ll configure a DHCP range so that Vyatta can issue IP addresses to internal clients.  If you have another DHCP server or plan to not use Vyatta for this, you can simply skip the next set of commands.

[edit]
vyatta@vyatta:~$ set service dhcp-server shared-network-name eth0_internal_pool subnet 192.168.20.0/24 start 192.168.20.100 stop 192.168.20.199
[edit]
vyatta@vyatta:~$ set service dhcp-server shared-network-name eth0_internal_pool subnet 192.168.20.0/24 default-router 192.168.20.10
[edit]
vyatta@vyatta:~$ set service dhcp-server shared-network-name eth0_internal_pool subnet 192.168.20.0/24 dns-server 192.168.100.101
[edit]
vyatta@vyatta:~$ commit

The above commands enable a DHCP scope on eth0 with an address range of 192.168.20.100-199.  It sets itself as the default router, and an external DNS server for the scope.  You can set the DNS server to fit your needs, but I’m still using a private DNS server that is just on a different subnet which is why you are seeing the local addresses in the 192.168.100.xxx range.

We’ll now configure a NAT rule for outbound traffic.

[edit]
vyatta@vyatta:~$ set service nat rule 10 source address 192.168.20.0/24
[edit]
vyatta@vyatta:~$ set service nat rule 10 outbound-interface eth1
[edit]
vyatta@vyatta:~$ set service nat rule 10 type masquerade
[edit]
vyatta@vyatta:~$ commit

This rule allows traffic from the Internal network to traverse the router out to the Internet.  The masquerade line causes the router to mark the packets as coming from itself so that the responding Internet servers will know where to send the responses back to since private IPs are not publicly routable.

Now that the basic Internet router infrastructure is configured, we’ll move on to the firewall.  Since all of Vyatta’s ports begin wide open, when you configure the firewall and associate it with connections, Vyatta becomes locked down with the exception of what is allowed by the firewall rules.  Vyatta has 3 firewalls per NIC (in, out, and local).  As can be assumed by the naming, in is for inbound traffic to that NIC, out is for outbound traffic from that NIC, and local is for traffic that is terminating at the Vyatta appliance (ie. you’re attempting to SSH in to the appliance).  Each firewall can have multiple rules, but only one firewall can be set per NIC/connection type.

In the next example, we’ll configure a firewall titled “ALLOW_ESTABLISHED” which will allow connections that are initiated from the Internal network.  This will be applied to the “in” connection type of the External NIC.  Since Vyatta locks down after a firewall is established with an implicit deny being the last rule to be evaluated, in this scenario, the router will deny all other connection attempts from external to inbound and local.

[ad#Google Adsense-1]

Still in configure mode:

[edit]
vyatta@vyatta:~$ set firewall name ALLOW_ESTABLISHED
[edit]
vyatta@vyatta:~$ set firewall name ALLOW_ESTABLISHED rule 10
[edit]
vyatta@vyatta:~$ set firewall name ALLOW_ESTABLISHED rule 10 action accept
[edit]
vyatta@vyatta:~$ set firewall name ALLOW_ESTABLISHED rule 10 state established enable
[edit]
vyatta@vyatta:~$ commit

This firewall mimics the default behavior of a typical plug-and-play router.  We can now apply that rule to the External NIC.

[edit]
vyatta@vyatta:~$ set interfaces ethernet eth1 firewall in name ALLOW_ESTABLISHED
[edit]
vyatta@vyatta:~$ set interfaces ethernet eth1 firewall local name ALLOW_ESTABLISHED
[edit]
vyatta@vyatta:~$ commit

as you can see from the above commands, we are applying the firewall ALLOW_ESTABLISHED to the ‘in’ and ‘local’ connection types of the External NIC.  The outbound is still wide open.

The above meets the basic needs of setting Vyatta up as your public facing router.  This does not enable any internal security, filtering, or allow any kind of remote access from external.

Below are some scenario based firewall rules that you can assign to the inbound and local destined traffic to enable external access.  You may need to combine rules into a single firewall to meet your needs because only 1 firewall can be applied to each NIC / connection type.

Publishing a Web Server

The following rule set will allow a web server to be published while also allowing internally initiated connections.  Publishing an internal server requires a DNAT (destination NAT rule) to be used to route to the server.  The destination address of 0.0.0.0/0 would represent all IP addresses associated with the NIC (eth1).  I have this NIC configured for DHCP, so this is what I’ll use for the DNAT rule since the IP address may change.

vyatta@vyatta:~$ configure
vyatta@vyatta:~$ set service nat rule 20 type destination
vyatta@vyatta:~$ set service nat rule 20 protocol tcp
vyatta@vyatta:~$ set service nat rule 20 inside-address address [web server IP]
vyatta@vyatta:~$ set service nat rule 20 inside-address port 80
vyatta@vyatta:~$ set service nat rule 20 inbound-interface eth1
vyatta@vyatta:~$ set service nat rule 20 destination address 0.0.0.0/0
vyatta@vyatta:~$ set service nat rule 20 destination port 80
vyatta@vyatta:~$ set service nat rule 30 type destination
vyatta@vyatta:~$ set service nat rule 30 protocol tcp
vyatta@vyatta:~$ set service nat rule 30 inside-address address [web server IP]
vyatta@vyatta:~$ set service nat rule 30 inside-address port 443
vyatta@vyatta:~$ set service nat rule 30 inbound-interface eth0
vyatta@vyatta:~$ set service nat rule 30 destination address 0.0.0.0/0
vyatta@vyatta:~$ set service nat rule 30 destination port 443

vyatta@vyatta:~$ set firewall name INTERNET_IN
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 10 action accept
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 10 state established enable
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 10 description ALLOW_ESTABLISHED
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 20 action accept
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 20 protocol tcp
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 20 destination address [web server IP]
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 20 destination port 80
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 20 description HTTP_INBOUND
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 20 state new enable
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 20 state established enable
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 20 state related enable
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 30 action accept
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 30 protocol tcp
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 30 destination address [SSL server IP]
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 30 destination port 443
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 30 description HTTPS_INBOUND
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 30 state new enable
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 30 state established enable
vyatta@vyatta:~$ set firewall name INTERNET_IN rule 30 state related enable
vyatta@vyatta:~$ commit
vyatta@vyatta:~$ set interfaces ethernet eth1 firewall in name INTERNET_IN
vyatta@vyatta:~$ commit

Publishing SSH access to Vyatta from the Internet

The following rule set will allow a remote client to establish an SSH connection over the standard port (22) to Vyatta.

[include the rules for allow established]
vyatta@vyatta:~$ set firewall name INTERNET_LOCAL
[add rules to allow established as noted above]
vyatta@vyatta:~$ set firewall name INTERNET_LOCAL rule 20 action accept
vyatta@vyatta:~$ set firewall name INTERNET_LOCAL rule 20 protocol tcp
vyatta@vyatta:~$ set firewall name INTERNET_LOCAL rule 20 destination port 22
vyatta@vyatta:~$ set firewall name INTERNET_LOCAL rule 20 state new enable
vyatta@vyatta:~$ set firewall name INTERNET_LOCAL rule 20 state established enable
vyatta@vyatta:~$ set firewall name INTERNET_LOCAL rule 20 state related enable

Vyatta’s a very powerful product that is capable of serving home networks, SMBs, and large enterprises at a fraction of the cost of the competition and even has a free version.  With virtualization readily available, this product becomes even more versatile.  Check it out. Check out the features, including the web proxy, IPS, and web filtering.

Good luck and enjoy.  I’m still learning the product so there is still much fun to be had. 🙂

Also, I didn’t get the chance to finish testing this configuration so please let me know if you have any problems or suggestions.

Advertisements

8 thoughts on “Create a Router with Front Firewall using Vyatta on VMware Workstation”

  1. I had just started to investigate vyatta so was glad to see your blog. Im specifically interested in its potential for settting up site-site vpn, I know I will have to read instructions at some point. My first problem was that I couldnt seem to work out how to save the config. Maybey add the “save” command somewhere on blog post. do you think it would be possible to create a site to site vpn using single interface? host(s) – virtual router – VPN tunnel – Virtual router – host

  2. @Sean: Updated the blog post to reflect the ‘save’ command. Thanks for the reminder on that.

    Vyatta can handle the site-to-site VPN but I don’t have experience with that functionality yet. As for doing it on a single NIC per VPN end-point, it is theoretically possible since a single NIC can have multiple IP addresses. The configuration would likely get a little confusing, but it should be doable from, again, a theorectical standpoint. There may be something within Vyatta that doens’t allow it for security reasons.

    If you give it a try, please let me know and if you run into trouble I’ll try to help with what I can. I’ll also take a quick look at the docs and see if anything specifically says you cannot configure using that architecture.

    Can you explain the full topology of what you’re trying to do? Will Vyatta be handling external traffic as well or only a VPN solution for you? How many networks will Vyatta be working with? That kind of thing.

    Good luck.

  3. Thanks for response. The topology of each site is flat (2-3 of the machines at each site to tunnel) Hosts-cisco router- private mpls cloud. They are soon to change so that multiple sites need to work together and access each others systems. I dont have control of the cisco router otherwise i would use that. My thoughts are to modify the routing table of the hosts that I want to tunnel to put next hop as the virtual router for particular destinations. I think it may get too complicated. My fall back is openvpn and just getting the individuals to establish their own connections (I have this setup working already in lab).

  4. Fallback seems easier. 🙂

    You could definitely use Vyatta as long as the Cisco doesn’t block the traffic, assuming it’s your gateway right now?

    If Vyatta is only providing VPN end-points, you may be able to get away with a single NIC, but I haven’t tried to configure in that way. It is definitely worth a try. If I get the chance, I may try to stand it up in a lab too, you’ve got me interested.

  5. AWESOME!

    I’ve been trying to figure this out all day…

    Study lab now has internet access!

    MCITP here I come!

    KUDOS!

  6. Interesting 🙂 Along with a open source vyatta router, I
    installed Traffic Squeezer ( http://trafficsqueezer.org ) free
    Internet optimization solution in my office, to optimize our 6
    vital vpn tunnels, since we use vpn as wan. But a web-cache like
    Squid along with Traffic Squeezer solution, I think we can make
    ourselves a private cloud. I am curious to build a small could in
    out company at Egypt.

  7. Hi Clement,

    Nice, simple & educational. Thanks, mate.

    Just minor thing: in section where you are setting NAT/Firewall rules for a webserver you missed 7 lines of commands for setting access to https, i.e. :

    vyatta@vyatta:~$ set service nat rule 30 type destination
    vyatta@vyatta:~$ set service nat rule 30 protocol tcp
    vyatta@vyatta:~$ set service nat rule 30 inside-address address [web server IP]
    vyatta@vyatta:~$ set service nat rule 30 inside-address port 443
    vyatta@vyatta:~$ set service nat rule 30 inbound-interface eth0
    vyatta@vyatta:~$ set service nat rule 30 destination address 0.0.0.0/0
    vyatta@vyatta:~$ set service nat rule 30 destination port 443

    Kind regards.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s