OpenVPN über Port 443

[neoman666]

Hi,

ich weiß, dieses Thema wurde hier schon x-fach behandelt, jedoch nicht gelöst. Ich möchte einen neue Anlauf zum Thema nehmen und hoffe auf eine gemeinsame Lösung.

Ich möchte, da ich mich bald im Ausland aufhalte wo mit Sicherheit in den Hotels die Port für ipsec geblockt sind eine VPN-Verbindung mit OpenVPN über Port 443 nutzen. Meine DS ist eine DS218+. Habe dort bereits OpenVPN über Port 1194 erfolgreich eingerichtet, was auch tadellos funktioniert.

Was muss ich aber alles umstellen, damit das OpenVPN auch über Port 443 klappt?

Was ich bis jetzt probiert habe:

1. In meinem Router habe ich Port 443/UDP auf Port 1194/UDP meiner DS forwarded.
- Eine Verbindung mit OpenVPN ließ sich herstellen, jedoch nicht in einem Netz, wo der Port 1194 geblockt ist.

2. In meinem Router habe ich Port 443/UDP auf Port 443/UDP meiner DS forwarded. Zusätzlich habe ich in der DS unter VPN-Server den Port für OpenVPN von 1194 auf 443 umgestellt.
- Eine Verbindung lässt sich zwar herstellen, aber ich bekomme keine Verbindung in mein internes Netz.


Nun meine Frage. Was muss ich alles umstellen, damit OpenVPN auf über Port 443 geht? Wer kann mir helfen?


MfG neoman

 

[diver68]

Hi

Ich habe das nach dieser Anleitung gemacht: http://smartathome.blogspot.com/2017/01/installing-sslh-onto-synology-dsm6-for.html
Läuft problemlos.

Gruß

 

[neoman666]

Hi,

also reicht die Portweiterleitung wie ich unter 1. beschrieben habe alleine nicht aus damit das funktioniert?

@diver68: Das werde ich mir anschauen. Wollte nur nicht an irgendwelche Konfigdateien auf der Shell rumbasteln. Aber so wie ich es überflogen habe, muss ich ja nur an die Konfig des SSLH-Pakets ran und nicht an irgendwelchen Kerndateien des DSM.

Wenns keinen anderen Weg gibt, werde ich das mal versuchen...

Bis später...

 

[neoman666]

Achso, noch ne Frage. Wozu ist dann eigentlich die Möglichkeit beim OpenVPN-Server der Sonology da die Portnummer über den DSM ändern zu können?

 

[Frogman]

Um eben Portnummer bzw. auch das Protokoll zu ändern...

 

[neoman666]

Um eben Portnummer bzw. auch das Protokoll zu ändern...

Ja, aber es funktioniert ja nicht mit Boardmitteln sondern nur mit Extra-Erweiterungen. Also sinnlos...

 

[NEWDS]

Ich habe damals port share für den OpenVPN Server konfiguriert:

https://www.synology-forum.de/showthread.html?65150-OpenVPN-Config-port-share

Ob das immer noch so funktioniert, kann ich nicht sagen, da ich es nicht mehr benötige.

Ich habe eine OpenVPN Konfig angelegt (/usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf.user):

proto tcp6-server
port 1194
port-share 127.0.0.1 443
...

Der Webserver lief auf Port 443 und der OpenVPN auf Port 1194.
Auf dem Router habe ich eine Portweiterleitung von Port 443 ---> Port 1194 (TCP) erstellt.

 

[tproko]

Hm, also bei mir war OpenVPN von außen per 443 verfügbar (jetzt läuft Vpn am Router)

Was ist dein Problem? Das lässt sich lösen.

Router leitet 443 von außen auf NAS 1194 UDP weiter.
In der openvpn config muss dann auch entsprechend also IP und Port 443 stehen (das nas wird 1194 generieren in der openvpn.config Datei).

Mehr ist nicht nötig. Wenn bei dir nix geht wenn 1194 gesperrt ist, geht dein Client wohl nicht richtig zum Server.

 

[neoman666]

Was ist dein Problem? Das lässt sich lösen.

Router leitet 443 von außen auf NAS 1194 UDP weiter.

Mein Problem ist das diese Methode bei mir nicht funktioniert hat, wie oben schon beschrieben. Normalerweise dürfte doch die Firewall des Hotelnetzes nun nichts mehr vom Port 1194 mitbekommen sondern nur vom Port 443. Dennoch wollte dies in meinem Testnetzwerk nicht klappen. Dort war der Port 1194 gesperrt, der Port 443 auf, dennoch bekam ich keine Verbindung.

 

[tproko]

Ja und warum hat dein Client nach wie vor 1194 verwendet? Wenn dem so war, dann ist das seltsam.
Das ganze ist jedenfalls einfach möglich.

