more SonicWALL "issues"

So tell me, who can access the following site without problems?

http://www.oid.state.ok.us/

It's causing me some "issues" here at the office. The strange thing is it has worked "fine" before. OID's support, while polite and willing to stay on the phone as long as needed, was of little help. She said there were a couple of other customers that had seen the same issue before, but nothing was done one "her end" and it finally started working.

Symtoms include the following:
- using Opera as a browser the first page will load in approx 30 minutes
- using IE or Firefox it times out in approx 7 minutes
- placing a laptop "outside" our lovely SonicWALL firewall, using IE or Firefox I can access the site no problem

Of course the SonicWALL is the obvious culprit, but like I said before, it's worked in the past. What's changed, right? Ideas anyone?

Not..gonna...do...it :)

That site will not come up :)

Just as reference, do you know what type of firewall device you are behind?

righty-o! cyberguard my friend cyberguard :)

Regardless of what she said, it's on their end. And you know that it pains me to say that, because I would dearly love to blame it on the SonicWall. :twisted:

I tried hitting their site fairly soon after your post. It took 20 seconds for their server to respond - my packet capture confirmed this as well. I'm just behind Linux/iptables, but nothing was getting dropped on my end. It loads fine now.

and yet if he puts a lappy outside the sonicwall it loads up lickety split.

btw, it loads up just fine for me: firefox on linux, no separate firewall (just my default iptables -P INPUT DROP , iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT)

also note that that site is only 7 hops from me here, all on the onenet network.

when all else fails, whip out ethereal.

Ok, here are the packet captures for anyone feeling....

ftp://ftp.ofumic.com/worky.pkt
ftp://ftp.ofumic.com/noworky.pkt

either something is REALLY messed up or that's not the whole packet capture there in the "noworky" one. looks like you started the capture too late (?)

Thanks for taking a look at it. I'm certain I began the capture before requesting the page. I have very little formal or real life experience evaluating packet captures, though I find it very interesting.

The first thing I noticed that was different was the first packet. There are TSV= and TSER= flags for the noworky.pkt file, but these flags don't exist on the worky.pkt file. What does this mean, anything?

there's really nothing to reading a packet capture. it's all perfectly logical, and laid out there in chronological order for easy analysis. now, in the "worky" one, we see just what we would expect: a TCP handshake, then an HTTP GET. I don't see any of that in the "noworky" one. first HTTP packet I see there is marked continuation. so, something is definitely not right. maybe my download was corrupted. let me grab it again... nope, looks the same as it did yesterday.

anyhoo, in the noworky capture it looks like the client machine is trying to initiate a TCP handshake, but the sever machine is replying back with stuff that doesn't make sense. yeah, the ACK bit is set, but why the heck is there HTTP data in the payload?!? so the client machine tries again, and again. eventually sends a RST, and then tries again and again, and never gets the handshake completed.

and now, looking at the worky capture again, I see that there's the same messed up behavior at the very beginning: client sends a SYN and the server responds with crap, but in that case, a RST is immediately sent, and the next handshake attempt works.


this is indeed very weird. unfortunately, if this capture was taken on the client machine, you can't know for sure what the sonicwall is doing to your packets. ultimately, you'd need to sniff the wire at both ends to know for 100% certain what's going on. you can approach 100% certainty though, by sniffing on the outside interface of the sonicwall (or perhaps at the next hop).