@jegr Ah, ich bin blöd! Die mail kommt von meiner pfsense zu hause (SG-1100) die bereits auf 21.02 ist und nicht der in der Firma, die ich die ganze Zeit untersuche.
Sorry, mein Fehler und danke, dass Du mich darauf gestoßen hast. Die beiden Geräte heissen fast gleich, daher hab ich das nicht gecheckt.
Jetzt wird mir einiges klar.

Danke!!

@oktech Vielleicht musst du PPPoE auf dem VLAN machen?

@nocling Hab ja jetzt nen 10G Switch, ich denke also, das wird nicht nötig sein. Könnte auch an Hyper-V gelegen haben.

@nocling Ja, wir mir wohl nichts anderes als neuaufsetzen bleiben... Wieder ein Samstag 😣

Nee, es ist leider die Version mit 3 LAN-Ports, weil wir damals a) ein WLAN-Modul wollten und b) noch ein LTE-Fallback. Das war zu der Zeit, als 2 ADSL-Leitungen zusammen nur 20Mbit/s gebracht haben und diese dann immer mal gleichzeitig ausgefallen sind...

@mdn Es kommt nur das, was auch quasi in der UI benachrichtig werden würde plus ggf. mal ein Gateway Fail/Switch wenn das genutzt wird, ansonsten bekommt man recht wenig zugespammt. Also von wegen "eine Menge" - ich bekomme täglich morgens die Dyndns Meldung vom DSL IF und ansonsten übern Tag die Vodafone fuckups wenn die Verbindung wieder auf DSL switcht weil Kabel nicht zu gebrauchen ist. Ansonsten wird man nicht einfach zugespammt. Sieht anders aus, wenn man da im Cluster mit CARP arbeitet etc.

@m0nji said in PFSense eingehende Anfragen auf 2. WAN Interface:

https://redmine.pfsense.org/issues/11436

Hi m0nji,

danke für deinen Link.. ich sehe darin zumindest eine Bestätigung von recht vielen die das Problem reproduzieren können.
Die Firewall Logs deuten bei mir auch auf eine Default Deny Rule und den Syn State

Hast du schon weitere Informationen gesehen?

Habe das Problem auch nicht mit einer neuen pfSense 2.5.
Im Server steht allow-compression no und beim client export ist es gar nicht enthalten.

@mansior

Toll, das es bei Dir funktioniert.
Könntest du mir mal deine komplette Konfiguration für das Magenta schicken?
Ich wäre für jeden Tipp dankbar.

@jegr jaaaa... nehme ich... auch beide... sind die "19 Zoll-Winkel" für's Rack dabei?
Wo machen wir die "Preisverhandlungen"? Nicht hier im Forum, oder?

@markus4210
🙂

Aber nicht vergessen, die interne Netze auch in die Ausnahme reinzunehmen, damit sie nicht zum VPN Server geroutet werden. Also am besten alles in einen Alias packen und diesen als Ausnahme-Ziel setzen.

Grüße

@m0nji Bei VMware: Veeam checken. Ist eine der besten Lösungen.

Ansonsten: Automatisierung! Das Gros meiner Proxmox Container sind Kisten, die man relativ einfach neu aufsetzen oder automatisieren kann. Bspw.: 2x PiHole. Die brauch ich nicht wirklich sichern, das Basis-Containerfile hat schon alles wichtige installiert, dann noch PiHole Installer automatisch ausführen lassen und mein Ansible Playbook für PiHole damit die ganzen Domains mit Forwardern woandershin eingetragen werden. Also nichts wirklich drauf was ich sichern müsste. Einfach neu aufsetzen und gut.

Also: Erst Automatisierung, Konsolidierung und was dann über bleibt ggf. als Daten dann ab in ein Backup (extern via NAS oder rsync o.ä.) oder Backup/Snapshots vom ZFS des Proxmox auf den anderen Host des Clusters.

@johndo da mobil nur kurz:

Nein du musst Zertifikate nicht auf der pfSense verwalten. Das entsprechend zu bauen für größere Rollouts ist auch nicht schwer, extern MS Kram machen lassen geht :)

