Connect to localhost bound port from outside?

Connect to localhost bound port from outside?

[jan_bar]

Hi,

I want to connect from my VPN interface to the port that is bound to
(listening on) localhost. The server listens only on localhost, so it is not
visible to outside world and it seems that I cannot use iptables to forward
outside traffice from VPN to that port.

Tahnks, Jan

-- 
Jan Bares
http://jan.vegetband.cz

Re: Connect to localhost bound port from outside?

[Покотиленко Костик]

В Срд, 31/01/2007 в 08:33 +0100, jan_bar пишет:
> Hi,
> 
> I want to connect from my VPN interface to the port that is bound to
> (listening on) localhost. The server listens only on localhost, so it is not
> visible to outside world and it seems that I cannot use iptables to forward
> outside traffice from VPN to that port.

-j REDIRECT should do the job.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: Connect to localhost bound port from outside?

[jan_bar]

Thank you, but REDIRECT works fine only if the server listens on 0.0.0.0,
when the server listens on 127.0.0.1, it doesn't work.

kernel:  2.6.9-gentoo-r14
iptables: iptables-1.3.5-r4

Jan

-- 
Jan Bares
http://jan.vegetband.cz


"??????????? ??????" <casper@meteor.dp.ua> wrote in message
news:1170234205.4464.0.camel@localhost.localdomain...
> В СOд, 31/01/2007 в 08:33 +0100, jan_bar ?иUAт:
> > Hi,
> >
> > I want to connect from my VPN interface to the port that is bound to
> > (listening on) localhost. The server listens only on localhost, so it is
not
> > visible to outside world and it seems that I cannot use iptables to
forward
> > outside traffice from VPN to that port.
>
> -j REDIRECT should do the job.
>
> -- 
> ?IкIтиIAнкI КIстик <casper@meteor.dp.ua>
>
>
>

Re: Connect to localhost bound port from outside?

[Pascal Hambourg]

Hello,

jan_bar a écrit :
> 
> I want to connect from my VPN interface to the port that is bound to
> (listening on) localhost. The server listens only on localhost, so it is not
> visible to outside world and it seems that I cannot use iptables to forward
> outside traffice from VPN to that port.

Iptables will happily redirect anything you like to localhost, but the 
kernel IP routing prohibits communications with a loopback address on a 
non loopback interface and thus will drop the packets. This is similar 
to the problem in the above thread "port forwarding through localhost", 
and the same workaround is applicable.

Re: Connect to localhost bound port from outside?

[Martijn Lievaart]

