OpenVPN über Port 443

Status
Für weitere Antworten geschlossen.

neoman666

Benutzer
Mitglied seit
16. Dez 2018
Beiträge
40
Punkte für Reaktionen
0
Punkte
6
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
 

neoman666

Benutzer
Mitglied seit
16. Dez 2018
Beiträge
40
Punkte für Reaktionen
0
Punkte
6
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

Benutzer
Mitglied seit
16. Dez 2018
Beiträge
40
Punkte für Reaktionen
0
Punkte
6
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

Benutzer
Mitglied seit
01. Sep 2012
Beiträge
17.485
Punkte für Reaktionen
8
Punkte
414
Um eben Portnummer bzw. auch das Protokoll zu ändern...
 

NEWDS

Benutzer
Mitglied seit
05. Aug 2012
Beiträge
109
Punkte für Reaktionen
4
Punkte
18
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):

Rich (BBCode):
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

Benutzer
Sehr erfahren
Mitglied seit
11. Jun 2017
Beiträge
2.101
Punkte für Reaktionen
253
Punkte
129
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

Benutzer
Mitglied seit
16. Dez 2018
Beiträge
40
Punkte für Reaktionen
0
Punkte
6
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

Benutzer
Sehr erfahren
Mitglied seit
11. Jun 2017
Beiträge
2.101
Punkte für Reaktionen
253
Punkte
129
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
 
Zuletzt bearbeitet:

Frogman

Benutzer
Mitglied seit
01. Sep 2012
Beiträge
17.485
Punkte für Reaktionen
8
Punkte
414
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

Benutzer
Sehr erfahren
Mitglied seit
11. Jun 2017
Beiträge
2.101
Punkte für Reaktionen
253
Punkte
129
Stimmt auch noch ein guter Tipp.
Ich hatte bisher in Deutschland / EU eigentlich mit 443 UDP eigentlich noch nie Probleme.
 

neoman666

Benutzer
Mitglied seit
16. Dez 2018
Beiträge
40
Punkte für Reaktionen
0
Punkte
6
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.

Rich (BBCode):
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?

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

diver68

Benutzer
Mitglied seit
07. Nov 2012
Beiträge
399
Punkte für Reaktionen
16
Punkte
18
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:

sslh.jpg

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

neoman666

Benutzer
Mitglied seit
16. Dez 2018
Beiträge
40
Punkte für Reaktionen
0
Punkte
6
Hier meine Config...

Rich (BBCode):
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

Benutzer
Mitglied seit
07. Nov 2012
Beiträge
399
Punkte für Reaktionen
16
Punkte
18
Mache mal die Komprimierung aus. Kommt bei Dir anschließend das Zertifikat?

Rich (BBCode):
script-security 2



reneg-sec 0

cipher AES-256-CBC

auth SHA1

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

neoman666

Benutzer
Mitglied seit
16. Dez 2018
Beiträge
40
Punkte für Reaktionen
0
Punkte
6
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

Benutzer
Mitglied seit
16. Dez 2018
Beiträge
40
Punkte für Reaktionen
0
Punkte
6
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

Benutzer
Mitglied seit
07. Nov 2012
Beiträge
399
Punkte für Reaktionen
16
Punkte
18
Wo bist Du gerade wenn ich fragen darf, dass UDP 443 gesperrt ist?
 

neoman666

Benutzer
Mitglied seit
16. Dez 2018
Beiträge
40
Punkte für Reaktionen
0
Punkte
6
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:

Rich (BBCode):
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:

Rich (BBCode):
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

Rich (BBCode):
netstat -an | grep 443

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

Rich (BBCode):
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?
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat