Example:
rdr pass on { $wifi $int } proto tcp from any to any port 21 ->
127.0.0.1 port 8021
This makes matching packets disappear and never come up. They are not
dropped (since there is no block rule in my pf.conf anywhere) and they
do not show on tcpdump of any interface.
They NEVER reach the inetd even if it is listening, and clients will
time out eventually.
The exact same inetd.conf and pf.conf work perfectly under NetBSD
3.0_beta, so this is very very likely to be a DFly bug. I'd take a look
at the new routing code, but I'm no expert. I know rdr itself works
because I use it to redirect port 42443 to 443 in the same pf.conf, and
that works. That points to 192.168.1.1 (but trying to do that here
doesn't help packets reach inetd.conf, no matter what its ftp-proxy is
meant to listen on).
Has anyone reproduced this? I reproduced it a few hundred times on a
very frustrating day.