On Mon, Aug 22, 2022 at 08:56:32PM +0200, Peter J. Philipp wrote: > On Mon, Aug 22, 2022 at 08:15:13PM +0200, Alexander Bluhm wrote: > > Note that sending an error reply to packets that cannot be processed > > is not uncommon and sometimes required to make the network behave > > smoothly. > > Ahh ok, thanks! So I guess this is configuration mistake on my part.
It is debatable who is doing something wrong. Due to the correct mac address, your packets are accepted and processed by the IP layer of the kernel. The network stack first checks whether the IP address is locally configured. As you have chosen a random IP address, it is not local. If IP forwarding is disabled (the default), such packet is silently dropped. That happens if you disable pf. If IP forwarding is enabled, you would see an ICMP redirect as your fake IP is in the same segment. This ICMP has the IP of the router, that is intensional. IP addresses of a router are not secret. pf does not know if an IP address is local. It just processes rules. As you send "echo reply" packets, they cannot create states. So the "block return" rule matches. pf does what it is told to do. Why is there a "block return" in default pf.conf? Returning error messages improves network responsiveness. If anything goes wrong or is configured incorrectly, you immediately get a response. Otherwise you run into timeouts or things fail silently. Debugging would be hell. If you don't like that, you can change pf.conf. I don't recommend that. If your network security is based on the fact that nobody knows you IP, you have different problems. If an attacker wants to detect your IP, he will. Having a silent network device creates more obscurity than security. I don't need that kind of privacy. bluhm
