[pfSense Support] Ticket #1931: NAT reflection bug

2009-08-27 Thread David Rees
I've recently run into the issue described on ticket #1931 and on the
forum thread below:

http://cvstrac.pfsense.org/tktview?tn=1931
http://forum.pfsense.org/index.php/topic,16314.0.html

Even though we only have about 200 port forwards, we have 6 local
interfaces so we've quickly run into this limitation.

So a couple questions before I go and tackle this issue:

1. Why the limitation of 1000?  Is that more or less arbitrary to keep
from too many local ports from being used by the inetd nc rules, or
could it be increased some?

2. If I write a patch to limit the number of inetd entries below the
above limit, will it be accepted upstream?  We should be able to stop
the inetd nc port multiplication issue so we will be able to reflect
up to 1000 ports, but there will still be $num_interfaces *
$num_portforwards NAT redirect rules generated.  If the patch is
likely to be accepted upstream, I'm more likely to spend time to write
a 'proper' solution instead of just hacking it. :-)

Thanks

Dave

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: [pfSense Support] Ticket #1931: NAT reflection bug

2009-08-27 Thread Scott Ullrich
On Thu, Aug 27, 2009 at 2:15 PM, David Reesdree...@gmail.com wrote:
 I've recently run into the issue described on ticket #1931 and on the
 forum thread below:

 http://cvstrac.pfsense.org/tktview?tn=1931
 http://forum.pfsense.org/index.php/topic,16314.0.html

 Even though we only have about 200 port forwards, we have 6 local
 interfaces so we've quickly run into this limitation.

 So a couple questions before I go and tackle this issue:

 1. Why the limitation of 1000?  Is that more or less arbitrary to keep
 from too many local ports from being used by the inetd nc rules, or
 could it be increased some?

Because of some of the issues you outlined in #2.

 2. If I write a patch to limit the number of inetd entries below the
 above limit, will it be accepted upstream?  We should be able to stop
 the inetd nc port multiplication issue so we will be able to reflect
 up to 1000 ports, but there will still be $num_interfaces *
 $num_portforwards NAT redirect rules generated.  If the patch is
 likely to be accepted upstream, I'm more likely to spend time to write
 a 'proper' solution instead of just hacking it. :-)

We will gladly accept changes for this.  Thanks!

Scott

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: [pfSense Support] Ticket #1931: NAT reflection bug

2009-08-27 Thread David Rees
On Thu, Aug 27, 2009 at 11:59 AM, Scott Ullrichsullr...@gmail.com wrote:
 On Thu, Aug 27, 2009 at 2:15 PM, David Reesdree...@gmail.com wrote:
 I've recently run into the issue described on ticket #1931 and on the
 forum thread below:

 http://cvstrac.pfsense.org/tktview?tn=1931
 http://forum.pfsense.org/index.php/topic,16314.0.html

 Even though we only have about 200 port forwards, we have 6 local
 interfaces so we've quickly run into this limitation.

 So a couple questions before I go and tackle this issue:

 1. Why the limitation of 1000?  Is that more or less arbitrary to keep
 from too many local ports from being used by the inetd nc rules, or
 could it be increased some?

 Because of some of the issues you outlined in #2.

OK - I guess what I'm asking is this:

I've just checked my particular pfSense box and aside from the nearly
1000 ports it's listening to from 19000+ for my NAT reflection rules,
is there anything else keeping us from using a wider port range to
allow even more NAT reflection rules to be used?

I don't see many other ports in use on localhost except for ssh, dns,
pptp and a handful of ports ranging from 8021+ (which I believe are
used for the FTP helper).  I think that it may be helpful to be able
to override the default starting port range and number as well as the
maximum number of ports to use for NAT reflection. Bonus points I
guess for a patch which does this as well!  ;-)

 2. If I write a patch to limit the number of inetd entries below the
 above limit, will it be accepted upstream?  We should be able to stop
 the inetd nc port multiplication issue so we will be able to reflect
 up to 1000 ports, but there will still be $num_interfaces *
 $num_portforwards NAT redirect rules generated.  If the patch is
 likely to be accepted upstream, I'm more likely to spend time to write
 a 'proper' solution instead of just hacking it. :-)

 We will gladly accept changes for this.  Thanks!

Cool - I'll try to find some time over the next week to work on this.

I assume that working from a recent 1.2.3 snapshot OK?  Do you think
it will apply to the 2.0 branch as well?  I have no idea how much the
code there has changed...

