Snapchat - Host Not Found

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"...

I got the same problem and this works for me.

Adding exeption for ^https?://([A-Za-z0-9.-]*\.)?feelinsonice\.com/ does not work

Is there a way to use an exeption rule that works?

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.

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

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