[Bug 219803] [patch] PF: implement RFC 4787 REQ 1 and 3 (full cone NAT)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219803

            Bug ID: 219803
           Summary: [patch] PF: implement RFC 4787 REQ 1 and 3 (full cone
                    NAT)
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Keywords: patch
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: damjan.jov at gmail.com
          Keywords: patch

Created attachment 183243
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183243&action=edit
pf RFC 4787 req 1 and 3 implementation

This patch implements RFC 4787 requirements 1 and 3, changing PF's allocation
of NAT mappings for UDP from the current "symmetric" NAT to a
"endpoint-independent mapping" NAT, a.k.a "full cone" NAT. All UDP packets from
the internal IP:port X:x go through the same external Y:y no matter the Z:z,
and nothing but X:x uses Y:y.

Internal             External
X:x  -----> NAT Y:y ----> Z:z

The implementation is relatively straightforward. pf_state for UDP connections
now reference a pf_udp_mapping, which is reference counted, and kept alive as
long as at least 1 pf_state is referencing it. Every new NAT mapping that gets
created tries to find a pf_udp_mapping by its source X:x endpoint and reuses
its external Y:y, failing which, it creates a new one through an unused Y:y.
Only allocation of NAT mappings is changed. Each X:x <-> Z:z still has its own
distinct connection state (struct pf_state) and behaves the same as before.

Currently, only if a Z:z was previously transmitted to by X:x, can it transmit
back to X:x through Y:y, i.e it behaves as a "port-restricted cone" NAT (or
endpoint-independent mapping NAT with address- and port-dependent filtering, as
per RFC 4787), but I am working on that too.

This should fix STUN and vastly improve UDP applications using PF's NATing such
as gaming, VoIP, WebRTC, peer to peer applications, etc.

Are the NAT implementations in our other firewalls also "symmetric" NATs?

-- 
You are receiving this mail because:
You are the assignee for the bug.