iceget
Goto Top

PfSense Zugriff vom LAN zu den verbundenen openVPN Clients

Hallo liebe Community,

folgendes Problem:

Hier einmal die Übersicht über mein Netzwerk & Einstellungen in pfSense:
9a8ac995ebe633cf0b9104aed5fab321

Mein Netzwerk sieht wie folgt aus:

192.168.0.10 = Windows 7 Client
192.168.0.250 = pfSense WAN
192.168.0.254 = Gateway

10.0.9.6 = Windows 7 Client EXT

Der Port 1194 UDP wurde am Gateway auf die 192.168.0.250 weitergeleitet.

- Verbindung von Windows 7 Client EXT zur pfSense funktioniert.
- Ich kann auch das Gateway (192.168.0.254) und den Windows 7 Client (192.168.0.10) pingen, alles okay.
- von pfSense kann ich ohne Probleme auf den externen Windows 7 Client EXT zugreifen


Was ich nicht kann (und genau da stehe ich an):
Ich müsste vom LAN (alle Geräte die den 192.168.0.254 als Gateway eingetragen haben) auf die 10.0.9.6 (Windows 7 Client EXT) zugreifen.

Wie mache ich das? Was mache ich falsch? Route ist auch bereits gesetzt...

Meine Firewall ist ALLOW * FROM * bei LAN, WAN sowieo OPENVPN eingestellt!

Und meine zweite Frage:
Kann ich meinen externen Clients auch statische IP-Adressen zuweisen?

z.B.Windows 7 Client EXT 1 = 10.0.9.10
Windows 7 Client EXT 2 = 10.0.9.11
Windows 7 Client EXT 3 = 10.0.9.12

Könnt ihr mir helfen?

Vielen Dank schon mal im vorhinein.

lg Iceget

Content-Key: 251334

Url: https://administrator.de/contentid/251334

Printed on: April 25, 2024 at 15:04 o'clock

Member: aqui
aqui Oct 08, 2014 updated at 17:18:32 (UTC)
Goto Top
Leider etwas oberflächlich face-sad
Folgende Fragen bleiben offen:
  • Erstmal: Das ist ein Laboraufbau, richtig ? Denn private 10er und 192.168er RFC 1918 IPs werden im wahren Internet NICHT geroutet da es private IP Netze sind was dir hoffentlich klar ist ?!
  • Ist deine pfSense OVPN Server für den externen 10er Client wie es in diesem_Tutorial beschrieben ist ?
  • Wenn ja hast du am WAN Port der pfSense die Default Regel "Block RFC 1918 private IP networks" durch Entfernen des Hakens deaktiviert ???
  • Zusätzlich musst du in den FW Rules am WAN Port einen Regel konfigurieren die Zugriff von any mit Destination Port UDP 1194 auf "WAN Port address" erlaubt (Pass) !
  • Der 10.0.9.6 (Windows 7 Client EXT) ist das der OVPN Client der sich in die pfSense einwählt ??
  • Wenn ja: a.) wird der VPN Tunnel sauber aufgebaut ? (OVPN Log) b.) Hast du eine entsprechende Firewall regel erstellt die den Zugriff aus dem 192.168.0er netz in das interne OVPN IP Netz erlaubt. Die IP Adresse auf dem virtuellen OVPN Client ist die die in der server.conf Datein von OVPN mit server a.b.c.d konfiguriert wird ? Siehe Tutorial oben !!
Kann ich meinen externen Clients auch statische IP-Adressen zuweisen?
Wie meinst du das auf dem OVPN Tunnelinterface oder auf dem physischen Interface ?? Da ist deine Frage nicht eindeutig.
Diese offenen Dinge solltest du erstmal technisch klären.
Dein Bild ist ebenso total irreführend, denn der z.B. der "LAN Win7 Clint" hat sowohl ein Bein ins LAN Netz .10.0 /24 als auch ins Gateway Netz mit der .0.0 /24 was so niemals geht. Oder ist dem wirklich so ?
So oder so sind die wahren Kommunikationsbeziehungen ziemlich verwirrend und eine zielführende Hilfe damit nicht gerade einfach face-sad
Member: iceget
iceget Oct 09, 2014 updated at 06:28:44 (UTC)
Goto Top
Hallo Aqui,

danke für deine Antwort:

Erstmal: Das ist ein Laboraufbau, richtig ? Denn private 10er und 192.168er RFC 1918 IPs werden im wahren Internet NICHT geroutet da es private IP Netze sind was dir hoffentlich klar ist ?!:
Mit der IP 10.0.9.6 vom Win 7 Ext Client meine ich die IP-Adresse die der Client vom openVPN Server zugewiesen bekommt. Der Windows 7 Client EXT hat ein normales 3 G Modem (mit irgendeiner offiziellen IP-Adresse).

Ist deine pfSense OVPN Server für den externen 10er Client wie es in diesem_Tutorial beschrieben ist?:
Genau, die Einwahl funktioniert auch ohne Probleme. Ich kann das gesamte 192.168.0.X er Netzwerk vom Client aus erreichen (nachdem er die Verbindung ordentlich aufgebaut hat). Vom OVPN Server kann ich ohne Probleme auf den externen Windows 7 Client zugreifen (alle Ports), nur eben vom LAN nicht, das ist das was ich erreichen möchte (alle Verbundenen OVPN Clients möchte ich vom LAN aus zugänglich machen).

Zusätzlich musst du in den FW Rules am WAN Port einen Regel konfigurieren die Zugriff von any mit Destination Port UDP 1194 auf "WAN Port address" erlaubt (Pass)!:
In meinem Post steht doch "Meine Firewall ist ALLOW * FROM * bei LAN, WAN sowieo OPENVPN eingestellt!". Also ja, Verbindung vom W7 EXT Client zum OVPN Server funktioniert.

Der 10.0.9.6 (Windows 7 Client EXT) ist das der OVPN Client der sich in die pfSense einwählt ??:
Genau, jedoch ist die 10.0.9.6 schon die IP die von OVPN zugewiesen wurde (der Client selbst hat irgendeine offizielle vom 3 G Modem).

Wenn ja: a.) wird der VPN Tunnel sauber aufgebaut ? (OVPN Log) b.) Hast du eine entsprechende Firewall regel erstellt die den Zugriff aus dem 192.168.0er netz in das interne OVPN IP Netz erlaubt. Die IP Adresse auf dem virtuellen OVPN Client ist die die in der server.conf Datein von OVPN mit server a.b.c.d konfiguriert wird ? Siehe Tutorial oben !!:
Ja der Tunnel wird sauber aufgebaut. Auch die Firewall habe ich (wie gesagt) so konfiguriert:
Meine Firewall ist ALLOW * FROM * bei LAN, WAN sowieo OPENVPN eingestellt!

Danke
Member: aqui
aqui Oct 09, 2014 at 07:22:01 (UTC)
Goto Top
OK, das bringt Klarheit in die Sache.. face-wink
Fakt ist also:
  • OVPN Einwahl vom Client funktioniert fehlerlos
  • Du kannst vom Client sämtliche Endgeräte im lokalen LAN erreichen
  • Vom OVPN Server klappt der Client Zugriff problemlos
Das du dann von den LAN Clients nicht auf den OVPN Client zugreifen kannst ist einzig und allein dann eine Problematik der Windows lokalen Firewall bzw. das du auf dem virtuellen FW Adapter ein falsches Firewall Profil nutzt !
Das zeigt das Verhalten ganz deutlich, denn der OVPN Server selber nutzt als Absender IP eine 10.0.9.x IP Adresse die passieren darf, deshalb klappt da der Zugriff !
Die LAN Clients nutzen aber eine 192.168.10.x IP Adresse des lokalen LANs und für die lokale Client Firewall ist das ein Fremdnetz wovon sie dann wie bei Windows Firewalls so üblich alles blockt !
Durch das fehlende Routing identifiziert Winblows das FW profil dann als "nicht identifiziertes Netzwerk" in der FW und blockt alles.
Du musst also schlicht und einfach nur den Traffic aus dem 192.168.10.0 /24 Netz dort passieren lassen und dann kommt das sofort zum Fliegen.
Vielleicht hilft dir das dazu:
http://asktheoracle.com/blog/how-to-make-openvpn-work-with-the-windows- ...
http://www.carecom.de/de/blog/hm/blog/openvpn-unter-windows-mit-firewal ...
Meine Firewall ist ALLOW * FROM * bei LAN, WAN sowieo OPENVPN eingestellt!
Das ist natürlich böse und fahrlässig, denn damit hast du die Firewall komplett deaktiviert.
Zum Testen ist das absolut OK aber später solltest du zur eigenen Sicherheit das dringenst wieder einengen auf die Netze die du auch damit wirklich bedienst !!!
Member: iceget
iceget Oct 09, 2014 updated at 07:33:46 (UTC)
Goto Top
Zitat von @aqui:

OK, das bringt Klarheit in die Sache.. face-wink
Fakt ist also:
  • OVPN Einwahl vom Client funktioniert fehlerlos
  • Du kannst vom Client sämtliche Endgeräte im lokalen LAN erreichen
  • Vom OVPN Server klappt der Client Zugriff problemlos
Das du dann von den LAN Clients nicht auf den OVPN Client zugreifen kannst ist einzig und allein dann eine Problematik der Windows
lokalen Firewall bzw. das du auf dem virtuellen FW Adapter ein falsches Firewall Profil nutzt !
Das zeigt das Verhalten ganz deutlich, denn der OVPN Server selber nutzt als Absender IP eine 10.0.9.x IP Adresse die passieren
darf, deshalb klappt da der Zugriff !
Die LAN Clients nutzen aber eine 192.168.10.x IP Adresse des lokalen LANs und für die lokale Client Firewall ist das ein
Fremdnetz wovon sie dann wie bei Windows Firewalls so üblich alles blockt !
Durch das fehlende Routing identifiziert Winblows das FW profil dann als "nicht identifiziertes Netzwerk" in der FW und
blockt alles.
Du musst also schlicht und einfach nur den Traffic aus dem 192.168.10.0 /24 Netz dort passieren lassen und dann kommt das sofort
zum Fliegen.
Vielleicht hilft dir das dazu:
http://asktheoracle.com/blog/how-to-make-openvpn-work-with-the-windows- ...
http://www.carecom.de/de/blog/hm/blog/openvpn-unter-windows-mit-firewal ...
> Meine Firewall ist ALLOW * FROM * bei LAN, WAN sowieo OPENVPN eingestellt!
Das ist natürlich böse und fahrlässig, denn damit hast du die Firewall komplett deaktiviert.
Zum Testen ist das absolut OK aber später solltest du zur eigenen Sicherheit das dringenst wieder einengen auf die Netze die
du auch damit wirklich bedienst !!!
Hallo Aqui,

danke für deine Antwort!

Naja, da eigentlich die Hauptfirewall & Router die 192.168.0.254 ist, und nur der Port 1194 UDP auf die 192.168.0.250 (pfSense) weitergeleitet wird,
sehe ich nicht das dies fahrlässig ist (da ja der 192.168.0.254 die "echte" Firewall ist). pfSense verwende ich eigentlich nur für openVPN.

Ich hab etwas an den Einstellungen von pfSense rumgespielt, und habe es jetzt wenigstens erreicht das ich vom LAN den VPN-Client (in diesem Fall 10.0.9.6) pingen kann. Leider kann ich noch nicht auf den PC zugreifen (Ports sind irgendwie blockiert)...

Das mit der Windows Firewall habe ich mir auch schon gedacht, und diese deaktiviert. Was kann ich da noch dagegen tun?

Achja, es ist egal ob ich die Windows Firewall deaktiviere oder nicht, der Ping geht immer durch...
Member: aqui
aqui Oct 09, 2014 at 07:51:38 (UTC)
Goto Top
sehe ich nicht das dies fahrlässig ist (da ja der 192.168.0.254 die "echte" Firewall ist)
Oben schreibst du aber das das "nur" ein Router ist ! Ja was denn nun...Router ist keine Firewall wie jeder weiss. Bei einer simplen Router Kaskade ist das nicht wirklich sicher.
Aber egal...weisst du sicher alles selber. Security ist deine eigene Sache musst du selber beurteilen....
Ich hab etwas an den Einstellungen von pfSense rumgespielt, und habe es jetzt wenigstens erreicht das ich vom LAN den VPN-Client (in diesem Fall 10.0.9.6) pingen kann
"Rumgespielt" ist gut. Klingt einbischen danach als ob du ohne wirkliches Wissen frei nach "Trial & Error" blind rumklickst bis es geht...keine gute Idee...
Das sollte, wie schon gesagt, nicht an den pfSense Settings liegen, denn einseitig ging das ja schon. Kann nur noch die Win Firewall sein !
Du hast also irgendwie nur ICMP (Ping) erlaubt aber nicht alle anderen Dienste wie SMB/CIFS Sharing oder was auch immer du da nutzen willst auf dem Client ?!
Achja, es ist egal ob ich die Windows Firewall deaktiviere oder nicht, der Ping geht immer durch...
Daran kannst du schon sehen das irgendwas mit deiner FW nicht stimmt oder das ICMP für alle Profile dort erlaubt ist.
Letzteres würde bedeuten das du schon einmal in der Firewall rumgepfuscht hast ?!
http://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Member: iceget
iceget Oct 09, 2014 at 07:59:24 (UTC)
Goto Top
Zitat von @aqui:

> sehe ich nicht das dies fahrlässig ist (da ja der 192.168.0.254 die "echte" Firewall ist)
Oben schreibst du aber das das "nur" ein Router ist ! Ja was denn nun...Router ist keine Firewall wie jeder weiss. Bei
einer simplen Router Kaskade ist das nicht wirklich sicher.
Aber egal...weisst du sicher alles selber. Security ist deine eigene Sache musst du selber beurteilen....
> Ich hab etwas an den Einstellungen von pfSense rumgespielt, und habe es jetzt wenigstens erreicht das ich vom LAN den
VPN-Client (in diesem Fall 10.0.9.6) pingen kann
"Rumgespielt" ist gut. Klingt einbischen danach als ob du ohne wirkliches Wissen frei nach "Trial &
Error" blind rumklickst bis es geht...keine gute Idee...
Das sollte, wie schon gesagt, nicht an den pfSense Settings liegen, denn einseitig ging das ja schon. Kann nur noch die Win
Firewall sein !
Du hast also irgendwie nur ICMP (Ping) erlaubt aber nicht alle anderen Dienste wie SMB/CIFS Sharing oder was auch immer du da
nutzen willst auf dem Client ?!
> Achja, es ist egal ob ich die Windows Firewall deaktiviere oder nicht, der Ping geht immer durch...
Daran kannst du schon sehen das irgendwas mit deiner FW nicht stimmt oder das ICMP für alle Profile dort erlaubt ist.
Letzteres würde bedeuten das du schon einmal in der Firewall rumgepfuscht hast ?!
http://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen

Hallo,

die Settings sind nun 1:1 gleich wie in meinem Screenshot. Habe nur leider vorher die pfSense nicht neu gestartet. Seit ich die pfSense neu gestartet habe, funktioniert der Ping einwandfrei...

Wenn ich die Windows Firewall beende (Windows Firewall ein oder ausschalten), funktioniert der Ping weiter. Sobald ich jedoch den Dienst Windows Firewall beende bekomme ich eine Zeit Überschreitung zurück...

192.168.0.254 = eine Firewall (der Router steht dahinter). Leider habe ich auf Router / Firewall keinen Zugriff (ist ein "Managed-Network").

Danke und lg
Member: aqui
aqui Oct 09, 2014 updated at 08:18:42 (UTC)
Goto Top
Sobald ich jedoch den Dienst Windows Firewall beende bekomme ich eine Zeit Überschreitung zurück...
Das wäre dann quasi eine inverse Firewall...da ist irgendwas oberfaul. Kann ja niemals sein wenn man den gesamten Firewall Prozess killt das dann die Firewall mit einmal funktioniert.
Das da was nicht stimmt sagt einem schon der gesunde Menschenverstand. Hast du da zufällig noch zusätzlich so ein Security Müll wie Norton, Kaspersky und Co drauf ?!
Dort am Client liegt mit an Sicherheit grenzender Wahrscheinlichkeit dein Problem !
Leider habe ich auf Router / Firewall keinen Zugriff (ist ein "Managed-Network").
Oho...!!! und dann solche Aussagen wie "...sehe ich nicht das dies fahrlässig ist (da ja der 192.168.0.254 die "echte" Firewall ist)..." wo du also quasi völlig blind bist was vor deiner eigenen FW passiert ?!
Na ja...du weisst ja was du tust wenn du so sicher bist...no comment !
Member: iceget
iceget Oct 09, 2014 updated at 12:57:56 (UTC)
Goto Top
Hi,

jetzt hab ich endlich den Fehler gefunden...


