Building a Xen firewall with Firewall Builder

Original post date: March 30th, 2011
Updated: April 4th, 2011 (missing rule in prolog)

It's a kind of a problem to manage a firewall for a Xen dom0 with firewall builder. Xen itself adds forwarding rules when starting a virtual machines, and these rules are wiped away when fwbuilder scripts install theirs, which is unfortunate.

Summing up everything, the final plan was to install a firewall on dom0, which should a) forward to the VM the packets originating outside and directed to them (and back), and b) protect the dom0 itself.

It took me some time, experiments and advice to get it right, and here's how. … Continue reading

/proc/sys/net/ipv4/conf/all (and source routing in particular)

I was trying to find out if certain Linux machines allowed source routing or not. To do this, it should be enough to just take a peek into /proc/sys/net/ipv4/conf/*/accept_source_route. But, as it seems, the results are contradictory. Look at what I have on my workstation:

root@brabham:/proc/sys/net/ipv4/conf# for IF in * ; do echo -n "$IF: " ; cat $IF/accept_source_route ; done
all: 0
default: 1
eth0: 1
lo: 1
vboxnet0: 1

Now, if you look up how the settings in the "all" directory actually work, you'll see that a few talk about that, and those who do don't give much detail. This always rings a bell in my head, as it is a symptom that nobody actually knows exactly how it works, and those who do just don't write enough 🙂 E.g., a source writes:

The /proc/sys/net/ipv4/conf/ directory allows each system interface to be configured in different ways, including the use of default settings for unconfigured devices (in the /proc/sys/net/ipv4/conf/default/ subdirectory) and settings that override all special configurations (in the /proc/sys/net/ipv4/conf/all/ subdirectory).

Now, the last sentence does not make sense if you read it carefully, because that would make the per-interface subdirectories useless. In fact, if this was really the case, you could not, e.g., accept source routing on one interface and disable it on all the others, because the value in "all" would have priority.

So after some research I tried to ask to the most Linux informed person I know, one that I can safely mention without having to check the sources. And he told me that the "all" subdirectory was born as a shortcut to help changing the configuration on all interfaces simultaneously, but then evolved in an incoherent fashion, to the point that different settings work in different way (e.g.: one setting in all may override the per-interface setting, while others will do a boolean OR between all and the interface-specific value, while others again will do an AND). If you want to know how it goes in a specific case, you need to read the kernel code.

OK, now I have the confirmation that /proc/sys/net/ipv4/conf/*/accept_source_route is a minefield, but I did not make a step forward. In my specific case, that is the accept_source_route setting, how does it work?

Well, it turns out that it's a logical AND between "all" and the interface-specific value. Good to know.

Thanks Francesco 😉

Restoring Xen’s iptables rules

Those of you that use Xen may have noticed that, by default, Xen adds some iptables rules when a VM starts, so to ensure that some specific packets are actually forwarded to the virtual machines. If, for any reason, those rules are wiped away, it would be nice to recover them, wouldn't it?

I found out it's quite easy. The following script will just echo the iptables commands so you can safely test it on a running dom0. If it does something that you actually need, just wipe those echo's away!

#!/bin/bash

xm list | perl -alne 'next if not $F[1] > 0 ; print "@F[0,1]"' | while read VM ID 
do
  xm network-list $ID | perl -alne 'next if not $F[0] =~ m{^d+$} ; print $F[0]' | while read IFID
  do
    VIF="vif$ID.$IFID"
    echo iptables -A FORWARD -m physdev --physdev-in $VIF -s $VM -j ACCEPT
    echo iptables -A FORWARD -m physdev --physdev-in $VIF -p udp --sport bootpc --dport bootps -j ACCEPT
  done
done

I am using Perl here because I know it better than awk, but I am sure that awk can accomplish the same task as well as perl does.

Internet lingo: +1

Today I quickly answered to an email from my sister with a "+1". I couldn't imagine that it would have puzzled her so much, or pulled an incorrect explanation from my brother 🙂 So, what does "+1" mean?

It's simple: it just means "those who are counting how many agree with this, please add one", or simply put: "I agree".

