> -----Original Message----- > From: Angelo Turetta [mailto:[EMAIL PROTECTED] > Sent: 06 June 2006 10:43 > To: [email protected] > Subject: Re: [pfSense Support] port forwarding > > Bill Marquette wrote: > > On 6/5/06, Chris Buechler <[EMAIL PROTECTED]> wrote: > > > >> Ah, ok, yeah you're right on that. But that's useless. > Who cares what > >> the destination port was prior to NAT? > > > > Or I want port 443 to redirect to my honeypot by default > except for my > > friends which can legitimately get there. That can't be > accomplished > > by rules alone (ok, so it can with policy routing - bleh - > talk about > > a hack ;)), but the point remains. > > I think filtering both before and after NAT is out of scope > (pf is not > designed to do that). > What could be easily done to alleviate 'the missing' would be > to add to > the 'rdr' UI the possibility to specify the FROM part of the rule. If > you look at your /tmp/rules.debug yuo'll see that rdr rules are > specified as follows: > > rdr on vlan0 proto tcp from any to x.y.w.z/32 port {80 443} -> a.b.c.d > > The part 'from any to' is added by filter.inc Allowing the user to > specify a source would allow to translate only some of the > packets, with > the remainder matching some following NAT rules or being passed > untranslated to the filter. I don't know whether the rdr rules syntax > allows 'from' to contain an alias, or a list of values. > > Angelo. >
It's also useful when you are doing transparent proxying and have internal servers on another interface. Pre PFSense I redirected anything that wasn't for one of my nets to squid, and the rest went direct. It's one of those things that I miss, but is handy. Still prefer PFSense to doing it all by hand tho :D --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
