Externe statische IP per VPN auf DMZ routen

michaeljk

Hallo,

ich teste derzeit von Portunity den VPN-Tunnel mit einer einzelnen IPv4-Adresse und bin zur Einrichtung in der pfSense wie folgt vorgegangen:

http://www.portunity.de/access/wiki/OpenVPN-Tunnel_(IPv4)mit_pfSense_2.1(Anleitung)#Advanced_configuration

Es funktioniert auch alles, ich habe nun also ein zusätzliches Interface "PTYOpenVPN" zur Verfügung und die Verbindung per Tunnel läuft. Nun ist diese Anleitung aber eher für den Fall erstellt, dass man ein einzelnes Netzwerk komplett mit dem OpenVPN-Gateway verknüpfen möchte, also alle ausgehenden Verbindungen dann über die statische IP laufen.

Meine pfSense-Konfiguration beinhaltet aber ein zusätzliches DMZ-Interface (zusätzlich zu LAN und WAN), welches in der Firewall wie das LAN-Interface konfiguriert wurde (mit dem Unterschied das DMZ keinen Zugriff auf LAN hat, nur auf WAN. LAN darf wiederum auf WAN und DMZ zugreifen). Ich würde nun gerne die statische IPv4-Adresse welche ich durch den OpenVPN-Tunnel auf dem neuen Interface erhalte, gezielt an einen Rechner in der DMZ durchrouten (ohne NAT). Die Ports für die einzelnen Dienste sollen dann in den Firewall gezielt geöffnet werden können.

Ist dies in der Form möglich? Falls ja, wo sind die Einstellungen zu tätigen? Ich vermute mal, unter "Firewall -> NAT" werden einige Anpassungen notwendig sein. Muss im Outbound-Bereich auf "Manual Outbound NAT rule generation" umgeschaltet werden? Wie gehe ich vor, wenn ich über den VPN-Tunnel mehrere statische IPv4-Adressen erhalte welche ich gezielt an mehrere Rechner ohne NAT routen möchte?

Grüsse,

Michael

Marvho

Hallo,

das Outbound NAT ist nur dafür zuständig die einzelne IP die du vom OpenVPN Tunnel bekommst auf deine LAN/DMZ Clients zu NAT'ten. Sprich damit deine Clients über den Tunnel auch nach draußen auf das Internet zugreifen können, falls gewünscht, wie beim normalen WAN.

Ich habe noch kein 1:1 NAT eingestellt, aber ich denke das sollte deine Anlaufstelle sein, um die Öffentliche OpenVPN IP zum Rechner in der DMZ zu verknüpfen.

Gruß

viragomann

@michaeljk:

Ich würde nun gerne die statische IPv4-Adresse welche ich durch den OpenVPN-Tunnel auf dem neuen Interface erhalte, gezielt an einen Rechner in der DMZ durchrouten (ohne NAT). Die Ports für die einzelnen Dienste sollen dann in den Firewall gezielt geöffnet werden können.

Ist dies in der Form möglich? Falls ja, wo sind die Einstellungen zu tätigen? Ich vermute mal, unter "Firewall -> NAT" werden einige Anpassungen notwendig sein. Muss im Outbound-Bereich auf "Manual Outbound NAT rule generation" umgeschaltet werden? Wie gehe ich vor, wenn ich über den VPN-Tunnel mehrere statische IPv4-Adressen erhalte welche ich gezielt an mehrere Rechner ohne NAT routen möchte?

Was spricht hier gegen NAT? Und wenn du Outbound NAT einsetzt, ist das ja auch NAT.

Wie von Marvho empfohlen, ist 1:1 NAT prädistiniert für dein Vorhaben. Damit verbindest du deine Portunity IP direkt mit deinem Host in beide Richtungen.

Grüße

michaeljk

@viragomann:

Was spricht hier gegen NAT? Und wenn du Outbound NAT einsetzt, ist das ja auch NAT.

Bei NAT kämen wieder die Portweiterleitungen hinzu, welche gezielt eingestellt werden müssten. Das normale LAN-Interface soll natürlich zukünftig weiterhin per NAT laufen, aber bei der DMZ wäre mir eine 1:1 Durchreichung einer IPv4-Adresse auf ein bestimmtes Zielsystem lieber.

Wie von Marvho empfohlen, ist 1:1 NAT prädistiniert für dein Vorhaben. Damit verbindest du deine Portunity IP direkt mit deinem Host in beide Richtungen.

Gut, dann habe ich dort zumindest schonmal einen Ansatzpunkt. Der Tunnel per OpenVPN-Client ist aufgebaut und funktioniert, das zusätzliche Interface (auf ovpnc2) wurde angelegt und erscheint auch in der Auflistung auf der Startseite. An diesem Punkt komme ich aber derzeit gedanklich nicht weiter: Wird bei der 1:1 NAT-Konfiguration dann das VPN-Interface ausgewählt? Welche Werte gelten bei "External subnet IP", "Internal IP" und "Destination"? Müssen zuvor virtuelle IPs auf dem DMZ-Interface erstellt werden um das Routing zu gewährleisten?

