Redirecting ports on localhost

Redirecting ports on localhost

[Fabiano Bonin]

I followed a thread about redirecting ports on localhost, but i still 
did not have success in my case.
I have a service listening on port 5050, just on the local interface, as 
shown below:

netstat -n -a -p | grep 5050
tcp        0      0 127.0.0.1:5050          0.0.0.0:*               
LISTEN      7485/0

I need to access this service from other hosts through ETH0 interface 
(ip 192.168.0.254). The other hosts are in the same network.
I already enabled "NF_NAT_LOCAL" kernel option (btw, all netfilter 
options are enabled in my kernel), and the commands i'm using are these:

iptables -F
iptables -F -t nat
iptables -A OUTPUT -t nat -p tcp -o lo -d 192.168.0.254 --dport 5050 -j 
REDIRECT --to-ports 5050
echo "1" > /proc/sys/net/ipv4/ip_forward

After these commands, i can access the service on the eth0 interface 
from the server host itself, but not from other hosts in the same network.

What am i doing wrong?

Thanks.

Re: Redirecting ports on localhost

[David Cannings]

On Tuesday 30 March 2004 13:46, Fabiano Bonin wrote:
> I need to access this service from other hosts through ETH0 interface
> (ip 192.168.0.254). The other hosts are in the same network.
> I already enabled "NF_NAT_LOCAL" kernel option (btw, all netfilter
> options are enabled in my kernel), and the commands i'm using are
> these:

NF_NAT_LOCAL is for NAT'ing connections that originate on the local 
machine (ie the netfilter machine).  I don't believe it will do what you 
want though I may be incorrect.

> iptables -F
> iptables -F -t nat
> iptables -A OUTPUT -t nat -p tcp -o lo -d 192.168.0.254 --dport 5050 -j
> REDIRECT --to-ports 5050
> echo "1" > /proc/sys/net/ipv4/ip_forward

I don't think you need anything special to do this however your rule says 
"any packets going out on loopback to 192.168.0.254".  The only machine 
on your network that would send packets to 192.168.0.254 on loopback is 
the machine with that IP itself.

Can you not make that daemon listen on an interface IP as well as 
127.0.0.1?  This way other hosts could connect to 192.168.0.254:5050.  
Other hosts that try to access port 5050 on your machine will simply come 
through the INPUT chain, no NAT needed.  If you can't, or don't want to 
for good reason, I am sure it would be possible with DNAT. 

Perhaps I misunderstand what you are trying to accomplish, apologies if 
so.

David

Redirection to local lan, isn't DNAT method unsafe.

[Bo Jacobsen]

I use DNAT to redirect traffic from the external lan eth0 (192.168.1.1) to a
specific host (192.168.10.10) on the internal lan (eth1) like this:

iptables -t nat -A PREROUTING  -p tcp --dport 80  -d 192.168.1.1 -j DNAT 
    --to 192.168.10.10 -i eth0

and then I allow the redirected traffic:
iptables -a FORWARD -p tcp --dport 80  -d 192.168.10.10 ........

It works as expected but with this aproach, it's actually possible from the outside
to find out what internal ip, the http server is located at !.
All one has to do is sending to 192.168.10.1, 192.168.10.2, 192.168.10.3 etc.  (to 
eth0 on the outside) until one hits the server. The rules allows it.

I have not been able to figure out how to solve this problem.


Any suggestions.

Thanks in advance
Bo Jacobsen

Re: Redirection to local lan, isn't DNAT method unsafe.

[Antony Stone]

On Thursday 01 April 2004 9:25 am, Bo Jacobsen wrote:

> I use DNAT to redirect traffic from the external lan eth0 (192.168.1.1) to
> a specific host (192.168.10.10) on the internal lan (eth1) like this:
>
> iptables -t nat -A PREROUTING  -p tcp --dport 80  -d 192.168.1.1 -j DNAT
>     --to 192.168.10.10 -i eth0
>
> and then I allow the redirected traffic:
> iptables -a FORWARD -p tcp --dport 80  -d 192.168.10.10 ........
>
> It works as expected but with this aproach, it's actually possible from the
> outside to find out what internal ip, the http server is located at !.
> All one has to do is sending to 192.168.10.1, 192.168.10.2, 192.168.10.3
> etc.  (to eth0 on the outside) until one hits the server. The rules allows
> it.
>
> I have not been able to figure out how to solve this problem.

