port security: proxying KVM MAC addresses with Debian Lenny


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

Following the desaster that occurred when we tried to install a virtual server on a dedicated Hetzner.com root server [1], we had to find a workaround for the problem.

The problem itself was that the KVM instance would use it’s own MAC address and thus port security [2] struck us hard, leaving the physical server offline for (too) many hours.

Essentially there are two types of workarounds to get things working in such a scenario:

  • use the physical server as a NAT gateway for the virtual server(s)
    the main disadvantage here is that NAT has certain problems with certain protocols (FTP or SIP for example)
  • have the physical server act as a proxy for the MAC addresses of the virtual server(s)
    the only drawback I am aware of is that you cannot use DHCP for configuring the network interfaces of the guest systems

So here comes a walkthrough for boxes running at least kernel >= 2.4 (I actually tried with a 2.6.26):

The scenario to build up will be a physical server with one network interface, containing two virtual KVM instances. Each of the KVM instances shall get an externally reachable IP address coming from a dedicated subnet and without revealing their “new” MAC addresses to anyone else but the KVM host system.

If you don’t have an entire subnet but only a couple of possibly even segmented individual IP addresses instead, skip this article and proceed to this followup article, dealing with individual IP addresses.

Prerequisites:

  • install iproute
  • install bridge-utils
  • install iputils-arping
    not actually a requirement, but very useful when testing if everything is ok

Beware that going on now might cause terrible sideeffects, (ie. rendering your KVM host being unreachable over the network), but if you do everything as explained, you should be safe πŸ™‚

so, if you like, action time:

  • reconfigure your host system’s network:
    open /etc/network/interfaces and add a br0 section like this:
    [...]
    auto br0
    iface br0 inet static
    address 192.168.80.254
    network 192.168.80.0
    netmask 255.255.255.0
    bridge_ports none
    post-up sysctl -w net.ipv4.conf.br0.proxy_arp=1
    post-up sysctl -w net.ipv4.ip_forward=1
    pre-down sysctl -w net.ipv4.conf.br0.proxy_arp=0
    pre-down sysctl -w net.ipv4.ip_forward=0
  • apply settings
    ifup br0
  • check your settings:
    % ifconfig
    br0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
    inet addr:192.168.80.254 Bcast:192.168.80.255 Mask:255.255.255.0
    inet6 addr: fe80::21c:c4ff:fedb:f3eb/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    [...]

    eth0 Link encap:Ethernet HWaddr ac:00:00:00:01
    inet addr:192.168.70.1 Bcast:192.168.70.255 Mask:255.255.255.0
    inet6 addr: fe80::21c:c4ff:fedb:f3eb/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    [...]

    Yes, scary, a “network card” with a 00:00:00:00:00 MAC address, but don’t be afraid, more is to come πŸ˜‰

  • add the virtual devices that the two virtual guests will use, add them to the bridge and make them available:

    tunctl -b -u root -t vnet0
    tunctl -b -u root -t vnet1

    brctl addif br0 vnet0
    brctl addif br0 vnet1

    ifconfig vnet0 up
    ifconfig vnet1 up

    These are manual steps, in case you have created your virtual machines using libvirtd, modify the guest configuration file in /etc/libvirt/qemu/$NAME_OF_THE_GUEST.xml and ensure that there the “bridge” interface references our br0 bridge:

    [...]
    <interface type='bridge'>
    <source bridge='br0'/>
    </interface>
    [...]
  • start up your virtual guests:

    % kvm
    -boot c
    -drive file=/location/of/virtual/hdu/vhost0.qcow2,if=virtio,index=0,boot=on
    -net nic
    -net tap,ifname=vnet0,script=no

    and for the second one:

    % kvm
    -boot c
    -drive file=/location/of/virtual/hdu/vhost1.qcow2,if=virtio,index=0,boot=on
    -net nic
    -net tap,ifname=vnet1,script=no

    and once more, if you use libvirtd, you might also use virsh or virt-manager to start up the two virtual guests.
  • configure the network of your guests:
    If your guests are Debian based again, open /etc/network/interfaces for each guest and configure it, for the first one:
    auto eth0
    iface eth0 inet static
    address 192.168.80.1
    network 192.168.80.0
    netmask 255.255.255.0
    # the gateway is the IP of the br0 bridge on the KVM host
    gateway 192.168.80.254

    and for the second one:

    auto eth0
    iface eth0 inet static
    address 192.168.80.2
    network 192.168.80.0
    netmask 255.255.255.0
    # the gateway is the IP of the br0 bridge on the KVM host
    gateway 192.168.80.254

That should be it. Not exactly “extremely simple”, but still not too complicated either πŸ™‚

You can test your configuration by pinging around on the guest systems. You should be able to ping 192.168.80.254 (the br0), 192.168.70.1 (eth0 on the host). If however you ping other machines, say 192.168.1.123, you would need a route back from it to the 192.168.80.0 subnet. The “router” for that subnet is 192.168.80.254 then. But typically this is handled by your “real” routers (and is beyond the scope of this already far too long posting πŸ™‚

Happy hacking!

[1] http://riaschissl.blogs.bestsolution.at/2009/06/05/scary-and-incompetent-support-at-hetzner-com/
[3] http://lartc.org/howto/lartc.bridging.proxy-arp.html
[4] http://www.sjdjweis.com/linux/proxyarp/

Spread the love

2
Leave a Reply

avatar
2 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
1 Comment authors
theselAnonymous Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
Anonymous
Guest
Anonymous

So. Do I get get correctly that you’re unable to connect directly to Host and Guest at the same time?

Ideal setup would be – if you have 2 IP’s given by Hetzner, have host under 1st and guest under 2nd.

thesel
Guest

the “problem” if you like is that port security is active at Hetzner, meaning that you will get locked out of the entire network if you use other than the expected MAC addresses. The “only” MAC address allowed is the one of the main server (“the host”).

And that is why you need to “hide” the MAC addresses of your virtual guests from the port that the physical server is connected to.

Post Navigation