[nycbug-talk] PF

[Miles Nordin]

>>>>> "od" == Okan Demirmen <okan at demirmen.com> writes:

    od> if you are talking about mtu path discovery...it is not a pf
    od> issue if admins don't know how to deal with this, and
    od> especially those you just like to block icmp period.

what I am saying is that I think PF creates this problem when used on
a server.

But challenged to look more closely, I think the problem is more
confusing than simple outright brokenness.  I'm not sure now if it's
PF or something else.

    od> have you read and understood pf.conf(5) completely? (it is in
    od> there)

I searched for 'MTU' in the man page and couldn't find anything about
PMTU&ICMP or the common misconfiguration and the tcp mss workaround.
The 'scrub max-mss' does not even say in the man page what is it's
purpose.  But my complaint was that you need to explicitly pass ICMP
for things to work, while the manual says the opposite:

     ICMP messages fall into two categories: ICMP error messages, which always
     refer to a TCP or UDP packet, are matched against the referred to connec-
     tion.  If one keeps state on a TCP connection, and an ICMP source quench
     message referring to this TCP connection arrives, it will be matched to
     the right state and get passed.

It looks like I was wrong either completely or at least partly.
Looking more carefully, I find that some of these ICMP need-to-frag
messages get passed just as the documentation promises:

20:45:21.071388 IP (tos 0x0, ttl 254, id 48036, offset 0, flags [none], proto: ICMP (1), length: 56) 69.31.131.57 > 10.100.100.140: ICMP 121.140.62.51 unreachable - need to frag (mtu 1476), length 36
        IP (tos 0x0, ttl  62, id 54841, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.100.100.140.41461 > 121.140.62.51.6881:  tcp 1480 [bad hdr length 0 - too short, < 20]
20:45:22.639579 IP (tos 0x0, ttl 254, id 48039, offset 0, flags [none], proto: ICMP (1), length: 56) 69.31.131.57 > 10.100.100.140: ICMP 82.28.7.59 unreachable - need to frag (mtu 1476), length 36
        IP (tos 0x0, ttl  62, id 43920, offset 0, flags [DF], proto: TCP (6), length: 1492) 10.100.100.140.52611 > 82.28.7.59.52766:  tcp 1472 [bad hdr length 0 - too short, < 20]
20:45:23.321231 IP (tos 0x0, ttl 254, id 48040, offset 0, flags [none], proto: ICMP (1), length: 56) 69.31.131.57 > 10.100.100.140: ICMP 82.224.153.188 unreachable - need to frag (mtu 1476), length 36
        IP (tos 0x0, ttl  58, id 33526, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.100.100.140.56881 > 82.224.153.188.5334:  tcp 1480 [bad hdr length 0 - too short, < 20]

while others end up blocked on pflog0:

20:45:21.804815 IP (tos 0x0, ttl 255, id 48037, offset 0, flags [none], proto: ICMP (1), length: 56) 69.31.131.57 > 10.100.100.140: ICMP 198.31.229.238 unreachable - need to frag (mtu 1476), length 36
        IP (tos 0x0, ttl  62, id 23542, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.100.100.140.36040 > 198.31.229.238.10001:  tcp 1480 [bad hdr length 0 - too short, < 20]
20:45:25.190748 IP (tos 0x0, ttl 255, id 48043, offset 0, flags [none], proto: ICMP (1), length: 56) 69.31.131.57 > 10.100.100.140: ICMP 189.146.99.232 unreachable - need to frag (mtu 1476), length 36
        IP (tos 0x0, ttl  62, id 8156, offset 0, flags [DF], proto: TCP (6), length: 1492) 10.100.100.140.58081 > 189.146.99.232.39437:  tcp 1472 [bad hdr length 0 - too short, < 20]
20:45:26.003286 IP (tos 0x0, ttl 255, id 48046, offset 0, flags [none], proto: ICMP (1), length: 56) 69.31.131.57 > 10.100.100.140: ICMP 82.24.138.186 unreachable - need to frag (mtu 1476), length 36
        IP (tos 0x0, ttl  58, id 6289, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.100.100.140.56881 > 82.24.138.186.1113:  tcp 1480 [bad hdr length 0 - too short, < 20]

not sure what is the difference.  This is not some kind of malformed
packet attack---it's clearly just bittorrent.  It's possible the
blocked ones simply don't have any 'keep state' state associated with
them, but I don't know why that would be, or how to check if it's
true.

I see the blocked ones have ttl 255, and the passed have ttl 254, but
(1) so what? and (2) both are generated by the same IOS 12.3(15)fc3
router at my site, so it's not like half the packets are generated by
some broken OS.  I don't know why the TTL difference nor why one would
be more valid than the other according to PF.

I'm passing ICMP need-frag manually (not just implicitly by tcp 'keep
state') until I can explain this, to avoid becoming part of the PPPoE
misconfigured-firewall-problem.

That IPsec-tagging is neat---didn't know about it.  IMHO one of the
best reasons to run OpenBSD is so that all the seldom-used PF bells
and whistles actually work instead of causing kernel panics.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20070111/b1fb4538/attachment.bin>