It is normally recommended *not* to do filtering in the nat or mangle tables, 
however in this case if you really want to do what you say then that is the 
solution.

iptables -I PREROUTING -t nat -s 192.168.1.0/24 -d 192.168.10.10 -p tcp 
--dport 80 -j DROP

Note the -I which inserts the rule before the prerouting rule you listed 
above.

Regards,

Antony.

-- 
What is this talk of "software release"?
Our software evolves and matures until it is capable of escape, leaving a 
bloody trail of designers and quality assurance people in its wake.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Redirection to local lan, isn't DNAT method unsafe.

[Bo Jacobsen]

> > I use DNAT to redirect traffic from the external lan eth0 (192.168.1.1) to
> > a specific host (192.168.10.10) on the internal lan (eth1) like this:
> >
> > iptables -t nat -A PREROUTING  -p tcp --dport 80  -d 192.168.1.1 -j DNAT
> >     --to 192.168.10.10 -i eth0
> >
> > and then I allow the redirected traffic:
> > iptables -a FORWARD -p tcp --dport 80  -d 192.168.10.10 ........
> >
> > It works as expected but with this aproach, it's actually possible from the
> > outside to find out what internal ip, the http server is located at !.
> > All one has to do is sending to 192.168.10.1, 192.168.10.2, 192.168.10.3
> > etc.  (to eth0 on the outside) until one hits the server. The rules allows
> > it.
> >
> > I have not been able to figure out how to solve this problem.
> 
> It is normally recommended *not* to do filtering in the nat or mangle tables, 
> however in this case if you really want to do what you say then that is the 
> solution.
> 
> iptables -I PREROUTING -t nat -s 192.168.1.0/24 -d 192.168.10.10 -p tcp 
> --dport 80 -j DROP
> 
> Note the -I which inserts the rule before the prerouting rule you listed 
> above.
> 
> Regards,
> 
> Antony.

Thanks.

> however in this case if you really want to do what you say then that is the 
> solution.

Is there another and better way to redirect traffic to the inside ?

Bo

Re: Redirection to local lan, isn't DNAT method unsafe.

[Antony Stone]

On Thursday 01 April 2004 9:55 am, Bo Jacobsen wrote:

> > It is normally recommended *not* to do filtering in the nat or mangle
> > tables, however in this case if you really want to do what you say then
> > that is the solution.
> >
> > iptables -I PREROUTING -t nat -s 192.168.1.0/24 -d 192.168.10.10 -p tcp
> > --dport 80 -j DROP
> >
> > Note the -I which inserts the rule before the prerouting rule you listed
> > above.
>
> Thanks.
>
> > however in this case if you really want to do what you say then that is
> > the solution.
>
> Is there another and better way to redirect traffic to the inside ?

Well, DNAT is normally used to map externally-accessible public IPs to real 
internal systems on non-routable 10.x.y.z, 172.16.a.b or 192.168.c.d 
addresses, therefore the problem never arises (since people across the 
Internet can't send packets to the real private addresses even if they knew 
what they were).

There's isn't a "better" way to redirect traffic to other IP addresses, 
however why do you think it's a problem for people to use the "real" address 
instead of the one you're telling them to use.   They have access to the 
machine, so why does it really matter which address they use to connect to 
it?

Regards,

Antony.

-- 
RTFM may be the appropriate reply, but please specify exactly which FM to R.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Redirection to local lan, isn't DNAT method unsafe.

[Bo Jacobsen]

