Home > Toolbox, VMWare > Using Vyatta as firewall in ESX/ESXi for Private network simulation, routing, firewalls, DHCP and identifying port requirements

Using Vyatta as firewall in ESX/ESXi for Private network simulation, routing, firewalls, DHCP and identifying port requirements

VMware is an amazing tool for emulating physical Firewalls, Routers, DHCP servers. It is especially useful for helping identify port requirements of various applications and tools.
Quite often, as a consultant, people ask you to implement some new product and expect you to provide all port requirements for the product, so that relevant firewall rules etc can be created – but they won’t allow you to drop anything like Wireshark on their live network.

My normal solution is to create my own ‘Private’ network on an ESX host (which could be your mobile lab)
This allows me to isolate traffic behind an ‘appliance’ firewall / router and if I like, drop a VM on that private network, to do port capture etc.

Of course, this is also a great tool for simulating routing / firewalls in your home lab, providing DHCP and so on.

In the following example, I’ll use Vyatta to build a Private network and then do some port monitoring.

First of all, we need to import the Vyatta appliance

Importing appliance
Download thje applicance form VMware Virtual Appliance store, or Vyatta’s website (you need the ESX / ESXi version)
Import Vyatta OVF (In VC, go to File – Deploy OVF template) – Follow the wizard.

Boot Vyatta (2vNics required – ideally on different vSwitches)
You’ll want one Nic attached to the public / office network and one to your new private network.
in this case, eth0 is public, eth1 is private.

We’ll make the private network be with s default gateway of on the Vyatta)
The public side of the Vyatta will be connected to Subnet and will have a gateway of
eth0 on that network will be – this address will be an endpoint for that network, unless traffic is coming from within the isolate Private network we create – we’ll create some Nat rules to allow the Private Network to get to the public network

OK, once you have imported the Vyatta, you need to connect the 2 vNics to the relevant port groups.
The first will need to be connected to a port group that has access to the network
The second can be connected to a portgroup that has been created on a vSwitch that is created on a pNic that does not even have network connectivity.

Defaul Login to vyatta is u: vyatta p:vyatta

So Let’s Configure the Vyatta

remember . . IP interfaces on Vyatta as follows

eth0 :, gw:
eth1 :, gw: none

To enter edit mode

# >configure

assign IP / SM to eth0

# >set interfaces ethernet eth0 address

assign IP / SM to eth1

# >set interfaces ethernet eth1 address

assign default gateway for Live Network

# >set system gateway-address

commit changes

# >commit

save changes

# >save

At this point, we need to configure NAT rules as the ‘Live Network’ does not know anything about our Private network, so traffic can not route back.
These will basically tell the router to ‘disguise’ traffic so tha tthe source address is the public side of the router – so a known address on the network.

# >set service nat rule 1 source address
# >set service nat rule 1 outbound-interface eth0
# >set service nat rule 1 type masquerade 
# >commit
# >save
# >exit

You can now route from the network to any other network that is attached. – if not, commit changes, save and reboot.
Of course, it may well be that you do not want this to happen, so before dropping any VMs on the new network, you’d want to enable the Firewall(I’ll do that in a bit)

If you would like the Vyatta to provide IPs on the inside of the Private network, you can do so as follows:
Configuring DHCP from the Vyatta to give IP address to the network

Enable DHCP Service (must be in edit mode)
go to edit Mode

# >configure

Enable DHCP

# >set service dhcp-server shared-network-name ETH1_POOL subnet start stop
# >set service dhcp-server shared-network-name ETH1_POOL subnet default-router
# >set service dhcp-server shared-network-name ETH1_POOL subnet dns-server
# >commit
# >save

At this point, a machine on the Private network should be able to boot and get an IP from the DHCP pool you have created, then access beyond the Vyatta box.

We now have an isolated network that has DHCP enabled and can send data requests to our Public network.
At this point, all traffic should route and no firewall rules etc should get in the way.

We said at the start that though, that we would like to use this tool to idetify port requirements etc.
Well, as the network is private, we could drop a VM on the Private network, running something like WireShark and it will catch all requests running on the network segment. Most importantly of all, it won’t get any of the usual broadcast traffic that you normally get when running Wireshark, as the only hosts on the segment are your VM and the Vyatta (which will not forward broadcasts)

If you have a second VM running the application that needs to get through the firewall, you simply need to track the requests coming form that host using Wireshark.


As a bonus though, Vyatta also has a built in port monitor:

If you would like to monitor traffic on any ethernet interface, this can be done by issuing the following command

# show interfaces ethernet eth0 capture

To quit from the capture, type ‘q’

So, what we have done is created an isolated network, with limited traffic.

The next thing to do is enable the firewall on the Vyatta and only allow ports that your application requires.
Usually, I am a great fan of the Command line (automation is always the way forward as far as I am concerned) – but doing so for large numbers of rule can be quite arduous. Luckily, Adam over at http://www.arkf.net/blog/?p=217 has created an Excel spreasheet that generates everything we’ll need to create the relevant firewall rules (nice old school automation in itself)

to enable the firewall and block all traffic, you need ot create a rule as follows:

# >set firewall name eth1 rule 9999 
# >set firewall name eth1 rule 9999 action drop
# >set firewall name eth1 rule 9999 description "Drop and log all others"
# >set firewall name eth1 rule 9999 log enable

This will again require to commit and save all changes.
We have purposely chosen the rule number as 9999, so if we create any further rules at lower numbers, they will override this one and allow the relevant bits of traffic.

If we enable the aobve rules now and then drop a Wireshark client on that network, we’ll be able to track all IP requests and calculate which ports / ips we’ll need to open

From here, the process is pretty simple, run your application on the private network, capture packets with Wireshark, create port rule (as per above) repeat process . . until your app starts to work – happy days.

For a quick scripted install, with a very similar config try:

Categories: Toolbox, VMWare Tags: ,
  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.