Hast du am Client den Port in der ovpn Config von 1194 auf 443 geändert?
Welchen router hast du, Fritzbox zickt ja auch hin und wieder bei PortForwards was man hier so liest.

Du müsstest dich nochmal damit beschäftigen, aber jetzt kann man nur die Nadel im Heuhaufen suchen, weil mehr Info außer es geht nicht haben wir noch nicht. Also da müssten wir nochmals gemeinsam versuchen, das zu lösen.
Ich behaupte, es geht

Vielleicht blockiert auch die syno Firewall, ggf. diese bei den Tests mal abdrehen.

- Außen am router 443, sprich 443 auf 1194 weiterleiten
- beim Router würde ich 1194 nicht weiterleiten, denke du hattest hier immer beide Regeln?
- Openvpn config mit IP und port 443 (das musst du manuell ändern, weil syno exportiert das immer mit dem internen Port)
- Am vpn server 1194 als port
- Firewall checken

 

[Frogman]

Dennoch wollte dies in meinem Testnetzwerk nicht klappen. Dort war der Port 1194 gesperrt, der Port 443 auf, dennoch bekam ich keine Verbindung.

Man sollte darauf schauen, welches Protokoll verwendet wird. In vielen Firewalls werden UDP-Ports gesperrt, dann muss man also 443/TCP nutzen.

 

[tproko]

Stimmt auch noch ein guter Tipp.
Ich hatte bisher in Deutschland / EU eigentlich mit 443 UDP eigentlich noch nie Probleme.

 

[neoman666]

Hast du am Client den Port in der ovpn Config von 1194 auf 443 geändert?

Ja habe ich.

Welchen router hast du, Fritzbox zickt ja auch hin und wieder bei PortForwards was man hier so liest.

Ist ne etwas ältere Fritzbox.

Vielleicht blockiert auch die syno Firewall, ggf. diese bei den Tests mal abdrehen.

Ist deaktiviert.

- Außen am router 443, sprich 443 auf 1194 weiterleiten
- beim Router würde ich 1194 nicht weiterleiten, denke du hattest hier immer beide Regeln?
- Openvpn config mit IP und port 443 (das musst du manuell ändern, weil syno exportiert das immer mit dem internen Port)
- Am vpn server 1194 als port
- Firewall checken

Auch das ist alles i.O.

Man sollte darauf schauen, welches Protokoll verwendet wird. In vielen Firewalls werden UDP-Ports gesperrt, dann muss man also 443/TCP nutzen.

Ok, das könnte gut möglich sein. Wenn ich das auf TCP umstelle bzw. weiterleite, dann werd ich doch bestimmt Probleme bekommen, da das auf der Sonology schon durch den Webserver belegt ist?



Ich poste mal das Log meines OpenVPN-Clients (IP-Adresse und Hostname ersetzt). Ist jetzt aber aus einem Netz wo alles offen ist. Im gesperrten Netz kann ich erst morgen wieder testen.

06:53 WARNING:  Compression enabled, Compression has been used in the past to break encryption. Enabling decompression of received packet only. Sent packets are not compressed.

