Re: pf in 4.0 not honoring nat rule with table for vlan tagged interface
On Wed, Jun 20, 2007 at 01:27:22AM -0400, Brian A. Seklecki wrote:
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).
The above worked!
Doesn't make sense though. According to pf.conf(5):
nat-rule = [ no ] nat [ pass [ log [ ( logopts ) ] ] ]
[ on ifspec ] [ af ]
[ protospec ] hosts [ tag string ] [ tagged string ]
[ - ( redirhost | { redirhost-list } )
[ portspec ] [ pooltype ] [ static-port ] ]
redirhost = address [ / mask-bits ]
address= ( interface-name | ( interface-name ) | hostname |
ipv4-dotted-quad | ipv6-coloned-hex )
So, - $nat_if and - ($nat_if) seem equally-valid.
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
--
albert chin ([EMAIL PROTECTED])
Re: pf in 4.0 not honoring nat rule with table for vlan tagged interface
* Brian A. Seklecki [EMAIL PROTECTED] [2007-06-20 07:39]: 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? no way. to teh original poster, please show: 1) ifconfig -A 2) pf.conf 3) pfctl -nvf /etc/pf.conf specically, compare the nat rule(s) in 2) and 3). you should see $nat_if replaced by an IP address. of course do NOT use ($nat_if) for that -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: pf in 4.0 not honoring nat rule with table for vlan tagged interface
On Wed, Jun 20, 2007 at 10:47:43AM +0200, Henning Brauer wrote: * Brian A. Seklecki [EMAIL PROTECTED] [2007-06-20 07:39]: 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? no way. to teh original poster, please show: 1) ifconfig -A vlan109: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0e:0c:b2:e3:e3 vlan: 109 priority: 0 parent interface: fxp1 groups: vlan egress inet6 fe80::20e:cff:feb2:e3e3%vlan109 prefixlen 64 scopeid 0x10 inet 192.168.13.1 netmask 0xfff8 broadcast 192.168.13.7 2) pf.conf 3) pfctl -nvf /etc/pf.conf specically, compare the nat rule(s) in 2) and 3). you should see $nat_if replaced by an IP address. of course do NOT use ($nat_if) for that Ahh. #3 shows the following: nat pass log on vlan109 inet6 from tww_nets to any - fe80::20e:cff:feb2:e3e3 when #2 looks like: nat pass log on $nat_if from tww_nets to any - $nat_if And, #3 shows the following: nat pass log on vlan109 from tww_nets to any - (vlan109) round-robin when #2 looks like: nat pass log on $nat_if from tww_nets to any - ($nat_if) I guess pf picks the first address for the interface. -- albert chin ([EMAIL PROTECTED])
Re: pf in 4.0 not honoring nat rule with table for vlan tagged interface
* Albert Chin [EMAIL PROTECTED] [2007-06-20 11:24]: On Wed, Jun 20, 2007 at 10:47:43AM +0200, Henning Brauer wrote: * Brian A. Seklecki [EMAIL PROTECTED] [2007-06-20 07:39]: 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? no way. to teh original poster, please show: 1) ifconfig -A vlan109: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0e:0c:b2:e3:e3 vlan: 109 priority: 0 parent interface: fxp1 groups: vlan egress inet6 fe80::20e:cff:feb2:e3e3%vlan109 prefixlen 64 scopeid 0x10 inet 192.168.13.1 netmask 0xfff8 broadcast 192.168.13.7 strange, on all my boxes there is al least lo0 and enc0, something in your kernel is broken. and fxp* disappeared too. 2) pf.conf 3) pfctl -nvf /etc/pf.conf specically, compare the nat rule(s) in 2) and 3). you should see $nat_if replaced by an IP address. of course do NOT use ($nat_if) for that Ahh. #3 shows the following: nat pass log on vlan109 inet6 from tww_nets to any - fe80::20e:cff:feb2:e3e3 when #2 looks like: nat pass log on $nat_if from tww_nets to any - $nat_if sp pf cannot figure out the address family for this rule, and picks v6 while you want v4. so just specify v4 explicitely: nat pass log on $nat_if inet from tww_nets to any - $nat_if -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: pf in 4.0 not honoring nat rule with table for vlan tagged interface
On Wed, Jun 20, 2007 at 11:40:36AM +0200, Henning Brauer wrote: * Albert Chin [EMAIL PROTECTED] [2007-06-20 11:24]: On Wed, Jun 20, 2007 at 10:47:43AM +0200, Henning Brauer wrote: * Brian A. Seklecki [EMAIL PROTECTED] [2007-06-20 07:39]: 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? no way. to teh original poster, please show: 1) ifconfig -A vlan109: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0e:0c:b2:e3:e3 vlan: 109 priority: 0 parent interface: fxp1 groups: vlan egress inet6 fe80::20e:cff:feb2:e3e3%vlan109 prefixlen 64 scopeid 0x10 inet 192.168.13.1 netmask 0xfff8 broadcast 192.168.13.7 strange, on all my boxes there is al least lo0 and enc0, something in your kernel is broken. and fxp* disappeared too. Sorry, I only posted the ifconfig of the vlan interface, not the full ifconfig output. 2) pf.conf 3) pfctl -nvf /etc/pf.conf specically, compare the nat rule(s) in 2) and 3). you should see $nat_if replaced by an IP address. of course do NOT use ($nat_if) for that Ahh. #3 shows the following: nat pass log on vlan109 inet6 from tww_nets to any - fe80::20e:cff:feb2:e3e3 when #2 looks like: nat pass log on $nat_if from tww_nets to any - $nat_if sp pf cannot figure out the address family for this rule, and picks v6 while you want v4. so just specify v4 explicitely: nat pass log on $nat_if inet from tww_nets to any - $nat_if Indeed, thanks. -- albert chin ([EMAIL PROTECTED])
pf in 4.0 not honoring nat rule with table for vlan tagged interface
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])
Re: pf in 4.0 not honoring nat rule with table for vlan tagged interface
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