-Dave

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: [pfSense Support] Ticket #1931: NAT reflection bug

2009-08-27 Thread Chris Buechler
On Thu, Aug 27, 2009 at 5:54 PM, David Reesdree...@gmail.com wrote:

 OK - I guess what I'm asking is this:

 I've just checked my particular pfSense box and aside from the nearly
 1000 ports it's listening to from 19000+ for my NAT reflection rules,
 is there anything else keeping us from using a wider port range to
 allow even more NAT reflection rules to be used?


There are some foot shooting possibilities if you aren't careful.

 I don't see many other ports in use on localhost except for ssh, dns,
 pptp and a handful of ports ranging from 8021+ (which I believe are
 used for the FTP helper).  I think that it may be helpful to be able
 to override the default starting port range and number as well as the
 maximum number of ports to use for NAT reflection.

Having them configurable in System-Advanced is probably good.


 I assume that working from a recent 1.2.3 snapshot OK?  Do you think
 it will apply to the 2.0 branch as well?  I have no idea how much the
 code there has changed...


This wouldn't be accepted into RELENG_1_2 (1.2.x), that's strictly bug
fixes only and this isn't a bug - though not ideal, it works as
designed. The patch (preferably merge request in git) would have to be
to 2.0. 2.0 is considerably different in many ways, but this
particular part of the code base probably isn't much different.

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: [pfSense Support] Ticket #1931: NAT reflection bug

2009-08-27 Thread David Rees
On Thu, Aug 27, 2009 at 3:09 PM, Chris Buechlerc...@pfsense.org wrote:
 On Thu, Aug 27, 2009 at 5:54 PM, David Reesdree...@gmail.com wrote:
 OK - I guess what I'm asking is this:

 I've just checked my particular pfSense box and aside from the nearly
 1000 ports it's listening to from 19000+ for my NAT reflection rules,
 is there anything else keeping us from using a wider port range to
 allow even more NAT reflection rules to be used?

 There are some foot shooting possibilities if you aren't careful.

Any details on those?

 I don't see many other ports in use on localhost except for ssh, dns,
 pptp and a handful of ports ranging from 8021+ (which I believe are
 used for the FTP helper).  I think that it may be helpful to be able
 to override the default starting port range and number as well as the
 maximum number of ports to use for NAT reflection.

 Having them configurable in System-Advanced is probably good.

 I assume that working from a recent 1.2.3 snapshot OK?  Do you think
 it will apply to the 2.0 branch as well?  I have no idea how much the
 code there has changed...

 This wouldn't be accepted into RELENG_1_2 (1.2.x), that's strictly bug
 fixes only and this isn't a bug - though not ideal, it works as
 designed. The patch (preferably merge request in git) would have to be
 to 2.0. 2.0 is considerably different in many ways, but this
 particular part of the code base probably isn't much different.

Hmm, if I just submit a patch which addresses #1931 and keeps
duplicate nc entries out of inetd.conf without adding new features
(which IMO is a bug), could that be accepted into the stable branch?

Hate to say it, but I don't have a lot of interest in writing code for
a release whose release schedule appears to be many, many, months away
and I am not yet even testing in the lab.  I am much more motivated to
write code which has a good chance of seeing production use relatively
soon.

-Dave

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: [pfSense Support] Ticket #1931: NAT reflection bug

2009-08-27 Thread Chris Buechler
On Thu, Aug 27, 2009 at 6:51 PM, David Reesdree...@gmail.com wrote:

 There are some foot shooting possibilities if you aren't careful.

 Any details on those?


Binding to things that local services would bind to, and then those
fail to start.


 Hmm, if I just submit a patch which addresses #1931 and keeps
 duplicate nc entries out of inetd.conf without adding new features
 (which IMO is a bug), could that be accepted into the stable branch?


Yeah that would be acceptable.

 Hate to say it, but I don't have a lot of interest in writing code for
 a release whose release schedule appears to be many, many, months away
 and I am not yet even testing in the lab.  I am much more motivated to
 write code which has a good chance of seeing production use relatively
 soon.

Anything that gets added to RELENG_1_2 must be added to 2.0 first. So
you're going to have to accommodate 2.0 either way for it to be
accepted. I don't know what your definition of many, many months is,
but 2.0 isn't years out or anything, talking a few months to final
release maybe, partially dependent on the FreeBSD 8.0 release
schedule.

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org