OpnVPN über TCP 443

[PiMas]

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:

Code Select Expand


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


[lfirewall1243]

Du musst beim OpenVPN Server TCP auswählen

Auf welchen Interfaces hört der vpk Server und der HAproxy?

[PiMas]

Du musst beim OpenVPN Server TCP auswählen

Das macht wohl Sinn :).  VPN-Verbindung kommt aber leider immer noch nicht zustande

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 Punkt "Reverse-Proxy"

[JeGr]

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

[Patrick M. Hausen]

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 ...

[JeGr]

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 ;)

[mimugmail]

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.

[Patrick M. Hausen]

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  ;)

[PiMas]

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?

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

[JeGr]

> 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. :)

[chemlud]

>
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...

[JeGr]

...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 :)

[Patrick M. Hausen]

Chef 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.