@aaronouthier To properly support cell phones and devices tethered to them, you should try to set up your PBX to use IPv6, if possible. 4G & 5G phones are IPv6 only and use a translation protocol to send IPv4 over IPv6 networks. Android phones use 464XLAT. I don't know what iPhones use. There's no need for NAT with IPv6.

@chris1284 said in pfsense HA an Telekom Glasfaser Anschluß: Proxmox HA vernünftig aufgesetzt sind 3 nodes minimum, da man mit 2 nodes bei Ausfall kein Quorum (Mehrheit) zustande kommt und der Cluster read only geht (also die vms laufen, aber man kann nicht migrieren oder neue starten). Das kann man jedoch händisch "arbeitsfähig bleiben" (expected 1), wenn 1 node down ist. Jein. Ja du hast mit vernünftig aufgesetzt recht, Homelab ist aber != Business best-case setup. 2 Nodes gehen absolut und können auch bei Ausfall reagieren. Ausfall muss dann eben korrekt definiert und Fencing konfiguriert sein. Das geht. Und selbst wenn nicht, semi automatisch geht immer. :) @chris1284 said in pfsense HA an Telekom Glasfaser Anschluß: Bei bedarf fahre ich den 2. node hoch, migriere die VM, expect 1 setzen und fahre den 1. node runter/führe dort die Wartung durch. Danach alles zurück migrieren, node 2 wieder down Das geht natürlich auch. @chris1284 said in pfsense HA an Telekom Glasfaser Anschluß: Ein 3 Port WAN VLAN auf einem Switch und da dann Modem uplink, WAN Node 1 und WAN Node 2 dran. bei Life Migration dürfe dem Modem dann der Wechsel des nodes nicht auffallen (selbe Mac WAN pfsense) Mit Nodes meinst du die Proxmoxe? Ja klar, da reicht ein Hub oder "dummer" Switch mit simplem VLAN. Hauptsache die Nodes haben physikalisch das WAN gleich bei sich und könnten auf egal welchem Node/WAN dann via PPPoE das Interface anfahren zur Einwahl. @chris1284 said in pfsense HA an Telekom Glasfaser Anschluß: Das müsste gehen. Hub dazwischen wäre doch dann simpler? In der Tat :) @chris1284 said in pfsense HA an Telekom Glasfaser Anschluß: Das Szenario hatte ich auch schon, dann läuft aber entweder ein Router statt dem Modem oder ein Modem, 1 Router, 2 PVE. Double NAT hat man so oder so, das wollte ich vermeiden. Der erste Router müsste dann ja auch auf "Durchzug" stehen und alles durchreichen. Alle Welt schreit immer Zeter und Mordio bei Doppel NAT. Wenn du aber im Homelab kein Mega-Gamer mit Extrem-Anspruch bist, der P2P Port mäßig super-direkt überall erreichbar sein muss, ist egal wie viel NAT völlig egal dazwischen. Und bei einem Cluster-Paar ist ein vorgeschalteter Router eben "Pflicht" oder zumindest best-case setup, da man ansonsten auf dem secondary node kein Internet hat, was den Betrieb stark beeinträchtigt. Zum einen kann er dann nicht sofort übernehmen wie schon gesagt, zum anderen geht dir gerade einer der Pluspunkte vom Clustering kaputt: einfaches Failover und Update bei neuen Versionen. Normalfall: Update 2nd node, durchbooten, testen - hey geht - switchen auf 2nd node, 1st in maint setzen, upgraden, testen, zurückschwenken. Normaler Fall: 2x 1-3s Ausfall/Ruckeln. Best Case du merkst gar nix. Geht aber nicht, wenn nicht beide Nodes unabhängig Internet haben :/ Und die "Doppel-NAT" ist kein Drama, da du auf dem Router davor exposed Host machst, du bekommst also trotzdem alles ab (außer der Router kann so gar nix - dann verbrennen und anderes Gerät). Aber gehen wir von ner frittierten Fritte aus, dann exposed Host man die VIP und kann dann auf den einzelnen pfS Nodes trotzdem sauber (durch das NAT davor) ins Netz, während alles von extern via Exposed Host auf die VIP auf den aktiven Node reingeballert wird. Pluspunkt (bei einigen ISPs): Du setzt den/einen kompatiblen Providerrouter ein, den sie entweder selbst ersetzen, warten oder supporten müssen und sie können sich nicht rausmurksen wenns mal Probleme gibt. @chris1284 said in pfsense HA an Telekom Glasfaser Anschluß: Danke! Wenn mein Gedanke zum "downgraded" Proxmox Cluster mit 2 Nodes und VLAN für sauberen WAN switch bei Migration sauber funktioniert aus deiner Sicht, wäre das mein Weg, den ich teste. Klar feuer frei :) Wenn die 2 kleinen Nodes entsprechend verkabelt sind, sollte das kein Thema sein. @chris1284 said in pfsense HA an Telekom Glasfaser Anschluß: Danke sehr für deinen Input und den Denkanstoß Immer gern :) Aber es hat schon seinen Grund, warum selbst Netgate Personal sagt, dass im Homelab/zu Hause Clusterbetrieb einfach zu oversized ist. Da bist du so am puzzeln und basteln dass das geht... uff. :D Cheers!

@djp123 said in How the heck do I actually install CE 2.8?: the only "purchase" choice for a memstick image is "Netgate appliance". You aren't shown the other options? image: [image: 1758291449972-eb4cf63a-adff-4d7f-989b-fc3f40445de6-image.png] Or if you're asking which to use, you can burn the ISO to a USB stick. https://docs.netgate.com/pfsense/en/latest/install/prepare-installer-media.html

