Very bizarre. The only advice I can offer is that maybe it's getting
confused on "-> $nat_if" instead of the more-pragmatic "-> ($nat-if)".
Perhaps the parse code is trying too hard to resolve $nat_if in the
former, and thus finding the underlying interface instead of the logical
upper layer vlan interface?
Give it a shot. If not, we'll turn up debugging and log
~BAS
On Tue, 19 Jun 2007, Albert Chin wrote:
I have a perfectly-working 4.0 firewall and decided to move one of the
physical interfaces to a new vlan tagged interface. I changed the
interface name in pf.conf and noticed that NAT wasn't working. The NAT
rule is:
nat_if = "vlan109"
table <tww_nets> const { 192.168.1.0/24, 192.168.4.0/24, 10.191.57.0/24 }
nat pass log on $nat_if from <tww_nets> to any -> $nat_if
If nat_if is a physical interface, like fxp0, the above nat rule
works. I can get the nat rule to work if I omit the use of the table:
nat pass log on $nat_if from { 192.168.1.0/24, \
192.168.4.0/24, \
10.191.57.0/24 } to any -> $nat_if
So:
1. If the only change I make to pf.conf is a global search/replace
from "fxp0" to "vlan109", why doesn't pf behave as if using
a physical interface?
2. Why the workaround above to get pf working with the vlan tagged
interface? Bug in pf?
--
albert chin ([EMAIL PROTECTED])
l8*
-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
http://www.spiritual-machines.org/
"Guilty? Yeah. But he knows it. I mean, you're guilty.
You just don't know it. So who's really in jail?"
~Maynard James Keenan
