Jul 15, 2015

2829

IPSec Netz zu Netz - ich krieg es nicht hin

Hallo,

ich habe mir eine IPSec Netz zu Netz Verbindung eingerichtet. Dabei hängt ein Cop ("tor") direkt im Internet, ein Cop ("tuxnet") befindet sich hinter einer Fritz!Box (Kabel Deutschland). Ich habe bei KD eine IPV4-Adresse und kann z.B. auch via Portforwarding auf 8443 zugreifen. Meine Fritz!Box zeigt kein DualStack Lite oder Ähnliches an.

Wo ich mir nicht ganz sicher bin:

ich habe auf der Fritz!Box UDP 500, 4500 und GRE (ohne Portangabe) an den dahinter befindlichen Cop weitergeleitet
ich habe auf beiden Cops eine Regel "Zugriff von extern auf Cop" gesetzt und dort 500, 4500 (jeweils TCP/IP und UPD) sowie Port 47 (GRE) geöffnet

Der Cop an der Festverbindung sagt:

38:08 pluto[1749] | 
38:08 pluto[1749] | *received whack message
38:08 pluto[1749] | kernel_alg_esp_auth_keylen(auth=2, sadb_aalg=3): a_keylen=20
38:08 pluto[1749] | kernel_alg_esp_auth_keylen(auth=1, sadb_aalg=2): a_keylen=16
38:08 pluto[1749] | kernel_alg_esp_auth_keylen(auth=2, sadb_aalg=3): a_keylen=20
38:08 pluto[1749] | kernel_alg_esp_auth_keylen(auth=1, sadb_aalg=2): a_keylen=16
38:08 pluto[1749] | * processed 0 messages from cryptographic helpers 
38:08 pluto[1749] | next event EVENT_RETRANSMIT in 3 seconds for #5
38:08 pluto[1749] | next event EVENT_RETRANSMIT in 3 seconds for #5
38:11 pluto[1749] | 
38:11 pluto[1749] | next event EVENT_RETRANSMIT in 0 seconds for #5
38:11 pluto[1749] | *time to handle event
38:11 pluto[1749] | handling event EVENT_RETRANSMIT
38:11 pluto[1749] | event after this is EVENT_PENDING_DDNS in 30 seconds
38:11 pluto[1749] | processing connection tuxnet
38:11 pluto[1749] | handling event EVENT_RETRANSMIT for 77.22.19.102 "tuxnet" #5
38:11 pluto[1749] | sending 456 bytes for EVENT_RETRANSMIT through wan-1:500 to 77.22.19.102:500 (using #5)
38:11 pluto[1749] | inserting event EVENT_RETRANSMIT, timeout in 40 seconds for #5
38:11 pluto[1749] | next event EVENT_PENDING_DDNS in 30 seconds

Der Cop hinter der Fritz!Box sagt:

38:06 pluto[1511] | 
38:06 pluto[1511] | next event EVENT_PENDING_DDNS in 0 seconds
38:06 pluto[1511] | *time to handle event
38:06 pluto[1511] | handling event EVENT_PENDING_DDNS
38:06 pluto[1511] | event after this is EVENT_PENDING_PHASE2 in 60 seconds
38:06 pluto[1511] | inserting event EVENT_PENDING_DDNS, timeout in 60 seconds
38:06 pluto[1511] | next event EVENT_PENDING_DDNS in 60 seconds
39:06 pluto[1511] | 
39:06 pluto[1511] | next event EVENT_PENDING_DDNS in 0 seconds
39:06 pluto[1511] | *time to handle event
39:06 pluto[1511] | handling event EVENT_PENDING_DDNS
39:06 pluto[1511] | event after this is EVENT_PENDING_PHASE2 in 0 seconds
39:06 pluto[1511] | inserting event EVENT_PENDING_DDNS, timeout in 60 seconds
39:06 pluto[1511] | handling event EVENT_PENDING_PHASE2
39:06 pluto[1511] | event after this is EVENT_PENDING_DDNS in 60 seconds
39:06 pluto[1511] | inserting event EVENT_PENDING_PHASE2, timeout in 120 seconds
39:06 pluto[1511] | pending review: connection "tor" was not up, skipped
39:06 pluto[1511] | next event EVENT_PENDING_DDNS in 60 seconds

Vielleicht habt Ihr ja einen Tipp für den Papa?

Gruß,
Jörg

Please also mark the comments that contributed to the solution of the article

Content-Key: 277376

Url: https://administrator.de/contentid/277376

Printed on: April 25, 2024 at 13:04 o'clock

9 Comments

Latest comment

Zitat von @117471:

Vielleicht habt Ihr ja einen Tipp für den Papa?

Direkt das in der Fritzbox eingebaute IPSEC nutzen?

Anonsten schauen, daß alles entsprechende in der Fritzbox deaktiviert wird.

lks

Das hiesige Tutorial zu dem Thema hast du gelesen ??
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Das sollte eigentlich alle deine Fragen beantworten ?!

2 Sachen die vermutlich beides die Ursache deines Scheiterns oben sind:

Da die FB selber IPsec VPNs macht MUSST du wie Kollege LKS oben schon richtig bemerkt IPsec im FB Setting deaktivieren (VPN deaktivieren) ansonsten leitet die FB die IPsec Pakete nicht weiter ! Kannst du auf dem IPsec Endtunnel auch sofort selber sehen wenn du dir mit tcpdump mal die eingehenden Pakete ansiehst !! Bei dir kommt da vermutlich gar nicht erst IPsec an so das ein Scheitern des Tunnelaufbaus klar ist.
GRE ist Schwachsinn. Sorry, aber das ist Bestandteil von PPTP VPNs wie jeder netzwerker weiss und hat mit IPsec nichts zu tun. Mach dich also bitte kundig was IPsec VPNs benötigen an Protokoll Komponenten: UDP 500, UDP 4500 und das ESP Protokoll (IP Protokoll Nummer 50, Achtung: kein TCP oder UDP 50 ! ESP ist ein eigenes IP Protokoll !)

Danke für eure bisherige freundliche Unterstützung. Ich glaube, ich bin mit eurer Hilfe schon ein ganzes Stück weiter.

Die Schwierigkeit ist tatsächlich, dass man genau so viele potentielle Anleitungen wie Fehlerquellen findet und beim Lernen nur sehr schwer den "gemeinsamen Nenner" herausextrahiert

Auf dem Cop hinter der Fritz!Box heißt es neuerdings:

15:50:41 pluto[1525] packet from <ip.vom.internetcop>:500: initial Main Mode message received on 192.168.178.2:500 but no connection has been authorized with policy=PSK

Die Tunnelenden habe ich wie folgt konfiguriert:

Cop mit direkter Internetverbindung

Name: MeinTunnel
Hostname: cop.ia.local
Host-IP-Adresse: <ip.vom.internetcop>
Lokales Subnetz: 10.10.10.0/24
Remote Host: <dyn.dns.hostname>
Remote Subnetz: 10.10.20.0/24

Cop hinter der Fritz!Box

Name: MeinTunnel
Hostname: cop.tuxnet.local
Host-IP-Adresse: <dyn.dns.hostname>
Lokales Subnetz: 10.10.20.0/24
Remote Host: <ip.vom.internetcop>
Remote Subnetz: 10.10.10.0/24

Mir fällt auf, dass der Cop hinter der Fritz!Box in der Statusanzeige noch einen zweiten Hostnamen anzeigt: Nämlich den, den er vom DNS der Fritz!Box bekommen hat (xyz.fritz.box). Das muss irgendwie damit zusammenhängen, dass der Cop auf Rot nur die lokale IP sieht; der <dyn.dns.hostname> jedoch zur öffentlichen IP der Fritz!Box gehört. Liegt da der Hase im Pfeffer? An welcher Stelle löst man das auf?

Der Grund, warum ich das IPSec nicht direkt auf der Box fahre ist der, dass das so eine Art "Familienkiste" ist. D.h., der Sohn von meiner Frau lädt da öfter mal Kumpels mit diversen mir unbekannten Geräten ins WLAN ein. Die möchte ich nicht unbedingt im gleichen Netz wie meine Rechner haben.

nitial Main Mode message received on

Main Mode solltest du besser nicht verwenden. Es ist einfacher wenn du auf den Agressive Mode gehst.
Laut Fehlermeldung (die leider sehr spartanisch ist

) ist gar keine Policy definiert, d.H. der Tunnel grundsätzlich nicht definiert.
Knackpunkt ist meistens das ESP Protokoll das das nicht durchkommt.
Du kannst doch auf dem Cop ein tcpdump laufen lassen. Check doch mal damit ob da beidseitig überhaupt ESP ankommt ?!
.local in einem Domainnamen zu verwenden ist auch nicht besonders gut, denn das kollidiert mit mDNS das diese Root Domain als Default nutzt. Besser ist hier imm .intern oder .lokal zu nehmen. Das ist aber nicht ursächlich für den obigen Fehler.

Wichtig wäre noch zu wissen ob du eine Authentisierung auf den FQDN Namen oder die IP machst ? Das muss auf beiden Seiten identisch sein. Da du keine öffentlichen Domain Namen verwendest solltest du immer auf die IP authentisieren !

Nämlich den, den er vom DNS der Fritz!Box bekommen hat (xyz.fritz.box)

Genau das ist nämlich der Punkt !
Allein schon die Tatsache das du auf Firewall oder Router dynmaische IPs verwendest ist auch kontraproduktiv !
Niemals sollten diese Geräte dynmaische IPs und DNS bekommen sondern immer statische !
Genau deshalb nämlich um solche Diskrepanzen zu verhindern. Änder das dann sind wir ebenfalls einen Schritt weiter !
Ggf. ist das auch die Lösung, da jeder Mismatch diesbezüglich die IPsec Phase 2 zum Abbruch zwingt.

D.h., der Sohn von meiner Frau lädt da öfter mal Kumpels mit diversen mir unbekannten Geräten ins WLAN ein. Die möchte ich nicht unbedingt im gleichen Netz wie meine Rechner haben.

Das löst man aber auch nicht mit so einem VPN Unsinn wie du sondern schlicht und einfach mit einem mSSID fähigen WLAN Accesspoint, 2 unterschiedlichen SSIDs und einem Gast WLAN mit einem CP und entsprechendem User Tracking und Firewall:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)

