@peer_g: Nee. da tuts auch eine dicke Fritzbox. Nur zur Vollständigkeit, weil hier wahrscheinlich nicht nötig: Wenn man nur "alte" (keine IP) Telefone hat, tuts auch eine uralte FB. Ich mache das mit einer 5050 und zwei analogen Telefonen. -flo-

Hi Chris, ist mal nur als Denkanstoß gedacht und muss nicht zwingend nachgemacht werden. Bei mir läuft eine 7490 in vorderster Front am DSL. Fritte LAN      192.168.219.0/24 DHCP LAN-Abgang zum pfSense-WAN erhält immer die gleiche IP 192.168.219.2 . USB-Drucker an der Fritte. TV, Android-Handy und Gäste-LAN pfSense (auf ALIX-Board) WAN      192.168.219.2 LAN        192.168.159.0/24  DMZ      172.16.10.0/24 WLAN    192.168.89.0/24 Also keine Verbindung aus dem ersten Netz, Gäste, Handy auf die LAN-Geräte. Für DMZ ein Portforwarding. Ausserdem laufen da noch OpenVPN-Server auf der pf. (Portforwarding auf der Fritte. Gruß orcape

Hallo JeGr, super Tipp - das war's. Vielen Dank. Das Nat stand plötzlich auf "Manual" - richtig wäre "Hybrid Outbound NAT rule generation". Jetzt klappt's wieder :-) Gruß Thorsten

Jepp, alles zu, alles verboten. Alles andere wäre für ein Gerät das Sicherheit verspricht wohl Unsinn

zu den NIC meine Fritzbox geht einmal auf einen Switch einmal Server und vom Switch geht es auch auf den Server Ist klar ist nicht wirklich redundant und ich kann es auch trennen. …nun, so richtig gibt das für mich keinen Sinn. 2 WAN-NIC´s am Server (pfSense) die wie auch immer im LAN der Fritte hängen. VLAN´s mit gleicher Netzwerkadresse wie das LAN der Fritte... 10.147.42.0/? …fehlt eigentlich nur noch die Netzmaske 255.0.0.0, um das Kraut fett zu machen. Sorry, ich glaube Du solltest Dich noch mal eingehend mit den Grundlagen auseinandersetzen und die Netzstruktur überarbeiten. Ich habe bei mir eine ähnliche Struktur, allerdings ohne VLAN´s. Versuche die Netze ordentlich zu trennen (gibt genügend private IP´s), das hilft dann auch bei der Fehlersuche. Switch im Fritten-LAN wenn nötig, Ok. Von da eine 2. Verbindung zur pfSense-WAN ???? Richte Dir auf dieser NIC lieber eine Demilitarisierte-Zone für Dein NAS ein, das wäre sinnvoller. Gruß orcape

Der Fall ist gelöst!  :) Habe das die Einstellung auf der alten FB mit dem Handy geändert. Die FB hat wohl die Änderung nicht übernommen, weil ich in der Eile nicht oder nicht richtig auf ÜBERNEHMEN geklickt habe. Jetzt geht alles. Nun mach ich mich an die Regeln. Vielen Dank für den genialen Denkanstoß Gruß Chris

Hallo! D.h. du kommst jetzt gar nicht mehr auf die GUI? Der beste Weg ist dann, die Netzwerkkonfig des LAN Interface nochmals in der Konsole zu durchlaufen. Am Ende wird dann der URL zum WebConfigurator samt Port, falls vom Protokollstandard abweichend, angezeigt. Mit dem solltest du auch hinkommen. Grüße

Hallo zusammen, vielen Dank für eure Antworten! Das mit dem Alias ist wesentlich einfacher, danke dafür. Habe nun Pass src VLAN20 dest ! VLAN100etc. und damit bleiben ja dns und ntp dienste erhalten, da die dienste auf jedem subnetz laufen. Und die Top rule funktioniert wunderbar, danke! (Musste aber natürlich auf Port 443 schalten da https) Ist damit gelöst. Viele Grüße und schönes Wochenende !!

Aaaarrrg. Fehler gefunden. Pfsense hatte keine Schuld. Und openVPN auch nicht. Die Lösung: Auf dem Fileserver (Samba) fehlte der Eintrag, das auch andere Netze zugelassen sind. /etc/samba/smb.conf hosts allow = 127.0.0.1 10.20.33.0/255.255.255.0 192.168.100.0/255.255.255.0                                       ~~~~~~~~~~~~~~~~~~~ Aufgeflogen ist der Mist, weil eine testweise eingerichtete Freigabe auf einem Windows7 ootb lief. Damit war klar, das es am Samba liegen musste. – Rüdiger

Zwar nicht mit einem Alix board aber mit einer PfSense der Version 1.2.3 konnte man auf die Version 2.2 Springen. Hatten ein Backup eine Konfig da und haben die Version 2.2 frisch installiert und dann das Backup eingespielt. Sieht so weit gut aus. In Live konnten wir es aber noch nicht testen.

Mit der Version 2.2 scheint es viel besser zu laufen. Änderungen an den WLAN-Einstellungen führen nicht mehr zum Tod der Verbindung. Das Script ist daher vermutlich auch nicht mehr nötig, die Verbindung scheint sich nun selber reaktivieren zu können.

Hi flix87, danke dir für die Info. Das wusste ich nicht. Nun habe ich das ganze von der Reihenfolge geändert und he siehe da es funktioniert. Tausend Dank LG Jerome GELÖST *

… Die Verschlüssung kann dann mit WPA2-Enterprise erfolgen. Genau, so wars gemeint :) Habe ich mal vor längerer Zeit mit HP Access Points und einem FreeRadius, das gegen ein LDAP authentifiziert hatte umgesetzt. Hatte auch gut funktioniert. Ansonsten ist es schwierig das Cisco Gefrusel so einfach zu debuggen ;) Aber ich drück dir die Daumen. Grüße

Da ich meine Clients bereits per Hostname erreichen kann hat sich das für mich ja erübrigt. Vielen Dank leute! Ist dann erledigt. Grüße

gewünschtes Feature auch in 2.2. nicht verfügbar : https://forum.pfsense.org/index.php?topic=83822.0

@speedy-luis: Nur was meinst du damit: Das Problem, die Erreichbarkeit zu gewährleisten, hat die andere Seite, der VPN-Server. Der VPN-Server (am Hauptstandort) läuft immer und hat eine statische IP. Der VPN-Client muss dann so konfiguriert werden, dass der Tunnel automatisch (z.b. nach der 24h Zwangstrennung) wieder aufgebaut wird. Geht das? Ja, ich meinte die Konfiguration am VPN Server. Anfangs war ja nicht klar, ob hinterm Speedport der Server oder der Client sitzt. Meines Wissens baut der Client die Verbindung schon automatisch wieder auf. Damit habe ich aber keine Erfahrung. Es gibt aber hier im Board schon einige Threads dazu. Ich habe gelesen, die Funktion "State Killing on Gateway Failure" in System: Advanced: Miscellaneous soll nicht angehakt sein, sonst gibt es Probleme nach einem Verbindungswechsel.

Thx, das leben kann manchmal so einfach sein :facepalm: