[Problem] VPN zwischen Fritzbox und Strongswan

[vice_pres]

Moin,

Da ich plane (zumindest teilweise, vielleicht auch ganz) auf den Fritzboxen von OpenVPN auf AVM-VPN umzusteigen (um teilweise auf Freetz verzichten zu können das nur wegen openvpn im Einsatz ist) hab ich probiert mein funktionierenden Strongswan auf meinem Root-Server anzupassen damit die Verbindung funktioniert. Dabei habe ich aber Probleme und Fragen die mir keiner bisher beantworten konnte:

- Ich möchte mehr als ein /24 Netz routen, da sich 3 Fritzboxen auf den Strongswan Server verbinden sollen und die Kommunikation untereinander möglich sein soll. 192.168.0.0/24, 192.168.1.0/24, 192.168.3.0/24 - daher habe ich 192.168.0.0/22 als Maske genommen.

Die Verbindung kommt (teilweise) zustande:

ike.log

2016-02-04 08:10:21 avmike:<remote FQDN>: Warning: source changed from 0.0.0.0:500 to <remote ip>:500
2016-02-04 08:10:21 avmike:mainmode <remote FQDN>: selected lifetime: 3600 sec(no notify)
2016-02-04 08:10:21 avmike:<remote FQDN> remote peer supported XAUTH
2016-02-04 08:10:21 avmike:<remote FQDN> remote peer supported DPD
2016-02-04 08:10:21 avmike:<remote FQDN> remote peer supported NAT-T RFC 3947
2016-02-04 08:10:22 avmike:<remote FQDN>: Warning: source changed from 0.0.0.0:500 to <remote ip>:500
2016-02-04 08:10:22 avmike:mainmode <remote FQDN>: add SA 1
2016-02-04 08:10:22 avmike:<remote FQDN>: switching to NAT-T (Initiator)
2016-02-04 08:10:22 avmike:<remote FQDN>: Warning: source changed from 0.0.0.0:500 to <remote ip>:4500
2016-02-04 08:10:22 avmike:<remote FQDN>: Phase 1 ready
2016-02-04 08:10:22 avmike:<remote FQDN>: current=0.0.0.0 new=<remote ip>:4500
2016-02-04 08:10:22 avmike:<remote FQDN>: no valid sa, reseting initialcontactdone flag
2016-02-04 08:10:22 avmike:<remote FQDN>: remote is behind a nat
2016-02-04 08:10:22 avmike:<remote FQDN>: sending initial contact message
2016-02-04 08:10:22 avmike:<remote FQDN>: start waiting connections
2016-02-04 08:10:22 avmike:<remote FQDN>: Phase 2 starting (start waiting)
2016-02-04 08:10:52 avmike:mainmode <remote FQDN>: del SA 1
2016-02-04 08:10:52 avmike:wolke_neighbour_renew_sa 0 SAs
2016-02-04 08:10:52 avmike:wolke_neighbour_renew_sa 0 SAs RENEW
2016-02-04 08:10:52 avmike:<remote FQDN>: Phase 1 starting (renew)
2016-02-04 08:10:52 avmike:< cb_sa_create_failed(name=<remote FQDN>,reason=IKE-Error 0x2027)
2016-02-04 08:10:52 avmike:mainmode <remote FQDN>: selected lifetime: 3600 sec(no notify)
2016-02-04 08:10:52 avmike:<remote FQDN> remote peer supported XAUTH
2016-02-04 08:10:52 avmike:<remote FQDN> remote peer supported DPD
2016-02-04 08:10:52 avmike:<remote FQDN> remote peer supported NAT-T RFC 3947
2016-02-04 08:10:52 avmike:mainmode <remote FQDN>: add SA 2
2016-02-04 08:10:52 avmike:<remote FQDN>: Phase 1 ready
2016-02-04 08:10:52 avmike:<remote FQDN>: current=<remote ip>:4500 new=<remote ip>:4500
2016-02-04 08:10:52 avmike:<remote FQDN>: local is behind a nat
2016-02-04 08:10:52 avmike:<remote FQDN>: remote is behind a nat
2016-02-04 08:10:52 avmike:<remote FQDN>: start waiting connections
2016-02-04 08:10:52 avmike:<remote FQDN>: NO waiting connections

log auf dem Host:

Feb  4 08:10:03 <remote> charon: 16[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Feb  4 08:10:03 <remote> charon: 16[IKE] sending XAuth vendor ID
Feb  4 08:10:03 <remote> charon: 16[IKE] sending DPD vendor ID
Feb  4 08:10:03 <remote> charon: 16[IKE] sending NAT-T (RFC 3947) vendor ID
Feb  4 08:10:03 <remote> charon: 16[ENC] generating ID_PROT response 0 [ SA V V V ]
Feb  4 08:10:03 <remote> charon: 16[NET] sending packet: from <remote IP>[500] to <local DYN IP>[500] (136 bytes)
Feb  4 08:10:03 <remote> charon: 10[NET] sending packet: from <remote IP>[500] to <local DYN IP>[500]
Feb  4 08:10:04 <remote> charon: 09[NET] received packet: from <local DYN IP>[500] to <remote IP>[500]
Feb  4 08:10:04 <remote> charon: 09[NET] waiting for data on sockets
Feb  4 08:10:04 <remote> charon: 05[NET] received packet: from <local DYN IP>[500] to <remote IP>[500] (228 bytes)
Feb  4 08:10:04 <remote> charon: 05[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
Feb  4 08:10:04 <remote> charon: 05[IKE] local host is behind NAT, sending keep alives
Feb  4 08:10:04 <remote> charon: 05[CFG]   candidate "fritz-3", match: 1/1/2076 (me/other/ike)
Feb  4 08:10:04 <remote> charon: 05[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
Feb  4 08:10:04 <remote> charon: 05[NET] sending packet: from <remote IP>[500] to <local DYN IP>[500] (244 bytes)
Feb  4 08:10:04 <remote> charon: 10[NET] sending packet: from <remote IP>[500] to <local DYN IP>[500]
Feb  4 08:10:04 <remote> charon: 09[NET] received packet: from <local DYN IP>[4500] to <remote IP>[4500]
Feb  4 08:10:04 <remote> charon: 09[NET] waiting for data on sockets
Feb  4 08:10:04 <remote> charon: 04[NET] received packet: from <local DYN IP>[4500] to <remote IP>[4500] (108 bytes)
Feb  4 08:10:04 <remote> charon: 04[ENC] parsed ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
Feb  4 08:10:04 <remote> charon: 04[CFG] looking for pre-shared key peer configs matching <remote IP>...<local DYN IP>[<local DYN FQDN>]
Feb  4 08:10:04 <remote> charon: 04[CFG]   candidate "fritz-3", match: 1/20/2076 (me/other/ike)
Feb  4 08:10:04 <remote> charon: 04[CFG] selected peer config "fritz-3"
Feb  4 08:10:04 <remote> charon: 04[IKE] IKE_SA fritz-3[1] established between <remote IP>[<remote FQDN>]...<local DYN IP>[<local DYN FQDN>]
Feb  4 08:10:04 <remote> charon: 04[IKE] IKE_SA fritz-3[1] state change: CONNECTING => ESTABLISHED
Feb  4 08:10:04 <remote> charon: 04[ENC] generating ID_PROT response 0 [ ID HASH ]
Feb  4 08:10:04 <remote> charon: 04[NET] sending packet: from <remote IP>[4500] to <local DYN IP>[4500] (92 bytes)
Feb  4 08:10:04 <remote> charon: 10[NET] sending packet: from <remote IP>[4500] to <local DYN IP>[4500]
Feb  4 08:10:04 <remote> charon: 09[NET] received packet: from <local DYN IP>[4500] to <remote IP>[4500]
Feb  4 08:10:04 <remote> charon: 09[NET] waiting for data on sockets
Feb  4 08:10:04 <remote> charon: 02[NET] received packet: from <local DYN IP>[4500] to <remote IP>[4500] (92 bytes)
Feb  4 08:10:04 <remote> charon: 02[ENC] parsed INFORMATIONAL_V1 request 1319778430 [ HASH N(INITIAL_CONTACT) ]
Feb  4 08:10:24 <remote> charon: 01[IKE] sending keep alive to <local DYN IP>[4500]
Feb  4 08:10:24 <remote> charon: 10[NET] sending packet: from <remote IP>[4500] to <local DYN IP>[4500]
Feb  4 08:10:34 <remote> charon: 09[NET] received packet: from <local DYN IP>[4500] to <remote IP>[4500]
Feb  4 08:10:34 <remote> charon: 09[NET] waiting for data on sockets
Feb  4 08:10:34 <remote> charon: 09[NET] received packet: from <local DYN IP>[4500] to <remote IP>[4500]
Feb  4 08:10:34 <remote> charon: 09[NET] waiting for data on sockets
Feb  4 08:10:34 <remote> charon: 13[NET] received packet: from <local DYN IP>[4500] to <remote IP>[4500] (92 bytes)
Feb  4 08:10:34 <remote> charon: 13[ENC] parsed INFORMATIONAL_V1 request 1999035825 [ HASH D ]
Feb  4 08:10:34 <remote> charon: 13[IKE] received DELETE for IKE_SA fritz-3[1]
Feb  4 08:10:34 <remote> charon: 13[IKE] deleting IKE_SA fritz-3[1] between <remote IP>[<remote FQDN>]...<local DYN IP>[<local DYN FQDN>]
Feb  4 08:10:34 <remote> charon: 13[IKE] IKE_SA fritz-3[1] state change: ESTABLISHED => DELETING
Feb  4 08:10:34 <remote> charon: 13[IKE] IKE_SA fritz-3[1] state change: DELETING => DELETING
Feb  4 08:10:34 <remote> charon: 13[IKE] IKE_SA fritz-3[1] state change: DELETING => DESTROYING
Feb  4 08:10:34 <remote> charon: 11[NET] received packet: from <local DYN IP>[4500] to <remote IP>[4500] (496 bytes)
Feb  4 08:10:34 <remote> charon: 11[ENC] parsed ID_PROT request 0 [ SA V V V V V V ]
Feb  4 08:10:34 <remote> charon: 11[CFG] looking for an ike config for <remote IP>...<local DYN IP>
Feb  4 08:10:34 <remote> charon: 11[CFG]   candidate: %any...<local DYN FQDN>, prio 2076
Feb  4 08:10:34 <remote> charon: 11[CFG] found matching ike config: %any...<local DYN FQDN> with prio 2076
Feb  4 08:10:34 <remote> charon: 11[IKE] received XAuth vendor ID
Feb  4 08:10:34 <remote> charon: 11[IKE] received DPD vendor ID
Feb  4 08:10:34 <remote> charon: 11[IKE] received NAT-T (RFC 3947) vendor ID
Feb  4 08:10:34 <remote> charon: 11[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Feb  4 08:10:34 <remote> charon: 11[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Feb  4 08:10:34 <remote> charon: 11[ENC] received unknown vendor ID: <id>
Feb  4 08:10:34 <remote> charon: 11[IKE] <local DYN IP> is initiating a Main Mode IKE_SA
Feb  4 08:10:34 <remote> charon: 11[IKE] IKE_SA (unnamed)[2] state change: CREATED => CONNECTING

VPN Config für die Fritzbox:

/*
 * C:\Users\test\AppData\Roaming\AVM\FRITZ!Fernzugang\strongswan\strongswan.cfg
 * Thu Jun 25 09:40:07 2015
 */
 
 vpncfg {
 connections {
 enabled = yes;
 editable = no;
 conn_type = conntype_lan;
 name = "<remote FQDN>";
 boxuser_id = 0;
 always_renew = yes;
 reject_not_encrypted = no;
 dont_filter_netbios = yes;
 localip = 0.0.0.0;
 local_virtualip = 0.0.0.0;
 remoteip = 0.0.0.0;
 remote_virtualip = 0.0.0.0;
 remotehostname = "<remote FQDN>";
 keepalive_ip = 0.0.0.0;
 localid {
 fqdn = "<local DYN FQDN>";
 }
 remoteid {
 fqdn = "<remote FQDN>";
 }
 mode = phase1_mode_idp;
 phase1ss = "all/all/all";
 keytype = connkeytype_pre_shared;
 key = "<KEY>";
 cert_do_server_auth = no;
 use_nat_t = yes;
 use_xauth = no;
 use_cfgmode = no;
 phase2localid {
 ipnet {
 ipaddr = 192.168.3.0;
 mask = 255.255.255.0;
 }
 }
 phase2remoteid {
 ipnet {
 ipaddr = 192.168.0.0;
 mask = 255.255.252.0;
 }
 }
 phase2ss = "esp-all-all/ah-none/comp-all/pfs";
 accesslist = "permit ip any 192.168.0.0 255.255.252.0";
 }
 ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
 "udp 0.0.0.0:4500 0.0.0.0:4500";
}

ipsec.conf

conn %default
        keyexchange=ikev2
        ike=aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-modp1024,aes256-sha1-modp1024!
        esp=aes128gcm16-ecp256,aes256gcm16-ecp384,aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-modp1024,aes256-sha1-modp1024,aes128gcm16,aes256gcm16,aes128-sha256,aes128-sha1,aes256-sha384,aes256-sha256,aes256-sha1!
        dpdaction=clear
        dpddelay=300s
        rekey=no
        left=%any
        leftid=<remote FQDN>
        leftsendcert=always
        leftsubnet=0.0.0.0/0
        leftcert=<keyfile>.pem
        right=%any
        rightdns=8.8.8.8,8.8.4.4
        rightsourceip=%ipsecpool

conn IPSec-IKEv2
        keyexchange=ikev2
        auto=add

conn IPSec-IKEv2-EAP
        also="IPSec-IKEv2"
        rightauth=eap-tls
        # rightauth=eap-mschapv2
        # rightsendcert=never
        eap_identity=%any

#conn CiscoIPSec
#       keyexchange=ikev1
#       # forceencaps=yes
#       rightauth=pubkey
#       rightauth2=xauth
#       auto=add

conn fritz-3
        keyexchange=ikev1
        leftsubnet=192.168.0.0/22
        right=<local DYN FQDN>
        rightid=@<local DYN FQDN>
        rightsubnet=192.168.3.0/24
        ikelifetime=4h
        keylife=1h
        authby=secret
        auto=add

ipsec.secrets

# This file holds shared secrets or RSA private keys for authentication.

# RSA private key for this host, authenticating it to any other host
# which knows the public part.  Suitable public keys, for ipsec.conf, DNS,
# or configuration of other implementations, can be extracted conveniently
# with "ipsec showhostkey".

: RSA <keyfile>.pem
@<remote FQDN> @<local DYN FQDN> : PSK "<KEY>"
<local DYN FQDN> : PSK "<KEY>"

Es werden jedoch keine Daten übertragen... Ich hab das Strongswan sonst nur laufen für Roadwarrior (iOS Devices) - das funktioniert auch ohne Probleme. Das IPSEC natürlich eine ganz andere Nummer ist als OpenVPN ist mir klar, leider komme ich aber nicht weiter...

Kann hier vielleicht jemand helfen? Ich hab keine Ahnung mehr leider...

 

[PeterPawn]

Da ist durch ausführliches Maskieren mit zu vielen sehr ähnlichen "Beschreibungen" nichts mehr so richtig zu erkennen.

Aus

found matching ike config: [COLOR="#FF0000"]%any[/COLOR]...<local DYN FQDN> with prio 2076

würde ich ableiten, daß (beim zweiten Versuch) der falsche Kontext (%default anstelle von fritz-3) verwendet wird, weil das der einzige (sichtbare) ist, in dem "any" auf irgendeiner Seite der Verbindung erlaubt ist. Allerdings wird beim ersten Versuch ja offenbar der richtige Kontext ausgewählt und es fehlen nur weitere Pakete. Aber schon die Tatsache, daß eine Protokoll-Zeile beim StrongSwan immer genau in die (meines Erachtens) falsche Richtung zeigt:

Feb  4 08:10:04 <remote> charon: 10[NET] sending packet: from <remote IP>[500] to <local DYN IP>[500]
Feb  4 08:10:04 <remote> charon: 09[NET] received packet: from <local DYN IP>[4500] to <remote IP>[4500]

macht mich etwas stutzig ... entweder die StrongSwan-Maintainer haben ein vollkommen anderes Sprachverständnis oder da sind die Adressen vertauscht - denn beim Senden würde ich bei "from" die lokale IP und bei "to" die entfernte IP erwarten, beim Empfangen dann natürlich umgedreht.

Ich würde auch nicht auf den "main mode" setzen bei dieser Verbindung - allerdings kenne ich StrongSwan nicht gut genug (müßte also auch erst deren Dokumentation lesen) um zu wissen, ob bei einer Konfiguration mit einem dynamischen Namen anstelle der IP-Adresse für den "initiator" im "main mode" überhaupt PSK-Auth verwendet werden kann.

Ich würde es jedenfalls erst einmal mit dem "aggressive mode" versuchen.

Beim "racoon" müßte man nach jeder Aktualisierung der DynDNS-Adresse erst einmal den IKE-Daemon neu initialisieren, damit der die (einmalige) Namensauflösung macht und anhand der Absender-IP des Initiators den richtigen Kontext findet.

Ob das beim StrongSwan auch so ist, weiß ich eben nicht genau ... mich da in die Doku zu vertiefen habe ich aber noch keinen Anlass, solange da noch andere Fragen offen sind bzw. andere Tests (eben mit "aggressive mode") möglich sind.

Wenn man dabei dann noch die Uhrzeit auf beiden Geräten synchronisiert, kann man event. auch die beiden Protokolle miteinander vergleichen ... im Moment passen die irgendwie nicht zueinander (eine Sekunde Differenz verstehe ich noch, aber > 15 Sekunden sind entweder unterschiedliche Versuche oder total unterschiedliche Zeiten).

Wenn ich das richtig lese, kommt P2 auch nie wirklich zu einem Ende, dann können auch keine Daten übertragen werden ... ich verstehe auch nicht so richtig, warum Du die ID des Servers für P2 mit /22 erstellst.

Welche Daten am Ende über den Tunnel gesendet werden, entscheidet ohnehin der "accesslist"-Eintrag (das ist keine "route" in P2), da ist dann /22 wieder richtig.

Wenn ich das aber richtig lese, willst Du am Ende für jede FRITZ!Box einen Kontext einrichten, da würde ich bei /24 bleiben und auf dem Server ein (internes) LAN mit einer 192.168.x.0/24 definieren (wenn der nicht schon für das OpenVPN und den TUN/TAP-Adapter dort irgendein Netz verwendet, dann kann man auch gleich das nehmen). Den Austausch der Daten zwischen den drei FRITZ!Box-LANs muß dann der Root-Server ohnehin über sein eigenes Routing machen.

Die Alternative mit "racoon" wird sicherlich nicht in Frage kommen ... aber selbst bei eigener Bereitschaft, sich mit der StrongSwan-Konfiguration auseinanderzusetzen, müssen eben die Protokolle/Konfigurationen irgendwo stimmen und/oder einen Sinn ergeben.

Wenn Du das noch einmal machen möchtest, wäre die Verwendung von Austauschvariablen (z.B. 1.2.3.4 anstelle von "<local DYN IP>" - wobei ich immer noch nicht verstehe, wieso Dein Root-Server eine lokale dynamische IP-Adresse haben sollte) sinnvoller, weil man das hinterher dann wenigstens noch lesen kann. Im Moment ist das (wenn ich nicht die Konfiguration vollkommen falsch verstanden habe und der "charon" als IKE-Daemon tatsächlich auf einer der FRITZ!Boxen läuft) ein einziges Kuddelmuddel und ergibt (zumindest für mich) keinen richtigen Sinn.

BTW ... jetzt habe ich glatt noch vergessen zu erwähnen, daß natürlich Dein lokales Netz (192.168.3.0/24) bei der Angabe von 192.168.0.0/22 eingeschlossen wäre, was auch so eher nicht funktioniert.

 

[vice_pres]

Hi Peter,

Danke für deine Antwort. Ich hätte vielleicht oben dazu schreiben sollen was die einzelnen Maskierungen angeben sollen. Derzeit läuft Strongswan/charon auf dem Rootserver, das soll auch so bleiben.
- <local DYN > steht in jedem fall für die Fritzbox, egal ob FQDN oder IP
- <remote > steht in jedem fall für den Server, also nicht die Fritzbox. Ich denke damit klärt sich auf das mit den Protokollen in die falsche Richtung auf, oder?
- Es ist eigentlich der gleiche Versuch, auf den Zeitunterschied hatte ich noch garnicht geachtet bis ich das gerade gelesen hab
- das erneuern des Dyndns Namen wäre nicht das Problem laut https://layer9.wordpress.com/2010/07/28/ipsec-vpn-mit-strongswan-und-fritzbox-fon-wlan-7270-v3/ über ipsec starter –auto-update, solange die Verbindung erstmal zustande kommt wäre das ein Punkt mit dem ich mir später Gedanken machen würde.
- Das /22 in P2 ist ja dann tatsächlich ein Fehler, mir fehlte da etwas der Zusammenhang. Das wäre dann in der Accesslist besser aufgehoben, ich nehme an, dass ich dort aber dann mehrere Zeilen einfügen kann?

Viele Grüße
Peter

Edit:
Mehrere Access List Einträge habe ich rausgefunden: http://avm.de/service/fritzbox/frit...-IP-Netzwerke-hinter-der-FRITZ-Box-zugreifen/ - demnach mehrere Zeilen. Anbei meine etwas angepasste Config, agressive mode werde ich morgen mal ausprobieren. Ich habe in der ipsec.conf das left auf 10.7.0.0/24 gesetzt (das Netz das das OpenVPN nutzt) und in der Fritzbox conf die remoteid sowie die access list ebenfalls auf 10.7.0.0/24 - ohne zusätzliche netze damit ich das erstmal ans laufen bekommen. Scheinbar bleibt es aber dabei, dass nach 30 Sekunden P2 scheitert...

Der Zeitunterschied ist auch behoben... ~18 Sekunden offset

 

[PeterPawn]

Ja, Du könntest auch mehrere Zeilen in "accesslist" aufnehmen, aber das ist ebenfalls erst der zweite Schritt.

Die Erklärung zu den Ersetzungen habe ich nicht richtig verstanden ... spielt aber m.E. auch erst einmal keine Rolle. Mein Vorschlag bliebe die Verwendung des "aggressive mode" (eine Konfiguration für racoon habe ich letztens - also innerhalb der letzten 6 Monate - mal jemandem zusammen"redigiert", die sollte sich auch auf StrongSwan übertragen lassen) in Verbindung mit passenden FQDN-IDs für P1 (die haben zwar ein FQDN-Format, müssen aber keine existierenden Domainnamen sein - das sind lediglich die "Schlüsselwerte", mit denen der passende PSK für die Verbindung herausgesucht wird und wenn der nicht paßt, ist der folgende Verkehr - der ja schon verschlüsselt ist - nicht zu entziffern) und dann gibt es mit so einem Versuch ja in jedem Falle auch neue Protokolldateien.

Wenn Du die IP-Adressen diskjunkt konfigurierst, sollte da zumindest schon mal die erste Verbindung einer einzelnen FRITZ!Box mit dem Root-Server möglich werden. Die "accesslist"-Einträge kannst Du dann immer noch später anpassen, wenn alle drei Verbindungen stehen und zwischen den LANs der FRITZ!Boxen über den Server vermittelt werden soll.

EDIT: Hab den Thread mit "racoon" gefunden: http://www.ip-phone-forum.de/showthread.php?t=283014

 

[vice_pres]

Ich habs mal im aggressive mode probiert, bin damit aber genauso gescheitert... Keine Phase 2...

Das liegt aber vermutlich an mir, bzw meinem nicht-nachdenken weil die iOS RW ja funktionieren... Die Kiste auf der es laufen soll ist ein VPS (QEMU basierend scheinbar laut HDD, Hetzner hat mit den neuen Modellen jedenfalls gewechselt - seitdem haben die Server selber auch ne 172.31.x.x IP statt wie früher die öffentliche direkt), ich hab mal meinen richtigen hardware-root genommen (mit den gleichen Configs) - und NATÜRLICH funktioniert Phase 2 dann direkt. Warum sollte es auch anders sein? Daten gingen zwar beim ersten Versuch nicht durch vom Server auf das Netz der Box (liefen stattdessen auf dem Standard-GW raus) - aber das war mir erstmal egal. Phase2 is ja direkt durchgelaufen...

Damit steh ich jetzt eh erstmal vor einem Grundsatz-Problem:
Die Hardware-Kiste steht in nem anderen RZ und soll die Abwicklung auch eigentlich nicht machen, die Anbindung ist zwar ok, schwankt aber von der Auslastung her leider. Damit scheint aber zumindest die Verbindung zu funktionieren
Der VPS sollte (wie bisher auch) die Abwicklung machen, OpenVPN läuft, IPSEC von den iOS Clients (IKEV2) funktioniert auch - nur die Fritzbox mag nicht.

Entweder ich tausch den VPS gegen ne andere Hardware-Kiste aus oder nehm die die schon da ist und leb mit der schlechteren Leitung (was ich eigentlich auch nicht will)

Fazit: Son Mist... Da P2 mit der Config die auf dem anderen Host funktioniert nicht zustande kommt werd ich wohl doch erstmal bei OpenVPN bleiben (müssen)

 

[Shirocco88]

ike.log

2016-02-04 08:10:52 avmike:<remote FQDN>: Phase 1 starting (renew)
2016-02-04 08:10:52 avmike:< cb_sa_create_failed(name=<remote FQDN>,reason=IKE-Error 0x2027)

Hallo vice_pres,
ich hatte auch mal IKE-Error 0x2027, da war die Ursache ein fehlendes localid bei remote-ipsec-peer; dies mag AVM-IPsec nicht;
und genau so sieht es bei Dir auch aus:

ipsec.conf

conn %default
        keyexchange=ikev2
        dpdaction=clear
        dpddelay=300s
        rekey=no
[COLOR=#ff0000]        left=%any[/COLOR]
        leftid=<remote FQDN>
        leftsendcert=always
        leftsubnet=0.0.0.0/0
        leftcert=<keyfile>.pem
        right=%any
        rightdns=8.8.8.8,8.8.4.4
        rightsourceip=%ipsecpool
SNIP


conn fritz-3
        keyexchange=ikev1
        leftsubnet=192.168.0.0/22
        right=<local DYN FQDN>
        rightid=@<local DYN FQDN>
        rightsubnet=192.168.3.0/24
        ikelifetime=4h
        keylife=1h
        authby=secret
        auto=add

daher schlage ich vor "left" explizit in ipsec.conf zu definieren

NEU:
ipsec.conf

...
conn fritz-3
        keyexchange=ikev1
 [COLOR=#0000ff]       left=<remote FQDN>
        leftid=<remote FQDN>
        leftsendcert=never[/COLOR]
        leftsubnet=192.168.0.0/22
        right=<local DYN FQDN>
        rightid=@<local DYN FQDN>
        rightsubnet=192.168.3.0/24
        ikelifetime=4h
        keylife=1h
        authby=secret
        auto=add
...

LG Shirocco88

 

[vice_pres]

[...]
daher schlage ich vor "left" explizit in ipsec.conf zu definieren
[...]

Hi,

Danke für den Tip! Habe ich ausprobiert, leider bleibt das Ergebnis gleich Selbst mit %any habe ich auf dem Hardware-Server direkt eine vollständige Phase2 hinbekommen... Ich vermute jetzt mal (ins Blinde) dass hier die neue Handhabung der IP-Adresse der neuen VPS von Hetzner dazwischenhaut... Der Server hat laut ipconfig nämlich nur die 172.31.x.x IP - die öffentliche IP wird vom Server "drüber" durchgeleitet...

Ergo sieht das so aus:

Feb  5 09:49:10 remote charon: 14[IKE] IKE_SA fritz-3[2] established between 172.31.x.x[server.fqdn]...1.2.3.4[fritzbox.dyn.dns]
Feb  5 09:49:10 remote charon: 14[IKE] IKE_SA fritz-3[2] state change: CONNECTING => ESTABLISHED
Feb  5 09:49:10 remote charon: 14[ENC] generating ID_PROT response 0 [ ID HASH ]
Feb  5 09:49:10 remote charon: 14[NET] sending packet: from 172.31.x.x[4500] to 1.2.3.4[4500] (92 bytes)

Also müsste ich vermutlich irgendwo den Dreh reinbringen...

 

[vice_pres]

Ich hab mich mittlerweile dazu durchgerungen zu wechseln auf den physikalischen Server - die VPN Verbindungen stehen auch, Ping zum Server und vom Server ins jeweilige Netz funktioniert auch. Ich bekomme es aber nicht hin, von einem Netz ins andere zuzugreifen über die Verbindung.

Fritzbox Config

/*
 * C:\Users\test\AppData\Roaming\AVM\FRITZ!Fernzugang\strongswan\strongswan.cfg
 * Thu Jun 25 09:40:07 2015
 */
 
 vpncfg {
 connections {
 enabled = yes;
 editable = no;
 conn_type = conntype_lan;
 name = "VPN";
 boxuser_id = 0;
 always_renew = yes;
 reject_not_encrypted = no;
 dont_filter_netbios = yes;
 localip = 0.0.0.0;
 local_virtualip = 0.0.0.0;
 remoteip = 0.0.0.0;
 remote_virtualip = 0.0.0.0;
 remotehostname = "server.fqdn";
 keepalive_ip = 0.0.0.0;
 localid {
 fqdn = "fritzbox.fqdn";
 }
 remoteid {
 fqdn = "server.fqdn";
 }
 mode = phase1_mode_idp;
 phase1ss = "all/all/all";
 keytype = connkeytype_pre_shared;
 key = "passwort";
 cert_do_server_auth = no;
 use_nat_t = yes;
 use_xauth = no;
 use_cfgmode = no;
 phase2localid {
 ipnet {
 ipaddr = 192.168.3.0;
 mask = 255.255.255.0;
 }
 }
 phase2remoteid {
 ipnet {
 ipaddr = 10.10.11.0;
 mask = 255.255.255.0;
 }
 }
 phase2ss = "esp-all-all/ah-none/comp-all/pfs";
 accesslist = "permit ip any 10.10.11.0 255.255.255.0",
 "permit ip any 192.168.0.0 255.255.255.0",
 "permit ip any 10.7.0.0 255.255.255.0";
 }
 ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
 "udp 0.0.0.0:4500 0.0.0.0:4500";
}

Leider werd ich nicht schlauer irgendwie... Wenn ich es recht verstanden habe reicht doch die erweiterte accesslist auf beiden Gegenstellen aus, oder?

 

[PeterPawn]

Irgendwie paßt die Konfiguration auch nicht zu #1 ... mit dieser werden die Daten für 192.168.0.0/24, 10.10.11.0/24 und 10.7.0.0/24 durch den Tunnel geschickt. In #1 ist die Rede von irgendwelchen 192.168.irgendwas-Netzen.

Daß der Server dann für das Routing der Daten zwischen den Netzen verantwortlich ist (von "ip_forwarding" bis zu passenden "iptables"-Regeln, falls es so etwas gibt), versteht sich sicherlich von selbst ... aber dazu kann man einer FRITZ!Box-VPN-Konfiguration naturgemäß nur wenig entnehmen.

Was klappt denn nun nicht? Kommen keine Daten von irgendeinem Host aus 192.168.3.0/24 bis zum Server? Das ist das einzige, was man anhand der Konfiguration in #8 sehen kann, daß das tatsächlich funktionieren sollte (s. erster Satz von mir in diesem Beitrag). Alles andere ist "dichter Nebel" (und der hat heute wieder eine Lesung in London) ...

 

[vice_pres]

Hallo Peter,

Ich habe ein "virtuelles" Netz aufgespannt auf dem Server (das sind die beiden 10.er Adressen, eine ist aus dem Openvpn netz das für 2 Clients derzeit noch weiterläuft, das andere dient als virtuelles Netz passend zu den ipsec Adressen). Die "richtigen" Netze haben 192.168. Adressen. Der Server macht ip-forwarding (da er auch mal für 2 Tage Openvpn server gespielt hat als mein vserver umgezgeon ist) daran liegt es nicht.

Situation:
Fritzbox1 192.168.0.0/24
Fritzbox2 192.168.3.0/24

Beide haben eine (fast - PSK etc...) identische Config aus #8 (die Netze jeweils getauscht). Die Verbindung zum Server funktioniert, der Server erreicht Clients in den beiden Netzen. Clients aus beiden Netzen erreichen den Server. Die Server-Config entspricht #1 - mit der Ausnahme, dass leftsubnet das jeweilige 192.168er netz mit /24 hat und es natürlich für die andere VPN-Verbindung einen zusätzlichen Eintrag gibt.

Was NICHT funktioniert: Client1 192.168.0.5 erreicht nicht Client2 192.168.3.5

 

[PeterPawn]

Das ist doch angesichts meines ersten Satzes in #9 (zweiter Halbsatz) nur natürlich ... wenn das funktionieren soll, braucht es in der Konfiguration der FRITZ!Boxen jeweils einen "accesslist"-Eintrag, der auf das Zielnetz zeigt. Irgendwelche Transitnetze (das sind die 10er ja wohl, wenn ich das richtig verstehe), spielen dabei gar keine Rolle.

EDIT: Falscher Button, zu früh gesendet ...

Was passiert denn mit den Paketen von einer FRITZ!Box, kommen die nun auf dem Server an oder nicht? Wenn ja, werden sie vom Server auf das richtige ausgehende Interface in Richtung "entfernte FRITZ!Box" weitergeleitet? Wenn ja, kommen sie auf der FRITZ!Box auch an? Das sind doch alles Punkte, die man mit einem Packetdump schnell klären kann.

Der Server braucht dann passende Einträge in der Routing-Table, wobei die eigentlich vorhanden sein sollten, wenn der Server die Clients erreichen kann. Dann würde ich am ehesten darauf tippen, daß es doch eine Firewall mit "iptables" gibt und da macht es eben einen Unterschied, ob die Daten in der "INPUT/OUTPUT"-Table aufschlagen oder in "FORWARD".

 

[vice_pres]

Eine vorhandene Firewall ist vor dem Verbindungsaufbau deaktiviert worden, es sind derzeit keine Firewall-Regeln vorhanden.

zu dem Satz mit dem Zielnetz: Die gibt es doch, das Beispiel in #8 ist für die Box die selber das 3.0/24 hat und hat als accesslist 0.0/24 drin. Ich habe mir mit tcpdump den Traffic auf dem Interface des Servers angeschaut - die ICMP echo requests kommen an (von 3.5 -> 0.5 z.B.), die accesslist Einträge sind also richtig und funktionieren auch.

Also muss ich irgendwo auf dem Server weitersuchen - das reine IP-Forwarding kann es ja nicht sein, da es ja an ist. Firewall (shorewall) an/aus macht in meinem Fall auch kein Unterschied. Vermutlich liegt aber doch irgendwo in Sachen iptables der Hase begraben...

Edit:
HERR.... oh man. Die Forward Einträge fehlen... Jetzt muss ich mir mal überlegen wie man die am besten dynamisch erzeugt wenn sich eine Box verbindet... Strongswan legt nur die X.0/24 (und die jeweilige zurück) an...

Edit2:
Wobei mich das doch wundert und auch das manuelle anlegen nicht hilft... default ist doch ACCEPT wenn keine Firewall an ist

Chain FORWARD (policy ACCEPT)

Edit3:
Ich hab die Firewall mal angemacht und das Logging ganz aufgedreht - die Firewall spielt da scheinbar nicht quer... Wenn sie aus ist ja sowieso nicht. Ich komm einfach nicht weiter...

 

[PeterPawn]

Chain FORWARD (policy ACCEPT)

Kann es sein, daß Du gar kein NAT machst und Dich nur darauf verläßt, daß der IPSec-Traffic dank XFRM-Regeln auf dem "default"-Interface schon irgendwie ausgefiltert wird?

Der IKE-/ISAKMP-Daemon erzeugt Dir vermutlich keine XFRM-Regeln für Pakete von der einen 192.168.x.0/24 auf die andere 192.168.y.0/24 ... entweder Du machst NAT auf dem Server (dann sehen die FRITZ!Boxen praktisch immer die Adresse des Servers und Du kannst Dir auch zusätzliche "accesslist"-Einträge sparen) oder Du brauchst vermutlich auch die XFRM-Regeln, die Pakete von und an 192.168-Adressen transformieren - ich weiß aber nicht, welche Policies der charon einrichtet.

Was sagt denn die Ausgabe von "ip xfrm" (state und policy), wenn beide FRITZ!Boxen mit dem Server verbunden sind?

 

[vice_pres]

Da liegt der Hund begraben... Ich habe mich in der tat darauf verlassen, dass XFRM-Regeln automatisch da sind... Ich wollte bewusst kein NAT da der Sinn des zentralen VPNs ist, dass ich den Traffic innerhalb des VPNs beschränken kann - ansonsten hätte ich auch die Boxen direkt miteinander verbinden können.

1.1.1.1 = IP Fritzbox 1
2.2.2.2 = Server-IP
3.3.3.3 = IP Fritzbox 2

root@remote:/etc/shorewall# ip xfrm state
src 2.2.2.2 dst 1.1.1.1
        proto esp spi 0x9a261da1 reqid 2 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) <key> 96
        enc cbc(aes) <key>
src 1.1.1.1 dst 2.2.2.2
        proto esp spi 0xc096d5e1 reqid 2 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) <key> 96
        enc cbc(aes) <key>
src 2.2.2.2 dst 3.3.3.3
        proto esp spi 0xafe3790e reqid 1 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) <key> 96
        enc cbc(aes) <key>
src 3.3.3.3 dst 2.2.2.2
        proto esp spi 0xc209a273 reqid 1 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) <key> 96
        enc cbc(aes) <key>

        
root@remote:/etc/shorewall# ip xfrm policy
src 192.168.0.0/24 dst 10.10.11.0/24
        dir fwd priority 1859
        tmpl src 1.1.1.1 dst 2.2.2.2
                proto esp reqid 2 mode tunnel
src 192.168.0.0/24 dst 10.10.11.0/24
        dir in priority 1859
        tmpl src 1.1.1.1 dst 2.2.2.2
                proto esp reqid 2 mode tunnel
src 10.10.11.0/24 dst 192.168.0.0/24
        dir out priority 1859
        tmpl src 2.2.2.2 dst 1.1.1.1
                proto esp reqid 2 mode tunnel
src 192.168.3.0/24 dst 10.10.11.0/24
        dir fwd priority 1859
        tmpl src 3.3.3.3 dst 2.2.2.2
                proto esp reqid 1 mode tunnel
src 192.168.3.0/24 dst 10.10.11.0/24
        dir in priority 1859
        tmpl src 3.3.3.3 dst 2.2.2.2
                proto esp reqid 1 mode tunnel
src 10.10.11.0/24 dst 192.168.3.0/24
        dir out priority 1859
        tmpl src 2.2.2.2 dst 3.3.3.3
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0

Also müsste ich scheinbar die xfrm Regeln von/zu irgendwie hinbekommen - oder das was ich eigentlich nicht machen möchte natten.

 

[PeterPawn]

Also müsste ich scheinbar die xfrm Regeln von/zu irgendwie hinbekommen

Vielleicht kann ja der charon irgendwelche User-Skripte aufrufen beim Einrichten/Abräumen einer SA ... dafür kenne ich StrongSwan nicht gut genug - daher bin ich dann hier raus. Viel Erfolg.

 

[vice_pres]

Danke für die Hinweise in die Richtung Peter!

Scripts wäre nicht das Problem, jetzt muss ich mir nur mal die Syntax raussuchen

 

[PsychoMantis]

Eins habe ich noch nicht verstanden: Warum sollen die Pakete den Umweg über den Server gehen - warum verbindest du sie nicht zusätzlich noch untereinander per VPN?

 

[vice_pres]

Nur der Vollständigkeit halber:
Ich habe die Verbindung jetzt laufen, IKEV1 unterstützt bei Strongswan(?) nur ein parameter für leftsubnet - daher habe ich wie in #1 beschrieben .252 genommen und damit laufen (bis auf die Transit-Netze) die Boxen.

Jetzt kommt aber der Haken: Scheinbar kann ich den entschlüsselten Traffic nicht mit shorewall filtern - was ja eigentlich der Grund war warum ich überhaupt auf den Server gehen wollte und keine direkten Verbindungen haben wollte. Da es ja kein eigenes Interface gibt sondern das routing ja eben anders abläuft als z.B. bei Openvpn bin ich da "gekniffen" und werd jetzt erstmal zurück auf openvpn drehen und mir das nächste woche nochmal anschauen - dann kann ich auch direkt die Verbindungen Box<->Box einrichten und eine getrennte zum Server um die dort erreichbaren Sachen zu bekommen...

Edit:
Huch, da haben wir uns überschnitten: Der Grund war (wie oben schonmal erwähnt) - ich möchte den Traffic zwischen den VPNs filtern können. Manches soll erlaubt sein, manches aber auch nicht. Mache ich seit Jahren mit Openvpn ohne Probleme. Vorallem wenn ich überlege was mein Neffe in seinem Freundeskreis alles für Geräte ins Netz lässt will ich das definitiv nicht fest ungefiltert mit meinem Netz verbunden haben...

 

[grauGolz]

Traffic im VPN Tunnel zu filtern geht doch ganz einfach. Man darf nur nicht auf "eierlegende Wollmilchsäue" fixiert sein.

Dazu muß man nicht einen "Server" bemühen.

Das ist nur eine Feststellung, keine Werbung.

 

[vice_pres]

Ehrlich, deine Kommentare sind schon in anderen Threads negativ aufgefallen... Es hat doch überhaupt nichts mit der Fritzbox zu tun wenn eine Policy-based routing Lösung anders läuft als meine bisherige Lösung. Totaler Unsinn... Das einzige was die Fritzbox damit zu tun hat ist die Tatsache, dass sie eine IKEv1 IPSEC Verbindung aufbaut ab Werk.

Ich hab auch genug andere Lösungen hier liegen, ob nun Alix Board oder Lancom oder sonstwas. ABER: Das tut nunmal nichts zur Sache - die Endgeräte an den Endpunkten sind gegeben. Punkt. Egal in wievielen Threads du noch trollen willst