Zitat von @aqui:

Zuallererst: Ich habe es hinbekommen

Entscheidender Hinweis war unter Anderem, dass entgegen diverser Tutorials und FAQs ESP statt GRE genutzt wird und dass die Fritz!Box eine VPN-Funktion hat, die ich bis dahin nicht kannte.

Weiterhin gibt es beim IPCop die Möglichkeit, für die linke und die rechte Seite einen Namen einzugeben, der in der Authentifizierung verrechnet wird. Auf der Weboberfläche des Cop ist das so dargestellt, dass man hier optional etwas eintragen kann, was "dem Kind einen schönen Namen gibt" und nicht weiter genutzt wird.

Des Weiteren gab' es bei Kabel Deutschland noch das Problem, dass ich dort keine echte IPV4-Adresse hatte ("Dual-Stack lite") und es stand auch der Verdacht im Raum, dass es bei KD Probleme mit IPSec-Tunneln gibt, die IP-Netze aus dem Subnet 10.10.0.0/16 transportieren (was ich persönlich allerdings für Blödsinn halte).

Main Mode solltest du besser nicht verwenden. Es ist einfacher wenn du auf den Agressive Mode gehst.

In dem Fall bekomme ich eine Hinweismeldung, dass der Schlüssel im Klartext übertragen wird. Möchte ich das wirklich?