[ Please don't toppost. Thank you ]

<citaat van="jan_bar">
> Thank you, but REDIRECT works fine only if the server listens on 0.0.0.0,
> when the server listens on 127.0.0.1, it doesn't work.
>
> kernel:  2.6.9-gentoo-r14
> iptables: iptables-1.3.5-r4

Did you try DNAT? That should work.

HTH,
M4

Re: Connect to localhost bound port from outside?

[Martijn Lievaart]

<citaat van="Martijn Lievaart">
> [ Please don't toppost. Thank you ]
>
> <citaat van="jan_bar">
>> Thank you, but REDIRECT works fine only if the server listens on
>> 0.0.0.0,
>> when the server listens on 127.0.0.1, it doesn't work.
>>
>> kernel:  2.6.9-gentoo-r14
>> iptables: iptables-1.3.5-r4
>
> Did you try DNAT? That should work.

Ah scratch that, see Pascals answer.

M4

Re: Connect to localhost bound port from outside?

[Grant Taylor]

Pascal Hambourg wrote:
> Iptables will happily redirect anything you like to localhost, but the 
> kernel IP routing prohibits communications with a loopback address on a 
> non loopback interface and thus will drop the packets. This is similar 
> to the problem in the above thread "port forwarding through localhost", 
> and the same workaround is applicable.

Does this apply if the reverse path filter is turned off?  Or is this a 
hard coded filter in the kernel that can not be gotten around?

Another thought to the OP would be to use the Dummy interface in lieu of 
the Loop Back interface as I believe it does not have the same 
restrictions that Loop Back does.  However I could be mistaken.

I have often considered using lo for local only but using dummy as a 
spur network to bind services to and then route traffic in to the spur 
network.  Thoughts / Opinions?



Grant. . . .

Re: Connect to localhost bound port from outside?

[Pascal Hambourg]

Grant Taylor a écrit :
> Pascal Hambourg wrote:
> 
>> Iptables will happily redirect anything you like to localhost, but the 
>> kernel IP routing prohibits communications with a loopback address on 
>> a non loopback interface and thus will drop the packets.
> 
> Does this apply if the reverse path filter is turned off?

Yes. This is not a reverse path issue, as rp_filter=1 checks only the 
source address, not the destination address.

> Or is this a 
> hard coded filter in the kernel that can not be gotten around?

AFAIK, it is hard coded. I guess the reason is that RFC 3330 reserves 
127.0.0./8 for the loopback and prohibits its use on any network outside 
the host. Unfortunately, the routing code does not know that the packet 
was DNATed and has an original non-loopback destination address.

> Another thought to the OP would be to use the Dummy interface in lieu of 
> the Loop Back interface as I believe it does not have the same 
> restrictions that Loop Back does.  However I could be mistaken.

I do not see how a dummy interface might be useful here. Can you please 
clarify ?

> I have often considered using lo for local only but using dummy as a 
> spur network to bind services to and then route traffic in to the spur 
> network.  Thoughts / Opinions?

A dummy interface is a black hole, a kind of "/dev/null" interface, 
traffic you route to it is lost. This is very different from a loopback 
interface, whose traffic you route to it loops back and is received by 
the local host. It is fine to use a dummy interface if you want to add 
an extra address to the host and bind services to it, but I guess you 
could do the same with the loopback interface.

Re: Connect to localhost bound port from outside?

[Grant Taylor]

Pascal Hambourg wrote:
> Yes. This is not a reverse path issue, as rp_filter=1 checks only the 
> source address, not the destination address.

Ah.

> AFAIK, it is hard coded. I guess the reason is that RFC 3330 reserves 
> 127.0.0./8 for the loopback and prohibits its use on any network outside 
> the host. Unfortunately, the routing code does not know that the packet 
> was DNATed and has an original non-loopback destination address.

*nod*

> I do not see how a dummy interface might be useful here. Can you please 
> clarify ?

(See below)

>> I have often considered using lo for local only but using dummy as a 
>> spur network to bind services to and then route traffic in to the spur 
>> network.  Thoughts / Opinions?
> 
> A dummy interface is a black hole, a kind of "/dev/null" interface, 
> traffic you route to it is lost. This is very different from a loopback 
> interface, whose traffic you route to it loops back and is received by 
> the local host. It is fine to use a dummy interface if you want to add 
> an extra address to the host and bind services to it, but I guess you 
> could do the same with the loopback interface.

I beg to differ.  Loop back is ONLY for the local host.  However, Dummy 
is not only for local host.  Dummy is *usually* used for local host 
only, however this is not an kernel enforced limitation.  Dummy network 
is akin to a network card that does not talk to any thing else.  I.e. if 
I put a loop back plug in an ethernet card so that it sees its self UP 
and UP (Cisco terms).  Then I can configure any computer to access the 
dummy network VIA the computer that dummy is on.

To verify this, I just brought my dummy net up with a 192.0.2.254 IP 
address.  I then went to my Windows VM session and added a route to the 
192.0.2.x/24 network via my Linux host.  My Windows VM was able to ping 
the 192.0.2.254 IP address on the dummy network.

With this in mind, if the dummy network is used to bind services to, it 
would be possible to DNAT traffic destined to the local system in to the 
dummy network with out being stopped the way that loop back does.

Now, what I'm not sure about is if it would be possible to not use lo 
but use dummy in place of it.  I.e. lo is down and down with dummy up 
and up with 127.0.0.1 on it.  In this case I don't know if you could 
DNAT traffic in to 127.0.0.1 from external or not.  And as I write this, 
I think that this may be more of a problem with routing than interface. 
  If it is the routing code that says the only thing that can speak to 
127.x.y.z/24 is 127.x.y.z/24 then this will do no good.

One thing that I do see as an advantage of using dummy in this way is 
that it would be possible to bind services to the dummy IP which would 
cause traffic destined for public services to pass through the 
filter:FORWARD table / chain.  So, you could possibly have a different 
management IP / interface (pair) than public service IP / interface 
(pair) on the system.  You could also have all management access pass 
through the filter:INPUT and public service pass through filter:FORWARD. 
  Or, if you are worried about the overhead of forwarding traffic to get 
to your public services, you could reverse things and put public on the 
main IP / interface and management on the dummy IP / interface.  Thus 
segregating which traffic is filtered where.

I don't know if there is an benefit / harm in doing things either way, 
it's just an idea that I had.

One use that I do see for such a dummy network would be in a lab type 
environment where some sort of routing protocol is running on each 
system, students could create / destroy networks on dummy as they wanted 
to (so long as they did not conflict) with a benefit of each system in 
the lab being able to route to each and every dummy network for testing 
/ learning type of exercises.



Grant. . . .

Re: Connect to localhost bound port from outside?

[Pascal Hambourg]

Grant Taylor a écrit :
> 
>>> I have often considered using lo for local only but using dummy as a 
>>> spur network to bind services to and then route traffic in to the 
>>> spur network.  Thoughts / Opinions?
>>
>> A dummy interface is a black hole, a kind of "/dev/null" interface, 
>> traffic you route to it is lost. This is very different from a 
>> loopback interface, whose traffic you route to it loops back and is 
>> received by the local host. It is fine to use a dummy interface if you 
>> want to add an extra address to the host and bind services to it, but 
>> I guess you could do the same with the loopback interface.
> 
> I beg to differ.  Loop back is ONLY for the local host.  However, Dummy 
> is not only for local host.  Dummy is *usually* used for local host 
> only, however this is not an kernel enforced limitation.

So far, we both agree that loopback and dummy interfaces are very 
different. :-)

> Dummy network 
> is akin to a network card that does not talk to any thing else.

You can remove "else". A network card that does not talk to anything.

> I.e. if 
> I put a loop back plug in an ethernet card so that it sees its self UP 
> and UP (Cisco terms).  Then I can configure any computer to access the 
> dummy network VIA the computer that dummy is on.

Yes. But actually you access nothing but void.

> To verify this, I just brought my dummy net up with a 192.0.2.254 IP 
> address.  I then went to my Windows VM session and added a route to the 
> 192.0.2.x/24 network via my Linux host.  My Windows VM was able to ping 
> the 192.0.2.254 IP address on the dummy network.

Yes, but doing this you do not access the dummy network. You just access 
the dummy interface _address_ like any other address owned by that host. 
The dummy interface nevers sees that traffic. You could do the same just 
by adding that address to any other interface, including the loopback 
interface lo.

> With this in mind, if the dummy network is used to bind services to, it 
> would be possible to DNAT traffic destined to the local system in to the 
> dummy network with out being stopped the way that loop back does.

I am not sure I get what you mean... Maybe an example would help.

> Now, what I'm not sure about is if it would be possible to not use lo 
> but use dummy in place of it.  I.e. lo is down and down with dummy up 
> and up with 127.0.0.1 on it.

Hmm... You don't want lo to be down, else the host cannot communicate 
with itself any more.

> In this case I don't know if you could 
> DNAT traffic in to 127.0.0.1 from external or not.  And as I write this, 
> I think that this may be more of a problem with routing than interface. 
> If it is the routing code that says the only thing that can speak to 
> 127.x.y.z/24 is 127.x.y.z/24 then this will do no good.

The routing code does not say that only 127.0.0.0/8 (not /24) can talk 
to 127.0.0.0/8. Actually any address allocated to any interface on the 
host (which I call a local address) can talk to 127.0.0.0/8 and 
conversely. The routing code says that you can talk to or from 
127.0.0.0/8 only through the loopback interface. So giving 127.0.0.1 to 
another interface won't help.

> One thing that I do see as an advantage of using dummy in this way is 
> that it would be possible to bind services to the dummy IP which would 
> cause traffic destined for public services to pass through the 
> filter:FORWARD table / chain.

Huh ? Traffic destined to a local service goes through the INPUT chain, 
not the FORWARD chain. Whether the IP address you bind the service to 
belongs to a loopback interface, a dummy interface or any other 
interface does not make a difference. All local addresses belong to the 
host and create a local route in the special "local" routing table.

Re: Connect to localhost bound port from outside?

[Grant Taylor]

Pascal Hambourg wrote:
> You can remove "else". A network card that does not talk to anything.

Ok.

> Yes. But actually you access nothing but void.

Not being able to access any thing but your self is vastly different 
than your data streaming in to /dev/null with no replies.  This is what 
I was trying to imply.  I suppose that I should say that I took what you 
said earlier about dummy being null to say that any traffic you sent to 
ti would be unacknowledged, which is not the case.

> Yes, but doing this you do not access the dummy network. You just access 
> the dummy interface _address_ like any other address owned by that host. 
> The dummy interface nevers sees that traffic. You could do the same just 
> by adding that address to any other interface, including the loopback 
> interface lo.

Hum.

> I am not sure I get what you mean... Maybe an example would help.

dummy0=192.0.2.254
eth0=192.168.1.123
lo=127.0.0.1

iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.123 -p tcp --dport 
1234 -j DNAT --to-destination 192.0.2.254:1234

>> Now, what I'm not sure about is if it would be possible to not use lo 
>> but use dummy in place of it.  I.e. lo is down and down with dummy up 
>> and up with 127.0.0.1 on it.
> 
> Hmm... You don't want lo to be down, else the host cannot communicate 
> with itself any more.

Why would a host not be able to communicate with its self if it is 
trying to communicate from / to 127.0.0.1 if that IP address is on a 
different interface?  Or are there other things that communicate over lo 
with out using IP.  If the latter is the case, have lo up with out an IP 
address.

> The routing code does not say that only 127.0.0.0/8 (not /24) can talk 
> to 127.0.0.0/8. Actually any address allocated to any interface on the 
> host (which I call a local address) can talk to 127.0.0.0/8 and 
> conversely. The routing code says that you can talk to or from 
> 127.0.0.0/8 only through the loopback interface. So giving 127.0.0.1 to 
> another interface won't help.

Hum.

> Huh ? Traffic destined to a local service goes through the INPUT chain, 
> not the FORWARD chain. Whether the IP address you bind the service to 
> belongs to a loopback interface, a dummy interface or any other 
> interface does not make a difference. All local addresses belong to the 
> host and create a local route in the special "local" routing table.

Ok, I think I you and I have a different understanding of how traffic 
traverses the kernel.  I am under the impressions that any traffic that 
is forwarded from one interface to another passes through 
filter:FORWARD.  ....  However, repeating the test that I did earlier 
and looking at the packet counters, you are indeed correct.  This fact 
makes a later part of what I was saying very much moot and / or 
incorrect.  I think my confusion comes from a lack of understanding of 
how IPs translate / relate to Sockets and where services actually bind to.

In light of this new information and the fact that the kernel will only 
allow local sources / destinations to talk to 127.0.0.1, I can only 
think of one thing that will allow the OP to redirect traffic in to the 
127.0.0.1 IP address, that being a proxy of some sort that is running on 
the local host that would initiate a local request for the internal 
service.  I also believe a proxy was previously mentioned in the 
referenced thread.



Grant. . . .

Re: Connect to localhost bound port from outside?

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 31 Jan 2007, Grant Taylor wrote:

> Pascal Hambourg wrote:
>> Iptables will happily redirect anything you like to localhost, but the 
>> kernel IP routing prohibits communications with a loopback address on a non 
>> loopback interface and thus will drop the packets. This is similar to the 
>> problem in the above thread "port forwarding through localhost", and the 
>> same workaround is applicable.
>
> Does this apply if the reverse path filter is turned off?  Or is this a hard 
> coded filter in the kernel that can not be gotten around?
>
> Another thought to the OP would be to use the Dummy interface in lieu of the 
> Loop Back interface as I believe it does not have the same restrictions that 
> Loop Back does.  However I could be mistaken.
>
> I have often considered using lo for local only but using dummy as a spur 
> network to bind services to and then route traffic in to the spur network. 
> Thoughts / Opinions?
>


What's a "dummy" interface?

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFyNNrst+vzJSwZikRAsmSAJ9yEz0ES2p3uwqd2nI6rqQ1+zFXNgCeNi8Z
kcbjNi0RSrT0Q63CTUHlWxA=
=SGzJ
-----END PGP SIGNATURE-----

Re: Connect to localhost bound port from outside?

[Jan Engelhardt]

On Feb 6 2007 14:13, R. DuFresne wrote:
>
> What's a "dummy" interface?

	modprobe dummy
	ip a a 192.168.222.222/24 dev dummy0

it's not particularly useful, but well, it's there for whatever reason one
might need it.


regs,
Jan