Re: PIX randomizing TCP sequence in ICMP Frag packets

sergey.klusov · ‎03-07-2008

I have a PIX-515E, Software Version 7.2(1) with NAT disabled, in router mode, and almost all inspection off. REcently i noticed that PIX randomizing TCP sequence in ICMP Frag embedded message, that is last 4 bytes of the packet. Looks like windows hosts are okay with that, BUT i have some unix boxes and looks like they use TCP Seq header part for PathMTU discovery process. Is there some way to disable this randomization?

Here is tcpdump of packet before and after passing PIX:

this is packet from router with lower mtu just before PIX

10:32:54.775244 00:1c:f6:2e:4b:6f > 00:1d:45:21:a6:51, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 255, id 18463, offset 0, flags [none],

proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36

(tos 0x8, ttl 61, id 2080, offset 0, flags [DF], proto: TCP (6),

length: 1420) 10.23.0.241.22 > 10.35.1.3.64856: tcp 1384 [bad hdr length 16

- too short, < 20]

0x0000: 4500 0038 481f 0000 ff01 5984 0a17 0503 E..8H.....Y.....

0x0010: 0a17 00f1 0304 bdf6 0000 0500 4508 058c ............E...

0x0020: 0820 4000 3d06 1a17 0a17 00f1 0a23 0103 ..@.=........#..

0x0030: 0016 fd58 2723 1573 ...X'#.s

--------------------------^^^^^^^^^^^

note the bytes

and this is the same packet _after_ PIX

10:32:54.775492 00:1d:45:21:a6:52 > 00:1b:78:e3:c7:66, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 255, id 18463, offset 0, flags [none],

proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36

(tos 0x8, ttl 61, id 2080, offset 0, flags [DF], proto: TCP (6),

length: 1420) 10.23.0.241.22 > 10.35.1.3.64856: tcp 1400 [bad hdr length 0

- too short, < 20]

0x0000: 4500 0038 481f 0000 ff01 5984 0a17 0503 E..8H.....Y.....

0x0010: 0a17 00f1 0304 a065 0000 0500 4508 058c .......e....E...

0x0020: 0820 4000 3d06 1a17 0a17 00f1 0a23 0103 ..@.=........#..

0x0030: 0016 fd58 2e89 2b9e ...X..+.

---------------------------^^^^^^^^^

bytes changed

amritpatek · ‎03-13-2008

The PIX altering the initial sequence number of the TCP SYN segment sent by the server is the normal (default) behavior for packets going from a higher security interface to a lower security interface (like in your case.) When going from a lower security interface to a higher security interface, the PIX does not randomize the initial sequence number. You are correct that Linux/Unix will drop ICMP messages that have TCP sequence numbers that fall outside the expected range, i.e. packets that have been sent and not yet acknowledged (in-flight packets).

As a resolution the PIX can be told to not to randomization of the TCP sequence number by adding the "norandomseq" keyword to the "nat" statements.

sergey.klusov · ‎03-13-2008

Thanks for reply.

Actually i solved this issue by specifying this:

class-map global-class

match any

!

policy-map global-policy

class global-class

set connection random-sequence-number disable

as i said before, i have NAT disabled.