OpenVSwitch Experiment mit Ubuntu und VMware Workstation

openvswitch-logoMotivation? Ich wollte mich etwas in OpenVSwitch einarbeiten. „Nice to know“ halt und dümmer wird man ja auch nicht. Dazu habe Ich auf einem Rechner mit zwei Netzwerkkarten einen Ubuntu LTS 14.04 Server aufgesetzt und diesen mit einem Enlightenment E20 Desktop ausgestattet. Anschliessend noch OpenVSwitch und VMware Workstation installiert. Die Netzwerkschnittstellen wurden in einem einem Bond0 an einen HP Switch als LACP active Trunk angebunden. Zwei interne Ports wurden angelegt, die als Access Port für ein VLAN dienen. Diese dann anschliessend als „vmnet0“ in die virtuelle Ubuntu Test-VM unter Vmware Workstation eingebunden. Hier ein Screenshot vom Setup:
Ubuntu_Test_1

Ich habe erst mal ein Interface in die Bridge eingebunden. Dazu musste ich einen OpenVSwitch  mit dem Hardwareinterface „em1“ erzeugen und dann „vlan100“ und „vlan151“ als interne Ports konfigurieren:
ovs-vsctl add-br br0
ovs-vsctl add-port br0 em1
ovs-vsctl set port em1 trunks=100,151 # wenn man nur spezielle VLANS erlauben will
ovs-vsctl add-port br0 vlan100 tag=100 — set interface vlan100 type=internal
ovs-vsctl add-port br0 vlan151 tag=151 — set interface vlan151 type=internal

Nun kann man sich den VSwitch und seine Konfiguration anzeigen lassen. In diesem Screenshot sieht man die erst später erzeugte Bond/Trunk Konfiguration:
ovs-vsctl show
Ubuntu_Test_2_lacp

Danach das gleiche Setup mit zweitem Interface und LACP zum HP Switch konfigurieren. Dazu muss das bereits hinzugefügte Interface „em1“ zuerst entfernt und neu im „bond0“ hinzugefügt werden:
ovs-vsctl del-port br0 em1
ovs-vsctl add-bond br0 bond0 eth0 em1 lacp=active  

Nun wieder die erstellte Konfiguration anzeigen lassen und prüfen mit
ovs-appctl lacp/show bond0

Auf dem HP Switch wird der LACP Trunk sofort als aktiv angezeigt:
Ubuntu_Test_4_lacp Ubuntu_Test_3_lacp

Let’s Encrypt unter Ubuntu mit Apache / Postfix / Dovecot

Kurz notiert für die Freunde der SSL Verschlüsselung: Let’s Encrypt ist am Start in der Public Beta. Ich habe mir direkt mal ein Zertifikat für klehr.de ausstellen lassen und eingebunden. Dazu wird ein Client installiert mit dem man den CSR ausstellt. Die Anforderung muss von der Server-IP gesendet werden, worauf der A-Record der Domaine.tld zeigt! Alles andere wird mit einem „urn:acme:error:unauthorized :: The client lacks sufficient authorization“ abgelehnt.

Zuerst benötigt man GIT auf dem Server:
apt-get install git
Dann zieht man sich das aktuelle Letsencrypt Verzeichnis:
git clone https://github.com/letsencrypt/letsencrypt
Nun wechselt man in das angelegte Verzeichnis und führt das „letsencrypt-auto“ Script aus:
./letsencrypt-auto certonly –standalone -d domaine.tld -d www.domaine.tld -d mail.domaine.tld
Es wird nun unter /etc ein Ordner „letsencrypt“ erzeugt mit dem Zertifikat und privaten Schlüssel:
root@ubuntu / # l /etc/letsencrypt/live/domaine.tld/
1575405 lrwxrwxrwx 1 root root   32 Dec  4 08:43 cert.pem -> ../../archive/domaine.tld/cert1.pem
1575407 lrwxrwxrwx 1 root root   33 Dec  4 08:43 chain.pem -> ../../archive/domaine.tld/chain1.pem
1575408 lrwxrwxrwx 1 root root   37 Dec  4 08:43 fullchain.pem -> ../../archive/domaine.tld/fullchain1.pem
1575406 lrwxrwxrwx 1 root root   35 Dec  4 08:43 privkey.pem -> ../../archive/domaine.tld/privkey1.pem

