kern/115413: [ipv6] ipv6 pmtu not working

[Daniel Hartmeier]

When filtering statefully, there is no need for a specific rule allowing
ICMPv6 errors like ICMP6_PACKET_TOO_BIG. These ICMPv6 messages contain, as
payload, the header of the original packet that triggered the error. pf
extracts that inner header and searches for a matching state entry. If a
matching state is found, the ICMPv6 error is passed without ruleset
evaluation.

In your case, a matching state entry (for the corresponding TCP
connection) is found, but TCP sequence number checks fail:

>  pf: BAD ICMP 2:0 some_router -> src_addr
>  state: TCP src_addr[50400] src_addr[50400] dst_addr[22] 
>  [lo=2463013638 high=2463020758 win=32844 modulator=0 wscale=1]
>  [lo=2412460872 high=2412526560 win=1278 modulator=0 wscale=3]
>  4:4 seq=2463010534

The TCP connection is from src_addr[50400] to dst_addr[22], an outgoing
connection (on some interface) for pf. I assume the ICMPv6 error is
coming in on the same interface.

Since some_router is sending the ICMPv6 error to src, we'd expect that
the TCP packet that triggered the error on some_router was sent from src
to dst.

The first section in square brackets represents src's TCP window, the
second one dst's. For packets src sends to dst, dst's window is
relevant.

For example, a TCP packet from src to dst might have th_seq 2412460873
legitimately, as that is within the window dst accepts (2412460872 to
2412526560).

But th_seq of the TCP packet quoted by the ICMPv6 error is 2463010534,
which is outside dst's window. Strangely, it is within src's window.

I don't understand why some_router would do this. It looks like it's
either quoting the wrong TCP header or sending the error to the wrong
side, neither of which sounds like an easy mistake to make.
Is some_router a FreeBSD 6.2 box, too?

It might help if you could capture a tcpdump -s 1600 -nvvvS of one such
TCP connection, including the ICMPv6 error.

Daniel