Fritzbox mittels Openswan mit einem Centos-Server verbinden

Hallo erstmal, es hat jetzt ein bisschen gedauert, bis ich mal wieder etwas schreibe. Vor einiger Zeit hatte ich ja meinen Homeserver auf einen vServer ausgelagert, was diverse Vorteile mit sich brachte. Allerdings war es nun schwierig, direkt mit dem Spamassassin auf dem Server zu reden, ohne den quasi für alle zu öffnen. Dazu kam dann neulich der Datenbank-Crash. Mein letztes manuelles Backup enthielt einige Änderungen noch nicht, ein automatisches Backup gabs bisher nicht. Das liegt unter Anderem auch daran, dass ich grundsätzlich keine Passwörter im Klartext auf demselben Server speichere, auf dem auch die Dienste laufen. Ich bin doch nicht blöd! Ich schreibe ja auch nicht meine PIN auf meine EC-Karte.

Also musste eine Lösung her. Mit dem Auszug des Home Servers zog eine Fritz!Box 7490 hier ein, die ja VPN (reines IPSec) kann. Der Gedanke war der: Spamassassin und Datenbankserver eben auf nem lokalen Netzwerk laufen lassen und das tunneln. Dann könnte ich das Backup-Script direkt von hier aus laufen lassen und das Thema mit dem Spamassassin wäre ganz easy.

So hab ich mir diverse Howtos aus dem Netz vorgenommen und stellte fest: es klappt nicht! (aber ohne diese Howtos wäre ich auch NIE dahinter gekommen, warum).

Hier kurz zusammengefasst ein paar Hürden:

  • der Server hat nur eine externe IP, irgendwie muss ein geschütztes virtuelles Netzwerk her.
  • die Firewall-Konfiguration muss angepasst werden
  • die Erläuterungen zur Fritzbox, die man diesbezüglich findet, sind mager
  • die Logs, wenn man nicht weiß, wo und was, sind zunächst eher verwirrend, als dass sie helfen.

Den ersten Punkt habe ich recht einfach gelöst: Ich habe dem loopback-device ein Pseudodevice hinzugefügt, das ein eigenes privates Netzwerk hat. Dazu genügt Folgendes:

cat >/etc/sysconfig/network-scripts/ifcfg-lo\:10<<„EOF“

DEVICE=lo:10
IPADDR=192.168.54.244
NETMASK=255.255.255.0
NETWORK=192.168.54.0
BROADCAST=192.168.54.255
ONBOOT=yes
NAME=lo10

EOF

Damit entsteht nun zwar kein neues Netzwerk-Device, aber das brauchen wir auch gar nicht. Unser „linksseitiges Netzwerk“ ist nun 192.168.54.0/24. Die IP-Adresse, auf der spamd und Datenbank lauschen müssen, haben wir damit auch schon festgelegt.

Die Firewall-Konfiguration ist recht einfach: in der konsole einfach system-config-firewall-tui aufrufen, dort durchs Menü hangeln und die openswan-regeln aktivieren. Fertig. (Ports 500 und 4500, beide udp werden geöffnet)

Nun installieren wir, sofern nicht schon geschehen ist, openswan:

yum install openswan

(es gibt hier einige buggy Versionen, im Falle der Fritzbox scheint das aber nicht tragisch zu sein.) Ich selbst habe mir die Mühe gemacht, mir das Ganze selbst zu compilierenund nutze Version 2.6.43.

Als Nächstes müssen wir die Konfigurationsdateien erstellen.

cat >/etc/ipsec.conf<<„EOF“

version 2.0 # conforms to second version of ipsec.conf specification

# basic configuration
config setup
# Debug-logging controls: „none“ for (almost) none, „all“ for lots.
#klipsdebug=all
#plutodebug=“all“
# For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
dumpdir=/var/run/pluto
protostack=netkey
nat_traversal=yes
virtual_private=%v4:192.168.54.0/24,%v4192.168.178.0/24
oe=off
# Enable this if you see „failed to find any available worker“
# nhelpers=