> D.h., der Sohn von meiner Frau lädt da öfter mal Kumpels mit diversen mir unbekannten Geräten ins WLAN ein.
Die möchte ich nicht unbedingt im gleichen Netz wie meine Rechner haben.

Das löst man aber auch nicht mit so einem VPN Unsinn wie du

Empfindest Du das wirklich als Unsinn, wenn ich einen IPCop als Firewall an eine bestehende Infrastruktur klemme um das dahinterliegende Netz abzuschirmen? Nur so interessehalber - warum?

sondern schlicht und einfach mit einem mSSID fähigen WLAN Accesspoint,

Dann müsste ich aber sämtliche Rechner über WLAN anbinden. Im Moment hängen die an einem Switch hinter dem Cop.

Also, nicht dass ich da jetzt eine Diskussion lostreten möchte, aber wie könnte man das denn sonst lösen? Im Moment sieht es so aus:

Testnetz Serverraum (Switch) ---> IPCop statisch ---> -Internet ---> Kabel Deutschland ---> Fritz!Box (Familiennetz) ---> IPCop ---> Testnetz daheim (Switch)

Wobei "Kabel Deutschland" und die dazugehörige Fritz!Box nebst den Kumpels von meiner Frau "gesetzte Rahmenbedingungen" sind und ich nicht unbedingt in neue Hardware investieren möchte (ich betrachte das Ganze als Lernprojekt).