06:53 OpenVPN 2.5-icsopenvpn [git:icsopenvpn/v0.7.8-0-g168367a5] armeabi-v7a [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 22 2019

06:53 library versions: OpenSSL 1.1.1a  20 Nov 2018, LZO 2.10

06:53 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.

06:53 TCP/UDP: Preserving recently used remote address: [AF_INET]1.2.3.4:443

06:53 UDP link local (bound): [AF_INET][undef]:1194

06:53 UDP link remote: [AF_INET]1.2.3.4:443

06:53 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

06:53 [xxx.synology.me] Peer Connection Initiated with [AF_INET]1.2.3.4:443

06:53 Initialization Sequence Completed

Nachfolgende Zeile stört mich etwas. Was bedeutet sie?

06:53 UDP link local (bound): [AF_INET][undef]:1194

 

[diver68]

Ok, das könnte gut möglich sein. Wenn ich das auf TCP umstelle bzw. weiterleite, dann werd ich doch bestimmt Probleme bekommen, da das auf der Sonology schon durch den Webserver belegt ist?

Deshalb ja die von mir vorgeschlagene Methode mit SSLH:



Poste doch mal Deine OpenVPN config (client). Da fehlt m.E. die Authentifizierungsmethode (CA)

 

[neoman666]

Hier meine Config...

dev tun
tls-client

remote xxx.synology.me 443

# The "float" tells OpenVPN to accept authenticated packets from any address,
# not only the address which was specified in the --remote option.
# This is useful when you are connecting to a peer which holds a dynamic address
# such as a dial-in user or DHCP client.
# (Please refer to the manual of OpenVPN for more information.)

#float

# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)

redirect-gateway def1

# dhcp-option DNS: To set primary domain name server address.
# Repeat this option to set secondary DNS server addresses.

#dhcp-option DNS DNS_IP_ADDRESS

pull

# If you want to connect by Server's IPv6 address, you should use
# "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode
proto udp

script-security 2


comp-lzo

reneg-sec 0

cipher AES-256-CBC

auth SHA512

auth-user-pass

 

[diver68]

Mache mal die Komprimierung aus. Kommt bei Dir anschließend das Zertifikat?

script-security 2



reneg-sec 0

cipher AES-256-CBC

auth SHA1

auth-user-pass
<ca>
-----BEGIN CERTIFICATE-----

 

[neoman666]

Ja, Zertifikat hab ich natürlich für den Post entfernt. Komprimierung mach ich mal raus. Ich kann es aber wie gesagt erst morgen testen.

Mit dem SSHL bin ich mir nicht so sicher ob ich das mach. Die Pakete kommen ja nicht direkt von Synology...

 

[neoman666]

So, ich denke es ist so wie @Frogman geschrieben hat. 443/UDP wird gesperrt sein, deswegen baut er keine Verbindung auf. Auch in anderen Netzwerken kann 443/UDP gesperrt sein, das weiß man ja vorher nicht. Deswegen wird es doch besser sein, hier 443/TCP zu verwenden, somit ist man dann auf der sicheren Seite.

Ich werde das mit dem SSLH mal versuchen. Denke man kann davon ausgehen, das die Pakete von SynoCommunity sicher sind...

 

[diver68]

Wo bist Du gerade wenn ich fragen darf, dass UDP 443 gesperrt ist?

 

[neoman666]

Ich würde nochmal Hilfe benötigen. Ich habe versucht nach dieser Anleitung vorzugehen. Jedoch bleibe ich beim Punkt 10 hängen, wie auch ein User in den Kommentaren beschreibt. Die Datei WWWService.mustache sieht bei mir anders aus als in dem Tutorial. Meine originale Datei sieht so aus:

server {
    listen 80 default_server{{#reuseport}} reuseport{{/reuseport}};
    listen [::]:80 default_server{{#reuseport}} reuseport{{/reuseport}};

    gzip on;

    {{> /usr/syno/share/nginx/WWW_Main}}

    location ~ ^/$ {
        rewrite / http://$host:{{DSM.port}}/ redirect;
    }
}

server {
    listen 443 default_server ssl{{#reuseport}} reuseport{{/reuseport}};
    listen [::]:443 default_server ssl{{#reuseport}} reuseport{{/reuseport}};
    {{#DSM.https.compression}}
    gzip on;
    {{/DSM.https.compression}}

    {{> /usr/syno/share/nginx/WWW_Main}}

    location ~ ^/$ {
        rewrite / https://$host:{{DSM.ssl.port}}/ redirect;
    }
}

Diese habe ich geändert in:

server {
    listen 80 default_server{{#reuseport}} reuseport{{/reuseport}};
    listen [::]:80 default_server{{#reuseport}} reuseport{{/reuseport}};

    gzip on;

    {{> /usr/syno/share/nginx/WWW_Main}}

    location ~ ^/$ {
        rewrite / http://$host:{{DSM.port}}/ redirect;
    }
}

server {
    listen 127.0.0.1:443 default_server ssl{{#reuseport}} reuseport{{/reuseport}};
    listen [::]:443 default_server ssl{{#reuseport}} reuseport{{/reuseport}};
    {{#DSM.https.compression}}
    gzip on;
    {{/DSM.https.compression}}

    {{> /usr/syno/share/nginx/WWW_Main}}

    location ~ ^/$ {
        rewrite / https://$host:{{DSM.ssl.port}}/ redirect;
    }
}

Wie gesagt, in dem Tutorial sieht diese Datei anders aus. Wenn ich nun die Anleitung bis zum Schluss weiter durchgehe und den Befehl

netstat -an | grep 443

ausführe kommt bei mir folgende Ausgabe (192.168.1.1 ist meine Synology):

tcp        0      0 127.0.0.1:443           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:38443           0.0.0.0:*               LISTEN
tcp        0      0 192.168.1.1:54610    99.84.92.57:443         TIME_WAIT
tcp        0      0 192.168.1.1:41038    35.183.227.87:443       TIME_WAIT
tcp        0      0 192.168.1.1:54612    99.84.92.57:443         TIME_WAIT
tcp        0      0 192.168.1.1:41036    35.183.227.87:443       TIME_WAIT

Irgendwas scheint hier nicht zu stimmen. Bis auf die Datei WWWService.mustache hat aber alle nach Anleitung funktioniert. Jemand eine Idee wie ich das noch zum Laufen kriege?