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
