Hier mal noch zwei Anleitungen dazu die die ganze Sache besser abhandeln und auch genauer dazu passen. Alles in deutscher Sprache und man kann auch dazu Fragen loswerden. WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion) VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern WLAN Netzwerk: zwei SSIDs anlegen (intern & extern) in zwei VLANs packen WPA2 AES-ccm verwenden Zwei Benutzergruppen anlegen (intern & und extern) Vouchers Lease-Time von "intern" auf never expire und von "extern" 4 - 8 Stunden Klient Isolation aktivieren!!! LAN Netzwerk: VLANs anlegen (Finger weg von VLAN0 und VLAN1 default) eines  und eines extern nennen jeweils ein eigens IP Netz verpassen Am Switch ACLs oder an der pfSense ACLs setzen Am besten eigenen sich dazu UBNT WLAN APs die sind günstig und es gibt einen WLAN Controller (kostenlose Software) dazu damit kann man dann die WLAN APs auch schnell warten und administrieren.

Alle paar Tage "vergisst" PFSense diese Hosts und die Leute können sich nicht registrieren, was mich langsam nervt. Kann das mit der Lease-Time der Vouchers zusammenhängen?

Hallo, wie sieht es denn damit aus zwei SSIDs anzulegen und dann jedes in ein eigenes VLAN zu packen wie zum Beispiel SSID "extern" (Gäste) und SSID intern (Mitarbeiter)? Dann legt man zwei Gruppen an und die einen bekommen eine Zertifikat was nicht abläuft (Mitarbeiter) und die anderen bekommen via Captive Portal ein Voucher auf Ihr Gerät übertragen und können nur das Internet nutzen und nicht auf das interne Netzwerk zugreifen. Den Zugriff auf das Internet kann man mittels Squid & SquidGuard (White- und Blacklists) regeln. Hier noch zwei deutschsprachige Anleitungen zu dem Thema: WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion) Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch

@JeGr: Damit hast du m.E. das Interface auch schon "gelöscht", da es keine Konfiguration mehr haben sollte (sollte in Status/Interfaces nicht zu sehen sein). Genau so ist es, man kann es unter Status/Intarfaces nicht sehen. @JeGr: Es geht nur darum, dass das Interface nicht zusätzlich auch noch untagged benutzt wird. Nein, sowas mache ich nicht, bei mir dient der eine Port als Trunk der den ganzen Switch mit VLANs versorgt.

und falls Probleme anstehen, können wir immer wieder nachfragen und/oder man kommt vorbei. Und man operiert an genau seiner Problemstellung und nicht an theoretischen Problemen, die evtl. gar nicht relevant für das Setup sind. Aber dann hat man wenigstens Leute vor Ort und die man auch kennt. Und die dein Setup kennen. Ganz genau :)

Danke für Deinen Tipp! Cryptographic Hardware war bereits aus 'none'. Mir ist noch folgender Log-Eintrag aufgefallen: Jul 23 08:28:59 php-fpm[53850]: /vpn_ipsec_settings.php: The command '/usr/local/sbin/ipsec stroke loglevel mgr 4' returned exit code '255', the output was 'connecting to 'unix:///var/run/charon.ctl' failed: No such file or directory failed to connect to stroke socket 'unix:///var/run/charon.ctl'' Jul 23 08:28:59 php-fpm[53850]: /vpn_ipsec_settings.php: The command '/usr/local/sbin/ipsec stroke loglevel dmn 4' returned exit code '255', the output was 'connecting to 'unix:///var/run/charon.ctl' failed: No such file or directory failed to connect to stroke socket 'unix:///var/run/charon.ctl'' … und im IPsec Log: Jul 23 08:29:33 charon: 00[CFG] opening triplet file /var/etc/ipsec/ipsec.d/triplets.dat failed: No such file or directory Das File 'triples.dat' finde ich auf der gazen pfSense nicht. Vielleicht ist das ein Ansatzpunkt. Jedenfalls vielen Danke für Deine Mühe. LG Thomas

