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!

Nein, dem VPN Interface ist kein Netzwerk zuzuordnen. Einfach die VPN Instanz auswählen, Add klicken, das neue Interface öffnen, aktivieren und eine vernünftigen Namen geben. Keine IP, weder für einen Server noch für einen Client! Wie gesagt, gesonderte VPN Interfaces sind nur für spezielles Routing in die VPN erforderlich. Ja, wenn du einer VPN-Instanz ein Interface zuweist, kannst du die Regeln, sowohl auf der Interface-Gruppe als auch am spezifischen Interface setzen. Einer der beiden Regelsätze erhält wohl den Vorzug. D.h. trifft eine Regel daraus auf ein Paket zu, werden die übrigen Regeln, also auch der gesamte andere Regelsatz, ignoriert. Welche den Vorzug erhält, weiß ich jetzt aber nicht, ich verwende nicht beides. Lässt sich aber bestimmt in der Doc nachlesen. Wenn du die Regeln so setzt, dass ohnehin nicht Regeln aus beiden Regelsätzen zutreffen können, erübrigt sich diese Frage.

Alles schon ausprobiert..Wenn der PC startet blinken die Ports der Karte nur kurz auf.

Hallo, ich kenne das Regelwerk sonst nur von LANCOM. pfSense ist da ja wirklich näher an der Technik/Logic. Danke für eure Hilfe!

Danke für die Hilfe, ich mache das ganze nur per VLAN.

Installiere dein WLAN Equipment ordentlich, dann hast du mehr davon! Zu behaupten, dass es völlig egal ist, wie du den AP anbaust, ohne Kenntnis der Örtlichkeiten ist schon mutig! Der UPA-AC-Lite ist ein 2x2 Gerät mit 20dBm bei 2,4 und 5GHz und 3dBi Antennen Der UPA-AC-LR ist ein 3x3 mit 24dBm bei 2,4GHz und 3dBi Antenne bzw. 2x2 mit 22dBm und 6dBi bei 5GHz Der UAP-AC ist ein 3x3 mit 23dBm bei 2,4GHz und 5dBi Antenne bzw. 3x3 mit 23dBm und 5dBi bei 5GHz Der UAP-AC-Pro ist ein 3x3 mit 22dBm bei 2,4GHz und 3dBi antenne bzw. 3x3 mit 22dBm und 6dBi bei 5GHz Die Geräte unterscheiden sich für dich bei Einhaltung der Norm also in den möglichen Streams und den Antennengewinnen sowie in der Leistung im 5GHz Band (bis 1000mW statt 100mW). Die Antennen wirken sich im Winkel der abgestrahlten Leistung aus, ebenso die Empfangsrichtung. Hier kannst du also den Nachbarn einfangen oder eher nicht. 6dBi mehr oder weniger bedeuten bei dir vielleicht Empfang oder auch nicht mehr. Plane vorher! Zum E-Smog: benutzt du ein Handy am Ohr? Da sind bis zu 2Watt erlaubt… Zur Nat Geschicht. Ich habe hier in meinem Netz sogar dreimal NAT hintereinander. Ist so gewachsen und funktioniert tadellos (ohne SIP, mit Skype, ohne IPTV). Schön ist es trotzdem nicht und ich hoffe es eitert bald raus! Grüße pfadmin

Der WAN Part.

Diese Frage kannst du schon selbst klären. Du hast RFC 1918 Adressen am WAN geblockt. Fällt deine WAN IP da rein?? Das könnte die Ursache für dein Problem sein. Ansonsten versichere dich, dass die Server-Firewall nicht die Zugriffe blockt. Du kannst auch Packet Capture vom Diagnostic Menü einsetzen, um zu sehen, welche Pakete an welchem pfSense Interface ankommen und rausgehen.