First off, thanks much for PF. An excellent tool.
> [ Discussion about 2 outside interfaces and routing NAT packets
> between them based on certain rules. ]
Here are my experiences with EXACTLY the same issue. NAT and two
outside interfaces: ADSL and SDSL. I was trying to route my outgoing
NAT connections over one interface _without_ changing my default
route. This was way harder than I expected.
1) First off, if the NAT rules had a net-hop address specification,
this would have been cake. This should be added IMHO. Not sure of
the technical ramifications.
# something like
nat on $if_out0 from $if_in:network to any -> ($ip_out0 $ip_gate0)
2) What I ended up with is the following:
nat on $if_out0 from $if_in:network to any -> $ip_out0
#nat on $if_out1 from $if_in:network to any -> $ip_out1
pass in quick on $if_in route-to ($if_out0 $gate_out0) \
from $if_in:network to {! $if_in:network} \
keep state
So a couple of things about this. Although NAT comes before the pass
filters in the pf.conf file, it seems that the NAT is _applied_
afterwards. Yes, this reveals my very shallow understanding of the PF
architecture.
I expected that I would be matching on packets _after_ the NAT has
rewritten them and that wasn't the case. It also meant that if I
tried to tag a packet as being rewritten by the NAT line, the tag
would not be seen by the pass line.
# this did NOT work
nat on $if_out0 from $if_in:network to any tag outside -> $ip_out0
pass in quick on $if_in route-to ($if_out0 $gate_out0) \
from $if_in:network to {! $if_in:network} \
tagged outside keep state
I was also confused when I uncommented the other NAT line to my
$ip_out1 interface. I initially thought that it would round robin
between them or take the first one or something but the pass line
seems to just cause PF to ignore the $ip_out1 NAT entry.
Please excuse the ignorance here. Just trying to share my
experiences.
---
Gray Watson
