Daniel:
Hmmmm,  could have sworn pf assumed that .0 meant that all possible .x was
valid (in this instance 192.168.1.0/24) but fair enough; the network is
defined as "192.168.1.0/24"   (sorry, was in a hurry so when I re-wrote the
ruleset I used shorthand.  My appologies)

Ben




> -----Original Message-----
> From: Daniel Hartmeier [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 10, 2005 12:20 AM
> To: Ben
> Cc: pf@benzedrine.cx
> Subject: Re: Tcpdump grepped for the machine: RE: Trouble 
> with route-to:
> 
> On Wed, Mar 09, 2005 at 10:19:17PM -0800, Ben wrote:
> 
> > Mar 09 22:10:45.682221 0:9:5b:12:43:xx 0:c:f1:91:70:xx 0800 62:
> > 192.168.1.132.1273 > 216.51.232.100.80: S 
> 417417262:417417262(0) win 
> > 16384 <mss 1460,nop,nop,sackOK> (DF)
> 
> > $internal_net = 192.168.1.0
> 
> > nat on rl0 from $internal_net to !$internal_net -> (rl0) nat on rl1 
> > from $internal_net to !$internal_net -> (rl1) pass in on 
> em0 route-to 
> > (rl1 gw1) from 192.168.1.132 to !$internal_net keep state
> 
> If you really defined internal_net as 192.168.1.0, and not 
> 192.168.1.0/24, neither of those three rule matches the 
> packet, because
> 192.168.1.132 is not within 192.168.1.0/32. Leaving out the 
> /network part means /32 (for IPv4) in pf.
> 
> If you misquoted your ruleset, quote precisely.
> 
> Daniel

Reply via email to