@keyser said in Change local source ports of IPsec tunnels: I think you are looking for the “custom ports” settings on VPN -> IPSEC - ADVANCED tab But this sets the port globally for IPSec, but I don't see a way to state a specific port for a certain connection, as the OP requested.

Yup, it's waaaay faster!

I won't ever be filtered by the WAN rules because that traffic never actually enters the WAN interface. However you should should still be able to use the public VIPs as a destination from internal clients. HAProxy will still see that traffic and proxy it to the servers. You may have to tweak it to prevent asymmetric routing if the clients are in the same subnet as the servers.

@richardsago You need to check System > Advanced > Miscellaneous > Skip rules when gateway is down to avoid that pfSense routes the connection out to the remaining active gateway.

@nws thanks for the consistent fix - I completely overlooked that for a while. And @credulous yes, it's still a mystery why the collectors seemingly trigger and gives errors, and also why they don't appear at the collector list. It seems the Prometheus Node Exporter package on FreeBSD has very low priority perhaps? Else you would imagine something like this could be fixed.

@chrcoluk said in Where are the inbound rules for routeable IPv6 on LAN interfaces? Solved: looking for another rule that might be whats allowing the traffic I presume your monitoring service pings (right ?!) from 'somewhere on the outside, somewhere from the Internet' so a firewall rule on the WAN interface is needed to allow this traffic coming into the WAN. The good news : normally ^^ you don't have many rules on WAN and typically none on the floating tab. So the matching rule is easy to find. In this case : look for the rules that match ICMP (or any), and a : 'any' as a source. @chrcoluk said in Where are the inbound rules for routeable IPv6 on LAN interfaces? Solved: If that makes sense. Yep. Re saving the firewall rules doesn't terminate already exiting states. Normally, these will time out, and disappear. But this is a case where you have to 'reset' them all, even loosing other connections, like the very noticeable web browser LAN pfSense GUI connection : you have to login again before you can see the changes. And that is just the tip of the iceberg, as more services on any LAN device that had open connections will get interrupted. Example : that gmail app in your phone, that update service in your PC and any other other service that wants to have a connection at all times for whatever reason. These will all get signaled : the connection closed, and they will re open one. You could have used an intermediate step to discover the IP of the Internet based device : Packet capture. [image: 1758694519433-81ca2312-fea4-4b87-b989-68f9d2803897-image.png] You'll see multiple packet popping up very regularly. The most obvious one : the pfSense WAN monitoring tool called dpinger, sending out an ICMP ping request, and getting an ICMP ping reply back. You can recognize these bu the sending IP? and replying destination. You will also see the ICMP ping request coming IN, and pfSense sending an ICMP ping reply - to the IP that is monitoring your WAN from the outside. Maybe you'll find other devices (== IPs) that are pinging pfSense WAN IP ^^

@andres-asm if I read it correctly you're running pfSense in a VM on Proxmox (8 or 9?) with EFI. What 'Machine' are you using on Proxmox, 'Default (i440fx) or 'q35'? There is a thread about issues with pfSense running on Proxmox with UEFI: After upgrade 24.03 to 24.11 reboot hangs at start @ 0xffffff..... The root cause is not yet known.

Oh you mean you have the PPPoE session running on the CARP VIP? Not the VIP on the PPPoE? That makes more sense. That's what was used in an HA setup previously. But that is not a supported setup. if_pppoe cannot run on a CARP VIP in the same way. I believe there is a user script being developed in another thread as a workaround.

Hmm, you added that cronjob yourself? Any particular reason? Do you have an url aliases with a large number of entries?

@feisal simple policy route https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html

Wow, that's painful! Nice to find a cause though.

I have made some progress. I have modified the file /src/etc/inc/ipsec.inc at lines 2365 and 2365 to remove the additional selectors, and now my proposal correctly matches the one on the other side and it works flawlessly.

UPDATE: I now recommend absolutely to avoid ULAs (fd:: and fc:: due to RFC 6724) it seems that those specific subnets will usually prioritise IPv4 traffic and other oddities so you can absolutely use them for special use cases but for a LAN or a dual stack setup I recommend the other f000::/4 subnets which work because they're not official ULAs (so I guess I want them to be that way now).

@itBJA In the p2 you can only masquerade your network. However, for communication also the remote site has to masquerade their networks. Otherwise you were not able to access anything there or lose access to the local network. This could look like that: At local network state 172.16.0.0/16. At NAT/BINAT select network and enter e.g. 10.16.0.0/16 At remote enter their masquerading networks. E.g. 10.116.3.0/24 for 172.16.3.0/24. The remote site has to use 10.16.0.0/16 as "remote network" and nat 172.16.3.0/24 to 10.116.3.0/24. Then you have a 1:1 NAT. This means if 172.16.3.26 on your site connects to 172.16.3.26 on the remote site, it needs you use 10.116.3.26 as destaintion.

@Nutri De fabrica no existe ningun utileria que te brinde esa informacion, lo que te ayudaria seria instalar un web proxy y ese si registra lo que buscas. Saludos.

@JeGr Ja, das ist eben Deutschland... Aber immerhin baut sich der Tunnel bisher immer wieder auf, es gab seit Wochen keine Probleme mehr. Gruss

@Gertjan said in There was an error trying to determine the public IP for interface - wan (mvneta0 ). DDNS not working..: dig @127.0.0.1 checkip.dyndns.org +short Thanks for having a look! I have removed those wan-rules now. And here are some outputs: [image: 1758183115943-screenshot-from-2025-09-18-10-10-43.png] [image: 1758183115960-screenshot-from-2025-09-18-10-10-22.png] And: "That's a script I wrote years ago. Totally forgot about it. That web site and host name is 'mine' " you are a god!