–-
EDIT 17:34
Mir würde es evtl. bereits weiterhelfen wenn ich zunächst die statische IP aus dem OpenVPN-Tunnel per NAT + Portforwarding auf den entsprechenden Rechner in der DMZ bringen könnte. Allerdings scheitert es da bereits an der Konfiguration - zunächst habe ich versucht, in dem neuen OpenVPN-Interface bei den NAT-/Firewall-Rules ein simples Forwarding von Port 80 vorzunehmen. Dies scheint aber nicht zu funktionieren, zumindest bekomme ich von externen Rechnern keine Rückmeldung (meine Vermutung ist, dass hier die Route vom DMZ zurück zu dem Tunnel fehlt, ich aber derzeit nicht weiss wo diese zu konfigurieren wäre). Von der pfSense selbst und den vorhandenen DMZ/LAN Interfaces aus läßt sich die "Virtual Addr" der OpenVPN-Client-Verbindung problemlos anpingen, von extern allerdings nicht.

Grüsse,

Michael

viragomann

Bei Interface musst du das erstellte VPN-Interface wählen.
External subnet IP: deine VPN-IP
Internal IP: der Zielhost
Destination: any (das sind die externen Ziele, für die diese Regel gilt, vermutlich für alle)

Zusätzlich musst du noch am VPN Interface eine Firewall-Regel anlegen, die die gewünschten Zugriffe auf den Zielhost erlaubt.

michaeljk

Diese Einstellungen habe ich eben einmal getestet - der Ziel-Host (192.168.1.5) kann die VPN-IP anpingen, jeder andere Rechner im LAN/DMZ auch. Allerdings kommen die externen Aufrufe auf die VPN-IP nicht durch bzw. es kommt von nirgendwo eine Rückgabe. Muss hier evtl. an einer Stelle noch konfiguriert werden, dass die Daten des Hosts 192.168.1.5 wieder durch das VPN-Interface durchgeleitet werden?

michaeljk

Nun bin ich einen Schritt weiter. Bei dem DMZ-Interface war noch eine Rule notwendig welche das Gateway des VPN-Tunnels nutzt:

Anschliessend kann der Rechner 192.168.1.5 über die VPN-Adresse ins Internet, aber nur, wenn auch die 1:1 NAT-Rule vorher aktiviert wurde. Was noch nicht funktioniert, ist der umgekehrte Weg - die im 1:1 NAT angegebene VPN-IP läßt sich von aussen weder anpingen noch ein bestimmter Port errreichen.

Ich hatte zuvor auch versucht, mittels normalem Port-Forwarding vom VPN-Gateway aus bestimmte Ports auf die Ziel-Rechner umzuleiten, leider ohne Erfolg. Sobald das 1:1 NAT deaktiviert wird, kann der 192.168.1.5 Host nicht mehr nach aussen pingen - daher vermute ich, dass da wohl weitere Einstellungen beim Outbound-NAT notwendig wären.

Marvho

Versuch doch mal die Regel am PTYOPENVPN auf Destination "Feste IP vom VPN Anbieter" zu wechseln und teste mal ob es geht.
Ansonsten schau mal in die Firewall Logs und guck ob dort irgendwas geblockt wird.

viragomann

@michaeljk:

Sobald das 1:1 NAT deaktiviert wird, kann der 192.168.1.5 Host nicht mehr nach aussen pingen - daher vermute ich, dass da wohl weitere Einstellungen beim Outbound-NAT notwendig wären.

Das liegt wohl daran, dass mit 1:1 NAT die interne IP des Hosts auf die VPN-IP transferiert wird und so die Antwort-Pakete wieder auf die VPN-IP gehen und dann wieder auf den Host geroutet werden. Genau das, was Outbound NAT bewirkt.
Fehlt das 1:1 NAT und ist es im Outbound NAT nicht entsprechend konfiguriert, gehen die Paket mit der internen Quell-IP des Hosts über die VPN raus, da werden sie aber nicht weiter geroutet, weil es ein privater IP-Bereich ist. Auch wenn sie geroutet werden würden, kämen die Antwort-Paket nicht zurück, weil die Route zur Quell-IP jenseits der VPN unbekannt ist.

Mit deinen Einstellungen sollte auch der Zugriff von außen funktionieren. Die einzige Erklärung wäre für mich, dass von Portunity nichts daher kommt.
Untersuche das mal mit Hilfe von Paket Capture im Diagnostics Menü, erst am VPN Interface und wenn da die Zugriffe ankommen am DMZ Interface. Wenn am VPN schon nichts kommt, liegts an Portunity. Eventell sind da noch Einstellungen nötig, damit auch von außen zugegriffen werden kann.

viragomann

@Marvho:

Versuch doch mal die Regel am PTYOPENVPN auf Destination "Feste IP vom VPN Anbieter" zu wechseln und teste mal ob es geht.

