Safari and Sonicwall

Recently, some networks that I've implemented Sonicwall devices on had a peculiarity. Mac clients running Safari wouldn't load certain pages. Any other browser would be fine. Knowing that Safari links itself to frameworks in OS X that others do not, I thought I'd start there - particularly with lookupd. That was a dead end, though. So, I started some packet captures.

From there, I could see the requests and responses (SYN, ACK, SYN/ACK) and then, the Sonicwall itself would drop the client conversation. What the heck was going on?

After a lot of poking around, I remembered that there's a 'hidden' settings page in Sonicwall devices. Simply go to http://your.ip.address/diag.html. Click on "Internal Settings" in the navigation menu. Then, please note the initial warning on the page:

"Internal Settings - to be used only at the direction of Technical Support

Warning: these settings are not documented and changing settings here could prevent proper operation of the SonicWALL. Only make such changes if instructed by SonicWALL technical support."

Seriously: don't go changing settings that you're unsure of. If you plan on forging ahead, you may want to have a dump of your config.

Scanning through the options here, I didn't see anything obvious - until I started using the tool-tip items for each choice. The " Enforce Host Tag Search for CFS" setting had this in the tool-tip:

"When CFS is enabled, the device performs additional processing and searches the host tags in HTTP headers. At times, HTTP requests may be spread across several packets with the host tag appearing in a later packet. The host tag search algorithm can encounter a problem if this happens unless this checkbox is disabled. This checkbox should be turned off if the following message in the log is seen: HTTP method detected. Examine stream for host header."

Figure 1 - Advanced setting that makes life better for Safari.

Now, I never did receive that message in the log, but this made sense. Going back and looking at the packet trace, I could see that Safari tended to split up long URLs across packets where other browsers do not, which makes the Sonicwall CFS engine flip out. Here's the bizarre thing: I never use CFS! It's a separate license, and it's not enabled on any Sonicwall I touch. None-the-less, the CFS engine seems to always be engaged.

This is confirmed on SonicOS Enhanced 4.0.0.1-49e, and noted missing on SonicOS 2.x, so, your results may vary.

Strangely, I found nothing about this in any of my searches, even though people - other tech types - have asked me about it. Hope this helps someone out there!