conn Site-to-Site
forceencaps=yes
pfs=yes
authby=secret
auto=add
type=tunnel
aggrmode=yes
left=<hier Server-IP eintragen>
leftid=<FQDN des Servers>
leftnexthop=%defaultroute
leftsourceip=192.168.54.244
leftsubnet=192.168.54.0/24
right=*
rightsubnet=<lokales Netzwerk der Fritzbox, z.B. 192.168.178.0/24>
rightid=%any
ike=aes256-sha2_256;modp2048
phase2=esp
phase2alg=aes256-sha2_256;modp2048

EOF

Die Sachen in spitzen Klammern müsst Ihr natürlich durch Eure eigenen Daten ersetzen, die spitzen Klammern dürfen nicht übrig bleiben! Die Stolperfallen in meinem Fall waren die Angaben right= und rightid=, die dazu führten, dass ipsec meine Fritzbox nicht anmelden wollte.

cat >/etc/ipsec.secrets<<„EOF“

<externe Server IP> %any : PSK „<wirklichlangesundfiesesPasswort>

EOF

gefolgt von

chmod 600 /etc/ipsec.secrets /etc/ipsec.conf

Nun starten wir das Ganze mit

service ipsec start

und prüfen mit

ipsec verify

ob alles in Ordnung ist.  Warnungen sind hier noch nicht wirklich ein Problem, Fehlermeldungen sollte man aber schon nachgehen. Wenn soweit alles ok ist, können wir den Dienst dauerhaft aktivieren:

chkconfig –levels 345 ipsec on

Bei der Überprüfung kann es sein, dass diverse Einstellungen bezüglich forwarding und/oder redirect bemängelt werden. Hier hilft (Achtung, Server IP einsetzen):

