by Mike Sawicki
Part 1 : Introduction and Command Language
Here at DefaultRoute we’re utilizing Vyatta, an open source networking platform, at an increasing rate. I’ve found that it runs very well within a virtualized environment and can handle impressive traffic levels when coupled with the right hardware. There are certainly dozens of applications where you would not want to use Vyatta, such as in the carrier space – but it’s excellent for edge applications and routing the virtual datacenter.
I’m a big fan of using the right tool for the right job. Vyatta’s marketing and documentation advertise the product as a “networking appliance” capable of doing almost everything for you. As of the time of this writing I have not used Vyatta in any role other than as a router, so I can’t really speak much on its abilities as a firewall, traffic shaper, vpn concentrator or any of the other devices this thing is intent on being. I can say that as a router Vyatta has saved me a bunch of time in both setup and testing of a home-brewed routing platform. Aside from having to learn the bipolar(see below) configuration language and experiencing facepalm on more than one occasion, it has been smooth sailing for the most part.
As a long in the tooth UNIX hacker, it’s my preference to roll my own solution when it comes to building dedicated systems with a specific purpose. Starting simply makes it easy to add precisely the features needed to get the job done. The resulting creation will be acceptably secure and reliable since it hasn’t been doctored it too much. While this method is satisfying and probably the right thing to do, it takes a great deal of research and time. Due to my increasingly complicated life and schedule, I’ve become more interested in the various free options popping up right and left for these kinds of systems. Under the hood most of these projects are the same thing; a free *NIX variant of some sort, using the predominantly popular tool x for solving problem y with the most community support. Most of these projects focus on ease of use and a pretty GUI to bring the technical under-the-hood power to the masses. Since I fundamentally agree with all of that it seemed like I should investigate becoming a user myself.
I think it’s important to get some of my gripes out of the way before we get into the meat of my message. First off, the Vyatta GUI is awful and embarrassingly incomplete. I don’t know if it gets better if you pay but I really hope so. Thankfully we’ll be focusing on the command line in any/all of my examples on this site in the future. Secondly, as mentioned above, the configuration language is officially saved in a hierarchical format which is logical but not always humanly readable, while it is manipulated interactively via a standard command language featuring intuitive commands such as set, delete, show, etc. The latter is certainly more in line with just about any major commercial or free platform which performs the kinds of roles which Vyatta considers cousins. I really have yet to understand why they did this. An example will explain this thought easier.
Cisco IOS commands to lock down a router’s vty from a single, trusted IP network:
access-list 50 permit x.y.z.0 0.0.0.255
line vty 0 4
access-class 50 in
Now, Vyatta:
firewall {
name local-protect {
default-action drop
rule 4 {
action accept
destination {
}
protocol tcp
source {
address x.y.z.0/24
}
}
rule 10 {
action reject
destination {
port ssh
}
protocol tcp
source {
address 0.0.0.0/0
}
}
}
}
interfaces {
ethernet eth0 {
firewall {
local {
name local-protect
}
}
}
}
I know that “humanly readable” is rather subjective, but over the years I’ve learned to read the Cisco language using a special part of my brain that loves to save time. The Vyatta language is overly complex. Thankfully, there’s an interactive language which I mentioned earlier. It behaves more like CatOS or the other countless interfaces I’ve seen over the years. So I’ve chosen to do almost all of my work using the interactive language.
Example:
set firewall name local-protect default-action 'drop'
set firewall name local-protect rule 4 action 'accept'
set firewall name local-protect rule 4 'destination'
set firewall name local-protect rule 4 protocol 'tcp'
set firewall name local-protect rule 4 source address 'x.y.z.0/24'
set firewall name local-protect rule 10 action 'reject'
set firewall name local-protect rule 10 destination port 'ssh'
set firewall name local-protect rule 10 protocol 'tcp'
set firewall name local-protect rule 10 source address '0.0.0.0/0'
set interfaces ethernet eth0 firewall local name 'local-protect'
See? Much better. However, it’s still lacking the simplicity I’d prefer.
So there’s an intro from my perspective. Part 2 will cover deployment within VMware.