Problems getting to adobe.com
2007-12-25 11:41:00
The original problem:
--------------------------
We're having problems getting to www.adobe.com. When we go there all we
get is a "Host contacted, waiting for reply". When we telnet to port 80 of
www.adobe.com from the firewall machine and do a "GET /" it just sits
there. We're not having this problem with any other site. Snoop isn't
really helping. We have an engineer onsite right now doing a sniff of the
network.
It doesn't seem to be fw-1 related since we can shut down the firewall and
we have the same problem, but I'm scrambling for answers here and asking
everyplace I can think of.
We're running the Sun version of fw-1, version 3.0b Build 3032. It's
running on an Ultra/2 with 128MB RAM, Solaris 2.6, and two token ring cards
(tri/s 3.0.2 with patches). Other UNIX and NT (we don't have any other Sun
machines at this facility) machines off the same MAU can get to
www.adobe.com. We can get to other web servers at adobe from this machine.
It's a very bizarre problem. We've had a ticket open with Sun since
Friday and they are pretty much stumped as well.
All addresses have in-addr.arpa delegation and resolve cleanly.
---------------------------
Here's the summary of the problem/resolution:
When negotiating the initial TCP session, Adobe's web server was setting
the don't-fragment bit in the initial SYN-ACK combination. What this means
is that any packet sent between the two machines can not be fragmented.
Also, during the initial SYN-ACK combination our firewall was negotiating a
frame size of 2012 bytes with Adobe's web server. Adobe's web server
agreed to this frame size, but instead used a larger frame size than
specified when sending the initial HTTP data back to our firewall. When
transmitting small messages (ie web server error messages, etc) the
traffic would make it back to OMH fine. When large messages ( ie HTTP
Data, etc) would be transmitted to OMH they would not make it. The
solution to the problem was to set the MTU (Maximum Transmission Unit) on
our firewall down to 576 bytes. Once this was completed, the firewall and
Adobe's web site agreed to a maximum packet size of 576 bytes. This fixed
the problem, but does not offer maximized performance from the firewall.
Currently we are pursuing a better solution to this problem with Adobe.
Gotta love snoops.
Chris
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chris Labatt-Simon Internet: labatt@disaster.com
D & D Consulting, Ltd.
100 State Street PHONE: (518) 462-0900
Albany, NY 12207 FAX: (518) 432-1829
For info on D&D, mail to info@disaster.com or http://www.disaster.com/
INTERNET/UNIX/SECURITY/LOCAL AND WIDE AREA NETWORK/ISP SPECIALISTS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comments
Got something to say?
You must be logged in to post a comment.
