Netflix 4K and v17

Hi,

I solved it as follows:

1. Create/enhance the Netflix FQDN Group with the following FQDNs:

*.nflximg.com
*.nflxvideo.com
*.nflxso.com
*.netflix.com
*.nflxext.com
*.nflximg.net
*.nflxso.net
*.nflxvideo.net

2. Create a dedicated FW rule for NetFlix FQDN Group and your TV:

Services: HTTP & HTTPS

Web Malware: everything disabled

IPS: can be enabled

Web Policy: None

And now the very important hint if it is still not working: Simply retry to play the video after 1-2 minutes if it was not working at first. This is some kind of a bug with the FQDNs, I've opened a thread for this here: First FQDN host resolution happens to late when used in FW rule

Best Regards

Dom Nik

Dom Nik said:

And now the very important hint if it is still not working: Simply retry to play the video after 1-2 minutes if it was not working at first. This is some kind of a bug with the FQDNs, I've opened a thread for this here: First FQDN host resolution happens to late when used in FW rule

Hi Dom,

As of v17 MR2 this should no longer be the behavior.

I just found out that as of MR2, the XG does passive monitoring of DNS traffic.  That means that even if the device is not using the XG to do DNS, as long as the packets are flowing across the XG it should populate the FQDN Host Group correctly.  Which means that as of MR2 it should not matter if box does DNS to the same thing (as long as the DNS flows through the XG).

Is there anyone in who is currently experiencing problems with Netflix where:

Using v17 MR2 or later

Using the OOB FQDN Host Group "Netflix" as describe here: https://community.sophos.com/kb/en-us/125061

In other words, does the KB fully resolve all issues?  Or do we still have a problem?

Hi Michael,

thanks for your reply.

I'm not affected by the DNS problem as I publish my XG as DNS server through DHCP and the DNS port to WAN is not open for my clients. --> Netflix is basically working with the KB workaround (though I've added some more FQDNs to it I think).

However the problem described in my other thread is still present in MR3 and can be reproduced easily after a restart of the XG when the FQDN cache is empty. Then the FW rules with these FQDNs won't be applied on the first request that comes in. Some applications will then fail, e.g. "Outbank" for iOS/macOS or Netflix for the Amazon FireTV. After the first try you have to wait some time until the FQDN cache is filled in XG, close the app and retry afterwards.

Best Regards

Dom Nik

Reply from development:

Ok, that cause is perfectly clear to me. It’s expected behavior, and should be seen as an exceptional event. Firewall does not store learned DNS entries persistently, so after a reboot, clients may have cached DNS results that the firewall doesn’t yet know.  This should ONLY happen after a firewall reboot, which should be an uncommon occurrence

Are you finding any impacts aside from the fact that the cache is cleared on reboot?

It sometimes happens during runtime when one of the big players update their CDNs for example. This happens quite often with Netflix when streaming videos that might not be cached in locations nearby but in the US for example.

My FW is running for 14 days and has already built up a cache of 10438 IPs, yet. (Apple iCloud, Amazon Video, Netflix, Whatsapp and some iOS Apps)

When "debugging" strange behavior in blackboxed clients this is often a bit confusing with the way it works right now.

It's simply not working as reliable as the web exceptions, although it's seems to work way faster then a huge list of regex hosts and it's a very nice feature. (And IMHO that's why this thread occured.)

Although I cannot give a suggestion on how to improve this behaviour. I can confirm your opinion that keeping the cache won't be a solution...

I am lost on the logic of fqdn. Cache TTLs shouldn't have any effect on firewall behavior and yet it does. I thought the main reason to go with fqdn instead of application control was due to the fact that app control needed a few packets to classify an application which could then potentially bypass the firewall or get blocked while those initial packets are being sniffed. https://community.sophos.com/products/xg-firewall/sophos-xg-beta-programs/sfos-v170-beta/f/sfos-v170-beta-issues-bugs/96984/xg-beta2-rc1-netflix-no-longer-working-with-beta-1-no-problems/352410#352410 

I have always said fqdn is a bandaid to the problem and clearing the cache by restarting the firewall or restarting the DNS service and not taking into account that TTL (if the client decides to cache something longer than the assigned TTL) creates too many problems. I suppose a workaround could be to make the fqdn entries static to overcome the reboot/service restart cache flush but most cdns these days have TTL of 5 minutes already so I don't know how to fix this. 

I still think layer7 should be doing this and not DNS.

Application control sees the video stream as a video stream.  I don't think it detects it as the NetFlix application.  I've looked at it - the HTTP request don't even have a User Agent that declare itself to be NetFlix, there is very little at the layer7 that can tell this is NetFlix (and not some other video stream).

... So layer7 (eg deep packet inspection) cannot detect the Netflix video stream

 hmmmm, I wonder who is transferring all those files???? Great news, very little streaming media traffic so everyone is being productive.

Oh never mind, its roku streaming Netflix or amazon or hulu or who knows what. better start running whois on those IPs that we have in that colorful report[:#]

I think you proved that I'm wrong.  :)  I made a guess that both UTM and XG cannot detect the streams as Netflix, and you showed that at least UTM can.

I'm not a expert in the IPS / App Control stuff - though I know more than average.  All this is sparking some more internal discussion about what we could do.

I agree that nothing is impossible.

Hi Michael, first let me apologize for the post above. It comes across as rude and offensive now that I am reading it after a few days. That was definitely not my intent. You are one of the few sophos employees that engage with us on regular basis and my intention was not to prove you or anyone else wrong. I am always grateful to sophos for the software that they provide and every time I get involved in a discussion, its with the hope to make the software better for all of us. 

XG has great potential and I like it more now that I use it as my main firewall. My main complaints about its shortcomings are not because I want to bash sophos or XG in particular, its because we are not in v5/6 era of astaro where they took a bunch of open source daemons and tied them together with proprietary gui. A few open source firewalls provide functionality pretty close to what SG/XG offers now for free. Its a matter of how much you want to get your hands dirty and ofcourse the av scanning capabilities that only sophos can provide. I don't want sophos to get comfortable and take their foot off the gas while others are catching up. I want cutting edge technology that I know sophos is capable of providing if it focuses on what it does best.

I am all for new technologies and there is nothing wrong with snort openAppID. I cringe at the fact that sophos already knows how to classify certain things and then they go and try to redo something that has already been done by their own products. This has been happening over and over when you compare SG and XG where it seems that SG never existed and sophos doesn't even know what its own products are capable of.

Again, thank you for contributing to this forum and I for one always appreciate your feedback and expert insights.

Regards

Bill