1. Home
  2. Networking Firewalls
  3. Firewall possibly dropping POST form data

Firewall possibly dropping POST form data

I run a website that has forms (non-SSL) that cannot be properly submitted by a few of my customers. The problem can be easily reproduced using a small test form, and occurs only when the size of the POST data exceeds more than a couple of KB. It looks like the customer's end is dropping some of the form data packets, so the server at my end and their Internet explorer eventually times out. I have run an ethernet packet analyzer (Ethereal) and can see the gaps in the data packets during the test.

The problem continues even if I totally switch server environments at my end for the test (Linux to WinXP, Apache to IIS, swapped router and ADSL modem). I could not test non-IE browsers at the client end.

I suspect the problem is still at my end as these customers don't have this problem when they access other sites to submit forms with large amounts of POST data. However, the problem goes away if they bypass their firewall (i.e. if a laptop user dials up directly to the internet to access my site).

Has anyone experienced this kind of problem or have recommendations? Could their firewall (most testing was through a Symantec_Web_Security

3.0.0.52) somehow be doing this? Could my ISP be causing this (a compatibility between my ISP and their firewall behaviour)?

Tom

Reply to
Tom
Loading thread data ...

It isn't completely clear from what you post as to whether you have a firewall on your end ?

The behaviour you describe is what I would expect if ICMP Fragmentation Needed messages are being generated by something along the route, but those messages are not getting back to the other end. (ICMP FragNeeded is a specialization of ICMP Unreachable.)

It -could- happen at the ISP level, but not too many ISPs are foolish enough to filter those messages (well, not after the first few thousand complaints.) It is, though, a common mistake in configuring LAN firewalls: people tend to think of all icmp except ECHO REPLY as being "unsolicited" and thus something that needs to be blocked.

Reply to
Walter Roberson

My end is normally a DLINK 704 router/firewall. As part of the testing, I swapped it out for a (very cheap) AERO router/firewall and the problem continued.

My firewall was configured to allow ICMP Pings, which I confirmed works using

formatting link
You say that this may not be enough, so I have just enabled a firewall rule to allow all ICMP protocols from the WAN to get through. I will see if this works.

Thanks for your help. Tom

Reply to
Tom

Update on this .. Allowing all ICMP traffic to pass through my firewall did not help. Besides, since 95% of my other clients do not experience this problem I suspected that it wouldn't make a difference.

Possibly, it's a HTTP1.0 to HTTP1.1 compatibility problem. I notice the working clients have the SERVER_PROTOCOL as HTTP/1.1. The problem clients going through their firewall shows the SERVER_PROTOCOL as HTTP/1.0.

Tom

Reply to
Tom

cgi processing is usually limited/configured by the specific cgi processor, eg PHP is configured by

; Maximum size of POST data that PHP will accept. post_max_size = 1M

; Maximum allowed size for uploaded files. upload_max_filesize = 2M

this is due to the language processor must acquire the buffer into which the POST data will be read and held so as to pass it to the FORM ACTION program.

Reply to
Jeff B

The forms that are failing are nowhere near that size -- only about

2KB.

I have done network traces and can see that most sites chunk the POST data into two network packets. For the trouble sites -- for every test

-- I only see the second packet and the first is lost. The webserver continues to wait for the first packet to arrive but eventually times out.

Why would certain firewalls drop part of the payload? The failing customer I am currently testing with has a HTTP_VIA signature of WEBSENSE01SA, 1.0 Symantec_Web_Security (3.0.1.76), which appears to be a combination of Websense Enterprise and Symantec products.

Tom

Reply to
Tom

WEBSENSE operates in parallel: the initial packet is permitted to go out, but in the meantime the WEBSENSE server is checked, and if the site is not allowed then the security gateway sends a RST to the client.

The behaviour you have described is consistant with your site being blocked by an HTTP filter that is peaking into the first packet and seeing something it doesn't like there, but doesn't keep enough state to know that the second packet (which doesn't have complete headers) shouldn't be allowed through.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.