VPN Verbindung schlägt fehl

geohei

Mitglied
Mitglied seit
8 Apr 2005
Beiträge
476
Punkte für Reaktionen
3
Punkte
18
Hallo.

Ich benutze seit Jahren ein VPN Settings File um meine VPN Clients an meiner FB7490 FW:07.29 zu konfigurieren.
Alles klappt wunderbar.

Code:
vpncfg
{
    connections
    {
        enabled = yes;
        conn_type = conntype_user;
        name = "iphone-geohei";
...
        phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
        accesslist = "permit ip 192.168.178.0 255.255.255.0 192.168.178.205 255.255.255.255",
                     "permit ip any 192.168.178.205 255.255.255.255";
    }      
    ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
                        "udp 0.0.0.0:4500 0.0.0.0:4500";

    }
}
In einigen Ländern unterbinden die Provider VPN jedoch (z.B. Ägypten).
Kann ich an meinem Settings File etwas ändern um das zu umgehen?
 
Es kommt sehr darauf an, wie das VPN geblockt wird. Werden da einfach nur Ports gesperrt, oder auch Protokolle wie ESP? Ist letzteres der Fall, hast du keine Chance, das IPSec VPN der Boxen vor 07.50 ist auf ESP angewiesen.

Da Portnummern einfach zu verändern sind, wird jeder, der es ernst meint, die Protokolle blocken, und nicht die Ports.
 
Danke für die Erklärungen.
Ich werde es jetzt einmal mit 3 verschiedenen VPNs probieren.
Vielleicht geht einer ja durch.
Lästig das Ganze!
 
Die größten Chancen hast du meines Erachtens mit OpenVPN über TCP auf Port 443. Das ist von echter https Kommunikation kaum zu unterscheiden. Damit bin ich bislang noch durch jede Firmen-Firewall gekommen.
 
Ich habe jetzt OpenVPN über (default) Port 1194/udp erfolgreich auf meinem iOS installiert. Server ist ein NAS. Verbindung steht. Soll ich den Port auf 443/tcp umstellen oder hat der eine nichts mit dem anderen zu tun?
 
Auf 443 wechseln ist doch nur geboten, wenn 1194 geblockt wird. Hauptsache, Du behältst dies für den Fall der Fälle im Hinterkopf
UDP vs. TCP ist doch nur die Geschwindigkeit zu Lasten der Fehlerfreiheit der Datenpakete. UDP-Pakete werden ja einfach nur durch gewunken und im Fehlerfall verworfen. TCP-Pakete immer bestätigt und ggf. neu angefordert.
Wenn’s so läuft, wäre mein Motto:
Don‘t touch a running system
 
  • Like
Reaktionen: geohei
Damit bin ich bislang noch durch jede Firmen-Firewall gekommen.
Ja, bei einem nicht besonders aufmerksamen, nicht gut ausgebildeten oder überhaupt nicht vorhandenen IT-Sicherheitsbeauftragten mag das funktionieren. (Ich hatte Fälle, wo sogar der DNS-Port dafür etwas zweckentfremdet wurde.)
Und ich gehe auch davon aus, dass bei den üblichen staatlichen Methoden (TLS-Breaker und Content-Scan usw.) auch in so manchen Ländern (den dafür bekannten Ländern …) diese Methode auch nicht zum Ziel führt.

Auf jeden Fall kann man das probieren. Versuch macht kluch …

vy 73 de Peter
 
  • Like
Reaktionen: geohei
So ... alles ausprobiert.
1194/udp, 443/udp, 443/tcp ... nichts geht mit OpenVPN.
Das OpenVPN (Client) Log zeigt auch nichts verwertbares an.
Was kann ich noch probieren?
 
Zuletzt bearbeitet:
Du könntest analysieren, was überhaupt beim VPN Server ankommt und warum die Verbindung scheitert.
 
  • Like
Reaktionen: totalverrückteruser
Die entsprechenden Dienstellen im Iran oder Ägypten sind keine Idioten. Per DPI + vertrauenswürdigem Zertifikat brechen die die https Verbindung auf. Kommt kein Klartext raus wird geblockt. So stell ich mir das zumindest vor.
Sonst wäre die Unterbindung von VPN nicht wirklich möglich.
 
@frank_m24
Der VPN Server besteht z.Z. aus einer NAS App. Das Log gibt nicht wirklich viel her. Wenn wieder zu Hause werde ich einen ausgewachsenen OpenVPN Server aufsetzen.

@totalverrückteruser
Stimmt. Sonst müsste 443/tcp durch kommen.

Frage mich nur ständig warum die so einen Aufwand betreiben? (OT)

... später ...

Habe jetzt auf einmal mit 443/tcp diese Fehler auf der Client Seite bekommen:
- Errors receiving on network socket : 2 times
- General transport error : 2 times
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.