OpenVPN über pfSense erreicht LAN nicht
-
Es wurde auch eine Route auf dem Windows Rechner angelegt, die über das Gateway 10.0.8.5 in das 192.168.42er Netz rüber gehen soll. Nur existiert eben dieses Gateway nicht.
Wie kommst du auf diesen Schluss?
Ist die pfSense in deinem 192.168.42.0/24 Netz nicht das Standard-Gateway?
-
Lieber flix87,
folgende Firewall Regeln gibt es auf dem OpenVPN Tab:
ID Proto Source Port Destination Port Gateway Queue Schedule Description
IPv4 * * * * * * * none OpenVPNDiese wurde automatisch angelegt. Habe OpenVPN über den Wizard eingerichtet.
Lieber viragomann,
über route print auf dem Windows Rechner sehe ich die Route:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle
192.168.42.0 255.255.255.0 10.0.8.5 10.0.8.6Folgendes bekomme ich bei ipconfig /all:
Ipv4-Adresse: 10.0.8.6
Subnetzmaske: 255.255.255.252
Standardgateway:
DHCP-Server: 10.0.8.5Folgendes ergibt ein Ping auf die 10.0.8.5:
Ping wird ausgeführt für 10.0.8.5 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.Ich folgere daraus, dass das Gateway, was in der Route angegeben ist, nämlich die 10.0.8.5 einfach nicht existiert, ist auf jeden Fall nicht pingbar.
Momentan ist die pfSense noch nicht das Standard- Gateway im 192.168.42.0er Netz, da es noch eine aktive Firewall gibt, die abgelöst werden soll.
-
Momentan ist die pfSense noch nicht das Standard- Gateway im 192.168.42.0er Netz, da es noch eine aktive Firewall gibt, die abgelöst werden soll.
Wenn pfSense nicht das Standard-Gateway ist, kann das nicht ohne etwas Mehrarbeit funktionieren. Denn dahin werden die Antwort-Pakete der Hosts geschickt, wenn sie die Ziel-IP nicht kennen, und das tun sie wohl nicht, das ist die VPN-Client-IP.
Du benötigst auf deinen angepeilten Hosts entweder eine Route zum VPN-Tunnel über die LAN IP der pfSense, oder einfacher, auf der pfSense eine Outbound NAT Regel für den Traffic aus dem VPN- und Richtung LAN-Netz.
Das sieht so aus: Gehe auf Firewall > NAT > Outbound und füge da eine Regel hinzu:
Interface: LAN
Source: 10.0.8.0/24 (der VPN-Tunnel)
Translation IP: Interface IPDiese Regel transferiert dir die Quell-IP der Pakete aus der VPN auf die LAN Adresse der pfSense und diese kennen deine LAN-Hosts und antworten wieder dahin. pfSense transferiert die IP dann wieder zurück auf die Client IP.
Wenn später die pfSense das Standard-Gateway wird, kannst du (musst nicht) diese Regel wieder entfernen, damit du an den Ziel-Hosts die Client-IP siehst.
Grüße
-
Ich folgere daraus, dass das Gateway, was in der Route angegeben ist, nämlich die 10.0.8.5 einfach nicht existiert, ist auf jeden Fall nicht pingbar.
Doch das gibt es ;) das muss du uns schon glaube. wenn du das so eingerichtet hast wie du sagst wird für jeden der sich einwählt so ein kleines Netz erzeugt wo eben nur du dein Gateway und sonst nix drin ist.
Das mit den Routen stimmt auch.Anpingen kannst du das tatsächlich nicht. Aber versuch es mal mit der 10.0.8.1 die sollte gehen. Das ist in der Regel der OpenVPN Server.
Beim Rest kann ich viragomann nur zustimmen die Clients kennen den Rückweg einfach nicht. Solche infos sind immer wichtig für so etwas sonst geht man davon aus das die PfSense schon das Defaultgateway ist. :)
Das mit dem Gateway ist einfach so wie OpenVPN das eben löst. Die Wege des OpenVPN sind eben unergründlich aber es geht :)
-
Ich habe jetzt eine Outbound NAT Regel angelegt und habe zusätzlich mal bei einem Client die pfSense als Default- Gateway angelegt. Ich kann den Client nicht pingen und auch sonst nicht erreichen (ist eine Windows- Büchse).
Ich kann auch nicht die 10.0.8.1 pingen.
Das ist doch jetzt zum verrückt werden.
Ich glaube ich mache mal folgendes: ich packe Montag einen Rechner in mein zweites Netzwerk, das schon die pfsense als Default Gateway hat, schmeiße die ganze OpenVPN Config nochmal weg und versuche dann in dieses Netz zu kommen. Dann müsste der Rechner ja zu erreichen sein, oder?
-
Ich habe jetzt eine Outbound NAT Regel angelegt und habe zusätzlich mal bei einem Client die pfSense als Default- Gateway angelegt. Ich kann den Client nicht pingen und auch sonst nicht erreichen (ist eine Windows- Büchse).
Mit dem ersten Client meinst du einen LAN-Host im 192.168.42.0/24 Netz und mit dem zweiten Client den VPN Client? Bitte klarer ausdrücken.
Im Outbound NAT hast du den Modus auf "Hybrid Outbound NAT rule generation" oder "Manual Outbound NAT rule generation" gestellt? In der NAT Regel hast du das LAN Interface gewählt?Wenn das Outbound NAT nicht richtig eingestellt ist, hilft der auf der Windows Kiste das gesetzte Standardgateway auch nicht, wenn die Windows Firewall aktiv ist. Diese unterbindet Pings aus einem anderen Netzwerk. Ich bin mir gar nicht sicher, ob da ein Deaktivieren hilft, aber man kann die Firewall (viel Spaß) so einstellen, dass sie die Pings akzeptiert und Windows antwortet.
Nachdem die Firewall Regeln vom Wizard gesetzt wurden, sollte sie passen. Aber sicherheitshalber würde ich kontrollieren, dass sie so aussieht wie in der Anleitung.
Ich kann auch nicht die 10.0.8.1 pingen.
Das ist der OpenVPN Server, der muss von überall aus erreichbar sein, wenn es die Firewall-Regeln erlauben, vom VPN-Client wie auch von einem Host im LAN. Letzterer muss natürlich die LAN-IP der pfSense als Standardgateway haben oder eine Route dahin.
Die LAN-Regel erlaubt den Ping?Du könntest Screenshots dieser ganzen Regeln hier posten, damit wir sie überprüfen können.
Ich glaube ich mache mal folgendes: ich packe Montag einen Rechner in mein zweites Netzwerk, das schon die pfsense als Default Gateway hat, schmeiße die ganze OpenVPN Config nochmal weg und versuche dann in dieses Netz zu kommen. Dann müsste der Rechner ja zu erreichen sein, oder?
Wenn das Outbound NAT richtig konfiguriert ist, braucht die pfSense nicht das Standardgateway zu sein. Dann wird die Quell-IP eines Pakets vom VPN-Client beim Verlassen der pfSense auf dem LAN Interface in die LAN-IP transferiert und für die Hosts im LAN kommt es praktisch von der pfSense, und genau dahin schicken sie ihre Antwort. Die pfSense kennt anhand des gespeicherten Zustands die Verbindung und transferiert die Ziel-IP wieder entsprechend zurück.
-
Hallo viragomann,
sorry für das unverständliche Schreiben. Ich habe dir jetzt mal Screenshots gemacht:
Das ist das Outbound NAT:
Das ist die OpenVPN Firewall Regel:
Das ist die LAN Regel:
So und hier noch die Settings vom OpenVPN Tunnel:
Zum pingen (was ich in meinem vorherigen Post schrieb):
Ich hatte einen Client im 192.168.42.0/24 Netz mit pfsense als Default Gateway von meinem Rechner zuhause (der mit dem VPN Client drauf) versucht zu pingen. Da ich dann dachte, vielleicht geht ping nicht, hab ich versucht per Remote- Desktop auf den Client im 192.168.42.0/24 Netz zu kommen (das ist ein Server, der das auch kann), das ging aber auch nicht.
Windows Firewall gibt es in unserem Netzwerk nicht, meine zuhause hatte ich vorrübergehend deaktiviert (ich benutze Comodo).Von einem Rechner im LAN kann ich die 10.0.8.1 anpingen (pfsense ist das Standard- Gateway), von meinem per OpenVPN angemeldeten Rechner daheim nicht. Wenn ich die OpenVPN Firewall Regel richtig deute müsste aber eigentlich alles erlaubt sein.
Vielleicht kannst du auf den Bildern erkennen, was ich falsch gemacht habe.
Wenn du weitere Screenshots brauchst, mache ich gern :-)Vielen Dank und lieben Gruß
Joey -
Hallo,
ich sehe nichts, was den Zugriff auf LAN blockieren könnte.
Die Outbound NAT Regel ist in Ordnung und die OpenVPN Firewall-Regel erlaubt alles über IPv4.
Einzige Ungereimtheit ist die abgeschaltete Kompression in der OpenVPN Konfig. Die Empfehlung hier lautet, diese zu aktivieren (Enabled with Adaptive Copression). Mit deinem Problem wird das aber nicht in Zusammenhang stehen.
Ich habe den Verdacht, dass dein Rechner im Heimnetz hier einen Streich spielen könnte.
Um dem Problem auf den Grund zu gehen, mach mal ein Packet Capture aus dem Diagnostic Menü.Wenn du beispielsweise einen Ping in das 192.168.42.0/24 Netz testest, stelle das Interface auf OpenVPN, Protocol=ICMP und klick unten auf Start. Dann starte den Ping auf deinem VPN-Client. Wenn dieser gelaufen ist, klick auf Stop und sieh dir das Ergebnis an.
Wenn ich mit meiner OpenVPN-IP 10.0.41.6 den Host 192.168.3.212 im LAN pinge sieht das so aus:
13:28:47.341892 IP 10.0.41.6 > 192.168.3.212: ICMP echo request, id 1, seq 219, length 40 13:28:47.342086 IP 192.168.3.212 > 10.0.41.6: ICMP echo reply, id 1, seq 219, length 40 13:28:48.342167 IP 10.0.41.6 > 192.168.3.212: ICMP echo request, id 1, seq 220, length 40 13:28:48.342278 IP 192.168.3.212 > 10.0.41.6: ICMP echo reply, id 1, seq 220, length 40 13:28:49.342484 IP 10.0.41.6 > 192.168.3.212: ICMP echo request, id 1, seq 221, length 40 13:28:49.342631 IP 192.168.3.212 > 10.0.41.6: ICMP echo reply, id 1, seq 221, length 40 13:28:50.342393 IP 10.0.41.6 > 192.168.3.212: ICMP echo request, id 1, seq 222, length 40 13:28:50.342468 IP 192.168.3.212 > 10.0.41.6: ICMP echo reply, id 1, seq 222, length 40
Windows Standard eben 4 Ping hintereinander.
Man sieht also den ICMP request 10.0.41.6 > 192.168.3.212
und dann den reply 192.168.3.212 > 10.0.41.6 auf meine VPN IP zurück.So sollte es auch bei dir aussehen. Wenn du den reply auf deine VPN IP zurück bekommst, ist auf der pfSense alles in Ordnung und die Ursache beim Client zu suchen. Kommt der reply nicht zurück, schalte oben das Interface auf LAN um und mach das selbe nochmal.
Hier müsstest du dann anstatt deiner VPN IP die Interface IP der pfSense im 192.168.42.0/24 Netz sehen.Ggf. poste die Ergebnisse hier.
-
viragomann,
ich danke dir sooooo sehr. Das war meine blöde Comodo Firewall, die das - obwohl sie abgeschaltet war - geblockt hat. Erst als ich sie komplett beendet und nicht nicht deaktiviert hatte, kamen die Pings an.
Vielen, vielen Dank für deine Geduld :-)
Ganz liebe Grüße
Joey -
Freut mich, dass es nun klappt, wie erwartet. Danke für die Rückmeldung.
Übrigens, in meinen Kreisen gilt eine solche "Firewall" wohl nicht zu Unrecht als verpönt. Doch sollte auch diese sich so einstellen lassen, dass der nötige Traffic drüber geht, oder wenn nicht nötig, die Firewall für das OpenVPN-Interface ganz deaktivieren, wenn das überhaupt hilft. ;)
Grüße