> > > It is normally recommended *not* to do filtering in the nat or mangle
> > > tables, however in this case if you really want to do what you say then
> > > that is the solution.
> > >
> > > iptables -I PREROUTING -t nat -s 192.168.1.0/24 -d 192.168.10.10 -p tcp
> > > --dport 80 -j DROP
> > >
> > > Note the -I which inserts the rule before the prerouting rule you listed
> > > above.
> >
> > Thanks.
> >
> > > however in this case if you really want to do what you say then that is
> > > the solution.
> >
> > Is there another and better way to redirect traffic to the inside ?
> 
> Well, DNAT is normally used to map externally-accessible public IPs to real 
> internal systems on non-routable 10.x.y.z, 172.16.a.b or 192.168.c.d 
> addresses, therefore the problem never arises (since people across the 
> Internet can't send packets to the real private addresses even if they knew 
> what they were).
> 
> There's isn't a "better" way to redirect traffic to other IP addresses, 
> however why do you think it's a problem for people to use the "real" address 
> instead of the one you're telling them to use.   They have access to the 
> machine, so why does it really matter which address they use to connect to 
> it?
> 
> Regards,
> 
> Antony.
> 

The problem is that many hosts, with this setup, actually is connected to the 
internet using a public ip, and beeing able to resolve internal ip-information is not 
good.

Bo

Re: Redirection to local lan, isn't DNAT method unsafe.

[Antony Stone]

On Thursday 01 April 2004 10:42 am, Bo Jacobsen wrote:

> > Well, DNAT is normally used to map externally-accessible public IPs to
> > real internal systems on non-routable 10.x.y.z, 172.16.a.b or 192.168.c.d
> > addresses, therefore the problem never arises (since people across the
> > Internet can't send packets to the real private addresses even if they
> > knew what they were).
> >
> > There isn't a "better" way to redirect traffic to other IP addresses,
> > however why do you think it's a problem for people to use the "real"
> > address instead of the one you're telling them to use.   They have access
> > to the machine, so why does it really matter which address they use to
> > connect to it?
>
> The problem is that many hosts, with this setup, actually is connected to
> the internet using a public ip, and beeing able to resolve internal
> ip-information is not good.

Now I'm confused.   (Easily done...)

Were the 192.168.x.y addresses you gave in your original posting accurate, or 
just examples, and you are now saying that the source machines are actually 
systems out on the Internet somewhere with real public IPs?

Please clarify - who are you worried about discovering the real internal IP 
addresses of your machines, and where are they located on the network?   Can 
they really send packets to the private IP address as you outlined in your 
original posting?

My expectation is that people "out on the Internet" cannot connect to your 
private IPs (because the addresses are non-routable), therefore the question 
doesn't arise for them.   People associated with your local network (ie: 
inside your connection point to the Internet) surely aren't a problem even if 
they do discover the real private IP address?   Or am I missing something 
here about what you are trying to secure from whom?

Hope that's clear....

Regards,

Antony.

-- 
Software development can be quick, high quality, or low cost.

The customer gets to pick any two out of three.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Redirection to local lan, isn't DNAT method unsafe.

[Bo Jacobsen]

> > > Well, DNAT is normally used to map externally-accessible public IPs to
> > > real internal systems on non-routable 10.x.y.z, 172.16.a.b or 192.168.c.d
> > > addresses, therefore the problem never arises (since people across the
> > > Internet can't send packets to the real private addresses even if they
> > > knew what they were).
> > >
> > > There isn't a "better" way to redirect traffic to other IP addresses,
> > > however why do you think it's a problem for people to use the "real"
> > > address instead of the one you're telling them to use.   They have access
> > > to the machine, so why does it really matter which address they use to
> > > connect to it?
> >
> > The problem is that many hosts, with this setup, actually is connected to
> > the internet using a public ip, and beeing able to resolve internal
> > ip-information is not good.
> 
> Now I'm confused.   (Easily done...)
> 
> Were the 192.168.x.y addresses you gave in your original posting accurate, or 
> just examples, and you are now saying that the source machines are actually 
> systems out on the Internet somewhere with real public IPs?
> 
> Please clarify - who are you worried about discovering the real internal IP 
> addresses of your machines, and where are they located on the network?   Can 
> they really send packets to the private IP address as you outlined in your 
> original posting?
> 
> My expectation is that people "out on the Internet" cannot connect to your 
> private IPs (because the addresses are non-routable), therefore the question 
> doesn't arise for them.   People associated with your local network (ie: 
> inside your connection point to the Internet) surely aren't a problem even if 
> they do discover the real private IP address?   Or am I missing something 
> here about what you are trying to secure from whom?
> 
> Hope that's clear....
> 
> Regards,
> 
> Antony.
> 