Also, es ist so: ich erlaube und möchte Mails erhalten. Aber definitiv möchte ich keine Mails von bestimmte Länder/Regionen, wie zB Indien, Korea, Japan, etc. Und woher nimmst du die konkrete genaue Angabe, dass du absolut keine Mails von dort bekommen willst? Woher weißt du, dass bspw. durch einen lokalen/kontinentalen Ausfall eines Dienstes dieser über eine andere Geolokation sendet? Das ist ja unter anderem der Sinn von Internet und seinem Routing. Dass der Weg nicht vorgegeben ist. Und das gilt hier auch bei Mails, einem der ältesten Protokolle. Wenn jetzt - bspw. - Windows Live Mail Western Europe ausfällt und die dann - um möglichst geografisch nahe zu bleiben - die Mails via Ost Europa senden, du aber bspw. die Länder geblockt hast? Gibts keine Mail. Obwohl du die vielleicht haben möchtest. Das war meine Aussage. Man kann eben bei Diensten, die man "anbietet" - und da gehört indirekt dann der eigene Mailserver dazu - nur mit Abstichen solche krassen Aussagen treffen. Vor allem wird es dann bei Fehlersuche lustig, warum Mail x nicht lief und nach viel Debugging kommt dann raus - ups Land geblockt. Aber gut, dass musst du wissen, ob du das möchtest. Also dachte ich mir, pfBlockerNG hilft mir die Länder ausfindig zu machen, um dort alles zu blockieren, was reinkommt. Ich habe nicht behauptet, dass es das falsche Tool für Geo-Blocking ist. Ich habe nur in Frage gestellt, ob es für Mails das Richtige ist. Wie würdest du das machen? Frei nach der Aussage "Don't be a mail-nazi" im Mailserver. Wo es eigentlich hingehört, auch weil man dann beim Debugging die Firewall oder Routing außen vor hat. Hängt aber davon ab wie stark man beschränken will, kann, warum und in welchem Ausmaß etc. Wenn du aber unbedingt bspw. mit pfB arbeiten willst, kannst du auch für die Länder, die du nicht möchtest, Alias Listen erstellen und diese dann in deiner Allow Regel mit ! (NOT) Indikator als Quelle angeben. Dann erreichst du das, was du willst, aber wesentlich einfacher zu managen. Gruß

Ahoi Spezi, eine Variante wäre noch mit Unbound zu debuggen, ob der Request von checkip.dyndns.org lokal abläuft (also gegen Unbound oder DNSMasq) und diesen ggf. einfach umzuschreiben auf einen eigenen Service. Ein eigener Service mit gleicher Ausgabe ist ja nicht schwierig zu bauen. Ausgabe ist ja nur ein Einzeler: Current IP Address: a.b.c.d Das kann man sich auch leicht selbst auf den eigenen Webspace werfen so man einen hat. DynDNS selbst nutzt ja 3 verschiedene (checkip.dyndns.org, checkip.dyndns.com, checkip.dyn.com). Damit hätte man zumindest keine Arbeit im Code zu fixen oder dort etwas zu ändern. Besser wäre natürlich, wenn man ggf. unter Experteneinstellungen selbst den Server ändern könnte. Aber mit DNS Rewrite sollte es auch laufen. Das ändert natürlich am Grundproblem wenig, denn die Box bekommt eben nichts mit, dass sich die IP geändert hat. Aber wie soll sie auch. Gruß Jens

Naja, leider habe ich keine Anleitung parat. Schon deswegen nicht, weil ich auch mit den "Floating Rules" ein Problem habe; siehe hier. Also habe ich das hier gepostet, in der Hoffnung jemand liest hier mit, und hat eine Idee, wie man das lösen könnte. Danke

War das also ein Bug beim Hersteller? Auf jeden Fall war es nicht pfSense. Das ist beruhigend, denn die Aufregung war nicht gering! Das kann ich mangels Glaskugel nicht sagen ;) Ich habe nach deiner Beschreibung nicht mal verstanden, wo die Mailserver laufen, wohin die schicken wollen etc. Und was für Bug beim Hersteller? Welcher Hersteller? Ich bin fürstlich verwirrt, was du eigentlich sagen möchtest :)

Ach so ist das, na das wusste ich doch nicht. Klar da muss dann wohl etwas anderes her halten.

@rubinho: Wenn Bedarf ist, kann ich den Auszug aus der Mail besorgen. Klar, gern! Ist schon wieder Jahre her, dass ich mit Pascal telefoniert und gemailt habe. Ich erinnere mich dabei an folgende Aussage zu den APUs, als sie noch gar nicht am Markt waren (Mitte 2013): Siehe www.pcengines.ch/apu.htm . Firmware ist inzwischen weitgehend ok, Kühlung ist noch etwas knapp. Generell werden die Geräte bei 20°C Zimmertemperatur "gerade ausreichend" gekühlt und haben keinen besonders großen Spielraum. Steigt die Umgebungstemperatur auf 30°C, dann sind sie vom roten Bereich nicht weit entfernt.

D'oh! Jetzt läuft der DHCP Server wieder. Danke!! Ich hatte wohl mit dem Subnet ein bisschen rumgespielt und vergessen, den ursprünglichen Wert zurück zu setzen.