Mein Hauptziel ist, dass niemand von der Fritz!Box (...oder aus dem Internet...) auf das Testnetz kommt.

dass entgegen diverser Tutorials und FAQs ESP statt GRE genutzt wird und dass die Fritz!Box eine VPN-Funktion hat, die ich bis dahin nicht kannte.

Sorry, aber da muss man sich fragen ob du hinterm Mond lebst und wie lange.
Jeder Netzwerker und IT Azubi weiss das IPsec basierte VPNs immer ESP nutzen und nur bei PPTP basierten VPNs GRE genutzt wird. Das ist schon seit Jahrzehnten so !
GRE hat mit IPsec soviel zu tun wie ein Fisch mit einem Fahrrad. Ein Blick in die Wikipedia hätte das auch in 3 Sekunden gezeigt.
IPsec VPNs gibt es auch schon seit Jahrzehnten auf der FritzBox und auf zig anderen VPN Routern auch. Das dir das wirklich entgangen ist ist eigentlich völlig unverständlich. Aber egal....
Soviel zu dem Thema....

Weiterhin gibt es beim IPCop die Möglichkeit,....

Das gibt es bei ALLEN anderen IPsec basierten Routern und Firewalls wie z.B. der pfSense auch und ist keineswegs nur aus Spaß da.
Auch das erfährt man wenn man entsprechende Tutorials über das IPsec Protokoll mal wirklich liest und versteht wie z.B. hier:
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
usw. usw.

bei Kabel Deutschland noch das Problem, dass ich dort keine echte IPV4-Adresse hatte

Stimmt, das ist natürlich großer Mist aber letztlich hausgemacht, da du dich ja bewusst für diesen Provider mit dieser Technik entschieden hast !

In dem Fall bekomme ich eine Hinweismeldung, dass der Schlüssel im Klartext übertragen wird.

Das ist schlicht falsch. Auch im Aggressive Mode passiert sowas nicht. Es werden nur weniger Überprüfuingen gemacht. Der Agressive Mode ist in heterogenen Umgebungen sinnvoller. Wenn du beidseitig die gleiche HW hast kannst du natürlich auch den Main Mode verwenden...keine Frage.

wenn ich einen IPCop als Firewall an eine bestehende Infrastruktur klemme um das dahinterliegende Netz abzuschirmen?

Nein, das ist es natürlich nicht !
Auch die oben zitierte pfSense Lösung:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
bzw.
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Ist ja vollkommen identisch dazu nur das sie das eben auch mit einem CP und intelligentem Tracking verbindet..oder kann.
Es steht außer Frage das man nicht kontrollierbare Gastnetze immer so mit einer Firewall und möglichst stringenten Regeln abschottet !
Nur das nochmal als VPN auszuführen ist Unsinn ! Darauf bezog sich das. Sorry wenn das missverständlich war.

Dann müsste ich aber sämtliche Rechner über WLAN anbinden.