Well, the setup is used on a number of hosts located in a number of different 
environments. Some have public ip's, some don't. 

> inside your connection point to the Internet) surely aren't a problem even if 
> they do discover the real private IP address?   Or am I missing something 
That just true in a very simple setup. If different people/compagnies are sharing 
a "backbone" (using maybe 192.168.1.0 as the lan behind a commen internet router)
the problem is maybe not an internet problem, but an "internal" problem. Should
one trust all the other compagnies on the backbone, of course not.
So the general rule is ALWAYS to stop any leaking if it's possible.

I have solved the problem by always running a second -j DROP rule in the 
PREROUTING chain (as you suggested).


Bo

Re: Redirection to local lan, isn't DNAT method unsafe.

[Unknown, Alistair Tonner]

On April 1, 2004 04:55 am, Antony Stone wrote:
> On Thursday 01 April 2004 10:42 am, Bo Jacobsen wrote:
> > > Well, DNAT is normally used to map externally-accessible public IPs to
> > > real internal systems on non-routable 10.x.y.z, 172.16.a.b or
> > > 192.168.c.d addresses, therefore the problem never arises (since people
> > > across the Internet can't send packets to the real private addresses
> > > even if they knew what they were).
> > >
> > > There isn't a "better" way to redirect traffic to other IP addresses,
> > > however why do you think it's a problem for people to use the "real"
> > > address instead of the one you're telling them to use.   They have
> > > access to the machine, so why does it really matter which address they
> > > use to connect to it?
> >
> > The problem is that many hosts, with this setup, actually is connected to
> > the internet using a public ip, and beeing able to resolve internal
> > ip-information is not good.
>
> Now I'm confused.   (Easily done...)
>
> Were the 192.168.x.y addresses you gave in your original posting accurate,
> or just examples, and you are now saying that the source machines are
> actually systems out on the Internet somewhere with real public IPs?
>
> Please clarify - who are you worried about discovering the real internal IP
> addresses of your machines, and where are they located on the network?  
> Can they really send packets to the private IP address as you outlined in
> your original posting?
>
> My expectation is that people "out on the Internet" cannot connect to your
> private IPs (because the addresses are non-routable), therefore the
> question doesn't arise for them.   People associated with your local
> network (ie: inside your connection point to the Internet) surely aren't a
> problem even if they do discover the real private IP address?   Or am I
> missing something here about what you are trying to secure from whom?
>
> Hope that's clear....
>
> Regards,
>
> Antony.


	Actually I can see one other horrible possibility  --- an ISP with a \28 net --
	where the internal network of the ISP is by neccesity a non routeable address space, 
	and is natted within the \28 netowork ... or where subscribers are all on non routeable addresses
	and primary connection services are on the \28 space....

	Alistair.

Re: Redirection to local lan, isn't DNAT method unsafe.

[Antony Stone]

On Thursday 01 April 2004 11:20 pm, Alistair Tonner wrote:

> On April 1, 2004 04:55 am, Antony Stone wrote:
>
> > My expectation is that people "out on the Internet" cannot connect to
> > your private IPs (because the addresses are non-routable), therefore the
> > question doesn't arise for them.   People associated with your local
> > network (ie: inside your connection point to the Internet) surely aren't
> > a problem even if they do discover the real private IP address?   Or am I
> > missing something here about what you are trying to secure from whom?
>
> 	Actually I can see one other horrible possibility  --- an ISP with a \28
> net -- where the internal network of the ISP is by neccesity a non
> routeable address space, and is natted within the \28 netowork ... or where
> subscribers are all on non routeable addresses and primary connection
> services are on the \28 space....

Hm, I see what you're saying (and yes, there are a lot of ISPs who run 
networks like this), however I still think that if you're making the service 
available to people on a public IP address (NATted by your firewall to the 
real private address), then why are you particularly bothered about them 
accessing the same service, by its private address?

Okay, it's the way you wanted them to do it, but they can't do any more with 
it than they could by using the public IP.

?

Antony.

-- 
This is not a rehearsal.
This is Real Life.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Redirection to local lan, isn't DNAT method unsafe.

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

