OpenVPN Client Mode Zugriff Lokaler Webserver
-
Hallo,
ich habe hinter meiner Pfsense Firewall einen Webserver und Reverse Proxy laufen.
Für den Zugriff von außerhalb habe ich in Pfsense eine DynDNS Adresse eingerichtet sowie zwei Portweiterleitungen.Nun habe ich nach dieser Anleitung einen OpenVPN Client für einzelne Rechner in meinem Netz eingerichtet und folgende Regeln erstellt:
Leider ist es mir nun nicht möglich mit dem Client welcher den VPN benutzt über die DynDNS Adresse auf den lokalen Webserver zuzugreifen.
Mit den anderen Clients ohne VPN ist das ohne Probleme möglich.
Ich hoffe es kann mir jemand bei meinem Problem helfen. Sollten noch weiterer Infos benötigt werden bin ich gerne bereit diese zu liefern. -
Hallo,
das Problem ist hier, dass du mit den beiden LAN Regeln nur noch Verbindungen über eines der beiden Gateways erlaubst, entweder über WAN oder über VPN. Der Zugriff auf den internen Webserver soll aber ohne GW direkt erfolgen.
Normalerweise ist hier in der ersten Regel das Gateway auf "default" zu setzen.
Voraussetzung, dass das funktioniert, ist aber, dass der VPN Server nicht die Standardroute pusht. Sollte er das tun, gehe in die VPN Client Settings und setze einen Haken bei "Don't pull Routes".Grüße
Nachtrag:
Ja, wenn du das so haben möchtest, dass du gewisse Verbindungen über das WAN Gateway zwingst, kannst du natürlich für den Webserver auch eine eigene Regel setzen, in der das GW auf default gesetzt ist. -
Hallo,
vielen Dank für die Antwort.
Ich habe gerade versucht nach deiner Anleitung die Regeln zu ändern.
Leider erhalte ich beim Aufruf der Domain immer noch die Fehlermeldung "ERR_CONNECTION_TIMED_OUT" im Browser.
Der Zugriff über die IP-Adresse des Webservers funktioniert allerdings ohne Probleme, nur dann muss ich den weitergeleiteten Port mit angeben. Daher möchte ich den Zugriff über die DynDNS Domain realisieren.
Nur wenn ich über die DynDNS Domain zugreife erhalte ich die Fehlermeldung.Grüße
-
Wieso überhaupt den Traffic auf einen internen Server auf WAN schieben und kein split DNS einrichten?
-Rico
-
Hallo Rico,
kannst du mir erklären wie so eine Konfiguration aussehen muss, hab ich leider noch nicht gemacht.Grüße
-
Ich gehe mal davon aus du nutzt den DNS Resolver (pfSense default).
Dein DynDNS Host heißt meinserver.dyndns.org
pfSense WebGUI > Services > DNS Resolver > Host Overrides > Add
Host: meinserver
Domain: dyndns.org
IP Address: Interne IP deines Webserver
Save
Apply Changes-Rico
-
Hallo,
vielen Dank für die Anleitung.
Die Domain funktioniert nun bei allen Clients.
Leider funktioniert die Weiterleitung der Ports 80->180 u. 443->1443 bei den Clients nun nicht mehr.
Ich hoffe es kann mir jemand noch eine Tip zur Erstellung der passenden Regel geben.Grüße
-
@king79 said in OpenVPN Client Mode Zugriff Lokaler Webserver:
Leider funktioniert die Weiterleitung der Ports 80->180 u. 443->1443 bei den Clients nun nicht mehr.
Du meinst von außen bei Zugriff auf deinen Hostnamen?
Also mit dem DNS Host Override oder mit der genannten LAN Regel kann das wohl nichts zu tun haben. Deshalb bin ich da bei den vorliegenden Angaben überfragt.
Eventuell war der DNS Cache des Clients nach einem WAN-IP-Update noch nicht aktualisiert?
Versuche es ggf. mit der WAN-IP anstatt des Namens.Zum Untersuchen derartiger Probleme kann ich Diagnostic > Packet Capture empfehlen. Hiermit kannst du dir die Pakete am WAN und am internen Interface ansehen, um zu verstehen, was in der pfSense vorgeht.
Grüße
-
Hallo,
da habe ich mich falsch ausgedrückt. Der Zugriff von außen funktioniert super, nur intern klappt die Weiterleitung der Ports auf den Webserver nicht wie gewünscht. Es fehlt wahrscheinlich eine Regel.Grüße
-
Hallo,
du hast uns nicht allzu viel über dein Netzwerk wissen lassen, daher können wir hier nur mit Annahmen arbeiten.
Ich vermute, es fehlt noch eine NAT Regel. Nachdem die Ports der Pakete zum Server transferiert (80->180 u. 443->1443) werden müssen, ist auch hier eine NAT-Regel am LAN Interface nötig. Vorraussetzung ist hier, dass der Server auf einem anderen als dem LAN Interface angeschlossen ist.Im Zusammenhang mit dem Port-Translate wäre NAT-Reflection die einfachere Lösung gewesen als Split-DNS. Dazu genügt es, die Option in der bestehenden NAT-Regel (am WAN) auszuwählen.
Grüße
-
Wieso benutzt du intern denn überhaupt verfälschte Ports und nicht die standard zum jeweiligen Dienst?
Das würde dir einiges Bastelei ersparen.-Rico
-
Hallo,
das liegt daran das der Webserver / Reverse Proxy ein Docker Container ist und die Standardports von der Weboberfläche des Hostservers verwendet werden. Wenn die Bastelei allerdings zu groß wird mit den Weiterleitungen, könnte ich noch die Standardports des Hostservers ändern und dem Container diese zuweisen.Grüße
-
@viragomann said in OpenVPN Client Mode Zugriff Lokaler Webserver:
Hallo,
du hast uns nicht allzu viel über dein Netzwerk wissen lassen, daher können wir hier nur mit Annahmen arbeiten.
Ich vermute, es fehlt noch eine NAT Regel. Nachdem die Ports der Pakete zum Server transferiert (80->180 u. 443->1443) werden müssen, ist auch hier eine NAT-Regel am LAN Interface nötig. Vorraussetzung ist hier, dass der Server auf einem anderen als dem LAN Interface angeschlossen ist.Im Zusammenhang mit dem Port-Translate wäre NAT-Reflection die einfachere Lösung gewesen als Split-DNS. Dazu genügt es, die Option in der bestehenden NAT-Regel (am WAN) auszuwählen.
Grüße
Hallo,
der Webserver ist leider am LAN Interface angeschlossen.
Ich habe auch schon versucht eine zusätzlich Port Forward Regel am Lan Interface zu erstellen, welche nicht den gewünschten Erfolg brachte.
Nat-Reflection ist an den beiden Port Forward Regeln am WAN aktiviert. Nur damit hatte ich die Probleme mit den Clients welche über den VPN nach draußen gehen.Grüße
-
Port Forwarding funktioniert am selben Interface nicht vernünftig, weil Response-Pakete von einer anderen Quell-IP kommen als die Ziel-IP der ursprünglichen Client-Anfrage und der Client die Antwort nicht akzeptiert.
@king79 said in OpenVPN Client Mode Zugriff Lokaler Webserver:
Nur damit hatte ich die Probleme mit den Clients welche über den VPN nach draußen gehen.
Probleme mit dem Zugriff auf den Webserver?
Clients, denen du auf dem Weg zum Webserver kein Gateway aufzwingst, sollten keine Probleme damit haben.NAT-Reflection kann aber nur funktionieren, wenn du den Host-Override wieder entfernst.
Grüße
-
@viragomann said in OpenVPN Client Mode Zugriff Lokaler Webserver:
Probleme mit dem Zugriff auf den Webserver?
Clients, denen du auf dem Weg zum Webserver kein Gateway aufzwingst, sollten keine Probleme damit haben.Ja das stimmt, Clients welche den VPN Client nicht benutzen funktionieren ohne Probleme. Aber was mache ich mit den Clients welche den VPN benutzen sollen, da muss ich ja ein Gateway aufzwingen und dann funktioniert der Zugriff auf den Webserver nicht mehr.
Grüße
-
@king79 said in OpenVPN Client Mode Zugriff Lokaler Webserver:
Wenn die Bastelei allerdings zu groß wird mit den Weiterleitungen, könnte ich noch die Standardports des Hostservers ändern und dem Container diese zuweisen.
Ja das wäre wohl die sauberste Lösung, mit allem anderen wirst du auf Dauer wahrscheinlich nicht glücklich.
-Rico
-
@king79 said in OpenVPN Client Mode Zugriff Lokaler Webserver:
Aber was mache ich mit den Clients welche den VPN benutzen sollen, da muss ich ja ein Gateway aufzwingen und dann funktioniert der Zugriff auf den Webserver nicht mehr.
Nein, die Clients müssen ohne Gateway auf den Webserver kommen.
Dann musst du für diese Verbindung eine eigene Regel definieren, die kein GW erzwingt.
Also Quelle: LAN net, Ziel: Webserver
und diese Regel oberhalb der anderen positionieren, damit sie auch angewandt wird.Grüße
-
@viragomann said in OpenVPN Client Mode Zugriff Lokaler Webserver:
Nein, die Clients müssen ohne Gateway auf den Webserver kommen.
Dann musst du für diese Verbindung eine eigene Regel definieren, die kein GW erzwingt.
Also Quelle: LAN net, Ziel: Webserver
und diese Regel oberhalb der anderen positionieren, damit sie auch angewandt wird.Grüße
Genau diese Regel hat in meiner Konfiguration gefehlt.
Vielen Dank nochmal an alle Beteiligten für die Lösung meines Problems.