You can trigger a notification using php like: require_once('notices.inc'); file_notice(1,"Test"); That will use all the configured notification methods including Telegram if it's set. Steve

@Gertjan Hello, Thank you for your detailed answer. I have tried to even fresh installed the VM with NIC passthrough out of the box but PFsenese takes at least 5-10 min to resolve DNS. AFter the initial time my devices connect to it can resolve DNS. However, if I leave it over night or in the morning when I turn on my computer again. PFsense is still running 24/7. It takes at least about 5 min before every device can resolve DNS again. As you have suggested, I think it may lies at my Proxmox server. I may have to install it barebones. Thank you again for your time.

@stephenw10 I dunno.... no clue, I rebuilt the 2 hyper-v adapters on the pfsense vm, the external and internal... and of course now it works. Oh well... Thanks for responding to my question!!!

Yup, the local issue was resolved. Should be good now.

Yup, local v6 routing issue has been resolved.

Ah, interesting. You might check out general IPv6 connectivity from another client then.

@stephenw10 Thank you so much.

@stephenw10 It works ! Thanks !

TLDR; We're using pi-hole for DNS, and let pfSense do all the DHCP, routing and firewalling tasks. This solution suits our use case, and has been working well for a long time. YMMV.

@tapufd said in SMTP Notifications not working anymore: I was reading some other community topics about slowness of Package Manager and Update, which I was also experiencing. smtp.office365.com has a zillion local access points, so there is always one 'nearby' (Microsoft is a big company). For me, all nearby IPv6 is working well. If IPv6 is suspected, go Ipv4 mode : telnet -4 smtp.office365.com 587 and test the other one also telnet -6 smtp.office365.com 587 If you actually use IPv6 (have a working IPv6 connection). edit : ah, ok, didn't saw your latest port. Yeap, it is probably an IPv6 issue. Where are you ? Where is - as far as you know - is the smtp.office365.com for you ?

@incith said in PfSense - Cannot connect to Netflix and Hulu on Andriod devices / Smart TVs: I disabled pfblocker and suricata. Did you read my post, where did I say it was pfblocker or suricata?? I just stated if was pfblocker it wouldn't work be it you forward in unbound or resolve - so clearly its not that, etc. You can not troubleshoot the problem if you do not know what is failing - period. So did you even look at the status of the resolver, do you see any high RTT or RTO domains? Timeouts? sniff your clients IP when you try and go to netflix or hulu to login - what is failing in the dns queries it sends out? You will see the queries, and pretty easy to tell in the sniff what did and didn't get an answer.. Once you see something that doesn't get an answer, you can look to why your not getting an answer... But until you know that, you can not figure out what the problem is.. If your not going to do that, then you might as well just have unbound forward vs resolve.. My example above was showing how I determined what the problem was, there was as specific fqdn I couldn't resolve - so via a +trace with dig I could tell where it was failing in the resolve process, it wasn't a "unbound" issue.. It was a problem outside of my control in the resolve process. First step is to know what exactly is failing.. Which you do not - you just know netflix isn't logging in..

Mmm, I'm not sure that's possible. Not globally like that at least. TCP_NODELAY looks to be a build option that you would apply to the application when it's compiled that it then applies to TCP sockets as it opens them. I could be wrong though....

Thanks Steve, will make those changes and observe. Ujjwal

Hmm, that's curious. I wonder if it could be a timing issue...

Ouch. Nice catch!

I did solve this issue some time ago.. I solved it by checking the checkbox under System - Advanced - Networking - Disable hardware checksum offload. There was some issue there as I use Realtek nic

@fjmp24 Most welcome

Yeah this likely is the same thing: https://redmine.pfsense.org/issues/14531

That would need to be done at the AP. Nothing beyond that sees the SSID.