RE: Can "no ip unreachables" commmand break Citrix traffic?

From: Tony Varriale (tvarriale@flamboyaninc.com)
Date: Mon Mar 31 2008 - 11:08:00 ART


I like your response.

In general, if you really think it's a security risk, take a few minutes to
think of why it's a bad idea overall to disable them. Don't just do what
some supposed expert thinks. Believe me, there are many more intelligent
people/people with real experience that think the opposite.

Also, think of forcing MTU everywhere as putting host entries in your hosts
file. Only do it if you really really need to. Just because that option is
there doesn't mean you should throw it around like a rag doll.

Tony

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Dale
Shaw
Sent: Monday, March 31, 2008 2:38 AM
To: Joseph Brunner
Cc: Matemane, Walter; ccielab@groupstudy.com
Subject: Re: Can "no ip unreachables" commmand break Citrix traffic?

Hi all,

On Mon, Mar 31, 2008 at 6:19 PM, Joseph Brunner <joe@affirmedsystems.com>
wrote:
> I suspect your issue was MTU. The unreachables were reporting
fragmentation
> needed...

Yep, disabling ICMP unreachables can break TCP's Path MTU Discovery
(PMTU-D) function. Like Joe, I suspect that's what was happening here
-- the router needed to fragment a HTTP (tcp/80) or ICA (tcp/1494?)
packet, but the "Don't Fragment" (DF) bit was set in the TCP header.
Normally a router will generate a "fragment needed but DF bit set"
ICMP unreachable (type 3, code 4 -- see
http://www.iana.org/assignments/icmp-parameters), which the sender
will respond to. However, with "no ip unreachables" configured, the
router never generates this message, the sending host never knows it
needs to change its behaviour, and things generally go to mud
(timeouts, app lock-ups etc.)

> A better approach is to disable unreachables, as they are considered a
> security risk... and to enable "ip tcp mss-adjust 1380" on the client
facing
> ce
> Interfaces, and limit the "ip mtu 1412"

Are unreachables really considered a security risk? If they were, are
they still? I personally consider some ICMP types, unreachables
included, a key part of a well-functioning network. Maybe you'd
consider restricting unreachables in certain parts of your network, or
in certain directions, or (if you can) limit the specific sub-codes,
but disable them completely? Not on my network - at least not in the
soft gooey centre.

TCP MSS adjustment, while quite clever, obviously only affect
TCP-based protocols. Any non-TCP transports that have a big enough
payload to exceed the interface MTU might need ICMP unreachables to
work at all (I can't think of a good example at the moment).

BTW, slight correction: the command is "ip tcp adjust-mss <value>"

> You want to force the clients to use smaller mtu earlier on, to avoid
> "dumbbell" mtu issues as they route through the cloud.

I agree with this -- sometimes it's just less torture to drop the MTU
on individual hosts. You'll find most VPN clients (Cisco's included)
automagically drop the client's MTU prior to establishing a
connection. Having said all that, I don't know why the OP is having
MTU troubles with the configuration shown - there doesn't seem to be
anything configured on those interfaces that would introduce overhead
typically associated with PMTU-D problems (IPSec, PPPoE etc.). Would
probably need to see a more complete config.

> -Joe

cheers,
Dale



This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:55 ART