VM-firewall: sample config and step by step debug

This post provides a "step by step" how to debug a sample config of visualization firewall.

Before trying this make sure to read main VM-firewall documentation (here)

Sample configuration

Very simple test configuration, with three steps moving from very simple toward something more realistic, you may want to use in production. If you're not a network expert, it is probably a good idea to start with step-1 to debug your configurations before moving to next level. Samples explain here are embedded within VM-firewall archive file, in directory ./FW-firewall/fw-rules/sample-stepX. If you did not download the archive yet do it now from [here]

Step-1: one unique public IP and one guest

We only open port ssh(22) on both the hypervisor and guest, for this last one its ssh is remap on port:2222

Hypervisor [Internet public IP == 91.121.173.XX]
Guest [local IP = 10.10.101.1]
Port 22 goes on hypervisor SSH
Port 2225 is forwarded to guest ssh(22)

User vision

"ssh This e-mail address is being protected from spambots. You need JavaScript enabled to view it " reach the hypervisor
"ssh -p 2221 This e-mail address is being protected from spambots. You need JavaScript enabled to view it " Guest ssh

Step-2: one public IP and two guests

Step-2 targets something more realistic with 1st guest handling mail service and second guest that handle web.

Hypervisor Internet public IP [ZONE1== 91.121.173.XX]
Guest-1 [local IP = 10.10.101.1] Service SMPT=25 POPs=995 IMAPs=993
Guest-2 [local IP = 10.10.101.2] Service HTTP=80 HTTPs=443
Port 22 goes on hypervisor SSH
Port 2211 is forwarded to guest-1 ssh(22)
Port 2212 is forwardrd to guest-2 ssh(22)

User vision

"ssh This e-mail address is being protected from spambots. You need JavaScript enabled to view it " reach the hypervisor
"ssh -p 2211 This e-mail address is being protected from spambots. You need JavaScript enabled to view it " Guest-1ssh
"ssh -p 2212 This e-mail address is being protected from spambots. You need JavaScript enabled to view it " Guest-2 ssh

Step-3: two public IPs and three guests

Same as step-2 but with TWP public IP address and an extra guest dedicated to development. on which we map port 80,8080 and 2222

Testing step-1 sample config files

Sample config files are included in VM-firewall distribution under fw-rules/sample-stepX

Installing step-1 sample

cd ./VM-firewall
Copy directory fw-rules/sample-step fw-rules/my-$HOSTNAME
Edit fw-rules/my-$HOSTNAME/1st-common.conf with your public IP address
Edit t fw-rules/my-$HOSTNAME/vz-guest1.conf with your guest local ip-adress
Display your config "Fridu-firewall display config=my-$HOSTNAME"
Validate your config as default "./install template=my-$HOSTNAME

# cd vz-rules/my-$HOSTNAME

# cat 1st-common.conf

IP_ONE=91.121.173.80

# cat zones.conf

CreateZone NAME=zOne NIC=eth0 EXT=$IP_ONE BR=venet0 INT=10.10.101.0 MASK=255.255.255.0

# cat hypervisor.conf

CreateApp NAME=SSH ZONE=none EXT=tcp:22 INT=eth0

# cat vz-guest1.conf

CreateApp NAME=SSH ZONE=zOne EXT=tcp:2225 INT=10.10.101.1:2

# Fridu-firewall display config=my-$HOSTNAME

Zones

--------------------------------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------------------------------

| zOne | eth0 | 91.121.173.80 | venet0 | 10.10.101.0 | 255.255.255.0 |

---------------------------------------------------------------------------------------------------------------------------------------------------
Applications

-----------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------

| hypervisor_SSH | none | tcp:22 | eth0 |

| vzguest1_SSH | zOne | tcp:2225 | 10.10.101.1:22 |

-------------------------------------------------------------------------------------------------------------
Zone Tuning (optional)

-------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------

Activating step-1 sample

After checking that your hypervisor public IP is effectively the one your have in your config with " ifconfig eth0 | grep inet" and that you have a guest virtual machine with the IP declared on guest1.conf with "vzlist ; ping MY-GUEST-LOCAL-IP" you are ready to activate your firewall