for vpn in /proc/sys/net/ipv4/conf/*; do echo 0 > $vpn/accept_redirects; echo 0 > $vpn/send_redirects; echo 0 >$vpn/rp_filter; done
iptables -t nat -A POSTROUTING -j SNAT –to-source <externe server ip>

das Ganze dann am Besten noch in die /etc/rc.local einfügen (vorm „exit 0“, sofern vorhanden). Das wars eigentlich auch schon serverseitig. Wie man nun Datenbank und andere Dienste auf einer zusätzlichen IP lauschen lässt, will ich hier mal auslassen.

Bei der Fritzbox kam ich ganz ohne die sonst immer benannte Konfigurationsdatei aus. Ich habe einfach die Benutzeroberfläche gewählt. Hier ist der Menüpunkt Internet -> Freigaben ->VPN für uns wichtig. Achtung: Das Benutzermenü muss dazu auf „erweiterte Ansicht“ gestellt sein. Hier klicken wir auf „VPN-Verbindung hinzufügen“.

Im nächsten Menü wird schon der für uns passende Punkt vorgegeben: „Ihr Heimnetzwerk mit einem anderen FRITZ!Box-Netzwerk verbinden (LAN-LAN-Kopplung)“ Also auf „Weiter“ klicken.

fritzvpn2

In der nächsten Eingabemaske gibts nun Einiges:

Bei „VPN-Kennwort (Preshared Key):“ kommt das lange Passwort rein, das wir auf dem Server in die /etc/ipsec.secrets eingetragen haben.

Bei Internetadresse tragen wir die IP unseres externen Servers ein.

Bei „Entferntes Netzwerk“ kommt das Netzwerk rein, das wir auf dem Server an das loopback gebastelt haben, in diesem Falle also 192.168.54.0. Insgesamt sieht das dann so aus:

fritzvpn3

Beim nächsten klick auf „OK“ wird unsere Einstellung gespeichert. Achtung, die Fritz!Box trennt jetzt kurz das Internet und verbindet dann neu. Danach sollte unser Tunnel automatisch aufgebaut werden.

 

Zur Fehlersuche, besonders, wenn z.B. der Fehler 0x001c von der Fritzbox angezeigt wird, ist es evtl sinnvoll, in der /etc/ipsec.conf „klipsdebug“ und „plutodebug“ zu aktivieren und in den Logfile /var/log/secure und /var/log/pluto.log nachzuschauen. Achtung, diese Optionen loggen wirklich VIEL! Sie sollten daher nicht eingeschaltet bleiben!

 

Viel Spaß mit dem Tunnel!

Ich jedenfalls kann nun meinen Spamassassin, der auf dem Server schon filtert, bequem von zuhause aus anlernen und auch die Datenbank-Backups demnächst automatisiert laufen lassen. 🙂

Schlagwörter: , , , , ,

10 Kommentare zu “Fritzbox mittels Openswan mit einem Centos-Server verbinden”

  1. David sagt:

    vielen dank für die Anleitung, klappt soweit auch fast alles. ipsec verify zeigt keine fehler, aber der Tunnel kommt trotzdem nicht zu standen.

    Fehler im Log in der Fritzbox:

    VPN-Fehler: XXX.XXX.XXX.XXX, IKE-Error 0x2027

    jemand eine Idee?

    1. ck10245 sagt:

      Oh, den Spaß hatte ich anfangs auch. An der Stelle versuche mal einen Portscan auf den openswan, Ports 500 und 4500, beide udp. Zumindest 500 muss open sein, 4500 wird mir als open/filtered gezeigt. Ansonsten kannst Du noch die Debug-Optionen versuchen (ganz unten im Text). Viel Erfolg!

      1. David sagt:

        der portscan zeigt mir die ports gar nicht als offen an :/ ipsec verify sagt aber:

        Pluto listening for IKE on udp 500 [OK]
        Pluto listening for NAT-T on udp 4500 [OK

        im /var/log/secure tauchen folgenden

        received Vendor ID payload [XAUTH]
        received Vendor ID payload [Dead Peer Detection]
        received Vendor ID payload [RFC 3947] method set to=109

        received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 109

        als source immer die public ip meine servers:500

        any idea? verzweifel langsam

        1. ck10245 sagt:

          hmmm… da würde ich beinahe meinen, Dein Firewall macht da noch Ärger. Ich geh mal davon aus, dass Port Forwarding auf Deinem Server aktiviert ist. Die Fehlermeldung 2027 ist ein timeout.

          1. David sagt:

            ich konnte alle Fehler behben bis auf einen:

            OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM

            no acceptable Oakley Transform

          2. ck10245 sagt:

            hmmm… da scheint Deine Fritzbox etwas bei der Anmeldung zu versuchen,w as Openswan nicht mag. Evtl stimmt auch etwas mit dem Pre shared key nicht? Ich habe den ganzen Spaß nun nicht mit dem via centos gelieferten openswan-Paket versucht, sondern habe mir das aus den aktuellen sourcen gebaut.

  2. capod3icapi sagt:

    Ich danke auch erstmal für die hervorragende Anleitung und soweit funktioniert auch alles soweit gut. Wenn ich jedoch die VPN-Verbindung in der FRITZ!Box nicht dauerhaft halten will und den IPSec-Tunnel lediglich vom Server aus starten möchte, funktioniert es nicht und bekommen folgende Fehlermeldung:

    cannot initiate connection without knowing peer IP address

    Weil ich als peer IP den DynDNS-Namen der FRITZ!Box verwende, aber warum kommt der Fehler???

    1. ck10245 sagt:

      puh, so rum hab ich das jetzt noch nicht getestet Hilfreiche Kommentare anderer User sind willkommen! Ich könnte mir vorstellen, dass das evtl mit dem dyndns-Gedöns zusammenhängt.

    2. Wird diese Fehlermeldung in der FRITZ!Box angezeigt? Und wenn ja: Wo genau? Kontaktiere uns gern mal via community@avm.de, dann sehen wir uns das Problem genauer an.

  3. Anonymous sagt:

    großartiger Artikel! Great post!
    brumm92@chaoskind.de

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Ich stimme zu.