Wenn ich von pfSense (Shell) auf den FTP-Server zugreifen möchte, kommt pfSense mit der IP 10.0.9.1 daher.
Wenn ich mich jedoch mit eine Client vom LAN auf die 10.0.9.6 verbinden möchte (FTP), komme ich mit der IP Adresse 192.168.0.X (LAN IP Adresse vom Client daher)...

Also typisch ein NAT Problem... Wie kann ich das lösen? Outbound nat?

Danke.

Hier ein Auszug vom Filezilla FTP Server Log:

Verbindung von pfSense zur Tunnel IP vom Client (10.0.9.6)
(000017)09.10.2014 14:52:46 - (not logged in) (10.0.9.1)> Connected on port 21, sending welcome message...
(000017)09.10.2014 14:53:46 - (not logged in) (10.0.9.1)> 421 Login time exceeded. Closing control connection.
(000017)09.10.2014 14:53:46 - (not logged in) (10.0.9.1)> disconnected.

Verbindung vom LAN-Client zur Tunnel IP vom CLient (10.0.9.6):
(000018)09.10.2014 14:57:13 - (not logged in) (192.168.0.62)> Connected on port 21, sending welcome message...
(000018)09.10.2014 14:57:13 - (not logged in) (192.168.0.62)> 220-FileZilla Server version 0.9.47 beta
(000018)09.10.2014 14:57:13 - (not logged in) (192.168.0.62)> could not send reply, disconnected.
Member: iceget
iceget Oct 10, 2014 at 18:44:35 (UTC)
Goto Top
Zitat von @iceget:

Hi,

jetzt hab ich endlich den Fehler gefunden...


Wenn ich von pfSense (Shell) auf den FTP-Server zugreifen möchte, kommt pfSense mit der IP 10.0.9.1 daher.
Wenn ich mich jedoch mit eine Client vom LAN auf die 10.0.9.6 verbinden möchte (FTP), komme ich mit der IP Adresse
192.168.0.X (LAN IP Adresse vom Client daher)...

Also typisch ein NAT Problem... Wie kann ich das lösen? Outbound nat?

Danke.

Hier ein Auszug vom Filezilla FTP Server Log:

Verbindung von pfSense zur Tunnel IP vom Client (10.0.9.6)
(000017)09.10.2014 14:52:46 - (not logged in) (10.0.9.1)> Connected on port 21, sending welcome message...
(000017)09.10.2014 14:53:46 - (not logged in) (10.0.9.1)> 421 Login time exceeded. Closing control connection.
(000017)09.10.2014 14:53:46 - (not logged in) (10.0.9.1)> disconnected.

Verbindung vom LAN-Client zur Tunnel IP vom CLient (10.0.9.6):
(000018)09.10.2014 14:57:13 - (not logged in) (192.168.0.62)> Connected on port 21, sending welcome message...
(000018)09.10.2014 14:57:13 - (not logged in) (192.168.0.62)> 220-FileZilla Server version 0.9.47 beta
(000018)09.10.2014 14:57:13 - (not logged in) (192.168.0.62)> could not send reply, disconnected.

So problem gefunden...

Die Route die am 192.168.0.254 gesetzt wurde (10.0.9.0/24 -> 192.168.0.250) hat (warum auch immer) den TCP (sequence number) geändert.
Somit hat der Remote Client ein "reset package" zurück gesendet (da er mit der falschen sequence number nichts anfangen konnte.)

Route statisch am Client im LAN gesetzt, perfekt. Alle probleme gelöst..

Anmerkung: der ICMP (Ping) hat funktioniert weil dieser keine 3-Fach-TCP-ACK, ACKs... benötigt.

Lg
Member: aqui
aqui Oct 20, 2014 at 17:46:16 (UTC)
Goto Top
Die Route die am 192.168.0.254 gesetzt wurde (10.0.9.0/24 -> 192.168.0.250) hat (warum auch immer) den TCP (sequence number) geändert.
Sorry aber das ist technischer Unsinn wie jeder netzwerker weiss ! Kann niemals sein und darf natürlich auch nicht. Das muss etwas anderes gewesen sein !
Routen soll auch niemals der Client sondern IMMER der Router, deshalb heisst er ja auch so.
Da ist bei dir also immer noch irgendwo ein Wurm versteckt. aber wenns mit dem übelne Workaround so geht ist ja erstmal gut....lassen solltest du es nicht so und rausfinden wo der wirkliche Fehler ist !!