I know, we internet junkies look complicated sometimes. But we aren't, are we? 😉

Bug in AppConfig 1.56?

For example, suppose you define three scalar variables, named alpha, beta and gamma, and suppose that when you set them you first declare an unknown variable named delta. E.g.: you have this configuration file:

delta = D
alpha = A
beta  = B
gamma = G

Depending on the value of CREATE and PEDANTIC, you'll have different results, namely:

CREATE PEDANTIC alpha beta gamma delta
not set not set A B G undef
not set set to 0 A B G undef
not set set to 1 undef undef undef undef
set to ^[a-z_] not set A B G D
set to ^[a-z_] set to 0 A B G D
set to ^[a-z_] set to 1 A B G D

But if you run your script setting stuff in the same way, e.g.:

script.pl -delta D -alpha A -beta B -gamma G

results are completely different, namely:

CREATE PEDANTIC alpha beta gamma delta
not set not set undef undef undef undef
not set set to 0 undef undef undef undef
not set set to 1 undef undef undef undef
set to ^[a-z_] not set undef undef undef undef
set to ^[a-z_] set to 0 undef undef undef undef
set to ^[a-z_] set to 1 undef undef undef undef

The only values that correspond in the two cases are those marked in yellow. Is this the intended behaviour? I don't know, I hope I'll have an authoritative response from the module authors.

locales and Ubuntu 10.10

Today, during an upgrade of my workstation's 10.10, I noticed that a lot of unneeded EN locales were being generated, and I wanted to get rid of them. Coming from a debian background, I confidently ran dpkg-reconfigure locales, but instead of getting the usual interface I got

root@brabham:~# dpkg-reconfigure --priority=low locales
Generating locales...
  en_AG.UTF-8... up-to-date
  en_AU.UTF-8... up-to-date
  en_BW.UTF-8... up-to-date
  en_CA.UTF-8... up-to-date
  en_DK.UTF-8... up-to-date
  en_GB.UTF-8... up-to-date
  en_HK.UTF-8... up-to-date
  en_IE.UTF-8... up-to-date
  en_IN.UTF-8... up-to-date
  en_NG.UTF-8... up-to-date
  en_NZ.UTF-8... up-to-date
  en_PH.UTF-8... up-to-date
  en_SG.UTF-8... up-to-date
  en_US.UTF-8... up-to-date
  en_ZA.UTF-8... up-to-date
  en_ZW.UTF-8... up-to-date
  it_CH.UTF-8... up-to-date
  it_IT.UTF-8... up-to-date
Generation complete.

Odd, isn't it? Well, it turns out that, in order to get rid of the locales you don't want, you have to manually change the files in /var/lib/locales/supported.d. Oh, dear…

OK, Canonical claims to create "Linux for the human beings". I partially agree with that. But I would like to know how removing the ncurses interface to locales could possibly make the system simpler. I mean: "common" users just won't care if they have 100 locales instead of 10, so it doesn't matter for them. We "advanced users" can edit plan text files, for sure, but is that a good reason to remove a convenient interface from the system?

Ubuntu really puzzles me sometimes…

Drawing puppet class relationships with graphviz

In the last few days, I got the impression that my puppet class hierarchy was growing a bit out of control. In particular, it looked like "glue" classes aimed to simplify stuff were actually causing more harm than benefit. How I found out? Well, it was getting too complicated to understand what included what, and walking the classes by hand quickly became a terrible task.

So, I decided to go for something that could do the work for me: go through my modules, get the include statements, and draw the relationships. Luckily, I remembered I saw that graphviz was designed explicitly to ease that latest task. … Continue reading

OpenIndiana to release soon?

As you may know, after Oracle sunk OpenSolaris :rip: a couple of new project arose: one was Illumos, which took the development of the core from where it stopped, and started with rebuilding the "less open"-licensed stuff, and OpenIndiana, which focused on a whole operating system; OpenIndiana starts on the OpenSolaris base, but will eventually use Illumos for the core stuff.

Well. After about 6 months that OpenSolaris was unofficially declared dead, project OpenIndiana is planning its first official release.

Let's see what happens 🙂

:bye: