Warning: in_array() expects parameter 2 to be array, string given in /virtual/theblogs.bestsolution.at/httpd/htdocs/wp-content/plugins/google-one/google-plus-one.php on line 344

Warning: in_array() expects parameter 2 to be array, string given in /virtual/theblogs.bestsolution.at/httpd/htdocs/wp-content/plugins/google-one/google-plus-one.php on line 346

Debian+KVM: proxy_arp for individual ip adresses


Warning: in_array() expects parameter 2 to be array, string given in /virtual/theblogs.bestsolution.at/httpd/htdocs/wp-content/plugins/google-one/google-plus-one.php on line 344

Warning: in_array() expects parameter 2 to be array, string given in /virtual/theblogs.bestsolution.at/httpd/htdocs/wp-content/plugins/google-one/google-plus-one.php on line 346

In one of my older posts [1] I described how you can hide the MAC addresses of KVM virtualized guests living in a dedicated, externally reachable subnet.

If however you don’t have a dedicated subnet from your hosting provider but only got only a small number of maybe segmented IP addresses instead of an entire subnet, the solution is much simpler.

So, let’s say this is what you want:

  • a host
    living under 192.168.10.10 with a netmask of 255.255.255.0
  • a KVM guest
    designated to live under 192.168.10.20
  • another KVM guest
    designated to live under 192.168.10.30

Due to port security, each of the guests must not reveal their (virtual) MAC addresses to any external communication partner.

For a Debian lenny host, the following prerequisites are required

  • install iproute
  • install uml-utilities

Using uml-utilities (uml = user mode linux), you can setup virtual network interfaces useable by the KVM guests.

In order to get things going, add the following lines to /etc/network/interfaces

[...]
auto tap0
iface tap0 inet manual
  tunctl_user root
  uml_proxy_arp 192.168.10.20
  uml_proxy_ether eth0
  up ip link set tap0 up
  post-up sysctl -w net.ipv4.ip_forward=1
  post-up sysctl -w net.ipv4.conf.tap0.proxy_arp=1
  pre-down sysctl -w net.ipv4.ip_forward=0
  down ip link set tap0 down

auto tap1
iface tap1 inet manual
  tunctl_user root
  uml_proxy_arp 192.168.10.30
  uml_proxy_ether eth0
  up ip link set tap1 up
  post-up sysctl -w net.ipv4.conf.tap1.proxy_arp=1
  down ip link set tap1 down

The lines above create two to called “tap” devices tap0 and tap1, using the utilites provided by user mode linux (somewhat like an alternative to KVM, vmware, …). Due to severe Debian magic, the lines also enable proxy_arp for the new devices and tell the kernel to use the MAC address of eth0 instead:

% ifup tap0
[...]
% arp -an
[...]
? (192.168.10.20) at PERM PUB on eth0
% cat /proc/sys/net/ipv4/conf/tap0/proxy_arp
1

And still better, even a specific device route is created:

% route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.10.20 0.0.0.0 255.255.255.255 UH 0 0 0 tap0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.10.254 0.0.0.0 UG 0 0 0 eth0

If you ifup tap1 as well, you will see further entries like the ones above.

[sidenote]: User mode linux is quite a funny thing to play with, a good starting point for further reading is this link [2].

The only thing remaining for you is to instruct your KVM guests to use their new, dedicated devices. You can do so manually by ensuring that the guests are started with the following options set:
% kvm
[...]
-net nic
-net tap,ifname=tap0,script=no
[...]

and for the other guest
% kvm
[...]
-net nic
-net tap,ifname=tap1,script=no
[...]

If you use the libvirt daemon, you can alternatively update the guest’s xml definition like this:


[...]
<interface type='ethernet'>
<target dev='tap0'/>
</interface>
[...]

and for the other guest of course:


[...]
<interface type='ethernet'>
<target dev='tap1'/>
</interface>
[...]

If you now configure your guests to use once 192.168.10.20 and once 192.168.10.30, you should be able to ping other hosts without revealing the guest’s virtual mac addresses. That can be tested using arp again on the targeted hosts, eg.

In the first guest with an ip address of 192.168.10.20, start a ping against 192.168.10.254:
% ping 192.168.10.254
PING 192.168.10.254 (192.168.10.254) 56(84) bytes of data.
64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=1.76 ms
[...]

Then log into 192.168.10.254 and use arp to verify the mac address used:
% arp -an
[...]
? (192.168.10.20) at ac:00:00:00:01 [ether] on eth0
[...]

The mac address found (AC:00:00:00:01) should be the same as the KVM hosts physical network card.

Beware once more, that any “proxy_arp” style solution one major drawback: you cannot use DHCP to configure your virtual guests, because a DHCP server has no way to determine their (virtual) mac address.

Happy hacking again 🙂

[1] http://riaschissl.blogs.bestsolution.at/2009/06/08/port-security-proxying-kvm-mac-addresses-with-debian-lenny/
[2] http://user-mode-linux.sourceforge.net/old/UserModeLinux-HOWTO.html

Spread the love

4
Leave a Reply

avatar
4 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
1 Comment authors
iMxAnonymouswebwurst Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
webwurst
Guest
webwurst

Hi!

I get an error message using the setup you propose. After editing /etc/network/interfaces and restarting network the tun0 device shows up. I changed the libvirt-xml-file accordingly, but when i start the domain it shows this:

error: internal error unable to start guest: /etc/qemu-ifup: could not launch network script
qemu: could not initialize device ‘tap’

Any Idea?

Cheers!
Tobias Bradtke

webwurst
Guest
webwurst

Ok, this seems to be an Ubuntu Karmic specific problem.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/475327

But the “ugly fix” shown there does not work for me..

Anonymous
Guest
Anonymous

Webwurst,

1) Try fireup kvm from command line (command used to start kvm is available in /var/log/libvirt) and add -script=no.
This error might exists because device exists already when kvm tries to create it, this option prevents kvm from mangling with network setup before it starts.
2) If issue still exists, try again to fireup kvm from command line but ensure that tap0 is owned by root, and kvm is started by root. (If i remember correctly I had same issue when tried to start kvm using tap0 created for standard user).

iMx
Guest

error: internal error unable to start guest: /etc/qemu-ifup: could not launch network script

If you get the above error, and like me prefer to use virt-manager/libvirt xml files… you need to add the following to you interface config; rather than running from cli as suggested above:

script path=’no’

With the < />

Post Navigation