I'm using pf with rules like the following: rdr inet proto tcp from any to any port 80 -> localhost port 8080 rdr inet6 proto tcp from any to any port 80 -> ::1 port 8080
It works for IPv4. But for IPv6 it fails because the redirected packet violates IPv6's scoping rules. I've got a patch to hack around that, but it's a hack. There are three things wrong with the concept of both of these rules: 1) They both violate scoping rules. Even with IPv4, 127.0.0.1 isn't supposed to receive packets from outside the local machine. However, r73626 and r125785 hack around that. 2) They violate a security expectation. Some daemons are bound to localhost specifically so that they can't communicate with the outside world. But this expectation is violated by the above pf rules. 3) They don't work on multihomed hosts. They work fine for LAN traffic, but when a daemon's reply requires routing, it doesn't know which source address to use. It will try to use the default route, but that may be different than the IP address on which the packet arrived. pf won't be able to translate the reply's source address, and won't be able to send the packet out of the correct interface. All of these problems could be solved if pf were able to redirect a packet's destination port but not its address. You could bind the daemon to INADDR_ANY instead of localhost, and the packet it receives would be destined to the same address that the sender intended. Unfortunately, pf currently lacks this capability. But it looks like it could be added without breaking existing pf.conf syntax. Would this be a good idea? I don't use ipfw, but from reading the man page I believe that it has the same problem. -Alan _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
