For a post that is a little more advanced, try this one: Create a Router With Front Firewall Using Vyatta on VMware Workstation.
Otherwise… read on. 🙂
A few weeks ago, I installed Vyatta Open Source as a router internal to my network to see how it handled traffic between multiple subnets. To put it plainly, it worked like a champ! I put the router in place, assigned IP addresses to the NICs (network interface cards), and let the system do its thing. It now connects traffic between my physical network, my production virtual network, and my virtual lab running on ESX 3.5. I can easily manage most firewalls and routers that have a GUI but Vyatta presented a new challenge to me. In the case of this system, for some tasks it’s a lot easier to use the command line interface (CLI).
So without further ado, here’s the basics of Vyatta’s firewall.
Each NIC on the Vyatta build can have 3 firewalls associated with it. By default, before you setup the firewalls, they are wide open, blocking no traffic at all. That’s right, all traffic is allowed through the NICs all ways, inbound, outbound, and local destined traffic.
As I mentioned Vyatta has 3 firewalls per NIC. These firewalls are inbound – traffic coming into the NIC to pass through to another IP or subnet, outbound – traffic leaving the NIC, and local – traffic destined for the NIC. Each of these firewalls can be configured to lock the NIC down, and after configuring the firewall, all traffic not included in firewall rules is now blocked, versus the default state of open. For example, if you configure a firewall rule to allow traffic passing through the firewall from a specific IP address, all other traffic will be blocked.
So we’ll use a scenario to explain it further. This scenario consists of 3 separate subnets – lab (192.168.50.0/24), production servers (192.168.60.0/24), and clients (192.168.70.0/24) on which is also connected to the Internet through a router/gateway. Vyatta is more than capable of filling the gateway router role as well, but this scenario is for internal use only. Vyatta is configured with 3 NICs, one will reside on each subnet. The following diagram illustrates the configuration and traffic.
It’s best to configure all of your rules using a text editor so that you can easily edit and modify rules and implement them all at once. As well as being able to have a handy backup of your router’s configuration.
We want the lab subnet (192.168.50.0/24) to be able to reach the client subnet (192.168.70.0/24) so it has Internet access, but not the production server subnet (192.168.60.0/24). We want the production server subnet to be able to reach the client subnet, again for Internet access, but not the lab subnet. We want the client subnet to be able to reach both the lab and the production server subnet. In addition, we want a specific IP address to be able to manage Vyatta from the client subnet, but no others.
We have 3 rule sets on each NIC, so our rule set for the lab subnet (NIC eth0) will be configured as:
set firewall name eth0InFilter rule 10 action accept
set firewall name eth0InFilter rule 10 source address 192.168.50.0/24
set firewall name eth0InFilter rule 10 destination address 192.168.70.0/24
set interfaces ethernet eth0 firewall in eth0InFilter
set firewall name eth0OutFilter rule 10 action accept
set firewall name eth0OutFilter rule 10 action source address 192.168.70.0/24
set firewall name eth0OutFilter rule 10 action destination address 192.168.50.0/24
set interfaces ethernet eth0 firewall out eth0OutFilter
set firewall name eth0LocalFilter rule 1000 action reject
set firewall name eth0LocalFilter rule 1000 source address 0.0.0.0/0
set interfaces ethernet eth0 firewall local eth0LocalFilter
Tip: I usually create rules in steps of 10 in case I need to go back and add a rule in the middle somewhere since firewall rules are first come / first served.
– The set firewall commands begin with assigning the action [accept|reject|drop].
– Next they assign the source as [address address|port port|mac-address mac-addr].
– After that, if necessary, they assign a destination as [address address|port port|mac-address mac-addr].
In the last line of each block, we assign the rule to the NIC by rule name defined in the previous lines and target [in|out|local].
Remember that in the beginning of this post I told you that unless a firewall rule is specified, that portion of the NIC (in|out|local) is wide open? So to address the local traffic, we are ‘reject’ing all from source address 0.0.0.0/0. You could also set the destination to the IP address of the NIC. I haven’t specifically tried this rule, but it should work either way. With this rule in place, all traffic directed to the IP address of this NIC should be rejected. You could also use ‘drop’ to have the router just drop the packets instead of resetting the connection.
Tip: When there are no matching rules, traffic is rejected. With this in mind, you could even set up a simple dummy rule that blocks port 80 traffic, ie. http traffic. With this rule in place, all other traffic on that that hits that firewall would be blocked as well. You would simply change rule 1000 for eth0LocalFilter source to:
set firewall name eth0LocalFilter rule 1000 source port 80
The rules for the production networks routing would be very similar to the rules above, as well as configuring rules from the client subnet to the other subnets. You can configure rules as you need them to allow traffic from one place to the other.
For restricting access to manage the Vyatta router to a specific IP address on a specific target NIC in the router, the following commands would be used for the example above:
set firewall name eth3LocalFilter rule 10 action accept
set firewall name eth3LocalFilter rule 10 source address 192.168.70.170
set firewall name eth3LocalFilter rule 10 destination address 192.168.70.100
set interfaces ethernet eth3 firewall local eth3LocalFilter
Machines using IP address 192.168.70.170 would be allowed traffic to 192.168.70.100, which is the Vyatta router, and therefore be allowed to manage it.
This, along with the documentation, should be enough to get you off the ground in getting your firewalls set up. Vyatta is a very powerful, enterprise ready product that can and should be used to secure your network if you can’t afford or don’t want to afford the likes of Cisco. I don’t know if Vyatta is on par with Cisco for performance, configuration, reporting, etc, but for the price, I’ll stick with Vyatta Community Edition for my network. 🙂
Vyatta can be run in a virtual machine, can be downloaded as a VMware Workstation virtual appliance and then imported into ESX, can run directly on a multitude of hardware, and can even run directly from CD, without installing on a hard drive (though this configuration obviously does not allow you to save changes that you make in the router software.)
Make sure to check out Vyatta’s documentation. It is VERY thorough, but a little hard to read. The file you’re looking for in particular for firewall stuff is: Vyatta_SecurityRef_VC5_v03.pdf. You can download it directly from their site after filling out a short registration form. http://www.vyatta.com. While you’re there, pull down the rest of the docs too, since you’re filling out a form anyway. I’d post the doc on my site for your convenience, but it would likely be outdated quickly, and I don’t want to take any traffic or statistics away from Vyatta since registration is mandatory to download the docs. I filled out the registration forms for the downloads and have not seen a single piece of spam from Vyatta. 😉
Quick reference for the commands that I used:
[set|delete|show] firewall name name rule rule-num action [accept|reject|drop]
[set|delete|show] firewall name name rule rule-num source [address address|port port|mac-address mac-addr]
[set|delete|show] firewall name name rule rule-num destination [address address|port port|mac-address mac-addr]
[set|show] interfaces ethernet ethX firewall [in|out|local] name
Items in italics are input variables. Items between brackets  are parameters.
I hope this post helps someone to understand Vyatta’s CLI (command line interface) in regards to setting up the firewalls. Also remember that all of this needs to be done in configure mode and commit needs to be run after changes have been made.
Good luck and happy networking. If you run into trouble, post here and I’ll try to respond ASAP. If this article works out well for you, let me know too. 🙂