Lancom hinter Fritz!Box

[Avalanche]

Hallo,

nach langen Jahren habe ich das dunkle, langsame Internet-Zeitalter hinter mir gelassen und kann nun mit VDSL 250 surfen. Leider bedeutet das für mich auch, dass nun eine Fritz Box 7590 vor den Lancom 1781A geschalten werden muss (weil es AFAIK noch keine anderen passenden VDSL-Modems gibt).

Damit treten jetzt aber sporadisch Probleme mit der IPSEC VPN Verbindung auf, die es nun zu diagnostizieren gilt. Dies äußert sich dadurch, dass PRTG sich unregelmässig darüber beschwert, dass einzelne Geräte im Remote Netz nicht gepingt werden können. Bevor ich jetzt mit Packet Traces anfange, möchte ich mich gerne versichern, dass ich die vorgeschaltete Fritz Box richtig konfiguriert habe.

Ich habe dort ESP auf den Lancom weitergeleitet und auch die UDP Ports 500 bzw. 4500. Was mich etwas wundert ist, dass dennoch Encapuslation UDP im Lanmonitor für die VPN Verbindung aufgeführt wird. Ist das immer der Fall, wenn NAT erkannt wird?

Ich habe die Dead Peer Detection auf 5 Sekunden gestellt (hat die Stabilität etwas verbessert) und auch der Haken bei NAT-T ist aktiviert. Es handelt sich um eine IKEv1 Verbindung.

Gibt es noch weitere Einstellungen, die ich am Lancom bzw. der Fritzbox vornehmen sollte?

Vielen Dank!

[Avalanche]

Gerade gab es wieder einen Aussetzer. Im Log ist eigentlich nicht viel zu sehen, lediglich die markierte Zeile scheint so normalerweise nicht vorzukommen.

IPSEC Lancom Log.png

Wodurch kann "no Phase-1 SA available" verursacht werden?

Grüße
Avalanche

[hyperjojo]

hi,

Leider bedeutet das für mich auch, dass nun eine Fritz Box 7590 vor den Lancom 1781A geschalten werden muss (weil es AFAIK noch keine anderen passenden VDSL-Modems gibt).

doch, es gibt den LANCOM R883+ bei der Telekom, der kann bereits Super-Vectoring. Und die Digitalisierungsbox Basic (von Zyxel) kann ebenfalls SVVDSL und kann auch als reines Modem eingerichtet werden.

Gruß hyperjojo

[cpuprofi]

Hallo an Alle,

unabhängig von dem was hyperjojo schreibt, gibt es die LANCOM 1793 Serie welche auch dafür geeignet ist.

Grüße
Cpuprofi

[hyperjojo]

hi,

sind die 179x mittlerweile freigegeben?

Gruß hyperjojo

[fildercom]

hi,

sind die 179x mittlerweile freigegeben?

Gruß hyperjojo

Sieht so aus:
https://www.lancom-systems.de/produkte/ ... -gateways/

[Avalanche]

Vielen Dank für die Hinweise auf die aktuellen Geräte. Das ist ein Thema, das ich evtl. im nächsten Jahr angehen werde. Passen die 179x in die gleichen Rackmount-Kits wie die 1781? Ich bin etwas verwirrt, dass es da anscheinend doch noch neue Geräte in der alten Gehäuseform gibt?

Betreibt jemand einen Lancom mit IKEv1 IPSEC hinter einer Fritz Box und kann mir noch Tipps geben, wie ich die Verbindung genauso stabil bekomme, wie direkt am DSL-Anschluss?

Grüße
Avalanche

[medenz]

Ich weiss gerade nicht, inwiefern man die 7590 in den Modemmodus zwingen kann. (dsldmode_full_brige)
Fraglich bleibt auch, ob der Freescale MPC8314E des 1781A die 250 mbit/s des Anschlusses sinnvoll zu Verfügung stellen kann.
Ein Gerätetausch auf die VA Generation oder neuer erscheint sinnvoll.

p.s. Geräte der A Generation nutze ich bis 50 mbit mit 7412er Fritzboxen im o.g. Fullbridge Mode Modem Modus.

[GrandDixence]

Für das Versenden des DPD-Pakets (Dead Peer Detection) fehlt das Schlüsselmaterial (Phase 1-SA) für den Steuerkanal (IKE). Somit kann kein DPD-Paket versendet werden und der VPN-Tunnel ist als "getrennt" zu betrachten. Wahrscheinlich ist die Lebensdauer des Schlüsselmaterials für den Steuerkanal (IKE) abgelaufen. Siehe auch meine Beiträge mit ausführlicherer Beschreibung von DPD und der Lebensdauer des Schlüsselmaterials:
fragen-zum-thema-vpn-f14/fast-kein-traf ... tml#p92853

