Super freut mich, wenn das so geklappt hat. Ich würde noch der Einfachheit und Dokumentation halber die IP Netze so vergeben, dass die FBs nach Möglichkeit wenn sie resettet werden gleich wieder laufen (oder hat die 7390 nach FW Reset auch wie die 6490 ein 192.168.178.x?) und zusätzlich die VLAN IDs wie das 3. Oktett benennen (also 178 und 188), dann ist bei kurzem Blick auf die VLANs auch immer gleich klar, welches IPv4 Netz dahinter hängt. :) Macht das Debugging einfacher. Grüße -jens

@viragomann: Das sind ja keine gültigen URLs: @kromonos: https://pfsense/system_usermanager_settings_ldapacpicker.php?port=389&host=10.0.0.2&scope=subtree&basedn=DC=pdc;DC=kromonos;DC=net&binddn=cn=pfSense;DC=pdc;DC=kromonos;DC=net&bindpw=MeinPasswort&urltype=TCP%20-%20Standard&proto=3&authcn=CN=Users;DC=pdc;DC=kromonos;DC=net&cert=5508990deef15 Überprüf das mal bitte. Ich hab die URL etwas angepasst. Anstelle dem pfsense steht da schon eine richtige URL

Hi, vergiss nicht das in dem Teil immerhin ein Dual-Core verbaut ist und der keinen Lüfter hat. Ich würde schon sagen, das das normale Betriebstemperaturen für das Teil sind. Wenn schon normale Festplatten in einem NAS auf 40 Grad kommen, da wird wohl ein Lüfterloser Prozessor mal 58 Grad haben dürfen…. ;) Gruß orcape

Macht nichts, war nur irritiert :)

Hallo! @Mario: Nun stelle ich mir die Frage, welche Einstellungen bei der Firewall denn soetwas blocken können. Dazu ist keine Einstellung nötig, die pfSense blocked grundsätzlich alles, was nicht explizit per Regel erlaubt ist. Standardmäßig ist nur eine Regel gesetzt, die alles von der LAN Schnittstelle kommend erlaubt. Doch diese ist eher für den Hausgebrauch gedacht, der Admin löscht sie normalerweise. Du musst also Regeln anlegen, um den benötigten Traffic durchzulassen. Doch was dein iPXE genau an welchem Interface benötigt, weiß ich auch nicht. Grundsätzlich ist dafür ein DHCP nötig. Der pfSense DHCP Server hat eine spezielle Konfiguration für PXE vorgesehen. Du verwendest aber offenbar einen anderen, weil es ja auch ohne pfSense funktioniert hat. Ob es mit einem anderen DHCP und der Firewall dazwischen klappt, kann ich aber nicht sagen. Dann erfolgt der Zugriff auf das Boot-File. Du schreibst, es liegt auf einem TFTP Server, doch im URL hast du http: stehen? Tja, ich würde sagen, die wird per HTTP über Port 80 abgerufen. Ohne das System zu kennen, kann man eben nur Vermutungen anstellen. Wie es genau funktionieren soll, sollte aus deinen Unterlagen zu entnehmen sein. Andernfalls kannst du während eines Bootversuchs mit der pfSense dazwischen ein Packet Capture auf den jeweiligen Interfaces machen. Da sollten die Vorgänge erkennbar sein und du kannst die Firewall-Regeln entsprechend konfigurieren. Ja noch was: DHCP geht nur innerhalb einer Broadcast-Domäne, kann also nicht geroutet werden. Wenn also Rechner und DHCP Server in verschieden Broadcast-Domänen liegen, musst du zumindest auf der pfSense das DHCP-Relay aktivieren. Besser wäre, vielleicht in diesem Fall gleich die pfSense als Server für dieses Interface zu konfigurieren. Grüße

An welcher Stelle bekommt pfSense meine Tunnel Zugangsdaten gesagt? Beim GIF Interface. Dort konfigurierst du deine Gegenstelle, die den Tunnel aufbaut. Und deine IP wird dem Tunnelprovider mitgeteilt (er pingt die ja an). Deshalb zusätzlich: "If the WAN connecting the tunnel has a dynamic IP address, the HE.net Tunnelbroker DynDNS type may be used to update it when the WAN IP address changes." Das ist allerdings für HE.net, wie das bei Sixxs läuft, kann ich hier nicht genau sagen, würde aber annehmen, dass es dort ähnlich gehandhabt wird. Du aktualisierst deine IP dort via "DynDNS" Service, damit sie wissen, dass sie mit dieser Endstelle den Tunnel aufbauen dürfen bzw. wo die v6 Pakete hingeroutet werden.

