Deshalb meinte ich auch: TinyDNS hat diesen Sync bereits integriert. Es gab mal eine Zeit lang das Projekt "pfDNS" (wer sich noch erinnert), wo auf Minimal-Basis von pfSense ein DNS Server gebaut werden konnte, an den man dann einfach weitere per Sync dranhängen konnte. Kam aber leider nie über Prototyp Status hinaus.

Offtopic: Ich versuch' das selten zu machen und bin auch nicht reingegrätscht sondern wollte das nur hinterher als Abschluß nochmal zu Dokuzwecken drin haben. Da ich aber auch schon per Mail/PN mal häufiger das ein oder andere bekomme, hab' ich schon überlegt da wirklich eine Art kleine FAQ/Top10 zu schreiben, um das "Übliche" mal abzufrühstücken. Ich meine es meistens auch nicht bierernst ;)
Und nee, eher nicht so sehr genossen. Waren jetzt einige Wochen mit halb-krank bis krank und wieder zurück. Freue mich jetzt mal näcshte Woche auf eine richtige Woche Urlaub mit Erholung und etwas Zeit, auch hier mal das ein oder andere noch zu schreiben (dokutechnisch). Nebenbei versuche ich auch noch mich/uns/meine Firma bei pfSense zertifizieren zu lassen, damit das in Zukunft auch noch besser klappt. Insofern habe ich eher Hoffnungen auf den Winter/Weihnachtsferien - vorher ist einfach noch so viel zu tun ;)

@hoffi: Zum Thema Backup: Das Einfachste ist natürlich, hier ein Backup XML zu ziehen. Wenn wer das noch genauer will, dafür speichert pfSense eine Art Audit-Log. Auch wenn das noch spärlich dokumentiert und nicht richtig geführt ist, werden dort alle Änderungen vorgehalten, die jemand gemacht hat.

-> Diagnostic / Backup/Restore -> Reiter "Config History".

Seit Version 2.2+ kann hier auch die Anzahl der History Einträge erhöht werden.

Ich empfehle hier, für jeden Admin, der am System arbeitet, einen eigenen Account zu machen, dann kann man in der History auch sehen, wer es "verbrochen" hat.

–-

Sollte es interessant sein für jemanden: Ich habe bei uns firmenintern ein kleines Shell Skript geschrieben, welches per SSH/SCP diese History abgreift und auf einem Linux Host mit Git in ein vorgegebenes Verzeichnis herunterlädt. Anschließend wird versucht zu ermitteln, welche der History Files bereits in GIT vorhanden sind, diese werden gelöscht. Alle anderen werden dann zeitlich korrekt hintereinander mit entsprechendem Commit Text lokal committet und anschließend an einen GIT Master gepusht (bei uns in internes GitLab).

Vorteil der "Bastellösung" ;) - wir sehen genau wie die Config History jede kleine Änderung auch im Git inkl. der Information der pfSense, welcher User die Änderung vorgenommen hat (da es im Commit Log steht). Somit kann auch recht einfach zu einem bestimmten Config Punkt zurückgesprungen werden. Das ganze läuft mit einem extra Backup User der SSH Zugang per passwortlosem Key braucht. Ist aber keine "fully automatic" Geschichte, als ich kürzlich unseren Slave ausgetauscht habe, musste ich das wieder neu auf dem Slave einrichten (weil sich natürlich der SSH Host Key etc. geändert hatte) und da wir diesen neu installiert hatten, wurde natürlich auch der "letzte Config Stand" nicht erkannt (Timestamp aus dem XML File). Damit wurde dann die volle History eingelesen, aber einige Änderungen gingen dann verloren (hatte leider zu lange keiner gemerkt) ;)

Sollte daran Interesse bestehen, könnte ich das gern mal aufarbeiten und posten bzw. in ein GitHub Repo basteln, vielleicht mags ja jemand noch besser machen :)

Du schreibst oben etwas von "no entries for 'mail' …" - versuchst du hier nur einen Hostnamen ohne Domain aufzulösen? Dann versucht die im Normalfall der Forwarder/Resolver selbst zu beantworten. Oder sollen egal welche Adressen dort aufgelöst werden?

@BlueKobold

Siehe https://forum.pfsense.org/index.php?topic=81862.msg470372#msg470372
Das war ein früher Post Pre-2.2 wo bereits mit den ersten Varianten von AES-GCM weit mehr als 150-200MBit/s per VPN geschoben wurden. Später hatte gonzopancho in einem anderen Thread - den ich leider gerade nicht zu Hand habe - von einer C2750 oder 2758 gesprochen, mit der er bei sich an einem Gigabit Link bereits annähernd Gigabit VPN geschafft hat. Mit welcher Einstellung etc. sei dahingestellt, Fakt ist aber die Zahlen im Shop sind unterstes Level, da es Meßwerte sind aus dem (Ur)alten Shop, wo die Werte noch ohne AES-NI Unterstützung, ohne GCM und mit schlechten Voraussetzungen (alte 2.0er Version) gemacht wurden. Die sind also  überholt. Da du in einigen der Threads auch fleißig mitdiskutiert hast, sollte dir das eigentlich noch bekannt sein ;)

Nebenbei bemerkt ist da nirgends ein IP Wechsel vermerkt, sondern ein Link Change, also ggf. ein Up/Down Event des Interfaces. Könnte also schlicht sein, dass das Gerät hier das Netz verloren hat bzw. die Gegenstelle weg war.

