pfsync: support deferring IPv6 packets

[kp]

Summary

When we send out a deferred packet we must make sure to call
ip6_output() for IPv6 packets. If not we might end up attempting to
ip_fragment() an IPv6 packet, which could lead to us reading outside of
the mbuf.

PR: 268246
MFC after: 2 weeks

[melifaro]

sys/netpfil/pf/if_pfsync.c

2409

From the readability POV, I'd vote for moving the mbuf handling and sending code into the dedicated function.

[kp]

Factor out sending the mbuf into its own function.

[zlei]

sys/netpfil/pf/if_pfsync.c

2410

A little confused by this check ip->ip_v == IPVERSION.

I see only two functions pfsync_sendout() and pf_test_rule() -> pfsync_defer() -> pfsync_undefer() are calling _IF_ENQUEUE(&b->b_snd, m);, and pf_test() and pf_test6() call pf_test_rule().

So is it possible that pf_test6() enqueues IPv6 packets without correct version ip6->ip6_vfc |= IPV6_VERSION ?

If in doubt then we want to assert the version.

(ip->ip_v == IPVERSION || ip->ip_v == IPV6_VERSION >> 4)

[kp]

sys/netpfil/pf/if_pfsync.c

2410

Your understanding is correct. We'd only expect to see IPv4 or IPv6 here. Right now the only path for IPv6 packets to end up here is via pf_test6() -> pfsync_defer(). That's the path that can cause panics (see 268246).
At some point we may also add support for pfsync over IPv6. Someone was working on that, but I've not seen updates in a while.

An assert is a reasonable suggestion. I'll see about adding that.

[kp]

Assert that packets are IPv4 or IPv6.

[kp]

Also fix the same issue in pfsync_defer_tmo()

[zlei]

Looks good to me.

sys/netpfil/pf/if_pfsync.c

1840

Definitely this should be fixed ;)

2339

Style(9), remove extra blanks after >>