Jetzt kann man seinen Apache Webserver und/oder Mailserver mit diesen neuen Zertifikaten bestücken. z.B. in der Apache SSL Konfiguration:
SSLCertificateFile      /etc/apache2/sites-available/domaine.tld/cert.pem
SSLCertificateKeyFile   /etc/apache2/sites-available/domaine.tld/privkey.pem
SSLCACertificateFile /etc/apache2/sites-available/domaine.tld/fullchain.pem

Mehr Infos unter https://letsencrypt.org/howitworks/

Sophos XG Firewall – Erste Eindrücke

Sophos_XG_LogoMontagmorgen. Mal schnell die neue OVF der Firewall XG hochgeladen und… ja… und… erst mal nix. Erst mal muß ein total nerviger Aufwand mit der Registrierung betrieben werden um überhaupt die ersten Gehversuche zu machen. Die Konsole ist gesperrt und man kann nicht mal eben mit ifconfig die IP ins interne LAN setzen, sondern muss einen Clientrechner ins 172er Netz bringen um die quälende Prozedur der Registrierung hinter sich zu bringen. Ich hasse es wenn es mir so schwer gemacht wird. Ein offline Test ist also absolut unmöglich. Den Rechner erst mal ins Netz der XG packen, z.B. 172.16.16.100/24. Dann sollte die Default-IP der XG mit 172.16.16.16 erreichbar sein.
Install_1Install_2
Jetzt mit dem Browser über https://172.16.16.16:4444 die Grundeinrichtung vornehmen:
Install_4 Install_5 Install_6
Wenn man diese ganze Prozedur über sich hat ergehen lassen, so kann man endlich das Dashboard in Augenschein nehmen. Erster Eindruck von mir – das will man nicht 🙁
DASHBOARD_0
Das wird einige Zeit dauern bis man sich von einer UTM auf die neue XG „umgewöhnt“ hat. Hier einige weitere Impressionen der Oberfläche. Was beim VPN auffällt: wo sind die RED Tunnel? Schnell im FAQ nachgesehen -> ist noch nicht drin 🙁    Sophos XG FAQ
VPN_1So sehen die neuen Seiten für die Firewallregeln aus:
FW_1 FW_2       FW_3

Jetzt werde ich erst mal den ersten Eindruck setzen lassen und eine Migration von einer bestehenden UTM ausprobieren. Die meisten Migrationen werden wohl erst mal an dem nicht vorhandenen RED Device scheitern, welches ich für das OSPF Routing benötige….

Veeam Quick Migration für VCenter Server

Nachdem alle unsere virtuellen Server und Desktops auf die neue Nutanix Umgebung migriert wurden, blieb nur noch das VCenter übrig. Dank der VMware Enterprise Lizenz sollte Storage vMotion kein Thema sein, aber irgendwie hatte ich Bedenken das VCenter damit zu migrieren. Zu schlecht sind die Erfahrungen irgendwelche Operationen durchzuführen wenn das VCenter Aufgaben mit sich selbst ausführen soll. Aber Veeam hat ein sogenanntes „Quick Migration“ Feature. Dieses ist in der Lage mittels „Smart/Cold-Switch“ virtuelle Maschinen auch ohne VCenter/Datacenter oder gar zwischen verschiedenen Standalone Hosts zur Laufzeit zu verschieben. Ein paar Klicks später lief das VCenter auf dem neuen Cluster. Ohne Downtime.
Veeam-Quick-Migration

Sophos UTM: Kundenprojekt im Rechenzentrum von LuxConnect

Sophos-D2Ein schönes Kundenprojekt welches hier Erwähnung finden sollte: Ich habe für einen der größten deutschen Kaffeehersteller im Rechenzentrum „LuxConnect“ in Luxemburg eine alte Firewall durch einen Sophos UTM Cluster abgelöst. Die von mir damals installierte und in die Jahre gekommene Linuxfirewall mit Heartbeat, IPTables und OpenVPN musste ersetzt werden. Da die Sophos UTM ebenfalls eine sehr gute Unterstützung von OpenVPN bietet, konnten die bestehenden Standorte an die neue UTM angebunden werden, ohne jede Außenstelle mit neuer Firewallhardware zu versorgen. Diese können nun ohne Zeitdruck sukzessive ausgewechselt werden. Vorhandene IPSEC Tunnel konnten ebenfalls ohne Probleme migriert werden. Eine weitere aktuelle Success Story zu Sophos UTM finden Sie unter der Rubrik „Projekte„.