Date: Mon, 05 Jun 2017 17:48:30 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219803] [patch] PF: implement RFC 4787 REQ 1 and 3 (full cone NAT) Message-ID: <bug-219803-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219803 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@FreeBSD.org Reporter: damjan.jov@gmail.com Keywords: patch Created attachment 183243 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D183243&action= =3Dedit pf RFC 4787 req 1 and 3 implementation This patch implements RFC 4787 requirements 1 and 3, changing PF's allocati= on 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 connecti= ons 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 g= ets 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 trans= mit 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? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219803-8>