Was vielleicht daran liegen kann, dass du irgendeine externe Anleitung nutzt, die sich auf eine alte pfSense Version bezieht? Das sollte man ggf. vorher berücksichtigen.

Also mit einem Proxy hat das nur begrenzt bis gar nichts zu tun. Das ist Sache von Bandbreiten- oder Traffic-Monitoren. Wie detailliert diese arbeiten, hängt vom Produkt ab. Einen so hohen Detailgrad, dass man genaue Uhrzeiten mit IP und Volumen hat, dürfte in kaum einem Paket vorhanden sein, von ntopng einmal abgesehen, was aber wiederum fast zu mächtig sein dürfte für dich.

Eine andere Möglichkeit wäre hier eher, ein Tool zu nutzen, welches Flows unterstützt (SoftFlows bzw. Cisco Flow kompatibel) und diese auszuwerden. Dazu genügt auf der pfSense die Installation eines Pakets wie "softflowd" welches seine Flows dann an das Tool weiterschickt.

Da du keinerlei Angaben machst, WIE du dich zu deinem FTP Server verbinden möchtest, ist das ziemliches Raten, aber ich würde vermuten, dass du es mal mit passivem Modus versuchen solltest. Aktiv würde bedeuten, dass der FTP eine Rückverbindung aufmachen will, was durch NAT und Firewall nicht funktioniert. Der FTP Client Proxy ist an der Stelle nur ein Helfer, der dabei assistiert eine aktive FTP Verbindung aufzubauen, für den Fall, dass der Server kein passiven Modus unterstützt (was ziemliche Schlamperei wäre).

Wenn man den Filter kennt (pf) und sich ein wenig in pfSense einliest ist die Antwort relativ leicht. pfSense erstellt automatisch Regeln für ausgehenden Traffic, ansonsten müsste man pf immer vollständig konfigurieren nämlich den kompletten Weg, den das Paket durch die Firewall nimmt. Beispiel: Von LAN ins Internet kommt das Paket eingehend auf dem LAN IF rein, geht auf dem WAN IF raus. Ergo müsste man klassisch in pf eine incoming Regel auf LAN und eine outgoing Regel auf WAN erstellen. pfSense macht das outgoing aber automatisch. Was die Antworten von Traffic angeht, ist das bei TCP und ggf. bei UDP (etwas gemogelt) so, dass sich pfSense nach dem ersten Paket den State merkt (Stichwort Stateful Inspection, State Table). Danach werden alle Pakete die auf den selben State passen automatisch erlaubt. Dazu gehören auch Antwortpakete der Verbindung, die von außen zurück kommen.

Hallo!

@atlantyz:

Seltsamerweise werde ich nur, wenn ich den Webserver per www.domain-name.de oder bbb.domain-name.de anspreche auf die pfSense umgeleitet, ist mir gerade aufgefallen  ???

Dann würde ich auf dem Host, von dem aus du die Webseite aufrufst, mal ein nslookup machen, um zu sehen, welcher DNS dir da was zurückgibt.
Das kann ja wohl nicht die IP sein, die im externen DNS mit dem FQDN verknüpft ist, ansonsten würde damit auch das gleiche passieren.

Grüße

Hallo!

Ein Bild sagt mehr als tausend Worte…
Eine kleine Grafik von deinem Aufbau wäre übersichtlicher und für die Leser angenehmer als endlose Netzwerkbeschreibungen.

Aber das, was du da an Netzwerkeinstellungen der pfSense beschreibst, ist ja so gar nicht möglich. Ein Gateway muss doch innerhalb eines am Interface konfigurierten Subnetzes liegen, sonst weiß die Kiste ja nicht, wo sie die Pakete hin schicken soll.

Am LAN der pfSense sollte kein Gateway konfiguriert werden.

Und warum gibst du dem Host nicht eine IP im LAN der pfSense, dann kann er diese als Internetgateway nutzen.

Wenn das Netzwerk richtig konfiguriert ist und eine pfSense Schnittstelle am Host das Standardgateway ist, sollte kein NAT für RDP auf den Host nötig sein.

Hey,

danke für deine Antwort. Aber dieser Recht hat der entsprechende User leider schon  :(

Weitere Ideen?

Was man machen kann, um es wenigstens etwas zu erleichtern: Einen Alias für die Interface-IP anlegen. Der taucht dann auch in der Auswahl bei den Outbound-Nat-Rules auf.

Aber richtig schön finde ich das immer noch nicht ;)

Ok, ich habe jetzt erstmal hinbekommen das es funktioniert.

Ich dachte beim Erzeugen einer Zone wird ebenfalls ein Default View automatisch erzeugt. War leider nicht der Fall. Ich kenne es so unter Debian.

Dann kommt es wohl von dem Router und ist nicht weiter schlimm.

Wenn du die Meldung nicht sehen möchtest, kannst du in den Log-Einstellungen das Logging von Bogon Networks abschalten, hier gehört diese IP dazu.
Eventuell lassen sich diese Broadcasts auch im Router abstellen. Das Gerät kenne ich aber nicht.

Das "!" ist in der Regel ein "NOT" … also "pass NOT blahblah"
Oder lieg ich da falsch?