6
Ist es möglich das IPsec Verkehr geblockt werden kann?
Moin 
Es geht darum. Zwischen einem Bintec und dem NCP-Client wurde ein VPN erstellt. Dieses VPN lässt sich immer aufbauen. Allerdings scheint der Kunde das Problem zu haben, dass nach dem VPN-Aufbau kein Traffic durchgeht...
Das VPN habe ich nun auch unter 4 Bedingungen testen können:
1. Bei mir im Office: VPN lässt sich aufbauen und Clients sowie Internetadressen lassen sich pingen, RDP geht auch.
2. Bei mir daheim: VPN lässt sich aufbauen und Clients sowie Internetadressen lassen sich pingen, RDP geht auch.
3. Beim Kunden: VPN lässt sich aufbauen, allerdings zeigt mir der NCP-Client nur an das Daten gesendet werden können und erhält keine mehr zurück. Ping, RDP auf Clients und Google.de funktionieren nicht
4. Mobilfunk via T-Mobile: VPN lässt sich aufbauen, allerdings zeigt mir der NCP-Client nur an das Daten gesendet werden können und erhält keine mehr zurück. Ping, RDP auf Clients und Google.de funktionieren nicht
Es wäre mir neu, aber sobald das VPN aufgabaut ist, sollte sich der Traffic durch das VPN doch nicht blocken lassen können, oder haben Firewalls neuerdings die Möglichkeit das VPN aufzubauen aber nix durchzulassen?
Es handelt sich dabei um 2 Identische VPNs bei denen sich nur der User und der Preshared Key unterscheiden.
IKE wird via AES 128bit mit MD5 Hash verschlüsselt
IPsec läuft via ESP und dann AES 128bit mit MD5 Authentisierung
Ich hoffe ihr könnts mir einen Einfall geben wieso das VPN nicht funktioniert wie es soll.
Gruß
Seelbreaker
Es geht darum. Zwischen einem Bintec und dem NCP-Client wurde ein VPN erstellt. Dieses VPN lässt sich immer aufbauen. Allerdings scheint der Kunde das Problem zu haben, dass nach dem VPN-Aufbau kein Traffic durchgeht...
Das VPN habe ich nun auch unter 4 Bedingungen testen können:
1. Bei mir im Office: VPN lässt sich aufbauen und Clients sowie Internetadressen lassen sich pingen, RDP geht auch.
2. Bei mir daheim: VPN lässt sich aufbauen und Clients sowie Internetadressen lassen sich pingen, RDP geht auch.
3. Beim Kunden: VPN lässt sich aufbauen, allerdings zeigt mir der NCP-Client nur an das Daten gesendet werden können und erhält keine mehr zurück. Ping, RDP auf Clients und Google.de funktionieren nicht
4. Mobilfunk via T-Mobile: VPN lässt sich aufbauen, allerdings zeigt mir der NCP-Client nur an das Daten gesendet werden können und erhält keine mehr zurück. Ping, RDP auf Clients und Google.de funktionieren nicht
Es wäre mir neu, aber sobald das VPN aufgabaut ist, sollte sich der Traffic durch das VPN doch nicht blocken lassen können, oder haben Firewalls neuerdings die Möglichkeit das VPN aufzubauen aber nix durchzulassen?
Es handelt sich dabei um 2 Identische VPNs bei denen sich nur der User und der Preshared Key unterscheiden.
IKE wird via AES 128bit mit MD5 Hash verschlüsselt
IPsec läuft via ESP und dann AES 128bit mit MD5 Authentisierung
Ich hoffe ihr könnts mir einen Einfall geben wieso das VPN nicht funktioniert wie es soll.
Gruß
Seelbreaker
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 192932
Url: https://administrator.de/contentid/192932
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
6 Kommentare
Neuester Kommentar
Was den Punkt 4 anbetrifft ist das möglich und sogar auch sehr wahrscheinlich.
Wenn du einen billigen Surfaccount bei deinem provider hast werden in der Regel dort immer VPN Traffic blockiert.
Das passiert schon dadurch das du im Mobilfunknetz eine RFC 1918 IP Adresse (Private IP) bekommst. Damit macht der Provider dann lokales NAT (Adress Translation was VPN Tunneltraffic in der Regel nicht überwinden kann. Aber auch wenn wird ESP, GRE und die anderen gängigen Tunnelprotokolle bei solchen Accounts zusätzlich blockiert.
Aus Providersicht verständlich, denn Otto Normalsurfer nutzt eben kein VPN und wenn soll er dafür einen Business Account nehmen und auch bezahlen. Kost halt etwas mehr....
Du kannst das schnell und einfach kontrollieren indem du bei aktiver Mobilfunkverbindung dir einemal deien vergebene IP Adresse im Mobilnetz ansiehst. Ist das eine 10, 172 oder 192.168er ists meist aus mit VPN.
Das Provider auf dem DSL Link VPN Tunnelprotokolle filtern ist eher selten und unüblich. Ausschliessen kann man es bei einigen Tarifstrukturen aber nicht. Eine Telefonat mit der Hotline sollte dort schnell Klarheit schaffen.Zu vermuten ist eher das dein Kunde ggf. ein Problem mit der MTU am Router hat. Bei VPN Verbindungen ist das nicht unüblich.
Du solltest hier also mal die max. MTU rausbekommen:
http://www.gschwarz.de/mtu-wert-ermitteln
bzw.
http://www.gschwarz.de/mtu-wert-router
und den WAN MTU Wert ggf. entsprechend customozen für VPN.
Wenn du einen billigen Surfaccount bei deinem provider hast werden in der Regel dort immer VPN Traffic blockiert.
Das passiert schon dadurch das du im Mobilfunknetz eine RFC 1918 IP Adresse (Private IP) bekommst. Damit macht der Provider dann lokales NAT (Adress Translation was VPN Tunneltraffic in der Regel nicht überwinden kann. Aber auch wenn wird ESP, GRE und die anderen gängigen Tunnelprotokolle bei solchen Accounts zusätzlich blockiert.
Aus Providersicht verständlich, denn Otto Normalsurfer nutzt eben kein VPN und wenn soll er dafür einen Business Account nehmen und auch bezahlen. Kost halt etwas mehr....
Du kannst das schnell und einfach kontrollieren indem du bei aktiver Mobilfunkverbindung dir einemal deien vergebene IP Adresse im Mobilnetz ansiehst. Ist das eine 10, 172 oder 192.168er ists meist aus mit VPN.
Das Provider auf dem DSL Link VPN Tunnelprotokolle filtern ist eher selten und unüblich. Ausschliessen kann man es bei einigen Tarifstrukturen aber nicht. Eine Telefonat mit der Hotline sollte dort schnell Klarheit schaffen.Zu vermuten ist eher das dein Kunde ggf. ein Problem mit der MTU am Router hat. Bei VPN Verbindungen ist das nicht unüblich.
Du solltest hier also mal die max. MTU rausbekommen:
http://www.gschwarz.de/mtu-wert-ermitteln
bzw.
http://www.gschwarz.de/mtu-wert-router
und den WAN MTU Wert ggf. entsprechend customozen für VPN.
Hi aqui,
meinst du mit dem Kunden-Router der wegen der MTU zickt, dass Szenario Nr. 2?
Oder der Router von meinem der als VPN-Gegenstück fungiert?
Aufgrund meiner Tests vermute ich dass du den Router in Szenario Nr. 2 verwendest, da es bei mir im Office (M-Net) und bei mir daheim (Kabel Deutschland) geht.
Das es beim Mobilfunk zickt hatte ich mir auch schon gedacht das T-Mobile IPsec blockt, allerdings hätte ich eher vermutet, dass ich nichtmal das VPN aufbauen kann - das ist der Teil der mich am meisten stutzig macht
Danke dir schonmal für die Antwort!
meinst du mit dem Kunden-Router der wegen der MTU zickt, dass Szenario Nr. 2?
Oder der Router von meinem der als VPN-Gegenstück fungiert?
Aufgrund meiner Tests vermute ich dass du den Router in Szenario Nr. 2 verwendest, da es bei mir im Office (M-Net) und bei mir daheim (Kabel Deutschland) geht.
Das es beim Mobilfunk zickt hatte ich mir auch schon gedacht das T-Mobile IPsec blockt, allerdings hätte ich eher vermutet, dass ich nichtmal das VPN aufbauen kann - das ist der Teil der mich am meisten stutzig macht
Danke dir schonmal für die Antwort!
Sieht für mich nach einen NAT-Traversal Problem aus.
Es müsste noch geklärt werden, ob in allen 4 Fällen gegen die selbe Bintec verbunden wird und welche Mediatypen in den ersten 3 Fälle benutzt werden.
Es müsste noch geklärt werden, ob in allen 4 Fällen gegen die selbe Bintec verbunden wird und welche Mediatypen in den ersten 3 Fälle benutzt werden.
.@Sealbreaker
Nein, deiner kanns ja wohl kaum sein, den bei dir funktioniert der Router ja mit dem VPN problemlos. Es kann also nur der Kundenrouter sein....
Was IPsec anbetrifft solltest du ggf. Mal etwas zum Protokoll lesen:
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
..dann musst du nicht mehr denken was den VPN Aufbau anbetrifft.
Nein, deiner kanns ja wohl kaum sein, den bei dir funktioniert der Router ja mit dem VPN problemlos. Es kann also nur der Kundenrouter sein....
Was IPsec anbetrifft solltest du ggf. Mal etwas zum Protokoll lesen:
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
..dann musst du nicht mehr denken was den VPN Aufbau anbetrifft.
Das hatte ich auch schon mal und es lag an einem fehlerhaften Profil im IPsec Client. Konfiguration sah alles korrekt aus. Aber genau das Phänomen. Profil neu eingerichtet und es ging sofort.
MfG Andi
MfG Andi
Zitat von @JuergenNCP:
Sieht für mich nach einen NAT-Traversal Problem aus.
Es müsste noch geklärt werden, ob in allen 4 Fällen gegen die selbe Bintec verbunden wird und welche Mediatypen in
den ersten 3 Fälle benutzt werden.
Sieht für mich nach einen NAT-Traversal Problem aus.
Es müsste noch geklärt werden, ob in allen 4 Fällen gegen die selbe Bintec verbunden wird und welche Mediatypen in
den ersten 3 Fälle benutzt werden.
Es wird in allen 4 Fällen immer gegen die selbe Bintec R232b verbunden.
Zitat von @aqui:
Aber auch wenn wird ESP, GRE und die anderen gängigen Tunnelprotokolle bei solchen Accounts zusätzlich blockiert.
Aus Providersicht verständlich, denn Otto Normalsurfer nutzt eben kein VPN und wenn soll er dafür einen Business Account > nehmen und auch bezahlen. Kost halt etwas mehr....
Aber auch wenn wird ESP, GRE und die anderen gängigen Tunnelprotokolle bei solchen Accounts zusätzlich blockiert.
Aus Providersicht verständlich, denn Otto Normalsurfer nutzt eben kein VPN und wenn soll er dafür einen Business Account > nehmen und auch bezahlen. Kost halt etwas mehr....
Habe ebend bei mir nachgeschaut, es handelt sich bei mir um einen privaten t-mobile account allerdings erhalte ich keine private IP-Adresse sondern eine aus dem 80er Bereich.
Was des ganze angeht, bin ich mit meinem Latein schon ziemlich am Ende... Werde nun schauen, dass der Kunde mir sein Notebook in die Hand drückt... wenn es bei mir daheim funktioniert kann der bei sich schaun was die Firewall etc. sagt...
