@stephenw10 said in How do I discover ISP's PPPoE credentials and connection settings?: I assume you have no access to the ISP device config interface? What device is that exactly? The site is in another city, but I guess it's a ZTE. It allows access on the LAN, but you cannot configure WAN, or view configuration. @stephenw10 said in How do I discover ISP's PPPoE credentials and connection settings?: The ISP doesn't actually have to use individual credentials at all. BT in the UK for example use the same login for all devices. They know who you are by what line you're connecting on. This one does use credentials. But they probably know who you are by the line. @stephenw10 said in How do I discover ISP's PPPoE credentials and connection settings?: You could probably also bridge some ports in pfSense and use that instead of the switch mirror port to pcap on. That was my thinking exactly. I'll try that the next time. I cannot call and ask them to undo what they've just done.

@wineguy said in Unable to configure notifications using port 587: I expected that it would default to the 'From email address', which would make a nice enhancemen Noop. The "From" is the mail address from which you send the mail. This can be different one as the USER login credential, needed for submission over port 587 (smtp with authentication) to work. These two can be identical, true. @wineguy said in Unable to configure notifications using port 587: So, another nice enhancement would be to require a username and password when port 587 is selected. '587' or submission means (imho - check with RFC ?) : must authenticate. You could go one step beyond : Set up your mail server to use plain TLS, or SMTPS, normally over port 465. Most FAI's - look how gmail does things - don't use - or should I say : don't enforce the use of 587 anymore. It's TLS all the way = port 465, which means : from byte zero all is TLS. You can pick any port actually, as it would be used by your mail clients, the ones you control.

@johnpoz ~ I also added filter-AAAA to the DNS forwarder's Options so I think I've now killed IPv6 in every way possible on my firewalls! :o) Roy...

@Gertjan thanks you so much 🤟

@Laxarus Thanks for the help my friend. It helped me a lot!! After 12 hours of migrating 4 domain controllers, I almost hit the rollback button until I saw your tip. I tried this and it worked for two systems that had problems. The only two systems that we could not test in our lab environment.

@roben1000 See here : I RESTART THE PFSENSE BECAUSE OF THIS NOW I CANNOT ACCESS IT

We may be able to recover the old key if you send me the NDI or hint in chat.

Aha, that would do it! Easy mistake, we've all done stuff like that.

If you have a legitimate reason to need to migrate the NDI then we can accommodate that. If you had a hardware failure for example. Or, here, if you upgraded and found your new hardware is incompatible. We're not completely inflexible.

https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-proxmox-ve.html

@viragomann, thank you very much for your help!

@LaUs3r I am experiencing the same even on the latest pfSense Plus beta version (25.03)

@stephenw10 Thanks again. I've submitted a correction suggestion to MaxMind for the IP. I assume that the regular scheduled auto updates of pfBlocker databases within my pfSense also update Maxmind's free GeoIP database as well -- I noticed the free GeoIP database is updated by Maxmind every month. Cheers

@johnpoz getting a squid transparent proxy running on pfsense with ssl/mitm from scratch wasn't easy tbqh (but maybe that's another topic...) it is quite satisfying though to see the RT access logs flow in pfsense, and the secure lock in the browser at the same time (= [image: 1747930627954-squiddie.jpg] but still, as you mentioned before, without the device accepting my ""internal-ca"", it's besides the point

There is, here: https://redmine.pfsense.org/

Are you able to test in 25.03-Beta?

I have seen it happen in the past when the change is initially made. Somehow the dhcp server is still running on the interface. But not for a while and not beyond the initial switch.

Well from what we've seen here it is googles fault. Cogent is not preventing you use other DNS servers. What's happening is that Google's servers detects you are resolving DNS from a different location than you're are sourcing requests and flags the connection as suspicious in some way requiring additional screening. The same way that some sites will do that for VPN connections. A "DNS leak" is one way sites detect it. The interesting thing is that they only flag the Cogent connection that way. One other thing you could do VPN all your traffic over the Cogent WAN to the same location you are resolving from. But I would at least try resolving locally first since that would also set the DNS and source IPs to match. With DNSSec enabled you can be pretty confident in the results. Using DoT really just outsources your trust to cloudflare.

@BigTulsa Exactly. Allows me to run with 1 less piece of equipment and a few less cables. XGS-pon on one end and regular 10Gb SFP on the other end. My 7100 is happy with it. It does get hot, so I have a 20mm USB powered fan cooling it. Now I have a use for one of the USB ports on the firewall. You do need to keep the ATT router ready to power up, it would be best if it is up if you have a problem.

@stephenw10 Excellent thank you.