vSphere/VMware: failed to connect virtual device ethernet0

failed to connect virtual device ethernet0

That message said hello for every single VM after there was a major breakdown in a data center. The breakdown was seen as a welcome opportunity to upgrade everything from 4.1 to 5.1. And since everything was broken anyway (although the VMs continued to run, yeah VMware ;-)) no one bothered going the proper path but just evacuated some ESXi-Hosts, re-installed them with 5.1, created a new vCenter and tried to import the VMs.

What was happening?

The GUI gave no hint as to what was wrong. But in the ESXi host logfiles something gave away what was going on: “vShield filters cannot be found for ethernet0”. Now, that is a clue, indeed!

The old 4.1 was running with everything filtered through vShield, whereas it was decided to not use vShield in this setup for 5.1 anymore. But in every single vmx-file for every VM there had to be removed the following two lines in order for everything to work as it should:

ethernet0.filter0.param1 = “uuid=5006f477-a2df-b018-b331-b2b61f1b95f9.000”
ethernet0.filter0.name = “vshield-dvfilter-module”

So, people, beware of vShield when moving VMs from one cluster to another.

All the best,

Thomas

Site-to-Site VPN, or: IPSec via IPv6

Hey there,

more and more IPv6 addresses are assigned, and since we are using IPSec-tunnels to encrypt the traffic between our branch-offices, I was wondering ‘how far has the support for IPSec via IPv6 come’?

So, I checked it out, using our Astaro (now Sophos) Firewall at work and my M0n0wall at home.

First of all, you of course need IPv6 activated on both ends and need an active connection. Wether you get that native from your provider or, for example, through https://www.sixxs.net is up to you. If you see fe80:… addresses: These are the link local addresses and do not work for us here.

Setup on the Astaro (Sophos UTM):

  • Go to ‘Site-to-Site VPN’ -> ‘IPSec’, create a ‘Remote Gateway’. We use a Preshared Key for our test setup now, in a real setup you might want to use RSA or a certificate. For the gateway you use the IPv6 WAN address of the m0n0wall. Oh, and don’t forget to add the remote networks. (This can be the whole /48 for example, no need to use several /64).
  • Then go to ‘Connections’ and create a new connection, using our just created gateway. I use TrippleDES for a policy here.
  • If you hit ‘automatic firewall rules’ your remote network gets full access to your local network. If this is unwanted, don’t do it! You can create the rules you like under ‘Network Security’ -> ‘Firewall’

All done here!

Setup on the M0n0wall:

  • Go to ‘VPN’ -> ‘IPSec’ and click the + symbol to create a new tunnel
  • For the interface chose ‘WAN’, unless you are routing internal or something (the interface should have the same IP that you chose for the remote gateway on the Astaro).
  • Enter your local subnet, I chose my /48 here.
  • Enter remote gateway (again, WAN IPv6 from the astaro)
  • Phase 1: Use 3DES, MD5, DH Keygroup 5, Lifetime 7800, PreShared Key
  • Phase 2: 3DES, MD5, Lifetime 3600

These are the values taken from the pre-existing definition for 3DES on the Astaro. You could change that, but do it on both sides.

Now just create rules what traffic you want to allow through the tunnel and which not. Remember: Both sides must fit in order for traffic to go through.

All save, all encrypted, all IPv6.

Voilà: Enjoy your Site-to-Site IPv6 tunnel.

managing iptables on linux

hey there,

as you manage more and more linux servers, you might stumble upon iptables firewalls. Especially with newer distros that happens more and more often, for example Fedora 17 and CentOS 6.3 have their iptables switched on by default.

If you now start to install services and server software, you might want to disable your firewall to test if the server responds, right? wrong!

The firewall is there for a reason, and should not just be switched off. One little trick I picked up is to always have a little shell script on hand that contains all the rules you want on your server and blocks everything else.

That way you can easily add an open port or close one, can rearrange the rules to your like and then run the script and have the firewall in place exactly as you want it to be.

This is especially helpful in case you mess up your rules or something goes wrong. You are up and running with your set of rules again in no time.

So, here goes a little basic firewall file on one of my test servers that runs a media wiki and for test purposes webmin on port 4444. It even takes into account ipv6 (same rules as for ipv4) and dumps the rules to the screen for you to see whats in place now.

all the best,

maybe

#!/bin/bash

#flush all rules
iptables -F
ip6tables -F

#allow 22 (ssh)
iptables -A INPUT -p tcp –dport 22 -j ACCEPT
ip6tables -A INPUT -p tcp –dport 22 -j ACCEPT

#allow 80 (http, the wiki)
iptables -A INPUT -p tcp –dport 80 -j ACCEPT
ip6tables -A INPUT -p tcp –dport 80 -j ACCEPT

#allow 4444 (webmin)
ip6tables -A INPUT -p tcp –dport 4444 -j ACCEPT
iptables -A INPUT -p tcp –dport 4444 -j ACCEPT

#set default policies for INPUT, FORWARD and OUTPUT chains
iptables -P INPUT DROP
ip6tables -P INPUT DROP
iptables -P FORWARD DROP
ip6tables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
ip6tables -P OUTPUT ACCEPT

#set access for localhost
iptables -A INPUT -i -lo -j ACCEPT
ip6tables -A INPUT -i -lo -j ACCEPT

#accept packets belonging to established connections
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

#save settings
/sbin/service iptables save
/sbin/service ip6tables save

#list rules
iptables -L -v
ip6tables -L -v