Eine weitere mögliche Ursache könnte NAT-Traversal sein:
fragen-zum-thema-firewall-f15/connectio ... 16551.html

Ja, bei mindestens einem NAT-Gerät zwischen den beiden VPN-Endpunkte wird automatisch auf UDP Port 4500 gewechselt. Siehe auch:
https://www.heise.de/security/artikel/E ... 70056.html

IKEv2 bietet eine bessere Sicherheit als IKEv1. Deshalb sollte aus Sicherheitsgründen kein IKEv1 mehr eingesetzt werden! Für IKEv2-Anleitungen siehe:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

[Avalanche]

Danke für die Links, ich werde mir das in Ruhe durchlesen.
IKEv2 ist keine Option, da die Gegenstelle (Sophos UTM) nur IKEv1 kann.

Viele Grüße
Avalanche

[5624]

Ist NAT-T auf beiden Seiten aktiv? Wenn es nicht beide Seiten unterstützen, funktioniert es nicht richtig. DPD auf 5 Sekunden ist meiner Meinung nach zu gering. Bedenke, dass alle Einstellungen auf beiden Seiten angepasst werden müssen.

VPN auf der Fritzbox abgeschaltet? Nicht dass die versucht, die Verbindungen zu terminieren.

[JvO]

Hallo

Also ich mache das eigentlich immer so, dass sich auf der FRITZ!Box alle Ports weiterleiten an die Lancom und dann die Lancom als Hauptfirewall habe.
Man muss jedoch dabei beachten, dass man zum Beispiel einen DynDNS Dienst dann auf der FRITZ!Box ausführt und nicht auf der Lancom. Die Lancom würde nämlich nur die interne Netzwerkadresse der FRITZ!Box preisgeben.

Natürlich solltest Du dann die FRITZ!Box mit einem sehr hochwertigen Passwort versehen. Ich mache das mit einem Passwortgenerator zwölf ständig mit allen Optionen.

[Avalanche]

Hallo zusammen,

in der Zwischenzeit bin ich ein großes Stück weitergekommen:

Es ist bei mir schlicht unmöglich IPSEC IKEv1 mit Nat Traversal hinter einer Fritz Box zu betreiben. Es scheinen immer wieder Pakete verloren zu gehen, was dann zu ziemlich unberechenbaren Verhalten führt. Es hilft dabei auch nicht, den UDP Port 4500 an den Lancom weiter zu leiten. Ich weiß nicht, ob dieses Verhalten am Lancom oder an der Sophos UTM als Gegenstelle oder der verrückten Idee, IPSec in UDP zu packen, liegt. Fakt ist, es funktioniert nicht.

Was ich auch nicht hinbekommen habe (um das ganze NAT Thema zu umgehen): eine funktionierende IPv4 IKEv1 Verbindung bei der die Gegenstelle auf eine IPv6 Adresse umgestellt wird (als einzige Änderung) kann danach nicht mehr aufgebaut werden (initial Main Mode message received on 2001:db8:1:1::2:500 but no connection has been authorized with policy=PUBKEY).

Es gibt aber auch Licht am Ende des Tunnels! Was funktioniert: ESP kann auf der FritzBox weitergeleitet werden. Damit aber für die Verbindung nicht dennoch UDP verwendet wird, muss im Lancom unbedingt NAT-T ausgeschaltet werden (und auf der Fritzbox muss vermutlich die eigene VPN Funktionalität deaktiviert werden). Seitdem läuft diese VPN Verbindung endlich stabil.

Finde nur ich IPSEC an vielen Stellen sperrig und unnötig komplex und für die Praxis schlecht dokumentiert? Man kann beispielsweise Intervalle für Keep-Alive, Dead Peer Detection, Gültigkeit der Schlüssel usw. einstellen. Eine einfach verständliche Erklärung, welche Werte hier tatsächlich in der Praxis bewährt und empfohlen sind, gibt es aber nirgends...

Schöne Feiertage!
Avalanche

[GrandDixence]

Finde nur ich IPSEC an vielen Stellen sperrig und unnötig komplex und für die Praxis schlecht dokumentiert? Man kann beispielsweise Intervalle für Keep-Alive, Dead Peer Detection, Gültigkeit der Schlüssel usw. einstellen. Eine einfach verständliche Erklärung, welche Werte hier tatsächlich in der Praxis bewährt und empfohlen sind, gibt es aber nirgends...

Mit der Version 2 von IKE (IKEv2) wurden einige der Unzulänglichkeiten von IKE Version 1 (IKEv1) entfernt.