Ich hatte jetzt mit der v2.2.3 dreimal das Problem, dass sämtliche eingehnede VPN-Verbindungen (ausser die Verbindungen, wo meine Pfesense der Client ist), sowohl IPSec als auch Openvpn, unterbrochen wurden und nicht wieder verbunden werden konnten, bis ich das WAN-Interface einmal Down und wieder Up gefahren habe. Möglicherweise sind andere eingehende Dienste (Voip) auch nicht mehr glaufen, habe sie aber nicht überprüft In dem Moment hatte ich auch unrealistische Antwortzeiten an den Gateways (0 ms), die aber Online angezeigt wurden. Zweimal hatte ich das Problem, nachdem ich die WAN-Verbindung (32Mbit KabelDeutschland) über einen gewissen Zeitraum komplett ausgelastet hatte, beim dritten Mal war der Internet-Anschluss kurzzeitig gestört. Irgendwie hab ich bei den Problemen den Apinger in Verdacht. Der verfolgt mich schon seit v2.1 und verursacht an meinem KDG Anschluss mehr Probleme als alles andere. Dazu kommt das Problem, das die States ja nicht richtig beendet werden, wenn es Probleme mit einen WAN-Anschluss gibt. Das mag aber ein Problem mit Multi-Wan zu sein (Vermutung) PS. Ich habe 3 IPSec Tunnel zu Fritzboxen (Unterschiedliche Versionen 7270, 7390, 7490) aufgebaut und laufen bis auf das oben genannte Problem ohen Probleme. (Kurios)

Mit dd-wrt bin ich leider nicht vertraut. Aber du schickst mit dieser Route den gesamten Traffic über die VPN. Ist das so gewollt? Wie auch immer, lass die Route weg und versuch meinen Vorschlag mit dem Outbound NAT auf der pfSense. Funktioniert aber nur, wenn der dd-wrt das Default Gateway für den Server ist, was vermutlich der Fall ist. Denn dann schickt er die Pakete zum Router und wenn der die VPN aufgebaut hat, schickt er sie dahin weiter. Wenn nicht, schickt er sie ins WAN, wo sie beim ISP verworfen werden (sollten). Das ist ohnehin die bessere Lösung, wenn du wirklich, wie du anfangs geschrieben hast, mehrere Router hast, die eine VPN-Verbindung zur pfSense aufbauen.

Hallo, also wenn ich das recht verstehe, die VPN-Sitzung steht? Hier widerspricht sich aber was: @blixz: Nun ist das Problem das ich während der VPN Sitzung nicht auf unseren internen Webserver zugreifen kann, ping und dns Auflösung funktionieren auch. Oder fehlt da ein "nicht" am Schluss? Wenn die Sitzung steht und du kannst das VPN-Gateway pingen, fehlt meist die Route ins Netz, das du über die VPN erreichten möchtest. Dieses muss in der OpenVPN Server-Konfiguration bei "IPv4 Local Network/s" oder eben "IPv6 Local Network/s" eingetragen sein, damit der Client die Route gepusht bekommt. Das Netz darf natürlich nicht das gleiche sein wie das, in dem sich der Client befindet, sonst wird's nix mit der Verbindung. In deinem Fall, wo die Hosts vermutlich den ISP-Router als Default Gateway verwenden, brauchst du noch entweder eine Route zum VPN-Gateway, oder einfacher, du richtest auf der pfSense eine Outbound NAT-Regel für den VPN-Traffic ein: Interface: LAN (oder wo immer die Hosts dranhängen, die erreicht werden sollen) Source: OpenVPN Tunnel-Netzwerk Translation: LAN address Eine beliebige Beschreibung noch dazu, alles andere kann auf Default bleiben. Wenn das nicht hilft, beschreibe einmal detaillierte, was genau nicht funktioniert. "Kann nicht auf unsere internen Webserver zugreifen" lässt viel Spielraum. Über HTTP(S), RDP, SMB,…?

Hi, Wie unterbinde ich die WebRTC requests vom OpenVPN Client? ..in dem Du die Ursache der Requests beseitigst, Windows.. ;) Lies mal das dazu, ist auch noch eine weitere Seite verlinkt… https://www.perfect-privacy.com/german/webrtc-leaktest/ Gruß orcape

Hallo gsm, hast du hierzu explizit die Anti-Blockout Regel unter Advanced abgeschaltet? Ansonsten ist es eigentlich auf LAN Seite nicht möglich sich auszusperren? Für den Fall, dass dem so ist: du kannst auf der Konsole mit "8" auf die Shell und dort pfctl -d absetzen. Das schaltet vorübergehend SÄMTLICHES FILTERN ab. Also auch NAT. Sobald du in der Oberfläche eine Regel änderst wird das aber sofort wieder eingeschaltet, da ein neues Ruleset geladen wird. Grüße

Servus miteinander, das Thema ist noch aktuell. Ich bin nur leider völlig überlastet und komme nicht dazu. Danke der Nachfrage  :)

Ich habe alle IPs noch einmal neu vergeben. Nun nimmt der C7 die APU als Gateway an. Bis auf den Freifunk-Router (der komischerweise nun gar keine SSID mehr sendet, aber das wird morgen angegangen) funktioniert nun alles :) Sobald alle Geräte, die insgesamt ins Netzwerk gehören einmal connected waren, kann ich die Mac-Adressen-Einschränkungen vornehmen und alles weitere konfigurieren. Vielen Dank für die schnelle Hilfe :)