Re: PIX mss exceeded browsing netware 6.5 apache

Question

Massimo Rosen skrev:
> Hi,
>
> Jonas Augustine wrote:
>> we are running our web on a netware 6.5 server with apache. PIX users
>> with latest software on PIX can not browse our site anymore because of
>> mss exceeded. It works fine our windows servers with IIS.
>
> Well, first things first, how do you know it's a MSS alias MTU problem?
> And if you already know this, you most likely ad to have traces taken
> that show it, and that should mean you already know why the MSS problem
> occured too?
>
> Anyways, for MTU problem to occur, *all* of the follwoing must be true:
>
> 1. The to be transfered packets must have DF (don't fragment) set. This
> is usually the case today with most TCP apps, so we can use that as a
> given.
>
> 2. The sender and final receipient of the connection have to agree on a
> bigger MTU than some of the *intermediate* routers between them are able
> to transfer.
>
> 3. ICMP packets are either blocked somewhere, *or* the router which has
> the smaller MTU (see point 2) is completely misconfigured to not sent
> ICMP messages telling the sender that it's MTU is too big.
>
> 4. The sender of the too big packets must have TCP blackhole detection
> disabled.
>
> The best way to attack this problem is to solve #3, if that really turns
> out it's impossible (and some firewall lunatic that claims that ICMP is
> evil is no reason for it being impossible), then #4. On Netware, that's:
>
> "Set TCP Path MTU Black Hole Detection and Recovery=on"
>
> Note that this will badly increase timeout times on connections that
> really aren't working properly, that's why it's a last resort setting.
>
> CU,
Hi
log from PIX firewall when connecting to http://www.perstorp.se (netware
6.5 apache)
Dropping TCP packet from outside:194.23.101.3/80 to
inside:193.17.67.1/55747, reason: MSS exceeded, MSS 1380, data 1460
IT-PC27 Accessed URL 194.23.101.3:/
Answer to point 2 from Cisco:
The 7.0 release introduces several new security enhancements, one of
which is a check for TCP endpoints which adhere to the advertised
Maximum Segment Size (MSS). In a normal TCP session, the client sends a
SYN packet to the server, with the MSS included within the TCP options
of the SYN packet. The server, upon receipt of the SYN packet, should
recognize the MSS value sent by the client and then send its own MSS
value in the SYN-ACK packet. Once both the client and the server are
aware of each other's MSS, neither peer should send a packet to the
other that is greater than that peer's MSS. A discovery has been made
that there are a few HTTP servers on the Internet that do not honor the
MSS that the client advertises. Subsequently, the HTTP server sends data
packets to the client that are larger than the advertised MSS. Before
release 7.0, these packets were allowed through the PIX Security
Appliance. With the security enhancement included in the 7.0 software
release, these packets are dropped by default.
Complete URL from Cisco:
http://www.cisco.com/en/US/products/...804c8b9f.shtml
I will try "Set TCP Path MTU Black Hole Detection and Recovery=on" !
/Jonas

Answer 1

Jonas Augustine skrev:
> Massimo Rosen skrev:
>> Hi,
>>
>> Jonas Augustine wrote:
>>> we are running our web on a netware 6.5 server with apache. PIX users
>>> with latest software on PIX can not browse our site anymore because of
>>> mss exceeded. It works fine our windows servers with IIS.
>>
>> Well, first things first, how do you know it's a MSS alias MTU problem?
>> And if you already know this, you most likely ad to have traces taken
>> that show it, and that should mean you already know why the MSS problem
>> occured too?
>>
>> Anyways, for MTU problem to occur, *all* of the follwoing must be true:
>>
>> 1. The to be transfered packets must have DF (don't fragment) set. This
>> is usually the case today with most TCP apps, so we can use that as a
>> given.
>>
>> 2. The sender and final receipient of the connection have to agree on a
>> bigger MTU than some of the *intermediate* routers between them are able
>> to transfer.
>> 3. ICMP packets are either blocked somewhere, *or* the router which has
>> the smaller MTU (see point 2) is completely misconfigured to not sent
>> ICMP messages telling the sender that it's MTU is too big.
>>
>> 4. The sender of the too big packets must have TCP blackhole detection
>> disabled.
>>
>> The best way to attack this problem is to solve #3, if that really turns
>> out it's impossible (and some firewall lunatic that claims that ICMP is
>> evil is no reason for it being impossible), then #4. On Netware, that's:
>>
>> "Set TCP Path MTU Black Hole Detection and Recovery=on"
>>
>> Note that this will badly increase timeout times on connections that
>> really aren't working properly, that's why it's a last resort setting.
>>
>> CU,
>
> Hi
>
> log from PIX firewall when connecting to http://www.perstorp.se (netware
> 6.5 apache)
> Dropping TCP packet from outside:194.23.101.3/80 to
> inside:193.17.67.1/55747, reason: MSS exceeded, MSS 1380, data 1460
> IT-PC27 Accessed URL 194.23.101.3:/
>
>
>
> Answer to point 2 from Cisco:
> The 7.0 release introduces several new security enhancements, one of
> which is a check for TCP endpoints which adhere to the advertised
> Maximum Segment Size (MSS). In a normal TCP session, the client sends a
> SYN packet to the server, with the MSS included within the TCP options
> of the SYN packet. The server, upon receipt of the SYN packet, should
> recognize the MSS value sent by the client and then send its own MSS
> value in the SYN-ACK packet. Once both the client and the server are
> aware of each other's MSS, neither peer should send a packet to the
> other that is greater than that peer's MSS. A discovery has been made
> that there are a few HTTP servers on the Internet that do not honor the
> MSS that the client advertises. Subsequently, the HTTP server sends data
> packets to the client that are larger than the advertised MSS. Before
> release 7.0, these packets were allowed through the PIX Security
> Appliance. With the security enhancement included in the 7.0 software
> release, these packets are dropped by default.
>
>
> Complete URL from Cisco:
> http://www.cisco.com/en/US/products/...804c8b9f.shtml
>
>
> I will try "Set TCP Path MTU Black Hole Detection and Recovery=on" !
>
> /Jonas
I have talked to the customer and we have decided to migrate the server
to SLES.
I will still try "Set TCP Path MTU Black Hole Detection and Recovery=on"
before migrate..
/Jonas