Bug 8325 - -j REDIRECT --to-ports 1000-1009, always first choosen
Summary: -j REDIRECT --to-ports 1000-1009, always first choosen
Status: CLOSED CODE_FIX
Alias: None
Product: Networking
Classification: Unclassified
Component: Netfilter/Iptables (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: networking_netfilter-iptables@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-13 13:53 UTC by Rafal Wijata
Modified: 2008-02-02 10:14 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.19-1.2911.fc6PAE 2.6.19-gentoo-r4
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Rafal Wijata 2007-04-13 13:53:10 UTC
Most recent kernel where this bug did *NOT* occur:
Distribution: FC6, gentoo
Hardware Environment:
Software Environment:
Problem Description:

Steps to reproduce:
Try redirecting to range of ports with iptables, kernel(?) will always redirect 
to first port from given range.
Comment 1 Anonymous Emailer 2007-04-13 14:47:07 UTC
Reply-To: akpm@linux-foundation.org

On Fri, 13 Apr 2007 13:53:12 -0700
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=8325
> 
>            Summary: -j REDIRECT --to-ports 1000-1009, always first choosen
>     Kernel Version: 2.6.19-1.2911.fc6PAE 2.6.19-gentoo-r4
>             Status: NEW
>           Severity: normal
>              Owner: networking_netfilter-iptables@kernel-bugs.osdl.org
>          Submitter: wijata@nec-labs.com
> 
> 
> Most recent kernel where this bug did *NOT* occur:
> Distribution: FC6, gentoo
> Hardware Environment:
> Software Environment:
> Problem Description:
> 
> Steps to reproduce:
> Try redirecting to range of ports with iptables, kernel(?) will always redirect 
> to first port from given range.
> 

Comment 2 Patrick McHardy 2007-04-15 22:14:39 UTC
Andrew Morton wrote:
> On Fri, 13 Apr 2007 13:53:12 -0700
> bugme-daemon@bugzilla.kernel.org wrote:
> 
> 
>>http://bugzilla.kernel.org/show_bug.cgi?id=8325
>>
>>           Summary: -j REDIRECT --to-ports 1000-1009, always first choosen
>>    Kernel Version: 2.6.19-1.2911.fc6PAE 2.6.19-gentoo-r4
>>            Status: NEW
>>          Severity: normal
>>             Owner: networking_netfilter-iptables@kernel-bugs.osdl.org
>>         Submitter: wijata@nec-labs.com
>>
>>
>>Most recent kernel where this bug did *NOT* occur:
>>Distribution: FC6, gentoo
>>Hardware Environment:
>>Software Environment:
>>Problem Description:
>>
>>Steps to reproduce:
>>Try redirecting to range of ports with iptables, kernel(?) will always redirect 
>>to first port from given range.


It will use a different port if there is a clash (a connection with the
same identity already exists). I'm guessing you're expecting that it
will use the ports in order. We might be able to change that, but I
don't really see a case where it would make sense. Please describe what
you're trying to do.

Comment 3 Anonymous Emailer 2007-04-15 22:27:17 UTC
Reply-To: denys@visp.net.lb

Sorry, i will put my IMHO, since i am using it too.

I guess it can be useful for load-balancing scenario.
Is there way to provide both ways?
Thinking... 60% done, But maybe this can be done over -m statistic already

On Mon, 16 Apr 2007 07:12:33 +0200, Patrick McHardy wrote
> Andrew Morton wrote:
> > On Fri, 13 Apr 2007 13:53:12 -0700
> > bugme-daemon@bugzilla.kernel.org wrote:
> > 
> > 
> >>http://bugzilla.kernel.org/show_bug.cgi?id=8325
> >>
> >>           Summary: -j REDIRECT --to-ports 1000-1009, always first choosen
> >>    Kernel Version: 2.6.19-1.2911.fc6PAE 2.6.19-gentoo-r4
> >>            Status: NEW
> >>          Severity: normal
> >>             Owner: networking_netfilter-iptables@kernel-bugs.osdl.org
> >>         Submitter: wijata@nec-labs.com
> >>
> >>
> >>Most recent kernel where this bug did *NOT* occur:
> >>Distribution: FC6, gentoo
> >>Hardware Environment:
> >>Software Environment:
> >>Problem Description:
> >>
> >>Steps to reproduce:
> >>Try redirecting to range of ports with iptables, kernel(?) will always 
redirect 
> >>to first port from given range.
> 
> It will use a different port if there is a clash (a connection with the
> same identity already exists). I'm guessing you're expecting that it
> will use the ports in order. We might be able to change that, but I
> don't really see a case where it would make sense. Please describe what
> you're trying to do.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.

Comment 4 Patrick McHardy 2007-04-15 22:32:39 UTC
Denys wrote:
> Sorry, i will put my IMHO, since i am using it too.
> 
> I guess it can be useful for load-balancing scenario.


That makes sense with using multiple IPs (and we support doing that),
but whats the point of load-balancing to differenet *ports*?

> Is there way to provide both ways?
> Thinking... 60% done, But maybe this can be done over -m statistic already


2.6.21-rc supports randomized port selection (with iptables userspace
from SVN). Using the statistic match would work as well.

Comment 5 Anonymous Emailer 2007-04-15 22:45:55 UTC
Reply-To: denys@visp.net.lb




On Mon, 16 Apr 2007 07:30:33 +0200, Patrick McHardy wrote
> Denys wrote:
> > Sorry, i will put my IMHO, since i am using it too.
> > 
> > I guess it can be useful for load-balancing scenario.
> 
> That makes sense with using multiple IPs (and we support doing that),
> but whats the point of load-balancing to differenet *ports*?

Easy - for example i have my own TCP acceleration solution, which is using 
REDIRECT, then getsockopt/SO_ORIGINAL_DST to get original IP, then forwarding 
to compressed tunnel, stripping unneeded bytes (oh, my expensive satellite 
bandwidth). This way for example i can do some kind load-balancing for 
satellite bandwidth. But i have done it over -m statistic.

> 
> > Is there way to provide both ways?
> > Thinking... 60% done, But maybe this can be done over -m statistic already
> 
> 2.6.21-rc supports randomized port selection (with iptables userspace
> from SVN). Using the statistic match would work as well.
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.

Comment 6 Patrick McHardy 2007-04-15 22:54:12 UTC
Denys wrote:
> On Mon, 16 Apr 2007 07:30:33 +0200, Patrick McHardy wrote
> 
>>That makes sense with using multiple IPs (and we support doing that),
>>but whats the point of load-balancing to differenet *ports*?
> 
> 
> Easy - for example i have my own TCP acceleration solution, which is using 
> REDIRECT, then getsockopt/SO_ORIGINAL_DST to get original IP, then forwarding 
> to compressed tunnel, stripping unneeded bytes (oh, my expensive satellite 
> bandwidth). This way for example i can do some kind load-balancing for 
> satellite bandwidth. 


That sounds rather hackish, you might as well do it in your application.

I just noticed we don't accept the random option for DNAT/REDIRECT yet,
but that is easily fixed (I'll queue a patch for 2.6.22). Then this
will work and select ports from the range randomly:

iptables -t nat -A INPUT .. -j REDIRECT --to-ports 1000:1010 --random

Comment 7 Rafal Wijata 2007-04-16 01:14:28 UTC
Letm me explain why I posted this issue.
I have a sinlge encrypted tunnel to remote place. On remote there are few mail 
servers(each may be used in place of the other). The tunnel forwards few local 
ports to few remote servers.
Now You may imagine that I wanted REDIRECT/load-balnace local connections to 
remotes.
I workarounded that with redirecting to yet another port, where simple script 
chooses destination port randomly and execs netcat.

Looking forward for the --random option then.
Comment 8 Natalie Protasevich 2007-07-07 17:11:10 UTC
Any updates? Is this setup working for you now, Rafal?
Thanks.
Comment 9 Patrick McHardy 2008-02-02 03:46:21 UTC
The DNAT --random option has been merged in 2.6.22. Please close.
Comment 10 Natalie Protasevich 2008-02-02 10:14:21 UTC
Thanks, closing the bug.

Note You need to log in before you can comment on or make changes to this bug.