Fridu-firewall test config=my-$HOSTNAME timeout=300s ;# 5mn for verifying you did not dead lock your machine
iptables -L -n | grep 22 ;# verify port 22 on hypervisor is open
ssh root@MY-PUBLIC-IP ;# check from your home workstation that you can still access your hypervisor from internet
Fridu-firewall start config=my-$HOSTNAME ;# when you KNOW that you SSH is not closed you can start your firewall for real

You basic firewall is now in place we double/triple check that ssh on the hypervisor is accessible from Internet, and we can now start our real test.

Verify your config

Using Fridu-firewall display config=my-$HOSTNAME check that:

You zone point effectively on your hypervisor public IP with "ifconfig eth0 | grep inet" [here 91.121.173.80]
You have the right virtual network interface [here ifconfig venet0] (note: on openvz this interface has no address)
Make sure your effectively open the right port (here 22 and 2225)
Make sure your target the right guest IP address [here 10.10.101.1] make sure this IP is compatible with your zone netmask.
ignore tuning at this stage you don't need it.

Start your firewall

In order not to break the branch you're siting onto, it is a good practice to "test" your firewall before using "start"; By default test will start your firewall for 180s and then will stop it, you can adjust this timeout to what ever you want. When happy just replace "test" by "start"

Fridu-firewall test timeout=600 config=my-$HOSTNAME

From hypervisor: verify you can reach by ssh your guest [here ssh This e-mail address is being protected from spambots. You need JavaScript enabled to view it .1] when this is done check that your port forward 2225 is in place with "iptables -L -n | grep 2225" You should see port 2225 open for request coming your public IP [here 91.121.173.80]

From internet: Start pinging your port 2225, with " nmap MY-PUBLIC-IP -p 2225" or with "ssh -p 2225 root@MY-PUBLIC-IP". If it works you done but if is not then you have to dig a little further

WARNING: you MUST do this test from Internet, the same test from the hypervisor cannot work.

Check packet arrive on the hypervisor: while you probably thing packet must arrive, experience shows that often enough special port like 2225 can be lock at the infrastructure level. While this should not happen when running test from home, it is especially common that when running test from an enterprise that even outgoing ports are restricted.

For this we use "tcpdump -i eth0 port 2225" on the hypervisor, note that for this level of debug the only thing you need to undestand is that:

tcpdump will take the packet before your firewall, which mean that a bad config will not prevent it from viewing your "2225" packets.
you don't have to understand the output, if you see packet then it works, if you don't see anything then it does not work
When TCPDUMP is waiting on the hypervisor, restart your nmap from internet as in provious step.

Here we can see that TCPDUMP receive packets from 88.180.128.163 which is my home aDSL IP.

If you do not receive packet a this level, it mean that either you cannot send outgoing packet on port 2225 from where you are, or that your provider lock incomming port 2225 before it reaches your hypervisor. In case of doubt do the same test but with port 22 or 80 that MUST work.

WARNING; you should pass this test before moving forward as until this wont work, what ever will be your firewall config it cannot worK

Check packet are routed inside the hypervisor: the second step when packet reach your hypervisor is to make sure that they are correctly routed toward your guest. For this we will check that firewall route packets to our virtual network bridge, or to the one attached to guest zone if we have more than one bridge.

For this we use at the hypervisor level "tcpdump -i YOUR-BRIDGE-NAME port 22 and host YOU-GUEST-LOCAL-IP" . Note that we do not use anymore port 2225, because this is after port forward and if packets source IP did not change, destination is now set at guest local address/port. At his level it is a good idea to filter on both port and guest-ip in order not to be disturbed with other guests network traffic.

Check our packet arrive in our guest: last step is to make sure that our packet arrive to your guest. For this we will open a TCPDUMP directly inside targeted guest. On openvz guest interface is "venet0" for Xen,Virtualbox it is usually "eth0".

If your packet reach your guest, but your service is still not reachable from Internet, two options:

You have a firewall on your guest that lock packets. Check with "iptable -L" it should return an empty chain as in following sample.
You service [here ssh (port:22)] is not listening on your guest interface. Check with "netstat -nat | grep 22]