Hallo
Ich möchte den OpnVPN Dienst auf TCP 443 umkonfigurieren. Allerdings habe ich auf 443 bereits meine Nextcloud am laufen. Diese ist via HAProxy eingerichtet, nach dieser Anleitung: https://schulnetzkonzept.de/opnsense (https://schulnetzkonzept.de/opnsense).
Ist es überhaupt möglich, OpnVPN auch noch über 443 zu betreiben?
lg
Warum soll denn der Tunnel über den Port für HTTPS aufgebaut werden? Man kann doch irgendeinen Port (12345? whatever...) verwenden.
https://serverfault.com/questions/391887/running-multiple-services-on-one-port-443-is-possible
Es gibt halt Netze wo nur 80 & 443 erlaubt sind.
Die Firewall kann Anhand des eingehenden Interfaces, des Ports und des Protokolls entscheiden wie ein Paket behandelt wird.
Wenn auf Interface WAN, Port 443, Protokoll TCP der HA Proxy die Weiterleitung des Pakets erhält, hast du immer noch die Möglichkeit mit Interface WAN, Port 443, Protokoll UDP das OpenVPN Paket an den OpenVPN Server in der Opnsense zu senden.
Es gibt das Programm sslh zum splitten, allerdings nur via cli, ohne plugin
Danke für eure Antworten.
Wenn in einem eingeschränkten Netz nur 443/TCP freigegeben ist, reicht die Lösung via UDP leider auch nicht.
Gibt es denn mit dem HAProxy eine Möglichkeit zu "splitten"?
Nicht das ich wüsste, glaub der kann nur http oder TCP.
Quote from: PiMas on January 06, 2021, 01:30:36 PM
Wenn in einem eingeschränkten Netz nur 443/TCP freigegeben ist, reicht die Lösung via UDP leider auch nicht.
Wer betreibt denn sowas? Schulen?
Hotels zB. Schon mehr als einmal erlebt.
Rein theoretisch geht das.
Open Vpn kann ja TCP und dann auch port 443.
Mit Pfsense hat jemand sowas schon gebaut.
https://forum.netgate.com/topic/149715/haproxy-with-openvpn-over-tcp-443-on-pfsense
Ich habe auch tricks gesehen die das via Port 53 machen. Da ginge auch udp und das ist auch offen (meistens).
Mit 443 auf haproxy braucht es halt idealerweise eine subdomain für vpn und eine für den webserver.
Zum Beispiel vpn.domain.de und www.domain.de. Damit der haproxy auf die backend verteilen kann.
PS: Bei einem Kunden von uns macht der Softwaredienstleister das OpenVPN via 443 und TCP.
Ob da ein Proxy am anderen Ende ist weiß ich allerdings nicht.
Je nach Firewall hilft das aber eben auch nicht. Weil es gibt durchaus Produkte die eine Protoll Inspection machen. Heißt die schauen ob das typische Protokoll für einen Port auch genutzt wird. Weicht es ab verhindern die das. Ich kenne das aus den von uns bisher verwendten kommerziellen Produkten. Da gibst sowas wie erkenne Tunnel auf anderen Ports.
...wenn (nicht) 53 geht, warum nicht vielleicht 123? :-)
Quote from: lewald on January 06, 2021, 06:31:36 PM
Rein theoretisch geht das.
Open Vpn kann ja TCP und dann auch port 443.
Mit Pfsense hat jemand sowas schon gebaut.
https://forum.netgate.com/topic/149715/haproxy-with-openvpn-over-tcp-443-on-pfsense
Ich habe auch tricks gesehen die das via Port 53 machen. Da ginge auch udp und das ist auch offen (meistens).
Mit 443 auf haproxy braucht es halt idealerweise eine subdomain für vpn und eine für den webserver.
Zum Beispiel vpn.domain.de und www.domain.de. Damit der haproxy auf die backend verteilen kann.
PS: Bei einem Kunden von uns macht der Softwaredienstleister das OpenVPN via 443 und TCP.
Ob da ein Proxy am anderen Ende ist weiß ich allerdings nicht.
Je nach Firewall hilft das aber eben auch nicht. Weil es gibt durchaus Produkte die eine Protoll Inspection machen. Heißt die schauen ob das typische Protokoll für einen Port auch genutzt wird. Weicht es ab verhindern die das. Ich kenne das aus den von uns bisher verwendten kommerziellen Produkten. Da gibst sowas wie erkenne Tunnel auf anderen Ports.
Hallo lewald
Das Problem mit Protoll Inspection muss ich wohl in Kauf nehmen, für den Rest klingt das nach einer Lösung.
Ich habe für VPN und Web zwei verschiedene Subdomains.
Da ich zu wenig Erfahrung mit HAProxy habe, verstehe ich die Logik der Anleitung von netgate.com nicht. Reicht es "frontend TCP_HTTPS" & "backend pfsense_openvpn_tcp_1194_ipvANY" zum meiner bestehenden Konfig hinzuzufügen?
lg
Quote from: PiMas on January 06, 2021, 08:20:55 PM
Quote from: lewald on January 06, 2021, 06:31:36 PM
Rein theoretisch geht das.
Open Vpn kann ja TCP und dann auch port 443.
Mit Pfsense hat jemand sowas schon gebaut.
https://forum.netgate.com/topic/149715/haproxy-with-openvpn-over-tcp-443-on-pfsense
Ich habe auch tricks gesehen die das via Port 53 machen. Da ginge auch udp und das ist auch offen (meistens).
Mit 443 auf haproxy braucht es halt idealerweise eine subdomain für vpn und eine für den webserver.
Zum Beispiel vpn.domain.de und www.domain.de. Damit der haproxy auf die backend verteilen kann.
PS: Bei einem Kunden von uns macht der Softwaredienstleister das OpenVPN via 443 und TCP.
Ob da ein Proxy am anderen Ende ist weiß ich allerdings nicht.
Je nach Firewall hilft das aber eben auch nicht. Weil es gibt durchaus Produkte die eine Protoll Inspection machen. Heißt die schauen ob das typische Protokoll für einen Port auch genutzt wird. Weicht es ab verhindern die das. Ich kenne das aus den von uns bisher verwendten kommerziellen Produkten. Da gibst sowas wie erkenne Tunnel auf anderen Ports.
Hallo lewald
Das Problem mit Protoll Inspection muss ich wohl in Kauf nehmen, für den Rest klingt das nach einer Lösung.
Ich habe für VPN und Web zwei verschiedene Subdomains.
Da ich zu wenig Erfahrung mit HAProxy habe, verstehe ich die Logik der Anleitung von netgate.com nicht. Reicht es "frontend TCP_HTTPS" & "backend pfsense_openvpn_tcp_1194_ipvANY" zum meiner bestehenden Konfig hinzuzufügen?
lg
Hast du bereits einen HAProxy am laufen?
Hi Ifirewall1234
Ja, HAProxy läuft bereits.
Meine aktuelle Konfiguration entspricht dem Punkt "Reverse-Proxy" von hier: https://schulnetzkonzept.de/opnsense (https://schulnetzkonzept.de/opnsense)
Damit wird Nextcloud zugänglich gemacht.
Quote from: PiMas on January 07, 2021, 04:32:32 PM
Hi Ifirewall1234
Ja, HAProxy läuft bereits.
Meine aktuelle Konfiguration entspricht dem Punkt "Reverse-Proxy" von hier: https://schulnetzkonzept.de/opnsense (https://schulnetzkonzept.de/opnsense)
Damit wird Nextcloud zugänglich gemacht.
Würde es dann wie folgt versuchen
OpenVPN auf dem Standard Port laufen lassen. Im HAProxy eine Regel einrichten für "Host enthält vpn.domain.de" und als Backend dann auf deinen VPN Server.
Die Regel dann im öffentlichen Bereich des HAProxys hinterlegen.
Denke das sollte dann laufen
So, ich habe jetzt einiges rumprobiert. Das einzige was ich hingekriegt hab ist, dass ich keine Verbindung mehr zu nextcloud aufbauen kann :(
VPN-Verbindung-Aufbau bricht mit "Connecten reset" ab :(
Leider komme ich nicht weiter.
Dies hab ich gemacht:
Einrichtung OpenVPN
Protocol: UDP
Local port: 1194
Einrichtung HAProxy
Services / HAProxy / Settings / Real Servers → Add
Name: OpenVPN
FQDN or IP: 127.0.0.1
Port: 443
SSL: kein Haken
Verify SSL CA: kein Haken
Services / HAProxy / Settings / Virtual Services / Backend Pools → Add
Name: OpenVPN_backend
Mode: TCP (Layer4)
Servers: OpenVPN
Services / HAProxy / Settings / Rules & Checks / Conditions → Add
Name: OpenVPN
Condition type: Host ends with
Host Suffix: vpn.domain.de
Services / HAProxy / Settings / Rules & Checks / Rules → Add
Name: OpenVPN
Test type: if
Select conditions: OpenVPN
Execute function: Use specified Backend Pool
Use backend pool: OpenVPN_backend
Services / HAProxy / Settings / Virtual Services / Public Services → Add
OpenVPN
Description: Anfragen auf TCP 443
Listen Addresses:
10.0.0.10:80 (HAProxy_lan_wan)
Type: TCP
Default Backend Pool: none
Enable SSL offloading: kein Haken
Select Rules: OpenVPN
Du musst beim OpenVPN Server TCP auswählen
Auf welchen Interfaces hört der vpk Server und der HAproxy?
Quote from: lfirewall1243 on January 10, 2021, 08:59:58 PM
Du musst beim OpenVPN Server TCP auswählen
Das macht wohl Sinn :). VPN-Verbindung kommt aber leider immer noch nicht zustande
Quote from: lfirewall1243 on January 10, 2021, 08:59:58 PM
Auf welchen Interfaces hört der vpk Server und der HAproxy?
VirtualIP mit 10.0.0.10/32 ist an internem LAN definiert.
Mit Port Forward NAT Regel wird an diese weitergeleitet:
Interface: WAN
TCP/IP Version: IPv4
Protocol: TCP
Destination: any
Destination port range: from: HTTPS to: HTTPS
Redirect target IP: HAProxy_lan_wan
Redirect target Port: https
Die komplette HAProxy Konfig entspricht dem Aufbau von https://schulnetzkonzept.de/opnsense (https://schulnetzkonzept.de/opnsense) Punkt "Reverse-Proxy"
Ich möchte an der Stelle mal ganz böse auf die Doku der anderen Sense und auf die Doku von OpenVPN verweisen:
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/port-share.html
https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Die Option port-share ist genau dafür da, dass man den Traffic (HTTPS) erst via OpenVPN annehmen lässt, der dann prüft, ob das ein Tunnel oder HTTPS Traffic ist und diesen dann an den Service der port-share Konfiguration weiterreicht. Kein HAproxy, kein sonstiges Getunnel notwendig.
Problem nur: Wenn man auf dem Webservice dahinter Logs haben WILL, bekommt man leider keine Source IPs mehr für Zugriffe raus, da alle Zugriffe dann von der Firewall kommen. Das lässt sich dann auf diese Art leider nicht ändern.
Cheers
\jens
sslh ist hier deutlich überlegen, das Weiterleiten auf HTTPS durch OpenVPN dauert eine Ewigkeit und passiert für jeden einzelnen Abruf. sslh käme in diesem Anwendungsfall auf Port 443 und multiplext dann auf OpenVPN und HAproxy, die beide auf andere Ports weichen müssen.
Hatte ich eine Weile in Betrieb, unter FreeBSD, nicht auf der Sense, aber das fluppt zuverlässig.
Ich habs dann leider doch noch nicht geschafft, das Plugin zu basteln. Hab zum Hacktoberfest, wo ich Arbeitszeit dafür gehabt hätte, aber auch kein Feedback hier im Forum bekommen ...
Ah damn. Schade drum (wegen Plugin)
Aber ich kann dem schon folgen, dass sslh da natürlich (logisch) schneller/besser funktioniert als alles durch OpenVPN zu jagen, aber die Möglichkeit ist eben out of the box ohne Proxy oder dergleichen da, deshalb wollte ichs zumindest mal ansprechen. Und wie die Performance dann ist, hängt ja auch noch an anderen Faktoren wie Hardware etc. :)
Habs noch nicht selbst ausprobiert, kann ich erst wenn der Umbau auf neue HW fertig ist. Aber ich schreib sslh zusammen mit Guacamole auf die Liste ;)
Quote from: pmhausen on January 12, 2021, 05:58:14 PM
sslh ist hier deutlich überlegen, das Weiterleiten auf HTTPS durch OpenVPN dauert eine Ewigkeit und passiert für jeden einzelnen Abruf. sslh käme in diesem Anwendungsfall auf Port 443 und multiplext dann auf OpenVPN und HAproxy, die beide auf andere Ports weichen müssen.
Hatte ich eine Weile in Betrieb, unter FreeBSD, nicht auf der Sense, aber das fluppt zuverlässig.
Ich habs dann leider doch noch nicht geschafft, das Plugin zu basteln. Hab zum Hacktoberfest, wo ich Arbeitszeit dafür gehabt hätte, aber auch kein Feedback hier im Forum bekommen ...
Ich kann dir eins auf mein community repo legen. Sollte recht easy sein. Bin da nicht aktiv geworden weil du damals gemeint hast das selbst machen zu wollen.
Ich brauch's nicht mehr, aber der Threadersteller freut sich sicher.
Bin auf WireGuard umgestiegen - so viel besser. Wenn der Hotel-/Flughafen-Gateway fascho ist, dann halt LTE.
Wenn WireGuard jetzt noch dynamische Adressen für den Tunnel hätte und eine externe Authentifizierung ... deshalb haben unsere Firmen-Roadwarrior immer noch OpenVPN. Aber @work hab ich dafür keine IP-Adress-Knappheit ;)
Quote from: JeGr on January 12, 2021, 04:03:39 PM
Ich möchte an der Stelle mal ganz böse auf die Doku der anderen Sense und auf die Doku von OpenVPN verweisen:
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/port-share.html
https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Die Option port-share ist genau dafür da, dass man den Traffic (HTTPS) erst via OpenVPN annehmen lässt, der dann prüft, ob das ein Tunnel oder HTTPS Traffic ist und diesen dann an den Service der port-share Konfiguration weiterreicht. Kein HAproxy, kein sonstiges Getunnel notwendig.
Problem nur: Wenn man auf dem Webservice dahinter Logs haben WILL, bekommt man leider keine Source IPs mehr für Zugriffe raus, da alle Zugriffe dann von der Firewall kommen. Das lässt sich dann auf diese Art leider nicht ändern.
Cheers
\jens
Ich finde in Opensense keine derartige Option. Gibts die nur in PFsense?
Quote from: pmhausen on January 12, 2021, 09:29:05 PM
Ich brauch's nicht mehr, aber der Threadersteller freut sich sicher.
Bin auf WireGuard umgestiegen - so viel besser. Wenn der Hotel-/Flughafen-Gateway fascho ist, dann halt LTE.
Wenn WireGuard jetzt noch dynamische Adressen für den Tunnel hätte und eine externe Authentifizierung ... deshalb haben unsere Firmen-Roadwarrior immer noch OpenVPN. Aber @work hab ich dafür keine IP-Adress-Knappheit ;)
Wäre schon an einer Lösung interessiert.
Ich versuch mich nächstens mal in sslh einzulesen.
lg
> Ich finde in Opensense keine derartige Option. Gibts die nur in PFsense?
Mutmaßlich ja, denn das ist eine der Custom-Optionen die man manuell setzen muss. OPNsense möchte ja solche Custom-Freitext-Felder nach Möglichkeit überall weg haben, damit man sich nicht die Konfig (versehentlich) kaputt bauen kann.
@mimugmail weiß das IMHO genauer, aber ich glaube das war die Quintessenz was du schonmal meintest?
Anyway, das war der Grund, warum er ja u.a. sein Custom Community Repo aufgemacht hat, damit man Plugins/Addons bauen kann, wo es auch (auf eigene Gefahr) Freitext Felder gibt, die in OPNsense nicht mehr gewollt sind. Da OpenVPN aber Core Bestandteil ist, würde da nur die Möglichkeit bestehen, das als Feature Request in Github zu melden (man verbessere mich da gern!) und da zu schreiben, dass man das Port-Share Feature in der UI bitte hinzufügen möchte.
Nach der Rückmeldung von @pmhausen und kurzem Einlesen in "sslh" wäre ich aber wie @mimugmail und @pmhausen auch eher der Meinung, dass das wesentlich sauberer und besser mit sslh gelöst wäre (und performanter!) als das mit OpenVPNs eigenem Port-Share zu machen - außer dir ist egal, dass das den Webserver dahinter ggf. ziemlich ausbremsen könnte.
Cheers
\jens
Edit: Weil die Frage kam: Ich kenne ebenfalls aus der Praxis einige Netze, wo man vor Ort außer Common Ports wie HTTP/HTTPS kaum offene Ports hat. Und nein, DNS und NTP als "Schlupfloch" für UDP geht da meistens auch nicht, denn die machen das Gleiche, wie ich auch empfehlen würde ;) und weisen dem Gast etc. den Router selbst als DNS zu und erlauben keinen externen DNS oder NTP - was ja auch vollkommen legitim ist. :)
Quote from: JeGr on January 18, 2021, 10:32:07 AM
>
Edit: Weil die Frage kam: Ich kenne ebenfalls aus der Praxis einige Netze, wo man vor Ort außer Common Ports wie HTTP/HTTPS kaum offene Ports hat. Und nein, DNS und NTP als "Schlupfloch" für UDP geht da meistens auch nicht, denn die machen das Gleiche, wie ich auch empfehlen würde ;) und weisen dem Gast etc. den Router selbst als DNS zu und erlauben keinen externen DNS oder NTP - was ja auch vollkommen legitim ist. :)
...und zur Erfindung von DNS-over-https geführt hat. Game over...
Quote from: chemlud on January 18, 2021, 10:37:17 AM
...und zur Erfindung von DNS-over-https geführt hat. Game over...
Zwar kurz OT aber:
Nö. DoH ist in den allermeisten Implementationen so ausgerollt, dass es Trigger hat, die es deaktivieren. Zumindest das automatische DoH Geraffel von Mozilla und Co. die in Firmennetzen auch mehr kaputt als ganz machen.
DoH in so einem Fall kann man dann auch gern benutzen, bringt einem aber außer DNS nichts. Ob ich nun vor Ort den Router/Firewall als DNS nutze oder Google/Cloudflare meine Daten verkaufe oder mir selbst irgendwo DoH hochziehe - egal. Nichts desto trotz funktioniert es damit nicht VPN zu tunneln. Das war der eigentliche Punkt. Andere UDP Dienste als "Carrier" zu nutzen klappt in solchen Umgebungen meistens eben nicht.
Genau daher ist der Fall "OpenVPN auf tcp/443" auch nicht unüblich, sondern fast schon 2nd default bei vielen Setups. Chef ist im Urlaub und im Hotel XY und hat wieder nur "kastriertes" Internet, dann muss die Einwahl eben gehen :)
QuoteChef ist im Urlaub und im Hotel XY und hat wieder nur "kastriertes" Internet, dann muss die Einwahl eben gehen :)
This!
Das beste war Flughafen Dubai, da ging nicht mal HTTPS. Nur Klartext und Zwangsproxy, damit ja nichts unislamisches ins Land kommt. Da konnte ich $CHEF dann aber auch nicht mehr helfen.