Externe statische IP per VPN auf DMZ routen
-
Die Sache scheint mir nun auch nicht mehr klar. Jedenfalls nicht, solange nicht genau bekannt ist, wo der Router mit 87.X.X.X sitzt. An deinem WAN?
Das Packet Capture würde ich ja so interpretieren: Die Pakete kommen über die VPN rein und wird auch richtig weiter gerotutet, dein DMZ Host antwortet, die Antwort wird auf VPN Interface geschickt, da kann sie aber nicht abgesetzt werden, weil der Zielhost, also der der ursprüngliche den Request initiiert hat, nicht erreichbar ist.
Was mir auch nicht klar ist, ist das PTYOPENVPN_VPNV4 Gateway, über das du den Traffic vom internen Host routest. Hat das eine IP und passt die zur Interface-IP und zum Subnetz?
-
Die Sache scheint mir nun auch nicht mehr klar. Jedenfalls nicht, solange nicht genau bekannt ist, wo der Router mit 87.X.X.X sitzt. An deinem WAN?
Wir nutzen einen normalen Telekom ADSL-Anschluss mit einem DSL-Modem am WAN-Port der pfSense.
Die IP 87.X.X.X scheint dabei ebenfalls der Telekom zu gehören und ist der 1. oder 2. Next-Hop wenn man einen Traceroute auf den externen Host startet (91.X.X.X).Die IP 87.X.X.X ist die Gateway-Adresse vom WAN-Interface.Das Packet Capture würde ich ja so interpretieren: Die Pakete kommen über die VPN rein und wird auch richtig weiter gerotutet, dein DMZ Host antwortet, die Antwort wird auf VPN Interface geschickt, da kann sie aber nicht abgesetzt werden, weil der Zielhost, also der der ursprüngliche den Request initiiert hat, nicht erreichbar ist.
Was mir auch nicht klar ist, ist das PTYOPENVPN_VPNV4 Gateway, über das du den Traffic vom internen Host routest. Hat das eine IP und passt die zur Interface-IP und zum Subnetz?
Das PTYOPENVPN_VPNV4 Gateway wurde automatisch eingerichtet, nachdem ich das PTYOPENVPN Interface konfiguriert hatte. Nach dem Verbindungsaufbau des openVPN-Clients erhält das Interface die IPv4 Adresse 46.X.X.X sowie eine zusätzliche IPv6-Adresse (ich kann bei Portunity aber IPv6 auch deaktivieren). Die IP 46.X.X.X ist vom LAN/DMZ aus nach Verbindungsaufbau problemlos anpingbar, von aussen hingegen nicht. In "System -> Routing -> Gateways" habe ich die beiden automatisch angelegten Gateways der VPN-Verbindung (PTYOPENVPN_VPNV4 & PTYOPENVPN_VPNV6), jeweils mit dem Interface PTYOPENVPN und im Gateway-Feld "dynamic" hinterlegt.
Das Verhalten auf dem DMZ-Host (192.168.1.5) kann ich mir leider auch nicht genau erklären. Sicher ist nur, dass die Pakete durchkommen und der Host auch antwortet, allerdings geht diese Antwort wohl nicht bei dem Interface PTYOPENVPN durch (bei der Packet Capture sehe ich dort nur die eingehenden Sachen). Meine Vermutung ist daher, das irgendwo zwischen dem Weg "DMZ-Host -> DMZ-Interface -> OpenVPN-Interface -> OpenVPN-Gateway" etwas klemmt oder verworfen wird. Die eingehende Kommunikation funktioniert aber - ich kann z.B. vom DMZ-Host aus problemlos eine ISO-Datei aus dem Internet ziehen und habe nach aussen hin dabei die OpenVPN-IP in Benutzung. Nur der umgekehrte Weg klappt nicht, daher habe ich auch bereits das NAT in Verdacht gehabt, aber keine Idee wo man dort ansetzen könnte…
Edit:
Wo du grade das Subnet erwähnt hattest - wenn ich das 1:1 NAT erstelle und vom VPN-Interface nur eine statische IP zugewiesen bekomme, muss das DMZ-Interface dann dieselbe Subnet-Maske (/32) aufweisen? Muss evtl. etwas spezielles auf dem DMZ-Host konfiguriert sein (Gateway, Subnet, ...) oder behält dieser die internen Standard-EInstellungen (192.168.1.0/24 + 192.168.1.5 als IP + 192.168.1.1 als Gateway zur pfsense) ?Anbei noch einige Screenshots - dort sehe ich allerdings keinen Punkt, wo ich für das VPN-Interface eine Subnet-Mask vorgeben könnte:
Edit2:
Die IP 87.X.X.X ist das Gateway des WAN-Interfaces (also von der Telekom), dieses reagiert nicht auf ICMP-Anfragen. Ich habe allerdings keine Ahnung warum dieses im tcpdump auf dem DMZ-Host auftaucht? -
Das PTYOPENVPN_VPNV4 Gateway wurde automatisch eingerichtet, nachdem ich das PTYOPENVPN Interface konfiguriert hatte. Nach dem Verbindungsaufbau des openVPN-Clients erhält das Interface die IPv4 Adresse 46.X.X.X sowie eine zusätzliche IPv6-Adresse (ich kann bei Portunity aber IPv6 auch deaktivieren). Die IP 46.X.X.X ist vom LAN/DMZ aus nach Verbindungsaufbau problemlos anpingbar, von aussen hingegen nicht. In "System -> Routing -> Gateways" habe ich die beiden automatisch angelegten Gateways der VPN-Verbindung (PTYOPENVPN_VPNV4 & PTYOPENVPN_VPNV6), jeweils mit dem Interface PTYOPENVPN und im Gateway-Feld "dynamic" hinterlegt.
Ja, klar, die Gateway IP bekommst du vom VPN Server automatisch zugewiesen. Da sollte eigentlich alles passen, aber ich hätte mich gerne vergewissert.
In Status > Interfaces sollten bei verbundener VPN die gefragten Details aufgelistet werden.Edit:
Wo du grade das Subnet erwähnt hattest - wenn ich das 1:1 NAT erstelle und vom VPN-Interface nur eine statische IP zugewiesen bekomme, muss das DMZ-Interface dann dieselbe Subnet-Maske (/32) aufweisen? Muss evtl. etwas spezielles auf dem DMZ-Host konfiguriert sein (Gateway, Subnet, …) oder behält dieser die internen Standard-EInstellungen (192.168.1.0/24 + 192.168.1.5 als IP + 192.168.1.1 als Gateway zur pfsense) ?Nein, diese Dinge haben nichts miteinander zu tun. Das Angeben einer Subnetmaske im 1:1 NAT bewirkt, dass man einen ganzen IP-Bereich, ein ganzes Subnet mit einer einzigen Regel natten kann. Man kann also den ersten internen Host + Subnetmaske angeben und dieser wird dann mit der angegebenen externen IP verbunden, die nächste interne IP mit der nächsten externen, usw. bis der ganze Netzwerk-Bereich durch ist.
Edit2:
Die IP 87.X.X.X ist das Gateway des WAN-Interfaces (also von der Telekom), dieses reagiert nicht auf ICMP-Anfragen. Ich habe allerdings keine Ahnung warum dieses im tcpdump auf dem DMZ-Host auftaucht?Okay, dann kommt die Ping-Anfrage also beim VPN-Interface rein, der Response verlässt die pfSense aber offenbar am Wan-Interface Richtung Default-Gateway. Damit hast du einen Fall von "asymmetric routing".
Normalerweise schickt pfSense immer Antworten da raus, wo die Anfrage rein kam. Meines Wissens lässt sich diese Funktionsweise gar nicht speziell irgendwo einstellen, man kann sie bestenfalls abstellen, was du wohl nicht getan hast.
Aber überprüfe zur Sicherheit mal in System > Advanced > Firewall/NAT die beiden Einstellungen-
Static route filtering
-
Disable reply-to
Bei beiden sollte kein Haken sitzen.
Übrigens, wenn du sichergehen willst, dass der DMZ Host nicht über WAN rausgeht, falls die VPN mal down ist, musst du in System > Advanced > Miscellaneous den Haken bei "Skip rules when gateway is down" setzen.
Ansonsten hab ich zu deinem Problem auch keine Ideen mehr. Vielleicht im Forum nach dem Schlagwort "asymmetric routing" suchen oder im englischen Bereit damit anfagen. Das Problem kommt öfter bei Multi-WAN vor.
-
-
Ja, klar, die Gateway IP bekommst du vom VPN Server automatisch zugewiesen. Da sollte eigentlich alles passen, aber ich hätte mich gerne vergewissert. In Status > Interfaces sollten bei verbundener VPN die gefragten Details aufgelistet werden.
Bei dem Interface PTYOPENVPN sind sowohl bei IPv4 address als auch beim Gateway die Adresse 46.X.X.X eingetragen, also identisch. Subnet mask ist 255.255.252.0.
Nein, diese Dinge haben nichts miteinander zu tun. Das Angeben einer Subnetmaske im 1:1 NAT bewirkt, dass man einen ganzen IP-Bereich, ein ganzes Subnet mit einer einzigen Regel natten kann. Man kann also den ersten internen Host + Subnetmaske angeben und dieser wird dann mit der angegebenen externen IP verbunden, die nächste interne IP mit der nächsten externen, usw. bis der ganze Netzwerk-Bereich durch ist.
Ok, das wäre meine nächste Frage zum Einsatz mehrerer statischer IP-Adressen gewesen. Ich kann also per 1:1 NAT per Subnet Mask einen ganzen Netzbereich, oder eben immer gezielt einzelne Hosts konfigurieren.
Normalerweise schickt pfSense immer Antworten da raus, wo die Anfrage rein kam. Meines Wissens lässt sich diese Funktionsweise gar nicht speziell irgendwo einstellen, man kann sie bestenfalls abstellen, was du wohl nicht getan hast.
Aber überprüfe zur Sicherheit mal in System > Advanced > Firewall/NAT die beiden Einstellungen-
Static route filtering
-
Disable reply-to
Bei beiden sollte kein Haken sitzen.
Beide sind bei mir in der Konfiguration deaktiviert.
Übrigens, wenn du sichergehen willst, dass der DMZ Host nicht über WAN rausgeht, falls die VPN mal down ist, musst du in System > Advanced > Miscellaneous den Haken bei "Skip rules when gateway is down" setzen.
Danke für den Tipp, das habe ich hier im Forum schonmal an anderer Stelle gelesen. Ich habe eben auch nochmal ein Packet capture gestartet, diesmal auf dem WAN-Interface. Wenn ich beispielsweise versuche von einem externen Host über die VPN-IP auf Port 80 des internen DMZ-Host zuzugreifen, dann bekomme ich dort folgende Pakete angezeigt:
20:46:43.055350 IP 46.X.X.X.80 > 91.X.X.X.52874: tcp 0 20:46:43.305172 IP 46.X.X.X.80 > 91.X.X.X.52925: tcp 0 20:46:44.295346 IP 46.X.X.X.80 > 91.X.X.X.52925: tcp 0
(46.X.X.X = VPN-IP, 91.X.X.X = externer Host)
Mich irritiert an der Sache, dass die VPN-IP eine Rückmeldung an den externen Host über das WAN-Interface geben möchte - müsste dies nicht über das VPN-Interface erfolgen? Aus diesem Grund sehe ich vermutlich auch die Antwort-Pakete am VPN-Interface nicht, wenn ich ein Packet capture dort starte.
-
-
Erstmal vielen herzlichen Dank für die Hilfestellungen, insbesondere an viragomann. Der Tipp mit dem englischsprachigen Forum war gut, denn ich bin dort auf folgenden Topic gestossen:
https://forum.pfsense.org/index.php?topic=96929.0
Lösung in der Sache:
Just wanted to post and update that my issue has been resolved. With the help of Derelict (huge thanks to you), we were able to determine that my issue was an Any/Any rule on the OpenVPN tab (which has since been removed and replaced with a more strict rule on an interface I created for my home VPN server network) as well as the fact that I had the AIRVPN_WAN gateway selected on my NAT port forward rule instead of leaving it as default.
Wie es der Zufall will, habe ich ebenfalls einen openVPN-Server auf der pfsense konfiguriert. Dementsprechend existiert natürlich auch ein "OpenVPN" Interface mit folgender Rule (angelegt vom OpenVPN Wizard):
Kaum hatte ich diese deaktiviert, schon läuft das Routing über den OpenVPN-Client Tunnel wie gewünscht :) Die Lösung scheint dann wohl zu sein, eine restriktivere Firewall-Rule für das OpenVPN-Interface festzulegen - jemand einen Tipp hierfür?
-
Wow. Endlich kommen wir der Lösung einen Schritt näher.
In der Lösung steht, dass er die restriktivere Regel für ein neu erstelltes Interface für den VPN-Server angelegt hat.
Die Regel am OpenVPN-Tab bedient offenbar sämtliche OVPN-Verbindungen und hat Vorrang gegenüber speziellen VPN-Interfaces.
Demnach musst du ein eigenes Interface für den VPN-Server hinzufügen und die deaktivierte Regel auf dieses Interface legen. Ich denke, dann bedarf sie auch keiner weiteren Einschränkung. Dann sollte sie sich nicht mehr auf den VPN-Client auswirken. -
Demnach musst du ein eigenes Interface für den VPN-Server hinzufügen und die deaktivierte Regel auf dieses Interface legen. Ich denke, dann bedarf sie auch keiner weiteren Einschränkung. Dann sollte sie sich nicht mehr auf den VPN-Client auswirken.
Und dort stehe ich vor einem neuen Problem: Der Menüpunkt "PTYOPENVPN" in den Firewall-Rules tauchte dort erst auf, nachdem ich das Interface erstellt hatte - beim Server hingegen wurde es automatisch in irgendeiner Form mit erstellt. Oder gibt es da Unterschiede, ob man das ganze manuell anlegt bzw. per Wizard macht?
Der Connect zum OpenVPN-Server von extern scheint noch problemlos zu funktionieren, nur werden jetzt natürlich keine Daten mehr zwischen den Netzen durchgereicht (da die FireWall-Rule deaktiviert wurde). Muss ich nun per Interface-Assign genauso wie beim Client vorgehen, dass ich ein neues Interface für den OpenVPN-Server erstelle auf dem Device ovpns1() und bei diesem dann die Rule neu erstelle? Wie bekomme ich denn die bereits exitierende "OpenVPN" Menülasche in der Firewall weg, oder wäre es besser den OpenVPN-Server manuell von Grund auf neu (manuell) zu konfigurieren?
-
Muss ich nun per Interface-Assign genauso wie beim Client vorgehen, dass ich ein neues Interface für den OpenVPN-Server erstelle auf dem Device ovpns1() und bei diesem dann die Rule neu erstelle?
Ich habe das selbst nirgens so eingerichtet, aber so würde ich es machen.
Wie bekomme ich denn die bereits exitierende "OpenVPN" Menülasche in der Firewall weg
Das wird wohl nicht wegzubekommen sein. Stört doch nicht, oder?
-
Ich habe nun per "Interface -> Assign" ein neues Interface "SRVOPENVPN" auf dem Network Port ovpns1() erzeugt. Bei "Firewall -> Rules -> OpenVPN" wurde die vorhandene Rule deaktiviert, bei "FireWall -> Rules -> SRVOPENVPN" eine neue Rule angelegt:
Anschliessend unter "Status -> OpenVPN" einmal den OpenVPN Server neu starten lassen. Jetzt funktioniert der Connect zum OpenVPN-Server einwandfrei und ich komme wieder wie gewohnt ins interne LAN-Netz. Unter "Firewall -> Rules -> PTYOPENVPN" kann man nun gezielt einstellen, welche Ports für welchen Ziel-Host geöffnet werden sollen, unabhängig vom bereits vorhandenen 1:1 NAT.
Eine Zusatzfrage hätte ich noch:
Angenommen, ich würde nur die eine verfügbare VPN-IP nutzen wollen und die Ports gezielt per "Firewall -> NAT -> Port Forward" umleiten, also kein 1:1 NAT - die zugehörigen Firewall-Rules werden dabei ohnehin automatisch mit erstellt, aber sind dann noch zusätzliche Einstellungen beim Outbound notwendig? -
Ja, das hatte ich, glaub ich, zuvor schon erwähnt.
Damit du mit deiner VPN-IP aus dem Netz rausgehst, ist Outbound NAT nötig, ansonsten hätten die Pakete die interne IP des Rechners als Quell-IP und würden im Internet verworfen werden.
1:1 NAT macht eben beides, inbound und outbound NAT. Wenn du die Regel verwirftst, musst du dafür eine gesonderte Outbound NAT Regel anlegen, die so aussehen könnte.Ich nehme dafür an, dass du verschiedene Ports an mehrere Rechner weiterleiten möchtest, ansonsten könntest du es ja auch beim 1:1 NAT belassen.
Lege erst einen IP-Alias für alle Rechner an, die über die VPN-IP rausgehen sollen.
Am Outbound NAT Tab schalte auf "Hybrid Outbound NAT rule generation" und klick auf Save. Dann füge unter Mappings eine Regel hinzu: Interface = PTYOPENVPN, Source-Type = Network, -Address = <der oben="" angelegte="" alias="">, der Rest kann auf den Standardwerten bleiben.Was hier sympathischer ist, bleibt deine Entscheidung.</der>