pf: Make af-to work on outbound interface

[vegeta_tuxpowered.net]

Summary

Currently af-to works only on inbound interface by creating a reversed
NAT state key which is used to match traffic returning on the outbound
interface.

Such limitation is not necessary. When an af-to state is created
for an outbound rule do not reverse the NAT state key, making it work
just like if it was created for a normal NAT rule. Depending on firewall
design it might be easier and more natural to use af-to on the outbound
interface.

[kp]

Couple of very minor remarks and a few questions.

I am delighted to see all of these test cases.

sys/netpfil/pf/pf.c

8096–8103

This line (and the others like it) is too long.

8203

Can we simplify (*state) to *state?

We'd have to put the braces in the PF_REVERSED_KEY, but that's good practice anyway.

tests/sys/netpfil/pf/nat64.sh

42

Am I correct in assuming this is required for af-to on pass out rules, because otherwise we'd end up dropping the packet during the routing decision?

I wonder if we should move that to nat64_setup_out(). I'm a bit torn, we don't need it for the pass in case so maybe shouldn't have there. It shouldn't hurt anything either though.

66

This doesn't belong here. The shebang line is added by the makefile.

115

Perhaps a standard default route? Or is that not here because we'd have to have a neighbour entry for the gateway?

120

Do we have to play the tag game here?

Can we not just pass out quick on ${epair_link}a to 64:ff9b::/96 af-to inet from (${epair_link}a)" ?

239

A stray debug line?

[vegeta_tuxpowered.net]

tests/sys/netpfil/pf/nat64.sh

42

That's not even needed for the outbound case. I've removed it.

115

The current, inbound, implementation of af-to happens pre-routing, and once the packets are translated to IPv4 there is no need for working IPv6 routing. Clients need IPv6 routing towards the router with pf, and that router only needs outbound IPv4 routing.

With this patch the outbound AF translation happens post-routing, so there must be *some* way to direct the IPv6 traffic towards the outbound interface where it will be intercepted by pf pfil. It could be BGP installing real routes or a default route. Or as I did here, just plain interface route. It should not really matter for the test how it's configured. And having a real default route would require an IPv6 subnet on the outbound interface, which those tests don't provide.

120

The tag might indeed be unnecessary. The traffic arriving on the outbound direction must have first passed through the inbound rule (because there is also the block rule), and the returning traffic will pass through a state created for that rule.

[vegeta_tuxpowered.net]

Fix too long lines and other syntax issues. Deduplicate calculation of src, dst, psrc, pdst for state tracking, which also fixes outbound NAT64 for UDP traffic.

[kp]

Approved.

Go ahead and land it before I push more changes and you have to rebase it again ;)