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: [email protected]
Reporter: [email protected]
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.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
