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:
Hi
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
interface).
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 196.210.140.129) 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.
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
