@stephenw10 ok. If it happens again i think i need to reinstall.

Wireguard act as an interface. If you are confident about routing configurations it is doable. I own a GL.iNet Beryl AX and let me say that Wireguard configuration is more or less the same (actually maybe a little bit simpler on GL.iNet). Not so immediate to setup a Wireguard client on both devices with NordVPN, but this is a specific provider issue...

Yes you probably want filtering only on the bridge itself if you have just one subnet: https://docs.netgate.com/pfsense/en/latest/bridges/firewall.html Otherwise you would need rules with the advanced option set to pass multicast traffic on each member interface. And with only one subnet you shouldn't need Avahi at all.

@stephenw10 Hi Steve, Thank you, you're a star. I simply used the device id & password on a spare appliance and was able to obtain the unencrypted config. Evidently, there is os corruption on the flaky box with the suspect msata drive. Thanks again ;-)

It should be sufficient to allow https to 208.123.73.0/24. As long as DNS works locally.

@vitor-connectsolution MS doc: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365 There are several caveats to their 3 options. To simplify everything, if you have a static IP it's by far easiest to use "option 3" on that page and set up a connector that allows relaying by IP. One can control access out by firewall rules. For "option 1" (username/password) you have to enable SMTP AUTH for your account or for your tenant, and use 587. In pfSense, despite the web page saying to set "TLS/StartTLS" to "enabled" you have to uncheck the TLS option and use 587 as @viragomann suggested. "option 2" also is easy to set up but you can only send to your domain...however you can set up a distribution list to send to external addresses. @Gertjan said in notification: microsoft.com really told you to use 465 I think you misread, he said to use 587 not 465. :) Never mind I didn't realize you were responding to OP there.

Yup, it is still possible, I have some systems here running from CF. But, yes, you need to take steps to avoid excess writes. In addition to use UFS and ramdisks I would also remove the SWAP partition at install. Do not run packages that write a lot of logs. I will also add the CF is almost unbelievably slow! So be prepared for upgrades to take waaaay longer than you expect. Normal boot and running is fine though. Steve

We are currently testing it internally but there are quite a few moving parts so I anticipate a few test cycles before we have anything ready for customers. Hard to be more precise than that right now. As soon as we can though. Steve

@stephenw10 Aye, not exactly a burning community issue, and given this is home easy enough to do what I've done. If this warrants effort on your side in the future, I'm happy to help further.

@coolspot said in dpinger latency vs. ping from command ping?: Any ideas why dpinger reports a higher RTT and RTTsd than a command prompt ping? You always need to set the source IP for ping to ensure you are using the expected interface regardless of routes. See the -S option to ping. NB: Static routes are optional. See System / Advanced / Miscellaneous / Gateway Monitoring. With default parameters for command line ping, you are averaging a small number of packets, once per second. With default parameters for dpinger, you are averaging 116-120 packets spread over 60 seconds. The packets are also dramatically different sizes. Google's 8.8.8.8 and 8.8.4.4 are not really very good for monitoring anymore. Lots of variance, particularly on 8.8.8.8. If you really need to go out across the internet, try Cloudflare (1.1.1.1) instead. That you have such a high standard deviation on your WAN indicates that something between you and the monitoring target is not very stable.

Yeah, I can replicate that. Let's see....

Oh OK you're just bypassing for all rfc1918. That's fine. Nothing you have set there looks like a problem.

The drive showing > 100% usage with UFS is not that unusual as UFS has some "extra" space it holds, it just means that it's really full when it hits around what you see there. Something you have must be holding open a log file somewhere that's consuming the space. If it goes away on reboot then it may be files in /tmp as well. You'd have to inspect the contents of the filesystem when it's close to full to see what is using the space. https://docs.netgate.com/pfsense/en/latest/troubleshooting/filesystem-usage.html It's also possible the filesystem has some slight corruption that is making the numbers look off from reality, and running a manual filesystem check may help: https://docs.netgate.com/pfsense/en/latest/troubleshooting/filesystem-check.html If/when you do reinstall, you're probably better off moving to ZFS, but that wouldn't help if something is actually filling up the disk.

Yes you could use two 1G links in a lagg. You won't see 2G for a single connection though.

@stephenw10 said in PFsense monitoring (Centralized monitoring) over WAN: We have our own solution in the works but no ETA for that yet. You always leaving us on a cliff-hanger

@stephenw10 Interesting..Must be a v9 thing then. Thanks for checking.

@stephenw10 its gone now I had to reboot all devices since then there has been no more entries like that.

@Thondwe said in Hardware Failure Transfer NDI (question): And a separate trial option with a 30 day expiration or similar for dev/test/setup check... This would be great, in the old days (2 weeks ago) I would test things on my old desktop pfSense+, now I cross fingers and hope.

@stephenw10 Thanks so much, Stephen, for your excellent help!

Problem solved. Disk was full.... Took me a few minutes to figure that one out...