Lancom VPN IKEv2 nur einseitiger Ping hinter CGN
Hallo,
wir haben aktuell zwei Standorte:
Standort A: Zentrale Feste IP V4 - LANCOM 1781
Standort B: 100.64.0.0/8 -> Carrier GRade NAT Netz , Dynamische IP v4 - LANCOM 1640E
-(internen kommunikation zweier Netze A 192.168.1.0/24 und B 192.168.2.0/24)
Nun konnte ich bisher einen IPsec IKEv2 Tunnel zwischen A und B herstellen, Routen sind gesetzt. Firewall SA's ebenfalls.
Ping von A and B klappt, leider nicht umgekehrt.
1. Es handelt sich hier um zwei LANCOM modell. Hat es hier evtl. etwas mit dem CGN zu tun, das keine Pakete durchlässt?
2. Müssen spezielle IPv6 Broker genutzt werden?
3. Oder sind bei dem IKEv2 Tunnel andere SA Routing optionen zusäztlich nötig?
Vieklen Dank für eure Hilfe
wir haben aktuell zwei Standorte:
Standort A: Zentrale Feste IP V4 - LANCOM 1781
Standort B: 100.64.0.0/8 -> Carrier GRade NAT Netz , Dynamische IP v4 - LANCOM 1640E
-(internen kommunikation zweier Netze A 192.168.1.0/24 und B 192.168.2.0/24)
Nun konnte ich bisher einen IPsec IKEv2 Tunnel zwischen A und B herstellen, Routen sind gesetzt. Firewall SA's ebenfalls.
Ping von A and B klappt, leider nicht umgekehrt.
1. Es handelt sich hier um zwei LANCOM modell. Hat es hier evtl. etwas mit dem CGN zu tun, das keine Pakete durchlässt?
2. Müssen spezielle IPv6 Broker genutzt werden?
3. Oder sind bei dem IKEv2 Tunnel andere SA Routing optionen zusäztlich nötig?
Vieklen Dank für eure Hilfe
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 458575
Url: https://administrator.de/forum/lancom-vpn-ikev2-nur-einseitiger-ping-hinter-cgn-458575.html
Ausgedruckt am: 22.12.2024 um 20:12 Uhr
12 Kommentare
Neuester Kommentar
Moinm,
Versuchst du die öffentlichen IP-Adressen anzupingen oder interne, private IP-Adressen vom jeweiligen Standort?
Ersteres kann eigentlich nur von Standort B nach Standort A funktionieren.
Zweiteres deutet daraufhin, dass dam LAMCOM noch eine Einstellung nicht korrekt ist. Oder evtl. eine Access-Liste den Ping (=ICMP) verhindert.
Gruß,
Dani
Ping von A and B klappt, leider nicht umgekehrt.
ich muss leider "doof" fragen:Versuchst du die öffentlichen IP-Adressen anzupingen oder interne, private IP-Adressen vom jeweiligen Standort?
Ersteres kann eigentlich nur von Standort B nach Standort A funktionieren.
Zweiteres deutet daraufhin, dass dam LAMCOM noch eine Einstellung nicht korrekt ist. Oder evtl. eine Access-Liste den Ping (=ICMP) verhindert.
Gruß,
Dani
Mahlzeit,
welche Routen hast du gesetzt?
Wenn du ein IPSECv2-VPN einrichtest und dazu bei Lancom den Assi nutzt, werden die Routen schon von selbst richtig konfiguriert.
Du musst eigentlich nur einstellen, dass der Anschluss mit CGN der Initiator ist.
Macht der 1640 am CGN-Anschluss die Einwahl oder ist der hinter einem weiteren Router angeschlossen?
Was ist das für ein Anschluss, Kabel oder LTE?
Wenn nicht, hast du das mal in einem Trace überprüft?
welche Routen hast du gesetzt?
Wenn du ein IPSECv2-VPN einrichtest und dazu bei Lancom den Assi nutzt, werden die Routen schon von selbst richtig konfiguriert.
Du musst eigentlich nur einstellen, dass der Anschluss mit CGN der Initiator ist.
Macht der 1640 am CGN-Anschluss die Einwahl oder ist der hinter einem weiteren Router angeschlossen?
Was ist das für ein Anschluss, Kabel oder LTE?
Ping von A and B klappt, leider nicht umgekehrt.
Sagt der Lanmonitor, dass das VPN steht?Wenn nicht, hast du das mal in einem Trace überprüft?
Eigentlich brauchst du nur ein Portforwarding (Portfreigabe) auf der Fritzbox zum Lancom zu machen:
UDP500
UDP4500
ESP
Ich würde zur Fehlersuche den Lanmonitor für den 1640 starten und dort alles mit VPN tracen.
Dann siehst du sehr schnell, wo es hängt.
UDP500
UDP4500
ESP
Zitat von @aif-get:
Dann muss es also eher an einer Regel fürs IKEv2 liegen? haben bisher immer mit v1 gearbeitet.
Nein, da ist eigentlich nichts komplizierter geworden.Dann muss es also eher an einer Regel fürs IKEv2 liegen? haben bisher immer mit v1 gearbeitet.
Ich würde zur Fehlersuche den Lanmonitor für den 1640 starten und dort alles mit VPN tracen.
Dann siehst du sehr schnell, wo es hängt.
@goscho
Gruß,
Dani
Eigentlich brauchst du nur ein Portforwarding (Portfreigabe) auf der Fritzbox zum Lancom zu machen:
aus welchem Grund: Der VPN-Tunnel ist doch laut seiner Aussage aufgebaut und aktiv. Es scheint nur der Ping von B nach A nicht zu gehen.Gruß,
Dani
Zitat von @Dani:
@goscho
Tja, ob das tatsächlich stimmt?@goscho
Eigentlich brauchst du nur ein Portforwarding (Portfreigabe) auf der Fritzbox zum Lancom zu machen:
aus welchem Grund: Der VPN-Tunnel ist doch laut seiner Aussage aufgebaut und aktiv. Es scheint nur der Ping von B nach A nicht zu gehen.Wenn nichtmal ein Ping durchgeht, sollte irgendwas nicht stimmen und ich denke, dass nix durch den Tunnel geht.
Zitat von @goscho:
Wenn nichtmal ein Ping durchgeht, sollte irgendwas nicht stimmen und ich denke, dass nix durch den Tunnel geht.
@goscho
Tja, ob das tatsächlich stimmt?Eigentlich brauchst du nur ein Portforwarding (Portfreigabe) auf der Fritzbox zum Lancom zu machen:
aus welchem Grund: Der VPN-Tunnel ist doch laut seiner Aussage aufgebaut und aktiv. Es scheint nur der Ping von B nach A nicht zu gehen.Wenn nichtmal ein Ping durchgeht, sollte irgendwas nicht stimmen und ich denke, dass nix durch den Tunnel geht.
Ohje...
WENN tatsächlich die Kommunikation des Tunnels selbst nur einseitig möglich wäre (weshalb auch immer), würde ein Ping in keine Richtung funktionieren. Denn jenachdem aus welcher Richtung keine Pakete durchkämen, würden entweder die Ping-Anfragen oder die Antworten darauf verloren gehen.
Es ist also kein Port-Forwarding nötig, weil die Tunnelpakete an sich ja ganz offensichtlich bidirektional ankommen.
Dass man von A nach B pingen kann, von B nach A aber nicht ist zu 100% sicher ein Firewall-Problem am VPN-Router selbst, da es ja nur den Traffic innerhalb des Tunnels betrifft