Nur als kurzer Anstoß: die CA kann egal wo sein, die muss nicht auf der Sense sein, zumindest nicht ausstellend. Die Sense braucht für den Betrieb nur die CA lesend (cert) und ein Server Cert von ihr. That's it. Alles andere kann auch extern über build Prozesse, Ansible, Puppet, MS Deployment oder whatever gelöst werden. Und wir haben da durchaus Kunden, die 200+ User ausgerollt haben. User+PW via AD/LDAP und Zert via Microsoft. Beim Anmelden an der Domain bekommen die ihren Client installiert, Konfig gepusht und Zert eingespielt.

Könnte man sicher auch anpassen dass die Certs in den Trusted Keystore kommen dann wäre es schwerer das einfach auf die Privatkiste zu kopieren. Aber ganz ausschließen ist immer schwer. Solche großen Setups fahren dann aber statt irgendwelchen VPN Verbiegungen meist ein Login Control System. Dann wird per Rechnername/ID/MAC or whatever geprüft, ob das ein gültiger PC ist und wenn nicht, wird er geblockt. Das kann ggf auch per VPN klappen wenn es am AD Login hängt. :)

@jegr hach, wenn du antwortest ist das immer schön 😄
Danke für die Aufklärung.
Ich werde dann erstmal nur die Pakete updaten und später die Base.

mhm das hat sich dann wohl erst mal erledigt:
https://www.netgate.com/blog/wireguard-removed-from-pfsense-ce-and-pfsense-plus-software.html

@viragomann Wenn die erste Antwort bzw. der erste Hop von Traceroute schon * * * zurückgegeben hatte, dann stimmte zu dem Zeitpunkt was mit dem Routing nicht wirklich. Wäre dann eher interessant gewesen, was beim traceroute blubb dann tatsächlich der volle Output war. Wäre es pfBNG gewesen, dann hätte die Auflösung von awsh.de schon 0.0.0.0 oder 127.1.1.7 ergeben und wäre ins "nichts" gelaufen. Wenn die aber sauber zur IP aufgelöst wurde und der Trace dann nicht ging, dann war das kein pfSense, sondern eine Routing/Proxmox Problem.

@viragomann said in Dynamic DNS aktualisiert nicht mehr:

Aber soweit ich mich erinnere, ist @JeGr ein vehementer Gegner dieser Funktion. Er sollte wohl beantworten können, warum.

seufzt

Ich bin kein "vehementer Gegner dieser Funktion", sondern habe schlicht mehrfach zitiert und darauf hingewiesen, dass bei aktivem Haken von "Register DHCP Leases" es zu einem ständigen Neustart von Unbound kommt, weil jedes Gerät mit dynamischer IP sobald es per DHCP nen neues Lease bekommt oder aktualisiert eine Rückmeldung an Unbound gibt und der dann NEU STARTET um die aktuelle Liste an Clients zu kennen. Zudem gibt es keinen sinnvollen Grund einen rando dynamischen Client mit rando Name einfach in den DNS zu pumpen. Weshalb sollte ich den Namen von der Kiste brauchen? Und wenn jetzt einer sagt, weil er da mit RDP, SMB, CIFS oder sonstwas drauf muss, dann ist das kein "Client" Job, sondern ein Server/Service Job. Und dann bekommt sowas ne statische oder zumindest reservierte (semi statische) IP (via DHCP/MAC) und die werden einmalig beim Starten eingelesen und benötigen logisch keinen ständigen Neustart von Unbound.

Bei genug Clients und vielen Änderungen im DHCP hat man Unbound dann ständig am Neustarten weil es alle paar Sekunden/Minuten nen Client gibt, der das Ding zum Neustarten bringt. Darum macht man es aus. Es sollte mal via Reload gelöst und angesteuert werden, da gab es aber einen Regression Bug und ein Problem mit Unbounds neuer Python Module Integration. Daher ist das in 2.5 immer noch drin.

https://redmine.pfsense.org/issues/5413

tl;dr:

DNS Resolver:

disable DHCP Registration von irgendwelchen rando Clients disable DHCP Registration von irgendwelchen rando OpenVPN Clients
wenn notwendig: enable DHCP static lease Integration ins DNS. Da wird nur ein Neustart fällig wenn man neue DHCP Mappings erzeugt.