how do I "not rdr" with pfsense

[Etienne Ledoux]

I'm using pfsense to redirect all outgoing http traffic to a transparent
proxy. But I need to not redirect a specific range when browsing to that
specific range. pf supports "not rdr" as well as other options to achieve
this. But I can't figure out how can do this via pfsense ? Perhaps the "No
nat" feature somehow ?

Any ideas or is it a missing feature ?

thanks,

e.

[Bill Marquette]

Post by Etienne Ledoux
I'm using pfsense to redirect all outgoing http traffic to a transparent
proxy. But I need to not redirect a specific range when browsing to that
specific range. pf supports "not rdr" as well as other options to achieve
this. But I can't figure out how can do this via pfsense ? Perhaps the "No
nat" feature somehow ?

Yup, no nat. I assume you are redirecting to another server and not
using the squid on box. If so, 'no nat' should work for you, just
make sure the 'no nat' rule is before the fall through redirect that
redirects everything else.

--Bill

[Etienne Ledoux]

perhaps I should give more info about this:

I have a internal LAN , DMZ and a WAN. My proxy is in the DMZ. I redirect
all http traffic from the LAN to the proxy in the DMZ. The rule looks like
this:

rdr on vr0 inet proto tcp from any to any port = http ->
10.6.0.10<http://10.6.0.10>port 8080

I would like to eventually have a rule that reads something like:

no rdr on vr0 inet proto tcp from any to 10.2.0.0/16
<http://10.2.0.0/16>port = http

above it.
The "no nat" feature available on outbound nat currently doesn't even allow
me to select my internal interface. So I'm not sure if this rule will work
because its probably going to be caught by the the rdr rule above anyways.

Unless I'm not suppose to be using rdr for this in the first place, which
doesn't make sense to me, how should I then be doing this ?

thanks,

e.

Post by Etienne Ledoux

Post by Etienne Ledoux
I'm using pfsense to redirect all outgoing http traffic to a transparent
proxy. But I need to not redirect a specific range when browsing to that
specific range. pf supports "not rdr" as well as other options to

achieve

Post by Etienne Ledoux
this. But I can't figure out how can do this via pfsense ? Perhaps the

"No

Post by Etienne Ledoux
nat" feature somehow ?

Yup, no nat. I assume you are redirecting to another server and not
using the squid on box. If so, 'no nat' should work for you, just
make sure the 'no nat' rule is before the fall through redirect that
redirects everything else.
--Bill

[Bill Marquette]

Post by Etienne Ledoux
I have a internal LAN , DMZ and a WAN. My proxy is in the DMZ. I redirect
all http traffic from the LAN to the proxy in the DMZ. The rule looks like
rdr on vr0 inet proto tcp from any to any port = http -> 10.6.0.10 port
8080
no rdr on vr0 inet proto tcp from any to 10.2.0.0/16 port = http
above it.
The "no nat" feature available on outbound nat currently doesn't even allow
me to select my internal interface. So I'm not sure if this rule will work
because its probably going to be caught by the the rdr rule above anyways.
Unless I'm not suppose to be using rdr for this in the first place, which
doesn't make sense to me, how should I then be doing this ?

That's because you want Port Forward, not Outbound NAT (unless of
course Port Forward doesn't accept a 'not' option) :)

Suggestions for better wording accepted. I like DNAT and SNAT
(destination/source NAT respectively), but I'm not sure that people
would grok that either :)

--Bill

[Espen Johansen]

Count me in on SNAT/DNAT. It has been used for a long time and I for one
think it's very descriptive and logical.

-lsf

-----Original Message-----
From: Bill Marquette [mailto:***@gmail.com]
Sent: 1. november 2005 15:13
To: ***@pfsense.com
Subject: Re: [pfSense-discussion] how do I "not rdr" with pfsense