On Thu, Apr 01, 2004 at 10:25:06AM +0200, Bo Jacobsen wrote:
> I use DNAT to redirect traffic from the external lan eth0 (192.168.1.1) to a
> specific host (192.168.10.10) on the internal lan (eth1) like this:
> 
> iptables -t nat -A PREROUTING  -p tcp --dport 80  -d 192.168.1.1 -j DNAT 
>     --to 192.168.10.10 -i eth0
> 
> and then I allow the redirected traffic:
> iptables -a FORWARD -p tcp --dport 80  -d 192.168.10.10 ........
> 
> It works as expected but with this aproach, it's actually possible from the outside
> to find out what internal ip, the http server is located at !.
> All one has to do is sending to 192.168.10.1, 192.168.10.2, 192.168.10.3 etc.  (to 
> eth0 on the outside) until one hits the server. The rules allows it.

The 192.168.0.0/24 is a non internet routeable address, meaning all ISP
drop this address range.

Pretty sure you might be able to capture this in prerouting (mangle) and
drop it there, although your not meant to drop/filter table

also if you have rp_filter on (for the internet interface) it would probably capture it first before
it hits netfilter 


> 
> I have not been able to figure out how to solve this problem.
> 
> 
> Any suggestions.
> 
> Thanks in advance
> Bo Jacobsen
> 
> 
> 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 185 bytes --]

Re: Redirecting ports on localhost

[Fabiano Bonin]

 > On Tuesday 30 March 2004 13:46, Fabiano Bonin wrote:

>> I need to access this service from other hosts through ETH0 interface
>> (ip 192.168.0.254). The other hosts are in the same network.
>> I already enabled "NF_NAT_LOCAL" kernel option (btw, all netfilter
>> options are enabled in my kernel), and the commands i'm using are
>> these:
>  
>
> NF_NAT_LOCAL is for NAT'ing connections that originate on the local 
> machine (ie the netfilter machine).  I don't believe it will do what you 
> want though I may be incorrect.

>> iptables -F
>> iptables -F -t nat
>> iptables -A OUTPUT -t nat -p tcp -o lo -d 192.168.0.254 --dport 5050 -j
>> REDIRECT --to-ports 5050
>> echo "1" > /proc/sys/net/ipv4/ip_forward
>  
>

> I don't think you need anything special to do this however your rule says 
> "any packets going out on loopback to 192.168.0.254".  The only machine 
> on your network that would send packets to 192.168.0.254 on loopback is 
> the machine with that IP itself.

> Can you not make that daemon listen on an interface IP as well as 
> 127.0.0.1?  This way other hosts could connect to 192.168.0.254:5050.  
> Other hosts that try to access port 5050 on your machine will simply come 
> through the INPUT chain, no NAT needed.  If you can't, or don't want to 
> for good reason, I am sure it would be possible with DNAT. 

This daemon is a SSH tunnel to a remote machine. I couldn't enable interfaces other than lo to listen on that port, even enabling the option 'remote ports accept connections from other hosts' in the client program (putty). I'm almos sure this is a SSH protocol limitation due to security reasons, so probably my only choice is through iptables.

> Perhaps I misunderstand what you are trying to accomplish, apologies if 
> so.

Most probably you understood what i am trying to do, and the way i'm trying (as shown in the examples) is entirelly wrong. I used iptables few times before and i'm not skilled with it.

Maybe you can show the command needed to my case (i.e., using DNAT as you told above). Sorry if i'm asking too much...
I just need the hosts on my local network can access this port through server's eth0.

Thanks again.

> David

Re: Redirecting ports on localhost

[David Cannings]

On Tuesday 30 March 2004 15:15, Fabiano Bonin wrote:
>  > On Tuesday 30 March 2004 13:46, Fabiano Bonin wrote:
> >> iptables -F
> >> iptables -F -t nat
> >> iptables -A OUTPUT -t nat -p tcp -o lo -d 192.168.0.254 --dport 5050
> >> -j REDIRECT --to-ports 5050
> >> echo "1" > /proc/sys/net/ipv4/ip_forward
> > I don't think you need anything special to do this however your rule
> > says "any packets going out on loopback to 192.168.0.254".  The only
> > machine on your network that would send packets to 192.168.0.254 on
> > loopback is the machine with that IP itself.
> > Perhaps I misunderstand what you are trying to accomplish, apologies
> > if so.
>
> Most probably you understood what i am trying to do, and the way i'm
> trying (as shown in the examples) is entirelly wrong. I used iptables
> few times before and i'm not skilled with it.
>
> Maybe you can show the command needed to my case (i.e., using DNAT as
> you told above). Sorry if i'm asking too much... I just need the hosts
> on my local network can access this port through server's eth0.

