TL;DR

A patch from David Gwynne proposes changing pf's af-to handling to remove special-case behavior. The change simplifies code by not forcing translated packets to be forwarded, but operators may need to add explicit outbound rules for forwarded connections.

What happened

On 2026-01-16 David Gwynne posted a patch to the OpenBSD tech list that alters how pf handles af-to, the option used for IPv4/IPv6 address-family translation. Historically af-to has been treated specially: it only applied to "pass in" rules and forced the translated packet to be forwarded, which produced only one state for a connection crossing the firewall. Gwynne's patch alters that behavior so translated packets are handed into the peer ip_input handler (for example, ip6_input) instead of being forced through ip_forward, and it avoids re-running full pf processing on the nested input pass by using mbuf tags analogous to the PF_TAG_GENERATED and PF_TAG_REROUTE mechanism already used for output-side reroutes. The change makes translated packets behave more like rdr-to translations, enables translation on "pass out" rules, and simplifies the code path. Gwynne reports only minimal testing so far and is soliciting feedback from users who depend on af-to.

Why it matters

  • Reduces special-casing in pf implementation, simplifying maintenance and reasoning about af-to behavior.
  • Makes translated packets enter the local network stack the same way rdr-to translations do.
  • Enables address-family translation on outbound rules, expanding where af-to can be applied.
  • Operational impact: forwarded connections that previously worked without extra rules may now require explicit outbound allow rules.

Key facts

  • Legacy IPv4 and modern IPv6 are not directly compatible; translation between address families is required.
  • af-to has been treated specially in pf since OpenBSD 5.1.
  • Current restrictions on af-to: it only works on "pass in" rules and forces the translated packet to be forwarded.
  • Because af-to used to force forwarding, a single pf state would cover both directions for a forwarded connection.
  • The patch makes af-to stop forcing forwarding by sending the translated packet to the other ip_input handler (e.g., ip6_input) rather than ip_forward.
  • To avoid duplicate pf processing the patch extends the mbuf tagging state machine (PF_TAG_GENERATED and PF_TAG_REROUTE) to the ip_input side.
  • Translated packets will be handled by the local TCP/UDP stack similarly to rdr-to translations after this change.
  • As a result, operators may need to add explicit "pass out" rules for the translated outbound traffic.
  • David Gwynne reports only minimal testing and requests feedback from users who use af-to.

What to watch next

  • Follow the discussion and follow-ups on the openbsd-tech mailing list for additional testing reports and revision of the patch.
  • Test environments that use af-to to confirm translation behavior and whether additional pass-out rules are required in practice.
  • not confirmed in the source: whether and when this patch will be committed into OpenBSD-current or a release branch.

Quick glossary

  • pf: A packet filter and firewalling system used on OpenBSD and related systems.
  • af-to: A pf rule option that performs address-family translation between IPv4 and IPv6 addresses.
  • address-family translation: The process of converting packet addresses and headers between different IP versions (IPv4 and IPv6).
  • mbuf: A kernel memory structure used to hold network packets and associated metadata.
  • rdr-to: A pf feature that redirects packets to a different address/port on the local system.

Reader FAQ

What does this patch change about af-to?
It stops forcing translated packets to be forwarded and instead injects them into the peer ip_input handler so they are processed like other locally delivered translations.

Will I need to change firewall rules?
Possibly. Forwarded connections that previously worked without outbound rules may now require explicit "pass out" rules for the translated traffic.

Has the patch been widely tested or merged into OpenBSD?
David Gwynne reports only minimal testing; broader testing and whether it will be merged are not confirmed in the source.

Where should I send feedback or test results?
Feedback and discussion are requested on the openbsd-tech mailing list thread where the patch was posted.

Contributed by Peter N. M. Hansteen on 2026-01-16 from the raising my family dept. Seasoned networkers will know to tell you that legacy IPv4 and modern IPv6 are, in fact,…

Sources

Related posts

By

Leave a Reply

Your email address will not be published. Required fields are marked *