cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1154
Views
0
Helpful
4
Replies

Problem with ICMP Type3, code4 fragmentation needed

solfitadm
Level 1
Level 1

After upgrading PIX 6.3 to 7.0(2), we have the following problem, that the request for fragmentation from the MTU to a lower size is not working:

a) we've enabled the Destination unreachable on the particular interface

b) we've deactivated ICMP and ICMP Error inspection

which did not help.

Only the command 'sysopt connection tcpmss 1280' helped us (as we know the max limit of the tcp segment) in this particular case (which shouldn’t be the final solution)

We’ve learned that there were vulnerabilities with this kind of ICMP packages which are solved in the 7.0 release. But how can we enable a working PMTUD again ?

4 Replies 4

ciscopixguy
Level 1
Level 1

Hi,

When you say you enabled unreachables on the outside interface, do you mean?

icmp permit any unreachable outside

The icmp command only enables the PIX outside interface to participate in PMTU discovery.

You also need an access-list permiting unreachables on the outside interface.

access-list inbound permit icmp any any unreachable

In summary, the "icmp" command filters icmp going TO the PIX interfaces, while access-list filters icmp going THROUGH the PIX.

Hope this helps,

Dave

Hi Dave,

unfortunately no.... I have the following rules:

a) access-list outside_in line 2 extended permit icmp any any unreachable (hitcnt=4)

Where outside_in is the outside interface. As you might see, the rule is used, but unfortunately not in the right way....

b) show running-config icmp

icmp permit host 192.168.1.3 time-exceeded outside

icmp permit host 192.168.1.3 unreachable outside

(192.168.1.3 is sender of the ICMP requests)

But it doesn't resize the segment size to the requested 1350, which perfectly worked with the 6.3 version and the identical setup. I've read about a security hole of the 6.3 version (DoS attack) which is solved in the 7.0 release. Has this something to do with it ?

Thanks for your support!

Hi Dave,

in addition, the following interface capture:

1055: 10:03:47.166007 192.168.2.106.2273 > 192.238.1.11.1433: . 2109365183:2109366563(1380) ack 787131515 win 64624

1056: 10:03:47.168982 192.168.1.3 > 192.168.2.106: icmp: 192.238.1.11 unreachable - need to frag (mtu 1350)

1414: 10:03:56.791249 192.168.2.106.2273 > 192.238.1.11.1433: . 2109365183:2109366563(1380) ack 787131515 win 64624

1419: 10:03:56.795689 192.168.1.3 > 192.168.2.106: icmp: 192.238.1.11 unreachable - need to frag (mtu 1350)

2458: 10:04:10.356243 192.168.2.106.2254 > 192.238.1.11.1433: . 3906280277:3906280278(1) ack 2583806140 win 65155

2468: 10:04:10.380229 192.238.1.11.1433 > 192.168.2.106.2254: . ack 3906280278 win 24840

As you see, without setting the sysopt tcpmss to a lower value than 1350, the segments are not reduced, which was the case before....

Cheers,

Remo

Hi Remo,

If the device in your trace is a host on the inside, the PIX should merely "pass" the unreachable message to the inside host. It is up to the host to read the ICMP message and reduce its MTU for connections to that network. If the PIX modified the MTU, I would call it a bug.

Am I understanding the problem correctly?

Regards,

Dave