Wouldn't the same problem then apply? By the time pf sees packets
originating on the pf box itself, they are already outbound on a
specific interface, and cannot be routed to the correct interface.
I think I'll have to use rtables after all. That just means I'm limited
to destination routing only and not full policy routing.
It also seems that the "loopback" option (two bridged tap interfaces)
can't work because the packets always bypass the actual full stack of
the interfaces. The only weird thing with that is that when I set my
default route to tap0 and block inbound on tap1 (bridged to tap0), the
pings are stopped, but when I pass the traffic it does loop until TTL
expires. This suggests that pf does indeed see those packets, yet when I
try to apply routes to them inbound on tap1, they go nowhere... I'm
convinced that I just don't know the interactions between pf nat, pf
route-to and rtables well enough to crack this one...
On 2010-02-03 04:59, jhell wrote:
> On Tue, 2 Feb 2010 12:54, stefanferreira@ wrote:
>> In my quest to route traffic originating on the freebsd machine, I've
>> managed to loop back outbound traffic via lo0 so that I can try and
>> route it inbound on lo0 (pf can't apply route-to logic to outbound
>> traffic; by then it's to late to try and route it over a different
>> The loopback works when I switch off skip on lo0, and pass all lo0
>> traffic, so that traffic is definitely processed by pf. I also know
>> the looping works, because when I try to ping an outside IP, I get a
>> response that the TTL has been exceeded, and traceroute shows
>> repeating entries of 127.0.0.1 (in other words, the packets jost loop
>> back through the pf box repeatedly till their TTL is exceeded).
>> The problem is the moment I change my rule to try and route the
>> inbound traffic on lo0, the packets just seem to go nowhere. They are
>> not routed correctly and I can't tell what happens to them. In the
>> ruleset below, enabling the second rule results in the packets
>> looping back to the pf box repeatedly, and the first rule results in
>> the packets "disappearing". The only difference is the route-to
>> statement, which works for all traffic originating elsewhere on the lan.
>> #pass in quick on lo0 route-to (adsl-int0 184.108.40.206) from any
>> to ! $IPs_LAN $KEEPSTATE $ALTQ_DEFAULT label zSA_Local tag zSA_Local
>> #pass in quick on lo0 from any to ! $IPs_LAN $KEEPSTATE $ALTQ_DEFAULT
>> label zSA_Local tag zSA_Local
>> pass out quick all $KEEPSTATE tagged zSA_Local
>> pass quick on lo0
>> Please help! I really need to route traffic originating on the pf box
>> via pf, and not via rtables!
> Have you tried implementing "binat" and possibly making use of rdr
> while using some tables to hold your addresses and subnets ?
> # BINAT
> # Translate outgoing packets' source address (any protocol).
> # Translate incoming packets' destination address to an internal machine
> # (bidirectional).
> binat on $ext_if from 10.1.2.150 to any -> $ext_ifA
> you could change that to:
> binat on $ext_if from <binathosts> to any -> $ext_ifA
> Looping traffic that is originating internally back around to a
> loopback interface is not going to solve this, and it will cause you a
> lot more frustration.
> Best of luck.