It looks like the issue is caused by two things:
1) There is no DNS entry for "www.feelinsonice.com"
2) The "Pharming protection" feature of the web filtering proxy is broken...
Here is how I worked around these problems:
1) Create a static DNS entry for "www.feelinsonice.com" pointing to IP address "74.6.34.30'
2) In the Sophos UTM web management GUI go to "Web Protection" -> "Filtering Options" -> "Misc" tab. Scroll down to the bottom and deselect / disable "Enable Pharming protection"...
RobertAdelman said:So far the only way to get snap chat to work is to got Webprotection then to Filtering options then to Misc and scroll to the bottom and uncheck Pharming Protection. No exceptions or settings seem to work.
I was able to work around this in UTM 9 without disabling Pharming Protection. Am still a bit unclear what exactly worked.
I have confirmed this in SFOS and 99% sure it is the same in UTM.
In this case:
client makes a tcp connection to 146.148.72.110:443
the connection has SNI of www.feelinsonice.com
Because pharming protection is on, UTM does not trust that www.feelinsonice.com is really 146.148.72.110
UTM does dns lookup for www.feelinsonice.com
DNS lookup fails
UTM cannot connect to the far server because it is unresolvable
UTM does SSL handshake with client using its own CA to present error message.
There are two workarounds:
Workaround 1: turn off pharming protection
Workaround 2: Go to Network Definitions and add a Host object, making sure to fill in the ipv4 address and the DNS settings for Hostname.
146.148.72.110 www.feelinsonice.com
Note: For all I know snapchat has its own weird way of choosing where to connect to. I know that in one instance 146.148.72.110 was the destination. A "more correct" solution would be to tcpdump or turn on additional logging so that you can determine what ip your snapchat is connecting to, in case there are regional differences.
Thanks Michael Dunn for this insight. This made me think of a similar issue I was having and couldn't find a fix (ended up disabling HTTPS scanning altogether). Not ideal.
With some mobile apps, I can filter in Livelog the traffic to and from a specific IP within web filtering. However there have been cases where a mobile app, for example American Express Serve app, is unable to login to a user account with filtering enabled. When I view the web filtering log for anomalies and blocked pages, there are none. It's as if the web filtering log isn't complete or detailed enough for me to identify urls/pages for which I need to add other exceptions.
Is there additional web filtering that can be enabled?
There is additional logging that dev or support can turn on, however at this time I don't know if that is public information. It opens up another can of worms, and the developer level logging may lead you down wrong paths of understanding.
However what you can do is use WireShark or Fiddler to watch all your traffic. WireShark is a tcpdump so you can see all HTTP, DNS, and other traffic leaving your client machine, however inspecting HTTPS is a pain. Fiddler is a windows on-box proxy that lets you monitor all HTTP and HTTPS traffic, but it makes the traffic standard mode and not transparent mode.
For mobile apps, run tcpdump on the box then copy it to Windows and read the logs in WireShark.
Michael Dunn said:For mobile apps, run tcpdump on the box then copy it to Windows and read the logs in WireShark.
Appreciate the recommendation. Does tcpdump show the traffic in numeric IP addresses (1.2.3.4) or does it resolve it to FQDNs (server.microsoft.com)? I'll give it a try!
tcpdump will dump the raw tcp packets including the source and destination ip and port.
Then after the packet capture you need to read those packets. The linux tcpdump command line tool can do some things but it is better to load that capture into a graphical tool such as WireShark. I'm not sure, but I suspect wireshark could resolve the ip's for you however they would be resolved at the time of displaying the log, not resolved by the SFOS box during capture - since during capture there are no hostnames.
ask.wireshark.org/.../can-wireshark-automatically-resolve-the-ip-address-into-host-names
I'm adding in my experience on this list since my ultimate solution, that I tried to trim back to the bare minimum (with a quasi-patient teenager breathing down my neck) is slightly different (at least in the final combination of settings) to some of the earlier posts.
In case this makes a difference, I am running UTM (virtual) with firmware version: 9.502-4.
First of all I should note that I have in place a firewall exception for my kids' Apple devices using Any protocol to Apple's IP range (17.0.0.0/8).
Secondly, my Web filter is running in Transparent mode.
Now, for Snapchat, the settings that I found that worked for us (verified by the teenager, including for various sub-functions in Snapchat, so not just logging in) are:
1. Web Protection --> Filtering Options --> Misc --> [ ] Enable Pharming Protection (un-checked).
2. Web Protection --> Filtering Options --> Exceptions
^https?://([A-Za-z0-9.-]*\.)?feelinsonice\.com/?(.+)
^https?://([A-Za-z0-9.-]*\.)?snapchat\.com/?(.+)
Skipping: Antivirus / SLL scanning / Certificate trust check / Certificate date check.
Antivirus is only included since the teenager claimed that Snapchat messages were really slow. I added Antivirus to the list of things to skip and she said it was good again. The exceptions are definitely needed for us. Turning off pharming protection alone was not sufficient.
After getting things working I further examined other settings including testing re-enabling Pharming Protection, however, when I do that it always stops Snapchat from working, even when using a static entry for www.feelinsonice.com (where I used 74.6.34.30 from earlier in the thread). When using the static entry it solves the "host not found" issue in the log, but even though the host IP is resolved (dstip in the log), the action is still blocked, presumably, and based on reading the above replies, due to the pharming check overriding the static entry. (I agree that it seems like the static entry should be immune to the pharming check and for now it seems like a static entry is redundant for this use case).
So I guess I have to accept that Pharming protection is off for now.
I don't think this is a huge issue(?).
Better than adding the iPhone to the transparent mode skip list, I would assume and,
Much better than not having web filtering enabled at all!
But you all tell me!
In the meantime I've double checked that at least all home PCs have LMHOSTS disabled for their network adapters.
EDIT: Today I found that I also needed the following exception for "stories" in Snapchat, whatever they are.
^https?://cf-st.sc-cdn.net/?(.+)
FYI, in an upcoming MR (I don't know the schedule) we will change it so that you do not need to turn off pharming protection.
I have not heard of a problem where you would require the exception, and I would try without it. However leaving it is place is not a big risk.
For reference the problem with pharming protection is:
Client does a TCP/IP connection to 74.6.34.30.
Client sends an HTTPS SNI including feelingsonice.com
UTM says "pharming protection tell me not to trust that feelingsonice.com is 74.6.34.30" so it does its own DNS lookup for feelingsonice.com
There is no DNS entry for feelingsonice.com, so it cannot connect. In the current code it does not "fall back" to the IP in the TCP/IP connection.
Thanks for the information Michael;will be good to have a fix, but I can imagine it's got to complete with everything else on the agenda.
Since you are staff, I'll just throw out there that I discovered Sophos UTM a few weeks ago (started using it perhaps 2 weeks ago after an initial play in a VM) and I have found it to be an awesome, high quality, feature rich, piece of software that comes with excellent documentation, and I am very happy that I found it. I'm also very much appreciative of the home user license. I'm planning to spread the word about this product to anyone who will listen.
Keep up the good work!
Thanks for the feedback.
SG UTM is a very high quality product that is dependable and feature rich because it has been around for years. XG is our newer product that does much of the same thing - doing some things better and admittedly some worse. Because it is a newer product it has had some more hiccups in the past and there are some who come from the UTM and don't like it because it is missing their favorite feature X. Although we are still doing development work in SG (in fact, the next few months I'm switching focus to SG) most of the cool new features will be in XG. In the next week we are starting a beta for XG v17 - I suggest you look at it as well.
Thanks for the feedback.
SG UTM is a very high quality product that is dependable and feature rich because it has been around for years. XG is our newer product that does much of the same thing - doing some things better and admittedly some worse. Because it is a newer product it has had some more hiccups in the past and there are some who come from the UTM and don't like it because it is missing their favorite feature X. Although we are still doing development work in SG (in fact, the next few months I'm switching focus to SG) most of the cool new features will be in XG. In the next week we are starting a beta for XG v17 - I suggest you look at it as well.