Nein müsste man nicht wenn man einen preiswerten mSSID fähigen Accesspoint betreibt. Der kann multiple SSIDs über die gleiche HW aufspannen. So hat man die Option das Gäste entweder per LAN Port oder WLAN in ihrem Segment bleiben.
Idealerweise kombiniert man das mit einem kleinen, preiswerten 802.1x fähigen Switch der nichtbekannte Mac Adressen dann automatisch in das Gast Segment zwingt. Das wäre das Optimum wenn man auf Sicherheit Wert legt.
Anregungen dazu gibt dir dieses Tutorial, speziell der Part Praxisbeispiel:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Hardware dazu hast du ja alles schon und ein mSSID AP kostet zw. 20 und 30 Euro.
Wenn du die Frau ausnahmsweise 2mal bei Feinkost Albrecht einkaufen schickst hast du die Kosten wieder raus dafür

Zitat von @aqui:

GRE hat mit IPsec soviel zu tun wie ein Fisch mit einem Fahrrad.

so etwa?

lks

Zitat von @aqui:

Jeder Netzwerker und IT Azubi weiss das IPsec basierte VPNs immer ESP nutzen

Gut - und wie soll sich derjenige verhalten, der diese Information nicht am ersten Ausbildungstag von seinem Ausbilder zugerufen bekommen hat?

In dem Fall sehe ich nun mal nur die Möglichkeit, sich die Dinge zu erarbeiten. Und da Internetseiten, Anleitungen usw. auch mal fehlerhafte Informationen enthalten wird man gelegentlich auch einmal in die Irre geleitet. Wobei ich das nicht schlimm finde. Im Gegenteil - durch Fehler lernt man mehr

IPsec VPNs gibt es auch schon seit Jahrzehnten auf der FritzBox und auf zig anderen VPN Routern auch.

Ja, auch das habe ich gelernt. Auf meinem vorherigen Router (einen Zyxel Prestige 201 ISDN-Router) gab es das halt noch nicht (kein Scherz, das Teil habe ich 2000 konfiguriert und seitdem kontinuierlich genutzt - mit einer Uptime von fast 9 Jahren - da musste halt mal der Stromzähler getauscht werden).

Stimmt, das ist natürlich großer Mist aber letztlich hausgemacht, da du dich ja bewusst für diesen Provider mit
dieser Technik entschieden hast !

Im Gegenteil - ich rede permanent gegen diesen Anbieter an. Versuch' mal, deine Frau zu überzeugen dass ein schwarzer Audi besser ist als ein rosaner Fiat...

Wenn du die Frau ausnahmsweise 2mal bei Feinkost Albrecht einkaufen schickst hast du die Kosten wieder raus dafür

Wie gesagt - die Rahmenbedingungen bezüglich der Netzverbindung sind unveränderbar. Ziel des Lernprojektes ist, sich ein bisschen mit den IPCops zu beschäftigen. Diese Hard- bzw. Software ist somit ebenfalls gesetzt. Ohne Kompromisse geht es nun mal nicht und die Kunst besteht in diesem Fall darin, mit den vorhandenen Rahmenbindungen das Bestmögliche zu realisieren. Das es eine bessere Lösung gibt, steht außer Frage.

Und - um noch etwas Konstruktives beizutragen: Mir hat letztendlich diese Anleitung sehr gut weitergeholfen: http://www.elektronik-kompendium.de/sites/net/0906191.htm

Wenn du die Frau ausnahmsweise 2mal bei Feinkost Albrecht einkaufen schickst

Und wie soll sie sich verhalten?
- Wir müssen vorher noch 10k Euro in die Hand nehmen und ein rosanes Auto kaufen
- Ich fahre nie wieder einkaufen, weil der Audi nicht rosa ist - wir müssen jetzt leider verhungern
- Ich gehe den Kompromiss ein und fahre auch mit einem schwarzen Auto einkaufen

Ja, ich merke schon - immer diese Autovergleiche...^^

Danke noch mal für eure Hilfe!