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 --]