Hmm, ich habe mit allen VPN Protokollen das selbe Problem. Kann mir jemand Rules für die Freischaltung des LAN Zugriffes mitteilen? Solangsam blick ich wirklich nicht mehr durch :-(. Welche Rules bauch ich wo für L2TP, IPSec und Open VPN?

22%? Go Go Go  8)

@viragomann: @Shadow27374: ich kann eine Verbindung zum OpenVPN Server herstellen, die Rechner anpingen, auf das Intranet über Port 80 und 443 zugreifen und den Exchange nutzen. bist du sicher, dass diese Verbindungen über VPN laufen? Verwendest du die interne IP, um auf diese Services zuzugreifen? Ja, ich habe es auch per Android probiert und auch von zu Hause aus. Sobald die Verbindung steht, kann ich jeden Rechner anpingen und manche Dienste wie Intranet und Exchange nutzen. @viragomann: @Shadow27374: Als Distribution für OpenVPN verwende ich pfSense, bzw. ich nutze pfSense als OpenVPN Gateway. Das klingt, als würde diese pfSense nicht das Standardgateway im LAN sein. Das ist richtig, die pfSense läuft imselben Netz unter 192.168.67.248. Der Standard-Gateway ist ein TP-Link mit openWRT. @viragomann: Wenn dem so ist und die pfSense ist Teil des LANs, benötigst du auf allen Geräten, die du via VPN erreichen möchtest eine Route für das Tunnel Subnetz, die auf die pfSense zeigt. Am Wochenende habe ich nochmal alles mögliche ausprobiert, ich konnte mich sogar auf einen SSH-Server und einen alten XP-Client per RDP verbinden. Wenn etwas mit den Routen nicht stimmt, dürfte das ja auch nicht gehen. @viragomann: Alternativ kannst du auf der pfSense eine SNAT-Regel einrichten, um die Qelladressen der VPN-Pakete auf die des pfSense LAN IP umzusetzen. Bessere Lösung, du schließt die pfSense an deinen Router (Standardgateway) an ein eigenes Subnetz an, wenn der das erlaubt, und erstellst auf diesem die statische Route. Wenn nicht, mach die pfSense zu deinem Router und Gateway ins Internet. Muss ich mir alles noch mal sehr genau ansehen, bin da noch nicht fit genug.

Vielen dank für eure Unterstützung. Ich hatte den Reiter für OPT1 garnicht. Der Fehler lag im Detail. Die IP für mein OPT1 Interface hatte ich falsch gesetzt. 192.168.1.1/32 geht natürlich nicht :)) auf /24 gesetzt… alles OK

Sorry, das "dein" war im Sinn: "Dein Posting" zu verstehen. Es ist mir klar, dass das nicht dein Video war. :) Ich sage nur, dass der Vergleich vielleicht nicht ganz fair ist zwischen einer konkret ausgearbeiteten Präsentation mit Folien und einer "Live Demo". Und nachdem ich für einige Kunden jetzt auch pfSense Service spezifische Schulungen gemacht habe (kürzlich OpenVPN) kann ich da nur beipflichten: bei der Vorbereitung geht wirklich massig Zeit in Recherche und Zusammenstellung drauf um allein die Redepunkte und Inhalte dazu zusammenzutragen.

Mit Zielhost meinte ich das Gerät hinter der pfSense. Das, welches du vom VPN-Client aus erreichen möchtest. Als Client hätte ich eben letzteren verstanden. An den OpenVPN Einstellungen kann es meiner Meinung nicht liegen. Das Routing vom Client ins LAN auf der anderen Seite des Tunnel funktioniert ja. Mehr ist bei diesem Problem auf einem Access Server nicht relevant. Das Packet Capture am OpenVPN Interface zeigt, wie du auch festgestellt hast, nur Antworten der pfSense selbst, während du auch andere Geräte im LAN pingst. Der VPNrechner pingt, PFsense antwortet brav. Aber keine Spur von den Pings zu den anderen Rechnern!? Wenn du das untersuchen möchtest, mach ein Capture am LAN-Interface (ohne Details). Das zeigt, ob die Pakete überhaupt an der pfSense ankommen. Ich vermute mal, nein. Am WAN pingt die pfSense das eingestellte Gateway (dpinger), allerdings sollten da schon Antworten von der FB kommen, ansonsten wird das GW als offline angezeigt. Auch interessant wäre die Routingtabelle (route, route print) vom Zielhost und ggf. ein TCP Dump an dessen Schnittstelle.

Danke Ich Teste mal deine konf. mal schauen ob was läuft mit Windows Update  ;)

Nein, nein, so leicht lässt sich die pfSense nicht täuschen. Die Verbindung geht ja tatsächlich von einem Host in 10.1.1.0/24 nach 10.1.2.2 und die Pakete kommen in diesem Fall am LAN1 Interface rein. Daher muss auf LAN1 eine entsprechende Regel den Zugriff erlauben. Ein Portforward-Regel kann die Firewall-Regel automatisch anlegen, entweder sichtbar oder unsichtbar. Ein Tipp für ein kleine Erleichterung dazu: Wenn du bei "Filter rule association" "Add unassociated filter rule" wählst, wird eine von der NAT-Regel unabhängige Firewall-Regel am jeweiligen Interface erstellt. Diese kannst du dann in Firewall > Rules > WAN kopieren (Symbol rechts), danach editieren und das Interface auf LAN1 und die Source entsprechend ändern, damit sie für deine Zwecke pass.