Post by Etienne Ledoux
I have a internal LAN , DMZ and a WAN. My proxy is in the DMZ. I redirect
all http traffic from the LAN to the proxy in the DMZ. The rule looks like
rdr on vr0 inet proto tcp from any to any port = http -> 10.6.0.10 port
8080
no rdr on vr0 inet proto tcp from any to 10.2.0.0/16 port = http
above it.
The "no nat" feature available on outbound nat currently doesn't even allow
me to select my internal interface. So I'm not sure if this rule will work
because its probably going to be caught by the the rdr rule above anyways.
Unless I'm not suppose to be using rdr for this in the first place, which
doesn't make sense to me, how should I then be doing this ?

That's because you want Port Forward, not Outbound NAT (unless of
course Port Forward doesn't accept a 'not' option) :)

Suggestions for better wording accepted. I like DNAT and SNAT
(destination/source NAT respectively), but I'm not sure that people
would grok that either :)

--Bill

[Dan Swartzendruber]

Post by Espen Johansen
Count me in on SNAT/DNAT. It has been used for a long time and I for one
think it's very descriptive and logical.

Seconded.

[Andrew Lewis]

Post by Dan Swartzendruber

Post by Espen Johansen
Count me in on SNAT/DNAT. It has been used for a long time and I for one
think it's very descriptive and logical.

Seconded.

How is that better than a circuit level gateway? I lean towards that
sort of thing since it reduces various headaches like MTU negotiation.

[Bill Marquette]

Post by Andrew Lewis

Post by Dan Swartzendruber

Post by Espen Johansen
Count me in on SNAT/DNAT. It has been used for a long time and I for one
think it's very descriptive and logical.

Seconded.

How is that better than a circuit level gateway? I lean towards that
sort of thing since it reduces various headaches like MTU negotiation.

huh? what does this have to do with NAT?

--Bill

[alan walters]

Post by Etienne Ledoux
I have a internal LAN , DMZ and a WAN. My proxy is in the DMZ. I

redirect

Post by Etienne Ledoux
all http traffic from the LAN to the proxy in the DMZ. The rule looks

like

Post by Etienne Ledoux
rdr on vr0 inet proto tcp from any to any port = http -> 10.6.0.10

port

Post by Etienne Ledoux
8080
no rdr on vr0 inet proto tcp from any to 10.2.0.0/16 port = http
above it.
The "no nat" feature available on outbound nat currently doesn't even
allow me to select my internal interface. So I'm not sure if this rule
will work because its probably going to be caught by the the rdr rule
above anyways.

[alan walters]
I have been thinking about this a lot recently. I was wondering if rules
for squid ftp proxy ipsec extra. Could be added to the xml file. At
least this way the user has some control over what to do with them.

I thought the best way to display these would be under there relative
interface setting and grouped by the anchor points defined in pf.

At least this would allow for a bit more transperancyy as to what rules
are going on and maybe a bit more control over what services are used
where.

Look forward to hearing what other users have to say in respect to this
issue on hidden rules in the /tmp/rules.debug file.

Post by Etienne Ledoux
Unless I'm not suppose to be using rdr for this in the first place,

which

Post by Etienne Ledoux
doesn't make sense to me, how should I then be doing this ?
thanks,
e.

Post by Etienne Ledoux
I'm using pfsense to redirect all outgoing http traffic to a

transparent

Post by Etienne Ledoux
proxy. But I need to not redirect a specific range when

browsing

Post by Etienne Ledoux
to that

Post by Etienne Ledoux
specific range. pf supports "not rdr" as well as other options

to

Post by Etienne Ledoux
achieve

Post by Etienne Ledoux
this. But I can't figure out how can do this via pfsense ?

Perhaps

Post by Etienne Ledoux
the "No

Post by Etienne Ledoux
nat" feature somehow ?

Yup, no nat. I assume you are redirecting to another server and

not

Post by Etienne Ledoux
using the squid on box. If so, 'no nat' should work for you,

just

Post by Etienne Ledoux
make sure the 'no nat' rule is before the fall through redirect

that

