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.

Snort is already in legacy mode. I just force updated the rules. Let's see..

Send me your NDI in chat and I'll check it.

To be clear the pkg is installed by default on a clean Plus install since 23.05. In the same way as the ipsec-profile-wizard and aws-wizard packages are.

If you upgraded from CE then the same installed package list would be carried across which may or may not include wireguard.

Yeah you could certainly ask in the WG sub. Someone has probably tried that.

@felipefonsecabh said in Access service in device connected via IPSEC trought public IP:

I have change local network to Any to carry traffic from any external IP?

Yes, if you are using policy based IPSec and need to keep using that. The policy has to match that traffic and the source IP could be any IP.

But if you do that it will match traffic at the other end for 'any' destination. All traffic from site1 will go over the IPSec tunnel. Which you probably don't want.

A route based VPN tunnel of some sort would give you more options.

@Gertjan yep. Couldn’t watch YouTube any other way.