On Mon, Apr 05, 2004 at 05:35:59PM +0100, Joe Warren-Meeks wrote: > bash-2.05b# pfctl -vvss > icmp 10.95.1.8:48683 <- 10.65.1.1:48683 <- 10.88.1.8:48683 0:0 > age 00:00:04, expires in 00:00:09, 4:0 pkts, 336:0 bytes > > Now, what it seemed to be doing in the bitmask was taking the host portion > of the *source* address and adding that to the 10.95 network portion to > create the new destination address, when what I wanted was to take the > host portion of the *destination* address and add it to the 10.95 network. > > It did this with just the rdr and also with the rdr + nat rules in place. > > Is this how the bitmask works or have I messed something up?
Yes, I missed that, rdr uses the host part of the source address right now. I'm not sure this is expected in more than half of the cases bitmask is used with rdr. It's easy to use the destination address instead, maybe we could even make it two 'bitmask' options (like 'src-bitmask' and 'dst-bitmask'). binat won't help you, either. It replaces the destination address for incoming packets, so you'd have to use a binat on fxp0 rule for the example connection we refer to. It does, then, use the source address' host part to replace the destination address. But you can't use 'from 10.95.0.0/16' in the rule (which would make the replacement destination address correct), as then the rule just wouldn't match the orignal packet coming in on fxp0 (the source address isn't within 10.95.0.0/16). If you need a very specific solution just for this problem, I guess I'd change the source to use the other host part for rdr. It's a trivial change (I can send you a diff against -current, once you updated), but of course it will royally confuse the next person walking up to the firewall ruleset not knowing about the change. But then, this is such a detail that I got it wrong from memory, too. Daniel
