3
Pfsense kein Zugriff von LAN auf DMZ-Rechner nach dortiger OpenVPN-Verbindung
Hallo,
vorab einmal herzlichen Dank für die vielen nützlichen Infos und Tutorials in diesem Forum.
Ohne die Tutorials (aqui) hätte ich meine Grundkonfiguration der PfSense wohl nicht so einfach hinbekommen, bin also, was Netzwerke angeht, ein relativer, aber lernwilliger Anfänger.
Mit der Grundkonfiguration meines Heim-Netzwerkes hat bisher auch alles gut hingehauen.
Ich betreibe die PfSense auf einem APU1D-Board mit WLAN-Karte hinter einer Fritzbox mit einem bridged LAN-WLAN- und einem DMZ-Interface.
An beiden Interfaces hängt jeweils ein switch mit weiteren Devices.
Soweit funktioniert auch alles hervorragend.
Ich habe nun, vor allem wegen der leidlichen Diskussion um die Vorratsdatenspeicherung, bei einem VPN-Provider ein Abo abgeschlossen und auf der PfSense ein weiteres WAN für die VPN-Verbindung eingerichtet.
Auch das funktioniert.Mittels der Interface-Rules lässt sich sogar steuern, welcher Rechner über die VPN und welcher über den ISP ins Netz geht.
Jetzt zu meinem Problem, das ich auch nach gefühlt ewigem trial&error nicht in den Griff bekomme und einfach nicht verstehe.
Am switch des DMZ-Interfaces, welches über die VPN nach draussen geht, habe ich einen Intel-NUC mit Ubuntu eingerichtet.
Auf diesem läuft Privoxy zur AD-Filterung. Auch die Verbindung über Privoxy funktioniert selbst aus dem LAN-WLAN-bridged Interface tadellos.
Auf dem NUC habe ich nun auch OpenVPN installiert und versucht, eine VPN-Verbindung durch die VPN-Verbindung der PfSense ins Internet einzurichten.
Auch diese Verbindung kommt einwandfrei zustande. Schliesse ich einen PC an den DMZ-Switch an, kann ich die Tunnel-in-Tunnel Verbindung über Privoxy nutzen.
Möchte ich nun jedoch einen Verbindung zu Privoxy aus dem Netz des LAN-WLAN-bridged Interfaces starten geht gar nichts mehr (no route to host).
Alle Verbindungen aus dem bridged Interface zum Intel-NUC, nicht nur die auf dem Privoxy-Port, brechen ab, solange die openVPN-Verbindung auf dem NUC aktiv ist.
Deaktiviere ich diese, ist eine Verbindung wieder problemlos möglich.
Das Problem müsste also bei PfSense liegen, so zumindest meine Mutmassung.
An den Firewall Rules dürfte es wohl nicht liegen, da ohne aktiviertes VPN auf dem NUC die Verbindung zustande kommt.
Auch mit "offenen Scheunentoren" will es nicht funktionieren.
Hat vielleicht jemand eine Idee?
Danke
vorab einmal herzlichen Dank für die vielen nützlichen Infos und Tutorials in diesem Forum.
Ohne die Tutorials (aqui) hätte ich meine Grundkonfiguration der PfSense wohl nicht so einfach hinbekommen, bin also, was Netzwerke angeht, ein relativer, aber lernwilliger Anfänger.
Mit der Grundkonfiguration meines Heim-Netzwerkes hat bisher auch alles gut hingehauen.
Ich betreibe die PfSense auf einem APU1D-Board mit WLAN-Karte hinter einer Fritzbox mit einem bridged LAN-WLAN- und einem DMZ-Interface.
An beiden Interfaces hängt jeweils ein switch mit weiteren Devices.
Soweit funktioniert auch alles hervorragend.
Ich habe nun, vor allem wegen der leidlichen Diskussion um die Vorratsdatenspeicherung, bei einem VPN-Provider ein Abo abgeschlossen und auf der PfSense ein weiteres WAN für die VPN-Verbindung eingerichtet.
Auch das funktioniert.Mittels der Interface-Rules lässt sich sogar steuern, welcher Rechner über die VPN und welcher über den ISP ins Netz geht.
Jetzt zu meinem Problem, das ich auch nach gefühlt ewigem trial&error nicht in den Griff bekomme und einfach nicht verstehe.
Am switch des DMZ-Interfaces, welches über die VPN nach draussen geht, habe ich einen Intel-NUC mit Ubuntu eingerichtet.
Auf diesem läuft Privoxy zur AD-Filterung. Auch die Verbindung über Privoxy funktioniert selbst aus dem LAN-WLAN-bridged Interface tadellos.
Auf dem NUC habe ich nun auch OpenVPN installiert und versucht, eine VPN-Verbindung durch die VPN-Verbindung der PfSense ins Internet einzurichten.
Auch diese Verbindung kommt einwandfrei zustande. Schliesse ich einen PC an den DMZ-Switch an, kann ich die Tunnel-in-Tunnel Verbindung über Privoxy nutzen.
Möchte ich nun jedoch einen Verbindung zu Privoxy aus dem Netz des LAN-WLAN-bridged Interfaces starten geht gar nichts mehr (no route to host).
Alle Verbindungen aus dem bridged Interface zum Intel-NUC, nicht nur die auf dem Privoxy-Port, brechen ab, solange die openVPN-Verbindung auf dem NUC aktiv ist.
Deaktiviere ich diese, ist eine Verbindung wieder problemlos möglich.
Das Problem müsste also bei PfSense liegen, so zumindest meine Mutmassung.
An den Firewall Rules dürfte es wohl nicht liegen, da ohne aktiviertes VPN auf dem NUC die Verbindung zustande kommt.
Auch mit "offenen Scheunentoren" will es nicht funktionieren.
Hat vielleicht jemand eine Idee?
Danke
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 290705
Url: https://administrator.de/contentid/290705
Printed on: April 27, 2024 at 16:04 o'clock
3 Comments
Latest comment
der leidlichen Diskussion um die Vorratsdatenspeicherung, bei einem VPN-Provider ein Abo abgeschlossen
Macht die Sache eigentlich noch sehr viel schlimmer, denn Vertrauen das die VPN Schlüssel sicher sind kannst du diesen VPN Providern niemals. Die Schlüssel kommen ja nicht von dir selber also außerhalb deiner Hoheit, somit ist das eher Kasperkram als sicher.Im Gegenteil...an den Tunnelendpunkten deren VPNs tummeln sich alle Daten Schlapphüte meist in vergrößerter Anzahl um genau da diese Daten abzugreifen. Logisch das solche Dienste ein primäres Ziel sind.
Damit hast du dir also vermutlich einen üblen Bärendienst erwiesen...
Zurück zur Technik:
Auf dem NUC habe ich nun auch OpenVPN installiert
VPN in VPN...klingt etwas paranoid aber nundenn...Das Problem müsste also bei PfSense liegen, so zumindest meine Mutmassung.
Was lässt dich zu dieser Schlussfolgerung kommen. Wenn du OVPN auf dem NUC startest beeinflusst das in keinster Weise die pfSense Konfig oder die IP Forwarding Entscheidung der pfSense. Die hat doch keinerlei Ahnung davon das auf dem Zielhost gerade ein OVPN gestartet ist...woher auch.Die Schlussfolgerung das es an der pfSense liegen kann entbehrt also mehr oder weniger einer technischen Grundlage denn Logik.
Warum hast du dir nicht einfach mal die Mühe gemacht und mit tcpdump (oder wireshark) dir den Dataflow vom IP Client im LAN/WLAN Interface zum NUC an dem NUC angesehen ??
Damit hättest du in 3 Minuten gesehen wo das Problem liegt. Klaäre also:
- Kommt Traffic vom Client am NUC an ?
- Ja => Wie sieht der Reply Traffic aus aus dem NUC ?
- Stimmt die Absender IP ?
- Nein => Nutzt der NUC mit aktivem OVPN ggf. einen andere Absender IP und bleibt diese an den FW Regeln der pfSense hängen ?
- Wenn ja was sagt das Firewall Log der pfSense ?
- Das kein Client Traffic am NUC mehr ankommt über die FW nur weil auf dem NUC ein OVPN startet ist sehr unwahrscheinlich. Aber auch das kannst du ebenso über die embeddete Wireshark bzw. Sniffer Funktion in der pfSense sofort rausfinden.
Hallo aqui,
Erst einmal herzlichen Dank für Deine Antwort und Deine Anregungen.
Wie gesagt bin ich, was Netzwerke und Netzwerkdiagnostik angeht absoluter Anfänger.
Bisher galt für mich mehr Stecker rein und Stecker raus...vielleicht noch IP-Adresse,Maske,DNS ;)
Auch mit Linux befasse ich mit erst seit kurzem. Das ist der Grund, warum ich diese für Dich sicherlich einfachen und schnellen Troubleshooting Schritte bisher nicht unternommen habe (können). Als Anfänger muss man da erst einmal draukommen und die Werkzeuge kennenlernen.
Es geht darum, etwas dem zunehmenden Überwachungsstaat entgegenzuhalten und auch so seinen Protest auszudrücken. Wenn nicht so, wie dann?
Auch wenn der VPN-Provider nicht vertrauenswürdig wäre, hätte ich kein Problem damit. Ich benutze den VPN zum normalen surfen, keineswegs für online-Banking, emails oder andere private Dinge. Die Informationen, die man über einen sammelt etwas zu verwässern finde ich keine schlechte Sache.
Ein weiterer Zweck des VPN sind die Geoblockierungen z.B. von youtube Videos. Das ist auch der Grund, weshalb ich über privoxy auf den NUC mit einem zweiten VPN zugreifen möchte, da man dort das Land des VPN-Server-Standortes schneller wechseln kann, als in der PfSense. Ist also wirklich keine Paranoia.
Was meine Mutmaßung anging, das Problem würde bei der PfSense liegen, lag daran, dass ich dachte, wenn die Verbindung im Netzwerk des gleichen Interfaces funktioniert und nur dann geblockt wird, wenn ich den Zugriff aus dem anderen Netzwerk des LAN-Interfaces versuche, dann müsste es irgendwie an der PfSense liegen (auch wenn die PfSense Logs dies irgendwie nicht hergaben).
Scheinbar falsch gedacht. Ich habe auf dem NUC jetzt einmal das von Dir erwähnte tcpdump ausgeführt und bin dabei zu versuchen, es zu verstehen.
Wenn ich einen tcpdump aus dem Netz des gleichen Interfaces (DMZ) durchführe, während ich auf den Proxy des NUK unter Aktivierung des VPN zugreife (hier funktioniert alles wie es sollte) bekomme ich u.a. folgendes:
Die IPs stimmen (Notebook 10.11.0.10 am LAN-Interface bzw 10.11.1.101 nach DHCP am Switch der DMZ, 10.11.1.30 der NUC)
listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:56:14.467715 IP 10.11.1.101.56603 > 10.11.1.30.8118: Flags [S], seq 2764662043, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 718062821 ecr 0,sackOK,eol], length 0
18:56:14.467811 IP 10.11.1.30.8118 > 10.11.1.101.56603: Flags [S.], seq 1576968114, ack 2764662044, win 28960, options [mss 1460,sackOK,TS val 47412614 ecr 718062821,nop,wscale 7], length 0
18:56:14.468181 IP 10.11.1.101.56603 > 10.11.1.30.8118: Flags [.], ack 1, win 4117, options [nop,nop,TS val 718062821 ecr 47412614], length 0
18:56:14.468781 IP 10.11.1.101.56603 > 10.11.1.30.8118: Flags [P.], seq 1:272, ack 1, win 4117, options [nop,nop,TS val 718062822 ecr 47412614], length 271
18:56:14.468819 IP 10.11.1.30.8118 > 10.11.1.101.56603: Flags [.], ack 272, win 235, options [nop,nop,TS val 47412614 ecr 718062822], length 0
.
.
Bei Zugriff auf den Proxy aus der LAN-WLAN-Bridge (hoer funktioniert es nicht) erhalte ich dies:
18:38:15.807396 IP 10.11.0.10.56486 > 10.11.1.30.8118: Flags [S], seq 2617945917, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 716986649 ecr 0,sackOK,eol], length 0
18:38:16.038265 IP 10.11.0.10.56485 > 10.11.1.30.8118: Flags [S], seq 3965274998, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 716986882 ecr 0,sackOK,eol], length 0
18:38:16.288463 IP 10.11.0.10.56486 > 10.11.1.30.8118: Flags [S], seq 2617945917, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 716987129 ecr 0,sackOK,eol], length 0
18:38:17.002261 IP 10.11.0.10.56485 > 10.11.1.30.8118: Flags [S], seq 3965274998, win 65535, options [mss 1460,sackOK,eol], length 0
18:38:17.249627 IP 10.11.0.10.56486 > 10.11.1.30.8118: Flags [S], seq 2617945917, win 65535, options [mss 1460,sackOK,eol], length 0
.
.
Die Anfrage erreicht den Privoxy-Port des NUK, wird dann jedoch nicht weiter verarbeitet und verfällt schliesslich (eol steht wohl für end of life). Auch ein netstat -tulpn zeigt mit den Privoxy Port 8118 als offen. Die Flags zeigen lediglich [S] (wiederholter frustraner Versuch eines Starts der Verbindung?).
In der privoxy log-Datei (debug 2) erfolgt nach Aktivierung des VPN kein Eintrag für einen Verbindungsaufbau. Die Anfrage kommt dort also nicht an. Stimmt meine Interpretation?
Nachtrag 12.12.15: Lösung gefunden!
Nach einigem hin und her mit tcpdump und näherer Betrachtung der routing table des NUC-Ubuntu-Rechners war es letztendlich ein Routing-Problem.
Nach Hinzufügen des LAN-WLAN-Bridge-Netzwerks funktionierte dann alles perfekt.
Danke aqui für die "Tipps für einen Anfänger" mit tcpdump/wireshark und den "roten Faden", an dem ich mich entlang hangeln konnte
Erst einmal herzlichen Dank für Deine Antwort und Deine Anregungen.
Wie gesagt bin ich, was Netzwerke und Netzwerkdiagnostik angeht absoluter Anfänger.
Bisher galt für mich mehr Stecker rein und Stecker raus...vielleicht noch IP-Adresse,Maske,DNS ;)
Auch mit Linux befasse ich mit erst seit kurzem. Das ist der Grund, warum ich diese für Dich sicherlich einfachen und schnellen Troubleshooting Schritte bisher nicht unternommen habe (können). Als Anfänger muss man da erst einmal draukommen und die Werkzeuge kennenlernen.
Zitat von @aqui:
findest Du? Ich denke, es sollten noch viele Leute mehr VPNs oder Tor verwenden, ebenso wie PGP-verschlüsselte eMails.der leidlichen Diskussion um die Vorratsdatenspeicherung, bei einem VPN-Provider ein Abo abgeschlossen
Macht die Sache eigentlich noch sehr viel schlimmer, denn Vertrauen das die VPN Schlüssel sicher sind kannst du diesen VPN Providern niemals. Die >> Schlüssel kommen ja nicht von dir selber also außerhalb deiner Hoheit, somit ist das eher Kasperkram als sicher.
Im Gegenteil...an den Tunnelendpunkten deren VPNs tummeln sich alle Daten Schlapphüte meist in vergrößerter Anzahl um genau da diese Daten >> abzugreifen. Logisch das solche Dienste ein primäres Ziel sind.
Damit hast du dir also vermutlich einen üblen Bärendienst erwiesen...
Macht die Sache eigentlich noch sehr viel schlimmer, denn Vertrauen das die VPN Schlüssel sicher sind kannst du diesen VPN Providern niemals. Die >> Schlüssel kommen ja nicht von dir selber also außerhalb deiner Hoheit, somit ist das eher Kasperkram als sicher.
Im Gegenteil...an den Tunnelendpunkten deren VPNs tummeln sich alle Daten Schlapphüte meist in vergrößerter Anzahl um genau da diese Daten >> abzugreifen. Logisch das solche Dienste ein primäres Ziel sind.
Damit hast du dir also vermutlich einen üblen Bärendienst erwiesen...
Es geht darum, etwas dem zunehmenden Überwachungsstaat entgegenzuhalten und auch so seinen Protest auszudrücken. Wenn nicht so, wie dann?
Auch wenn der VPN-Provider nicht vertrauenswürdig wäre, hätte ich kein Problem damit. Ich benutze den VPN zum normalen surfen, keineswegs für online-Banking, emails oder andere private Dinge. Die Informationen, die man über einen sammelt etwas zu verwässern finde ich keine schlechte Sache.
Ein weiterer Zweck des VPN sind die Geoblockierungen z.B. von youtube Videos. Das ist auch der Grund, weshalb ich über privoxy auf den NUC mit einem zweiten VPN zugreifen möchte, da man dort das Land des VPN-Server-Standortes schneller wechseln kann, als in der PfSense. Ist also wirklich keine Paranoia.
Was meine Mutmaßung anging, das Problem würde bei der PfSense liegen, lag daran, dass ich dachte, wenn die Verbindung im Netzwerk des gleichen Interfaces funktioniert und nur dann geblockt wird, wenn ich den Zugriff aus dem anderen Netzwerk des LAN-Interfaces versuche, dann müsste es irgendwie an der PfSense liegen (auch wenn die PfSense Logs dies irgendwie nicht hergaben).
Scheinbar falsch gedacht. Ich habe auf dem NUC jetzt einmal das von Dir erwähnte tcpdump ausgeführt und bin dabei zu versuchen, es zu verstehen.
Wenn ich einen tcpdump aus dem Netz des gleichen Interfaces (DMZ) durchführe, während ich auf den Proxy des NUK unter Aktivierung des VPN zugreife (hier funktioniert alles wie es sollte) bekomme ich u.a. folgendes:
Die IPs stimmen (Notebook 10.11.0.10 am LAN-Interface bzw 10.11.1.101 nach DHCP am Switch der DMZ, 10.11.1.30 der NUC)
listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:56:14.467715 IP 10.11.1.101.56603 > 10.11.1.30.8118: Flags [S], seq 2764662043, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 718062821 ecr 0,sackOK,eol], length 0
18:56:14.467811 IP 10.11.1.30.8118 > 10.11.1.101.56603: Flags [S.], seq 1576968114, ack 2764662044, win 28960, options [mss 1460,sackOK,TS val 47412614 ecr 718062821,nop,wscale 7], length 0
18:56:14.468181 IP 10.11.1.101.56603 > 10.11.1.30.8118: Flags [.], ack 1, win 4117, options [nop,nop,TS val 718062821 ecr 47412614], length 0
18:56:14.468781 IP 10.11.1.101.56603 > 10.11.1.30.8118: Flags [P.], seq 1:272, ack 1, win 4117, options [nop,nop,TS val 718062822 ecr 47412614], length 271
18:56:14.468819 IP 10.11.1.30.8118 > 10.11.1.101.56603: Flags [.], ack 272, win 235, options [nop,nop,TS val 47412614 ecr 718062822], length 0
.
.
Bei Zugriff auf den Proxy aus der LAN-WLAN-Bridge (hoer funktioniert es nicht) erhalte ich dies:
18:38:15.807396 IP 10.11.0.10.56486 > 10.11.1.30.8118: Flags [S], seq 2617945917, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 716986649 ecr 0,sackOK,eol], length 0
18:38:16.038265 IP 10.11.0.10.56485 > 10.11.1.30.8118: Flags [S], seq 3965274998, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 716986882 ecr 0,sackOK,eol], length 0
18:38:16.288463 IP 10.11.0.10.56486 > 10.11.1.30.8118: Flags [S], seq 2617945917, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 716987129 ecr 0,sackOK,eol], length 0
18:38:17.002261 IP 10.11.0.10.56485 > 10.11.1.30.8118: Flags [S], seq 3965274998, win 65535, options [mss 1460,sackOK,eol], length 0
18:38:17.249627 IP 10.11.0.10.56486 > 10.11.1.30.8118: Flags [S], seq 2617945917, win 65535, options [mss 1460,sackOK,eol], length 0
.
.
Die Anfrage erreicht den Privoxy-Port des NUK, wird dann jedoch nicht weiter verarbeitet und verfällt schliesslich (eol steht wohl für end of life). Auch ein netstat -tulpn zeigt mit den Privoxy Port 8118 als offen. Die Flags zeigen lediglich [S] (wiederholter frustraner Versuch eines Starts der Verbindung?).
In der privoxy log-Datei (debug 2) erfolgt nach Aktivierung des VPN kein Eintrag für einen Verbindungsaufbau. Die Anfrage kommt dort also nicht an. Stimmt meine Interpretation?
Nachtrag 12.12.15: Lösung gefunden!
Nach einigem hin und her mit tcpdump und näherer Betrachtung der routing table des NUC-Ubuntu-Rechners war es letztendlich ein Routing-Problem.
Nach Hinzufügen des LAN-WLAN-Bridge-Netzwerks funktionierte dann alles perfekt.
Danke aqui für die "Tipps für einen Anfänger" mit tcpdump/wireshark und den "roten Faden", an dem ich mich entlang hangeln konnte
Hilfe zur Selbsthilfe 
Gut wenn nun alles klappt wie es soll...
Gut wenn nun alles klappt wie es soll...