@teward said in pfSense: Certificate Export only using Legacy SHA1 or MD5 exports/signatures: @jimp I assume then that this will hit pfSense Plus, so for $FULLTIME_JOB I'll need to get us a pfSense+ license for commercial / corporate use. Because I don't know when CE will (if ever) receive the patch. The code is in the upcoming Plus 23.01 release. The code is also in CE 2.7.0 snapshots. You can apply the patches to CE 2.6.0 or Plus 22.05 and get it on existing systems if you prefer. When the OpenVPN client export changes are ready they will also be available on 2.6.0 and likely 22.05 in addition to 23.01 and 23.05/2.7.0

@stephenw10 No Steve, it's even dumber. Maybe THATS the reason you should never virtualize pfSense! I wanted to see what the MTU will be on WAN, when I let it auto negotiate again. It was 1492, thats okay since it's PPPoE. But looking at my LAN Interface: The MTU was 1288! I dunno why, but after setting the MTU of 1500 in the Bridge in Proxmox and on the Interface on the VM the pfSense has on the LAN Interface 1500 MTU and since then everything is reachable. I'm really shocked what happened to proxmox that this set it on that weird MTU.

@jimp Thanks for confirming, I had missed the redmine ticket.

@stephenw10 I've just encountered the same issue as reported in the example you give (https://redmine.pfsense.org/issues/13224) where I received an alert from NUT that my UPS was not responding and then a barrage of 'is available now...' notifications for my secondary WAN connection. There was also a second notification from NUT when network connectivity was re-established to the UPS (only two notifications from NUT, the down notification and the up notification). I wasn't at liberty to take any action that might cause network downtime (reboot, etc...), but clearing out the repeating notification from /var/db/notifyqueue.messages worked to put a stop to it. Not sure what, if anything, NUT has to do with it, but it seemed interesting that the circumstances I encountered matched what was reported there.

@rcoleman-netgate thanks so much, doesn't bother me, just wanted to be sure I was safe. Thanks also for moving the thread, wasn't sure.

Only way you're likely to fix that sensor is a BIOS update. Or maybe a manually applied ACPI patch if you know exactly what it should be looking at. Just use the CPU on-die sensors.

@keyser New installs of CE use ZFS. The boot environment GUI is in Plus.

@johnpoz I only need internet on the WAN(that I have) and Management subnet(don't have), nothing else. The rest of the VLANs will only connect to interfaces on the same subnet. They should not connect to other VLANs(that is the point of me using pfsense. and having more VLANs and DHCP per subnet on my network).

I got it working. The system was locking to a MAC. Once I spoofed the old UTM firewall everything just started working. Monitoring is still failing, but I can live with that. What I don't understand is why it refused to allow the new MAC from the pfSense, when I was able to plug in a laptop and a Linksys WRT without needing to spoof the MAC. Thanks to everyone here for the quick responses.

@tobornimda said in Outbound NAT not working: Internet provider gave me a list of IP's from a different pool that will route out of my original gateway. I created a Virtual IP / Other / WAN / Network. Put the IP pool in with /27. If these additional IPs are not routed to your primary WAN IP by the ISP, you have to add each single IP out of the /27 subnet as a virtual IP to use it on pfSense.

@jknott that's right, but is comes with some linux distos as a boot menu option which is rather handy

In addition to a fresh install, I would consider any secret that touched that firewall to be compromised, including the admin password. Make sure you change everything on there. Passwords, VPN keys, anything considered private/secret. See this recipe for ideas: https://docs.netgate.com/pfsense/en/latest/recipes/changing-credentials.html

@steveits Thanks! I did some more testing and the CoDel rule seems to work fine. Bufferbloat still gives nice scores. So I'll keep it like this and see next week for some real-world tests. Thanks for the fix!

@stephenw10 Thanks for the reply. I forgot to mention I did iPerf tests between 10GB > 1GB nodes and the router - all got full speed. That being said, I think I've found the issue. The MikroTik switch is the problem. I am running it in SwitchOS mode, but when I change to RouterOS everything works as expected. So I'll open a ticket with them. I appreciate the help!

If some client was hard coded to use DoH then and local filtering/redirecting would not apply to it. However if would still be routed the same as any other traffic from that host so it should work OK. Steve

Please leave feedback on that bug report if it works for you.