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.

Hi,

Dementsprechend ist es schon paradox, daß das Thema MTU so selten Erwähnung findet.

Da kann ich Dir nur recht geben.
Die Standarteinstellung von 1500 sollte man nicht beibehalten, obwohl sich bei geringerer MTU-Größe meist die Logs beschweren.
Ist wohl auch immer die Server-/Client-seitige DSL-Anbindung entscheidend, ob Probleme auftreten oder nicht.
Ich hatte z.B. Tunnel über 2 Jahre mit MTU 1500 laufen, bis Clientseitig die DSL-Technik wechselte.
Erst dann traten hier Probleme auf.
Wobei ich in diesem Fall von MTU 1500, sogar bis auf MTU 1342 korrigieren musste, bis alles problemlos lief.
Gruß orcape

Hallo Stefan,
schön, dass es funktioniert.

Mein nächstes Projekt war ein Teamspeak 3 Server in einer VM - Umgebung in Betrieb zu nehmen und diesen von außen erreichbar zu machen. Als VM benutze ich einen Qnap TS853 Pro auf dem kann man direkt virtuelle Maschinen laufen lassen. Er läuft.
Sollte jemand wissen wollen warum….. bitte schreiben.
Gruß
Jörg

Hi,

entweder gibt es das gewünschte Paket für die Version von pfSense noch nicht, oder es ist für die Plattform (NanoBSD) nicht verfügbar. Ich bin auf der aktuellen v2.2.2 und bei NanoBSD wird das Paket nicht angezeigt. Eine aktuelle 2.2.2 mit HD Installation habe ich gerade nicht zur Hand.

Grüße