[Bug 193568] PF rdr rule with ipv6 does not work
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Tue Jan 23 15:51:55 UTC 2018
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193568
--- Comment #5 from Alan Somers <asomers at FreeBSD.org> ---
Created attachment 190002
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190002&action=edit
Fix RDR rules that redirect to ::1
"Fix" pf rdr rules with ::1 targets
Redirecting an IPv6 packet to ::1 is a violation of IPv6 scoping rules, because
::1 only has node-local scope. It's supposed to be used only for traffic the
begins and ends on a single node. Plus, it's a bad practice security-wise
(server processes are often bound to ::1 as a deliberate way to prevent them
from talking to the outside world), and it doesn't work on multihomed,
single-fib hosts (the reply packet doesn't know which interface to use if its
destination is non-local). However, the same arguments apply to IPv4, and
FreeBSD already has hacks to make it work there. So I'm extending those hacks
to IPv6.
Even with this "fix", rdr won't work for packets destined to a link-local
(ff80::*) address, because pf doesn't know how to set the embedded scope
identifier on the reply packets.
A better solution would be to configure pf to only redirect a packet's port,
not its address and port. However, pf doesn't currently have that capability.
netinet6/ip6_input.c
In ip6_input, don't reject a packet with bad scope if the firewall has
changed the destination address. ip_input does something similar with
the "dchg" variable.
sys/netinet6/ip6_output.c
In ip6_output, don't fail a packet immediately if the scope check
fails. Instead, repeat the scope check after running it through the
firewall, if the firewall changed either the src or dst address.
ip_output simply does the scope checking after the firewall. However,
ip6_output can't do that, because at that point multicast packets will
have inconsistent embedded scope identifiers.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-pf
mailing list