https://www.heise.de/security/artikel/E ... 70056.html

Aus Sicherheitsgründen sollte IKEv2 statt IKEv1 eingesetzt werden. Wenn einer der VPN-Endpunkte nicht IKEv2 unterstützt, ist dieser VPN-Endpunkt durch moderne Hardware und Software zu ersetzen. IKEv2 gibt es schliesslich schon seit über 10 Jahre!

Einen EDGE-Router zu betreiben, welcher vom Hersteller nicht mehr gepflegt wird und somit nicht regelmässig mit Sicherheitsupdates versorgt wird, ist fahrlässig. EDGE-Router von LANCOM sollten mit einer Version des Betriebssystem LCOS betrieben werden, dass den Status "aktiv" aufweist:
https://www.lancom-systems.de/produkte/ ... ebersicht/

BSI TR-02102-3 gibt Empfehlungen zu zahlreichen Konfigurationsparameter von IKEv2/IPSec. Diese Empfehlungen sind in die IKEv2-Anleitungen eingeflossen:
viewtopic.php?f=14&t=17229&p=97795#p97795
Zu IKEv1 mag das BSI keine Empfehlungen abgeben, da IKEv1 aus Sicherheitsgründen nicht mehr eingesetzt werden sollte. Irgendwann in der nahen Zukunft wird dann auch Version 3 von IKE (IKEv3) vor der Türe stehen... (à la Version 3 von WPA => WPA3)

Gemäss dem letzten Beitrag macht die Funktion "VPN Passthrough", auch "IPSec Passthrough" genannt, der Fritzbox Ärger. Auf der Fritzbox muss natürlich jegliche VPN-Funktionalität (IKE/IPSec) abgeschaltet werden. Insbesondere ist VPN/IPSec Passthrough (Weiterleiten von ESP-Paketen) auszuschalten, damit die beiden VPN-Endpunkte einen VPN-Tunnel über UDP Port 4500 (NAT-Traversal) realisieren (können). Die Fritzbox ist als "IPsec-aware NAT" zu betrachten. Siehe dazu mein Beitrag vom "11 Okt 2016, 21:42":
viewtopic.php?f=14&t=15620&p=87370&hili ... ugh#p87370

Code: Alles auswählen

IPsec-aware NATs can cause problems (See [RFC3715], section 2.3).
   Some NATs will not change IKE source port 500 even if there are
   multiple clients behind the NAT (See [RFC3715], section 2.3, case n).
   They can also use IKE cookies to demultiplex traffic instead of using
   the source port (See [RFC3715], section 2.3, case m).  Both of these
   are problematic for generic NAT transparency, as it is difficult for
   IKE to discover the capabilities of the NAT.  The best approach is
   simply to move the IKE traffic off port 500 as soon as possible to
   avoid any IPsec-aware NAT special casing.

   Take the common case of the initiator behind the NAT.  The initiator
   must quickly change to port 4500 once the NAT has been detected to
   minimize the window of IPsec-aware NAT problems.

Die ersten beiden IKE-Pakete laufen über UDP Port 500. Sobald mindestens eine NAT-Netzwerkkomponente zwischen den beiden VPN-Endpunkte erkannt wird, wird auf UDP Port 4500 gewechselt (NAT-Traversal, kurz NAT-T):
https://www.lancom-systems.de/docs/LCOS ... 75697.html

Beim Einsatz von NAT-Traversal wird ausschliesslich über UDP Port 4500 kommuniziert. Ausnahme die ersten 2 IKE-Pakete beim VPN-Tunnelaufbau. Sowohl der Steuerkanal (IKE) des VPN-Tunnels wie auch der Datenkanal (ESP/IPSec) des VPN-Tunnels wird über UDP Port 4500 abgewickelt.

Einen VPN-Tunnel mit IKE über UDP Port 500 und IPSec mit ESP-Paketen (IP-Pakete mit Protokollnummer 50) macht nur Sinn, wenn beide VPN-Endpunkte mit einer öffentlichen IPv4-Adresse betrieben werden (keine NAT-Netzwerkkomponente zwischen den beiden VPN-Endpunkte). Alternativ können beide VPN-Endpunkte mit einer IPv6-Adresse betrieben werden (IPv6 kennt kein NAT).

Aber im Hinblick auf das kommende (heute noch nicht von LCOS unterstützte) MOBIKE:
https://www.heise.de/security/artikel/M ... 70948.html
macht ein VPN-Tunnel mit ESP-Pakete (IP-Pakete mit Protokollnummer 50) auch bei zwei öffentlichen IPv4-Adressen keinen Sinn mehr (Stichwort: 24h-Zwangstrennung).