Besten Dank euch beiden!  8)

Oh sorry, ich meinte natürlich den Fehler im ersten Post. Das andere ist dann ein fehlendes Zertifikat beim Client - zumindest wird keins vorgelegt aber erwartet.

Hallo astartusfi, zuerst einmal: das wird sehr wahrscheinlich nicht funktionieren. Google Authenticator nutzt TOTP als Verfahren, Radius o.ä. mit OpenVPN verwendet aber M-OTP als Verfahren für Einmalpasswörter. Du bräuchtest also eine andere App dafür bzw. einen anderen Generator. Zum anderen: jedoch ist mir Zertifikat-und-Benutzername/Passwort zu wenig Sicherheit Das überrascht mich dann doch, denn wieviel Sicherheit möchtest du denn bei einer VPN Einwahl noch!? Du hast mit der maximalen Stufe von OpenVPN unter pfSense ja bereits 3(!) Faktoren (nicht nur 2) die alle getrennt voneinander gegeben sein müssen: Session Key User + Passwort Zertifikat des Users (sinnvollerweise mit CN=username matching) Alle 3 Faktoren müssen vorhanden sein, um die Einwahl vorzunehmen. Und selbst dann - sollte jemand aus doofen Gründen komplett das gesamte Paket verlieren - ist es noch möglich, problemlos das Zertifikat per CRL zurückzuziehen und den User zu disablen (im Radius). Da frage ich mich schon, wieviel Sicherheit du noch erkaufen möchtest mit wieviel zusätzlichen Faktoren? Denn wenn du davon ausgehst, dass alle einzelnen Daten wie Konfiguration, TLS Key, Zertifikat, Username + Passwort jemand anderem in die Hände fallen können, was hält den dann davon ab, dein OTP zu klauen (sprich die App oder die Einstellungen)? Grüße

Hi, zumindest ich sehe in Deinem Post kein verstoß (was nichts heißen muss) Da ich relativ frisch bei der Thematik bin, wurde ich meine Aussagen vielleicht nicht auf die Goldwaage legen Du schreibst - die Hardware liegt rum. Von daher wurde ich die erst mal einfach nehmen und schauen was passiert. Sollte es "eng" werden, wirst Du was anderes besorgen müssen. Ich wurde behaupten, dass die Hardware sich langweilen wird. Und zwar (man möge mich korrigieren wenn ich Mist erzähle/ denke) auf Grund der "dünnen" Leitung. Nut weil es 5x VPN aufgebaut wird, wird sie nicht dicker und damit hat die Hardware "weniger" zu Ver/Entschlüsseln Was die Netzkarten angeht - bin ich raus (stehen die in der FreeBSD HW Liste nicht drin?) Tobi

Moin, da steht "is not a valid IP address or alias". Trage deine Adresse als Alias ein und diesen Alias dann in die Rule. Gruß pfadmin

Gerne, auch wenn es in dem Fall natürlich nicht das ist was du hören wolltest :)

Hallo Chris, vielen Dank für deine offene, erhliche (und ganz wichtig) freundliche Antwort. Mein Problem konnte ich lösen. Dank Dir. :) –nur für die Richtigkeit-- Wie? Zurück auf Anfang! - Was manchmal nicht ganz einfach ist! Ich habe diverse Wiki und Foren zur Begriffserklärung und Grundwissen besucht. Somit war das eine oder andere schon viel klarer. Dann noch ein Schritt zurück vom Tisch... (Box mit Kabeln) und schon war es fast logisch. Anschliesend habe ich die pfSense resetet bzw neu aufgespielt und (mit meinem neu erlerntem Wissen) neu konfiguriert. Jetzt läuft (fast) alles so wie es soll. Multi-WAN CaptivePortal FBOX mit VOIP VPN mit FBOXen (IPsec) der betrieb einer RED hinter der pfSense Webserver u.v.m. für das "fast"  finde ich  hier im Forum sicher eine Lösung. Somit Danke schonmal an alle Problemlöser. Besten Dank auch an das "Übersetzer-TEAM" Viele Grüße Henry

Link ist zurück und funktioniert: https://www.netgate.com/blog/pfsense-software-translations-with-zanata.html

Danke JeGr! Das war der entscheidende Punkt. ein "ps -auxww" ergab: USER  PID  %CPU  %MEM  VSZ  RSS  TT  STAT  STARTED  TIME  COMMAND […] nobody  36263  0.0  0.1  30188  4224  -  I    Wed07PM    0:00.03 /usr/local/sbin/dnsmasq –all-servers -C /dev/null --rebind-localhost-ok --stop-dns-rebind --port=80 --listen-address=192.168.2.1 --dns-forward-max=5000 --cache-size=10000 --local-ttl=1 […] kill 36263 Neustart -> webcmd - funktioniert wieder :-) Scheinbar waren meine Einstellungen im "DNS Forwarder" nicht ganz korrekt. Jetzt habe ich den Host Override mit dem "DNS Resolver" gelöst und alles läuft problemlos. Vielen Dank für eure Unterstützung!  8)

Super, danke für die Rückmeldung!