Hi! War ein paar Tage unterwegs, daher die Antwort etwas verspätet. Ich habe Deinen Vorschlag mal in einer Shell getestet sieht dann so aus und Link bleibt UP. Habe diverse IF Parameter beim Aufruf mitgegeben (MPD,PPTP0,PPTP,WAN). [2.2.2-RELEASE][root@firewall.xxx]/var/run: /usr/local/sbin/ppp-linkdown PPTP0 ngctl: shutdown: No such file or directory OK [2.2.2-RELEASE][root@firewall.xxx]/var/run: /usr/local/sbin/ppp-linkdown MPD ngctl: shutdown: No such file or directory OK [2.2.2-RELEASE][root@firewall.xxx]/var/run: /usr/local/sbin/ppp-linkdown WAN ngctl: shutdown: No such file or directory OK [2.2.2-RELEASE][root@firewall.xxx]/var/run: /usr/local/sbin/ppp-linkdown PPTP ngctl: shutdown: No such file or directory OK Ja, das mit die Buttons wäre interessant, ich muß mir das nochmals genauer ansehen. Also soweit ich das bis jetzt gesehen habe löst der Disconnect Button einfach ein kill auf… (etc/inc/interfaces.inc -> Call interface_bring_down(WAN,false,false) 1.) Der Prozess mit dem Namen mpd5 wird gekillt. 2.) unlink_if_exists(/var/etc/mpd_wan.conf)  --> bin mir noch nicht sicher was das hier macht Beim Connect Button passiert noch mehr und ich hab keinen Plan :-) (etc/inc/interfaces.inc -> Call interface_configure(WAN,false,false)) Nachdem das zu kompliziert wird, was wäre wenn ich einfach mit curl auf die status_interfaces.php poste? lg

Danke dir für die Lösung :)

Da hast du natürlich vollkommen recht ;)

Mist… Dann hat sich diese Idee wohl erledigt. Trotzdem danke für deine Hilfe.

Wir sind zwar mittlerweile etwas Off Topic…. ;) …dass Daten von innen nach außen geschickt werden, von denen ich das aber nicht will. Als Optimist und Realist, weist Du ja was Du tust und handelst entsprechend. ….dass eben doch mal mehr Leute hinterfragen, überhaupt fragen oder nachdenken, ob und wie es Sinn macht, wenn mehr und mehr Dinge vernetzt werden (prinzipiell nichts schlechtes) und Daten untereinander getauscht werden (dito). Da sollten sich einige Gedanken machen müssen. Nicht nur was das eigene LAN betrifft. Facebook und Co. sind eigentlich ein absolutes No-Go und trotzdem postet fast jeder seinen privaten Develey und regt sich dann über die Abhöraffäre des NSA auf. Gruß Peter

Wenns immer so einfach wäre, wäre ich froh :) Gerne!

Servus, ja, genau das dachte ich mir auch und hatte deshalb folgenden NAT-Eintrag gesetz: LAN UDP * * WAN address 1196 127.0.0.1 1196 Der Witz: Vorhin gings nicht und nun läuft es. Das hatte ich nun schon einige Male  :-[

Das ist gut weil dann ;) Gehst du auf dein WLAN Interface und nimmst den Hacken bei "Allow intra-BSS communication" raus dann gehen alles Pakete über die PfSense. Dann musst du noch Regeln anlegen das die Clients zwar auf die PfSense dürfen um z.B. DNS zu machen blockst aber dann alles was in dieses Netz (und vielleicht deine anderen Netze) geht weg. Normal geht das nicht da in einem Layer 2 Netzwerk die PfSense ja gar nicht zum tragen kommt als WLAN AP aber sehr wohl. Zum Schluss erlaubst du dann noch den Rest so das die ins Internet drüfen. Im Prinzip einfach eine Regel anlegen die keinen Zugriff von WLAN auf das WLAN Netz erlaubt (immer die Reihenfolge beachten Firewall arbeiten von oben nach unten und den DNS Zugriff nicht vergessen der muss natürlich erlaubt sein) dann sollte das gehen. Gilt hier aber nur für WLAN wenn die PfSense auch WLAN AP ist.

Ich bin gespannt was da rauskommt ;)

Nein, aber in der Paketliste kannst du über den Link hinter der Versionsnummer mehr zum Paket erfahren.