On Wed, Jul 12, 2006 at 03:25:28PM +1000, Adam Clark wrote: > traffic going to hosts behing the box were showing in on pflog0, but > no traffic to 10.17.10.254 shows. If I put a log-all on a line that > matches the traffic on the $ext_if interface it shows that in deed > traffic is heading towards 10.17.10.254. Which means that even though > the internal IP address is bound to the internal interface, the internal > interface never sees traffic for 10.17.10.254 that can be filtered. > Tcpdump does not show this either > Is this true or is there a way perform what I need to do in another way?
Yes, that's normal, but you're not the first one to find this surprising. :) When the host, on one interface, receives a packet with a destination IP address that matches one of the host's own IP addresses (assigned to any interface), the packet is removed from the forwarding path and dispatched to the local socket instead. The destination address of the packet can influence what local socket it is dispatched to (like when you have two different sockets bound to different addresses), or it doesn't matter at all (when you have a single socket bound to *), but the kernel doesn't simulate any passage through $int_if. If it would try to send out the packet through $int_if, that would mean writing an ethernet frame out onto $int_if's wire. The simplest solution in your case is to move the bittorrent client process onto a different host on the internal network, so inbound packets to it really pass out on $int_if. We recently had a lenghty thread about the disadvantages (requiring separate hosts) of lacking inbound queues, see http://groups.google.com/group/bit.listserv.openbsd-pf/browse_thread/thread/5de1c7731114bdae If you have to move the process to another host, maybe it's a little comforting that this is also the wise thing to do from a security perspective. In the completely hypothetical case where the process has a remotely exploitable hole, you don't risk the attacker using it to gain root on the firewall and opening up its ruleset. Daniel