Absoluter Unsinn. Das Ziel ist von dieser Seite nicht die VPN-IP, sondern die IP des DMZ Hosts. Dass die IP auf die des Hosts transferiert wird, hat NAT zu sorgen.

michaeljk

@viragomann:

Mit deinen Einstellungen sollte auch der Zugriff von außen funktionieren. Die einzige Erklärung wäre für mich, dass von Portunity nichts daher kommt.
Untersuche das mal mit Hilfe von Paket Capture im Diagnostics Menü, erst am VPN Interface und wenn da die Zugriffe ankommen am DMZ Interface. Wenn am VPN schon nichts kommt, liegts an Portunity. Eventell sind da noch Einstellungen nötig, damit auch von außen zugegriffen werden kann.

Ich habe mal ein Packet Capture sowohl über das PTYOPENVPN als auch das DMZ-Interface laufen lassen, mit einem externen ICMP-Request:


Ping PTYOPENVPN
14:16:26.260278 IP 91.X.X.X > 46.X.X.X: ICMP echo request, id 3064, seq 1, length 64
14:16:26.286193 IP 87.X.X.X > 46.X.X.X: ICMP host 91.X.X.X unreachable - admin prohibited filter, length 36
14:16:27.298591 IP 91.X.X.X > 46.X.X.X: ICMP echo request, id 3064, seq 2, length 64
14:16:27.364441 IP 87.X.X.X > 46.X.X.X: ICMP host 91.X.X.X unreachable - admin prohibited filter, length 36

Ping DMZ
14:15:07.886133 IP 91.X.X.X > 192.168.1.5: ICMP echo request, id 3058, seq 1, length 64
14:15:07.886515 IP 192.168.1.5 > 91.X.X.X: ICMP echo reply, id 3058, seq 1, length 64
14:15:07.912525 IP 87.X.X.X > 192.168.1.5: ICMP host 91.X.X.X unreachable - admin prohibited filter, length 36
14:15:08.921498 IP 91.X.X.X > 192.168.1.5: ICMP echo request, id 3058, seq 2, length 64
14:15:08.921893 IP 192.168.1.5 > 91.X.X.X: ICMP echo reply, id 3058, seq 2, length 64
14:15:08.981996 IP 87.X.X.X > 192.168.1.5: ICMP host 91.X.X.X unreachable - admin prohibited filter, length 36

91.X.X.X: Externer Host, der Ping ausführt
192.168.1.5: Interner Host in der DMZ
87.X.X.X: ~~Aktuelle (dynamische) WAN-IP~~ Übergeordneter Next-Hop Router der Telekom
46.X.X.X: Statische VPN-IP von Portunity

Für mich sieht das danach aus, das bereits am PTYOPENVPN-Interface die Antwort-Pakete nicht durchkommen?

michaeljk

Eine kleine Korrektur: 87.X.X.X ist nicht die WAN-IP, sondern die Adresse des übergeordneten Next-Hop Routers der Telekom. Ich habe nun ebenfalls einen tcpdump direkt am Host 192.168.1.5 laufen lassen:


15:36:25.208405 IP 91.X.X.X > 192.168.1.5: ICMP echo request, id 3917, seq 631, length 64
15:36:25.208724 IP 192.168.1.5 > 91.X.X.X: ICMP echo reply, id 3917, seq 631, length 64
15:36:26.020968 IP 91.X.X.X > 192.168.1.5: ICMP echo request, id 3982, seq 358, length 64
15:36:26.021333 IP 192.168.1.5 > 91.X.X.X: ICMP echo reply, id 3982, seq 358, length 64
15:36:26.047909 IP 87.X.X.X > 192.168.1.5: ICMP host 91.X.X.X unreachable - admin prohibited filter, length 36

Man sieht dort, dass der ICMP-Request beim Host eintrifft und wohl auch beantwortet wird. Den externen Host (91.X.X.X) erreicht diese Reply allerdings nicht, daher muss das Paket irgendwo zwischendurch schon geblockt werden. Das PTYOPENVPN Interface zeigt beim Packet Capture nur die ICMP Requests von extern, dort kommt also die Reply des internen Hosts nie an.

Was mich insbesondere verwundert ist die Mitteilung vom Host 87.X.X.X an den DMZ-Host, dass der Host 91.X.X.X (welcher den Ping ausführt) nicht erreichbar sei - jemand eine Idee wo das herkommt? Werden die ICMP-Antworten vom DMZ-Host vielleicht fälschlicherweise über das WAN-Interface geroutet statt über das PTYOPENVPN Interface?

viragomann

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?

michaeljk

@viragomann:

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?

viragomann

@michaeljk:

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.

@michaeljk:

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.

@michaeljk:

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.

michaeljk

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.

michaeljk

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?

viragomann

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.

michaeljk

@viragomann:

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?

viragomann

@michaeljk:

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.

@michaeljk:

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?