Post by Etienne Ledoux
redirects everything else.
--Bill

[Bill Marquette]

Post by alan walters
[alan walters]
I have been thinking about this a lot recently. I was wondering if rules
for squid ftp proxy ipsec extra. Could be added to the xml file. At
least this way the user has some control over what to do with them.
I thought the best way to display these would be under there relative
interface setting and grouped by the anchor points defined in pf.
At least this would allow for a bit more transperancyy as to what rules
are going on and maybe a bit more control over what services are used
where.
Look forward to hearing what other users have to say in respect to this
issue on hidden rules in the /tmp/rules.debug file.

I agree (who cares about the users when the devs - well at least one -
agree? ;-P), the system generated rules do need to be exposed. It's
one of the items on my "Enterprise readiness TODO" list. Currently
those rules are tied pretty heavily into the rules.debug generation,
but I've got some ideas on the "best" way to move them out.

I'm actually finding this somewhat refreshing, with the user levels,
multi-user, and hidden rules discussions, it sounds like we're nearly
at a point where SOHO is usable and we've peaked enough interest to
consider it in an enterprise.

--Bill

[Etienne Ledoux]

ok, I guess this means there is no solution for this problem yet ?
I'll have to wait a bit ?


e.

Post by Bill Marquette

Post by alan walters
[alan walters]
I have been thinking about this a lot recently. I was wondering if rules
for squid ftp proxy ipsec extra. Could be added to the xml file. At
least this way the user has some control over what to do with them.
I thought the best way to display these would be under there relative
interface setting and grouped by the anchor points defined in pf.
At least this would allow for a bit more transperancyy as to what rules
are going on and maybe a bit more control over what services are used
where.
Look forward to hearing what other users have to say in respect to this
issue on hidden rules in the /tmp/rules.debug file.

I agree (who cares about the users when the devs - well at least one -
agree? ;-P), the system generated rules do need to be exposed. It's
one of the items on my "Enterprise readiness TODO" list. Currently
those rules are tied pretty heavily into the rules.debug generation,
but I've got some ideas on the "best" way to move them out.
I'm actually finding this somewhat refreshing, with the user levels,
multi-user, and hidden rules discussions, it sounds like we're nearly
at a point where SOHO is usable and we've peaked enough interest to
consider it in an enterprise.
--Bill

[Scott Ullrich]

Yes, there is no "no" directive in port forward as of yet.

Scott

Post by Etienne Ledoux
ok, I guess this means there is no solution for this problem yet ?
I'll have to wait a bit ?
e.

Post by Bill Marquette

Post by alan walters
[alan walters]
I have been thinking about this a lot recently. I was wondering if rules
for squid ftp proxy ipsec extra. Could be added to the xml file. At
least this way the user has some control over what to do with them.
I thought the best way to display these would be under there relative
interface setting and grouped by the anchor points defined in pf.
At least this would allow for a bit more transperancyy as to what rules
are going on and maybe a bit more control over what services are used
where.
Look forward to hearing what other users have to say in respect to this
issue on hidden rules in the /tmp/rules.debug file.

I agree (who cares about the users when the devs - well at least one -
agree? ;-P), the system generated rules do need to be exposed. It's
one of the items on my "Enterprise readiness TODO" list. Currently
those rules are tied pretty heavily into the rules.debug generation,
but I've got some ideas on the "best" way to move them out.
I'm actually finding this somewhat refreshing, with the user levels,
multi-user, and hidden rules discussions, it sounds like we're nearly
at a point where SOHO is usable and we've peaked enough interest to
consider it in an enterprise.
--Bill

[Bill Marquette]

Your thread kind of got hijacked. You're problem was addressed in a
reply to you, not to Alan. Looking, the Port Forward screen doesn't
appear to have a 'not' option. So yes, right now, I'd say there's no
quick solution, without code.

--Bill

Post by Etienne Ledoux
ok, I guess this means there is no solution for this problem yet ?
I'll have to wait a bit ?