http://netfilter.org/documentation/HOWTO//NAT-HOWTO-6.html#ss6.2

I've linked to the English HTML version of the HOWTO, other languages and 
formats are available at:

http://netfilter.org/documentation/index.html#documentation-howto

Have a read, see if you can make some sense of it.  If not, post back with 
what you've tried and why it doesn't work.  For the record, I've never 
tried redirecting a port to localhost although I can see no reason why it 
would not work as any other does.  I will have to give it a go myself 
when I have a few minutes spare.

Hope that helps,

David

Re: Redirecting ports on localhost

[Tony Earnshaw]

tir, 30.03.2004 kl. 21.13 skrev David Cannings:

> I've linked to the English HTML version of the HOWTO, other languages and 
> formats are available at:
> 
> http://netfilter.org/documentation/index.html#documentation-howto
> 
> Have a read, see if you can make some sense of it.  If not, post back with 
> what you've tried and why it doesn't work.  For the record, I've never 
> tried redirecting a port to localhost although I can see no reason why it 
> would not work as any other does.  I will have to give it a go myself 
> when I have a few minutes spare.

Hi David,

Dunno if you're the one responsible for the general Netfilter HOWTO. But
if so, could you please change "iplimit" to "connlimit"? I've used vi to
great effect after txt2html for my own copy, but I frigged around with
iplimit for a while with the non-existent iplimit first. I was *not*
pleased.

B.t.w., connlimit works a treat :)

Best,

--Tonni

-- 

mail: billy - at - billy.demon.nl
http://www.billy.demon.nl

Re: Redirecting ports on localhost

[David Cannings]

On Tuesday 30 March 2004 23:03, Tony Earnshaw wrote:
> tir, 30.03.2004 kl. 21.13 skrev David Cannings:
> > I've linked to the English HTML version of the HOWTO, other languages
> > and formats are available at:
> >
> > http://netfilter.org/documentation/index.html#documentation-howto
> >
> > Have a read, see if you can make some sense of it.  If not, post back
> > with what you've tried and why it doesn't work.  For the record, I've
> > never tried redirecting a port to localhost although I can see no
> > reason why it would not work as any other does.  I will have to give
> > it a go myself when I have a few minutes spare.
> Hi David,
> Dunno if you're the one responsible for the general Netfilter HOWTO.
> But if so, could you please change "iplimit" to "connlimit"? I've used
> vi to great effect after txt2html for my own copy, but I frigged around
> with iplimit for a while with the non-existent iplimit first. I was
> *not* pleased.

Definitely not, the only way I contribute to netfilter is helping out on 
the users mailing list.  I am unsure whether the source to the HOWTO 
documents is available, perhaps you could submit diff's for what you 
believe needs changing.

David

Re: Redirecting ports on localhost

[Tony Earnshaw]

ons, 31.03.2004 kl. 00.31 skrev David Cannings:
> avid,
> > Dunno if you're the one responsible for the general Netfilter HOWTO.
> > But if so, could you please change "iplimit" to "connlimit"? I've used
> > vi to great effect after txt2html for my own copy, but I frigged around
> > with iplimit for a while with the non-existent iplimit first. I was
> > *not* pleased.
> 
> Definitely not, the only way I contribute to netfilter is helping out on 
> the users mailing list.  I am unsure whether the source to the HOWTO 
> documents is available, perhaps you could submit diff's for what you 
> believe needs changing.

:g/iplimit/s//connlimit/g

--Tonni

-- 

mail: billy - at - billy.demon.nl
http://www.billy.demon.nl

Re: Redirecting ports on localhost

[David Cannings]

