VPN Security Association trotz VPN-Netzwerk-Regeln nicht stabil

[Hagen2000]

Für die Wartung verschiedener Cloud-Server ist aus Sicherheitsgründen deren SSH-Zugang auf die feste IP-Adresse der Firma beschränkt.
Aus dem Homeoffice besteht jeweils ein VPN-Zugang zur Firma.

Code: Alles auswählen

=============               =================               ================
| FRITZ!Box |   <- VPN ->   | LANCOM 1784VA |   <- SSH ->   | Cloud-Server |
=============               =================               ================
 Homeoffice                  Firma, feste IP                 Cloud-Provider
 192.168.x.x                 10.y.y.y                        IP a.b.c.d

Um nun aus dem Homeoffice Zugriff auf die Cloud-Server zu erhalten, sind in der VPN-Konfiguration der FRITZ!Box zusätzlich die IP-Adressen der Cloud-Server eingetragen und im Router der Firma entsprechende VPN Netzwerk-Regeln definiert, so dass die SSH-Verbindung zunächst durch den VPN-Tunnel zum Router der Firma fließt und dann von dort - durch das NAT geleitet - zum Cloud-Server. Entsprechende Firewall-Regeln existieren selbstverständlich auch.

Prinzipiell funktioniert der Zugriff wie gewünscht, jedoch kommt es immer wieder zu Hängern, die sehr störend sind. Diese treten regelmäßig beim ersten SSH-Verbindungsversuch nach dem Aufbau der VPN-Verbindung auf (der SSH-Verbindungsversuch schlägt dann sogar fehl), jedoch auch immer wieder sporadisch im Betrieb (dann treten nur Hänger auf).

Mit LANtracer konnte ich ermitteln, dass Folgendes passiert:
Ein SSH-Client im Homeoffice wird gestartet, das erste Paket passiert den VPN-Tunnel und wird zum Cloud-Server geschickt, die Antwort vom Cloud-Server kommt im LANCOM-Router an, hier wird das Paket verworfen mit folgender Fehlermeldung:

Code: Alles auswählen

--> Discarded, sa lookup failed

Die Fehlermeldung ist natürlich ausführlicher und enthält u.a. die zu erwartenden IP-Adressen. Ein

Code: Alles auswählen

show vpn sadb

zeigt, dass es in der Tat keinen Eintrag in der SADB für die Rückroute des Pakets gibt, obwohl eine entsprechende VPN Netzwerk-Regel existiert. Dieses Verhalten bleibt über ca. 10 Sekunden stabil, so dass (vermutlich) Retries auch fehlschlagen und der SSH-Client schließlich aufgibt. Der nächste Versuch, den SSH-Client zu starten, funktioniert nun, in der SADB steht jetzt die benötigte Regel und die Antwort vom Cloud-Server wird nicht mehr verworfen. Dabei konnte ich beobachten, dass Einträge für mehrere - aber nicht alle - Cloud-Server entstehen, obwohl zu diesem Zeitpunkt nur ein Cloud-Server angesprochen worden ist. Außerdem konnte ich beobachten, dass sogar der Eintrag für eine SSH-Verbindung zum LANCOM-Router selbst aus der SADB verschwand und in dieser SSH-Session der beschriebene Hänger auftrat.
Aufgrund dieser Beobachtungen scheint mir die Security Association (SA) "nicht stabil" zu sein.

Liegt noch ein Konfigurationsfehler vor bzw. wie können wir dafür sorgen, dass die SADB die Einträge länger behält?

Weitere Informationen:

• Im Prinzip nutzen wir das gleiche Szenario, wie in diesem Thema beschrieben: viewtopic.php?t=16316
• Es wird nur IPv4 benutzt
• LCOS ist 10.72.0484RU6
• Die VPN-Regelerzeugung steht auf "automatisch", zusätzlich sind IPv4-Netzwerk-Regeln angegeben. Bei manueller Regelerzeugung ändert sich das beschriebene Verhalten jedoch nicht (ist laut diesem Beitrag viewtopic.php?p=105394&hilit=regelerzeugung+vpn#p105394 auch nicht zu erwarten).
• Es gibt mehrere Homeoffice-Zugänge
• Es gibt mehrere Cloud-Server

[Hagen2000]

Zwischenzeitlich wurde ein Update auf LCOS 10.80.0345RU2 durchgeführt, jedoch ohne Änderung des beschriebenen Verhaltens.
Ein show vpn zeigt (nach meinem Verständnis), dass alle benötigten Netzwerkbeziehungen korrekt definiert wurden.
Woran kann das nur liegen?

[Hagen2000]

Leider bin ich in dieser Sache noch nicht weiter gekommen.
Eine Beobachtung, die ich nun zweimal verifiziert habe, sowohl mit LCOS 10.70 als auch mit LCOS 10.80, ist jedoch bemerkenswert:

Ich habe bei den VPN-Verbindungen die Regelerzeugung auf Manuell gestellt und bei den Netzwerkregeln eine IPv4-Regel erstellt, die zusätzlich zu den Adressen der Cloud-Server auch das INTRANET enthält (in der Betriebsart Automatisch wird die Beziehung zum INTRANET aus der Routing-Tabelle abgeleitet und entfällt dann).

Über Nacht (oder nach unbestimmter Zeit) stellt nun der Router die Regelerzeugung von selbst wieder auf Automatisch. Warum passiert das?

[backslash]

Hi Hagen2000

Über Nacht (oder nach unbestimmter Zeit) stellt nun der Router die Regelerzeugung von selbst wieder auf Automatisch. Warum passiert das?

das macht ber sicherlich NICHT! Da hat wohl eher irgendwer ünet Nacht eine alte Konfig eingespielt... oder du hast irgendwelche CRON-Jobs laufen, die die Konfig zwitgesteuert ändern


Gruß
Backslash

[Hagen2000]

Danke - guter Tipp!
In der Tat gibt es Einträge in der Cron-Tabelle, die die Regelerzeugung aus- und wieder einschalten - und dabei auf Automatisch (Wert 2) stellen.
Das musste ich vor vielen Jahren wegen dieses Problems einrichten: fragen-zur-lancom-systems-routern-und-g ... 15551.html

Deswegen passiert das auch nur, wenn der Router über Nacht durchläuft.
Somit ist dieses Detail geklärt.

[Hagen2000]

Leider bin ich mit diesem Problem immer noch nicht weiter gekommen.

Möglicherweise würde mir ein DNAT helfen: Dann könnte ich eine Adresse im INTRANET ansprechen, die dann auf die gewünschte externe Adresse umgesetzt wird. Das würde die VPN-Netzwerk-Regeln wieder reduzieren auf die beiden Netze Homeoffice und Firma - in dem Szenario hat das VPN jahrelang störungsfrei funktioniert.

So wie ich das sehe, stellt das LCOS aber kein DNAT zur Verfügung. Womit könnte ich das sonst noch umsetzen? Ein zweiter, derzeit unbenutzter 1781VA stünde zur Verfügung.

[Hagen2000]

Die Idee, einen zweiten Router (in diesem Fall einen LANCOM 1781VA) für das DNAT zu verwenden, war erfolgreich. Die Probleme mit instabilen Verbindungen sind nun beseitigt.

Der Zweitrouter nutzt dabei als WAN-Verbindung DSL-1 mit IPOE auf ETH-1 und einer statischen IP-Adresse aus dem INTRANET das Hauptrouters.
Unter dieser IP-Adresse kann er somit als LAN-Teilnehmer aus Sicht des Hauptrouters angesprochen werden. Dadurch werden für Zugriffe über VPN keine besonderen VPN-Netzwerk-Regeln mehr benötigt.

Über die Port-Forwarding-Tabelle wird nun das Destination-NAT (DNAT) realisiert. Je Zieladresse muss hier eine eigene, vom Standard abweichende Portnummer definiert werden. Da es sich in der Regel um SSH-Zugänge handelt, ist das kein Problem.

Da die Zieladressen wiederum über die WAN-Verbindung erreichbar sind, schickt der Zweitrouter die Pakete über diese wieder zum Hauptrouter und benötigt somit nur eine einzelne "Stichleitung" zum Hauptrouter. Sein VDSL-Modem ist abgeschaltet und die übrigen Ethernet-Ports bleiben unbenutzt bzw. sind einem nicht weiter verwendeten LAN zugeordnet.

Fazit: Eine langwierige Fehlersuche, deren eigentliche Ursache unklar bleibt und nur durch ein Workaround umgangen werden kann.