On Tuesday 30 March 2004 20:13, David Cannings wrote:
> On Tuesday 30 March 2004 15:15, Fabiano Bonin wrote:
> >  > On Tuesday 30 March 2004 13:46, Fabiano Bonin wrote:
> > Maybe you can show the command needed to my case (i.e., using DNAT as
> > you told above). Sorry if i'm asking too much... I just need the
> > hosts on my local network can access this port through server's eth0.
>
> http://netfilter.org/documentation/HOWTO//NAT-HOWTO-6.html#ss6.2
>
> I've linked to the English HTML version of the HOWTO, other languages
> and formats are available at:
>
> http://netfilter.org/documentation/index.html#documentation-howto
>
> Have a read, see if you can make some sense of it.  If not, post back
> with what you've tried and why it doesn't work.  For the record, I've
> never tried redirecting a port to localhost although I can see no
> reason why it would not work as any other does.  I will have to give it
> a go myself when I have a few minutes spare.

As a followup I have found some time to play with this now.  Spending a 
few minutes on Google turned up a wealth of information regarding this 
problem.  One of the most useful posts was this one:

http://lists.netfilter.org/pipermail/netfilter/2002-November/040104.html

In short: by the looks of it you cannot DNAT to localhost as the kernel 
thinks that it is a martian packet.  As this is a rather old message I 
decided to investigate it myself.

I added a rule to the prerouting chain to DNAT port 3001 (a number I 
picked totally randomly) to 127.0.0.1:3000, this appears to work as far 
as netfilter is concerned, proof follows.  Note the key part of the last 
sentence: "as far as netfilter is concerned".

The following method works as expected in all aspects when the --to 
argument for DNAT is a local interface.  As this is what is expected I 
will not copy and paste proof.

Method:

Machine running netfilter is a 2.4.24 kernel which normally does 
masquerading for a network.  It is 192.168.0.100.

To test, I set netcat to listen on port 3000 on all interfaces in verbose 
mode.  I then used nmap from another machine on the network to scan the 
netfilter machine on port 3001 only.  A combination of netcat running on 
all interfaces and only bound to specific IPs (127.0.0.1, local interface 
IPs, etc) was used.

david@david david $ nmap -sT 192.168.0.100 -p 3001
(.. ouput snipped, port shown as closed ..)

gateway:~# nc -lp 3000 -o dump -vv
listening on [any] 3000 ...
 sent 0, rcvd 0

As you can see from the output, no packets are received by netcat before I 
terminate it, after nmap has reported the port is closed.

The packet counters in iptables are incremented however:

Extract from `iptables -t nat -L -v"

   12   720 DNAT       tcp  --  eth0   any     anywhere             
anywhere            tcp dpt:3001 to:127.0.0.1:3000

I added two -j LOG rules into the PREROUTING table, one before the DNAT 
rule and one after.

/var/log/messages shows that the packet reaches the PREROUTING chain but 
is not present immediately after the rule above, which shows that it was 
matched and netfilter handed it off for routing to 127.0.0.1.

Extract from /var/log/messages:

Mar 30 23:13:54 gateway kernel: IN=eth0 OUT= 
MAC=00:10:a7:07:bf:89:00:e0:18:f1:3c:b9:08:00 SRC=192.168.0.19 
DST=192.168.0.100 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63265 DF PROTO=TCP 
SPT=36128 DPT=3000 WINDOW=5840 RES=0x00 SYN URGP=0

For clarification, my FORWARD chain had a default ACCEPT policy for the 
duration of the test.

My only minor confusion comes from the fact enabling logging of martian 
packets (`echo 1 >/proc/sys/net/ipv4/conf/all/log_martians`) does not 
output any information to either syslog or messages.  If this were a 
martians problem I would have expected some form of logging output from 
enabling it.

I have not had time to inspect the kernel source file mentioned in the 
post I linked to.  It would be good to see if the match for packets to 
127/8 still counts a source of !127/8 as invalid, somebody here might be 
able to tell us.

Perhaps there is something quite fundamentally wrong with the method I 
used to test, if so I hope somebody can point this out to me.  I also 
hope the evidence I've provided gives enough basis for me to say that 
whilst DNAT works as far as netfilter is concerned that packets "just 
don't get there".  My assumption is that this is caused by the problem 
described in the archived message above; therefore DNAT to loopback will 
not work as expected.

Apologies for the long message, it is a consequence of my attempt at being 
thorough.

David