Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #2877 > unrolled thread

Accessing devices behind a router

Back to article view | Back to comp.os.linux.networking

Contents

  Accessing devices behind a router Clark Smith <noaddress@nowhere.net> - 2014-03-30 01:30 +0000
    Re: Accessing devices behind a router Richard Kettlewell <rjk@greenend.org.uk> - 2014-03-30 08:30 +0100
      Re: Accessing devices behind a router David Brown <david.brown@hesbynett.no> - 2014-03-30 13:33 +0200
        Re: Accessing devices behind a router Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2014-03-30 14:09 +0200
          Re: Accessing devices behind a router David Brown <david.brown@hesbynett.no> - 2014-03-31 09:22 +0200
    Re: Accessing devices behind a router Clark Smith <noaddress@nowhere.net> - 2014-04-03 22:13 +0000
      Re: Accessing devices behind a router David Brown <david.brown@hesbynett.no> - 2014-04-04 09:01 +0200
        Re: Accessing devices behind a router Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-04-04 16:33 +0000
          Re: Accessing devices behind a router David Brown <david.brown@hesbynett.no> - 2014-04-06 14:26 +0200
        Re: Accessing devices behind a router Clark Smith <noaddress@nowhere.net> - 2014-04-04 19:20 +0000
          DNS caching servers [Was: Accessing devices behind a router] Ian Zimmerman <itz@buug.org> - 2014-04-08 10:32 -0700

#2877 — Accessing devices behind a router

	I am connected to the Internet by means of a modem/router M that 
exposes a single IP address to the world. Behind M I have a number of 
devices (PCs, phones, tablets) that can access the Internet without any 
problems.

	Let's assume two such devices - e.g. a PC P and tablet T. P can 
reach T, and vice-versa, when both use their respective IP addresses in 
my LAN. So far so good.

	There is a port forwarding rule in M so that any HTTP connections 
received from the Internet at M are automatically forwarded to P. 
Obviously, if I want to access my web server in P from T when T is in my 
WiFi (and therefore in my LAN) T will just use P's IP address in my LAN. 

	My question is, why can't I access the web server at P from T, 
when T is my WiFi, if T uses the IP address exposed by M? Is this an 
intrinsic limitation in my setup, or in the way TCP/IP networking works 
(I am admittedly networking-challenged)? Or is it the case that I can 
somehow change M's configuration so that this would work?

[toc] | [next] | [standalone]

#2879

Clark Smith <noaddress@nowhere.net> writes:
> 	I am connected to the Internet by means of a modem/router M that 
> exposes a single IP address to the world. Behind M I have a number of 
> devices (PCs, phones, tablets) that can access the Internet without any 
> problems.
>
> 	Let's assume two such devices - e.g. a PC P and tablet T. P can 
> reach T, and vice-versa, when both use their respective IP addresses in 
> my LAN. So far so good.
>
> 	There is a port forwarding rule in M so that any HTTP connections 
> received from the Internet at M are automatically forwarded to P. 
> Obviously, if I want to access my web server in P from T when T is in my 
> WiFi (and therefore in my LAN) T will just use P's IP address in my LAN. 
> 
> 	My question is, why can't I access the web server at P from T, 
> when T is my WiFi, if T uses the IP address exposed by M? Is this an 
> intrinsic limitation in my setup, or in the way TCP/IP networking works 
> (I am admittedly networking-challenged)? Or is it the case that I can 
> somehow change M's configuration so that this would work?

What is going on here is:

1. T constructs an outbound packet with source address T and destination
address M.  Write this T->M.  It expects the the response will be M->T.

2. Since the destination is M, T fowards the packet to M.

3. M applies the rewrite rule yielding T->P.

4. Since the destination is P, M forwards the packet to P.

5. P swaps the addresses when constructing the response, yielding P->T.

6. Since the destination is T, P forwards the packet to T.

7. T has no idea what this P->T connection is; it only knows about M->T.

The reason this failure doesn’t occur for externally originated
connections is that in step 6 P, the destination is not connected to the
local network so P forwards the packet to M, which can reverse the
rewriting before forwarding it over the Internet.

The answer is that you need an additional rewrite rule in M which
rewrites the source address to M (and only applies to packets received
from your local network).  If M happens to be a Linux box then the
iptables SNAT target can do it.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#2880

On 30/03/14 09:30, Richard Kettlewell wrote:
> Clark Smith <noaddress@nowhere.net> writes:
>> 	I am connected to the Internet by means of a modem/router M that
>> exposes a single IP address to the world. Behind M I have a number of
>> devices (PCs, phones, tablets) that can access the Internet without any
>> problems.
>>
>> 	Let's assume two such devices - e.g. a PC P and tablet T. P can
>> reach T, and vice-versa, when both use their respective IP addresses in
>> my LAN. So far so good.
>>
>> 	There is a port forwarding rule in M so that any HTTP connections
>> received from the Internet at M are automatically forwarded to P.
>> Obviously, if I want to access my web server in P from T when T is in my
>> WiFi (and therefore in my LAN) T will just use P's IP address in my LAN.
>>
>> 	My question is, why can't I access the web server at P from T,
>> when T is my WiFi, if T uses the IP address exposed by M? Is this an
>> intrinsic limitation in my setup, or in the way TCP/IP networking works
>> (I am admittedly networking-challenged)? Or is it the case that I can
>> somehow change M's configuration so that this would work?
>
> What is going on here is:
>
> 1. T constructs an outbound packet with source address T and destination
> address M.  Write this T->M.  It expects the the response will be M->T.
>
> 2. Since the destination is M, T fowards the packet to M.
>
> 3. M applies the rewrite rule yielding T->P.
>
> 4. Since the destination is P, M forwards the packet to P.
>
> 5. P swaps the addresses when constructing the response, yielding P->T.
>
> 6. Since the destination is T, P forwards the packet to T.
>
> 7. T has no idea what this P->T connection is; it only knows about M->T.
>
> The reason this failure doesn’t occur for externally originated
> connections is that in step 6 P, the destination is not connected to the
> local network so P forwards the packet to M, which can reverse the
> rewriting before forwarding it over the Internet.
>
> The answer is that you need an additional rewrite rule in M which
> rewrites the source address to M (and only applies to packets received
> from your local network).  If M happens to be a Linux box then the
> iptables SNAT target can do it.
>

An alternative way to handle this situation is using DNS and different 
name-host resolution in different situations.

When you are outside your network, ISP's DNS servers (and other public 
DNS servers) resolve the name of the web server to the IP of M, and port 
forwarding works as Richard described.  The trick is to add an explicit 
host entry in your network's DNS server/proxy D (which might be P or M) 
to resolve this name to the IP of P.  In that case, when T tries to 
access the web server by name, D returns the IP of P and the packets go 
T->P, P->T.  This has the additional benefit of being more efficient, 
which might be useful for large transfers if M is slow.

Typically, this requires a bit of change to your DNS - simple 
modem/routers often do not have the option for giving specific name-IP 
resolutions.  If T were another PC, you could just add the entry to its 
hosts file - that is not easy on a tablet.  You might find it easiest to 
do as I do - run a DNS server on the server P and set your modem/router 
to give that as the DNS server/proxy (I actually use P as the DHCP 
server as well, which works very well).  Then you can run dnsmasq on P 
and have full control of the names.


An alternative possibility is to use iptable rules on P to check the 
incoming packets checking for T->P packets that come from the MAC 
address of M, and apply SNAT at that point so that the web server sees 
the packet as M->P and sends the return to T back via M.  This is not as 
elegant as doing the SNAT on M, but it could be easier if M is an 
off-the-shelf router and P is Linux.

Another possibility is simply to put an explicit route in P that directs 
all packets to T via M.

[toc] | [prev] | [next] | [standalone]

#2881

Hello,

David Brown a écrit :
> On 30/03/14 09:30, Richard Kettlewell wrote:
>>
>> The answer is that you need an additional rewrite rule in M which
>> rewrites the source address to M (and only applies to packets received
>> from your local network).  If M happens to be a Linux box then the
>> iptables SNAT target can do it.
> 
> An alternative way to handle this situation is using DNS and different 
> name-host resolution in different situations.

Note that this option does not work if the same name is used for several
services/ports (ex : HTTP and FTP) which are forwarded to different hosts.

> An alternative possibility is to use iptable rules on P to check the 
> incoming packets checking for T->P packets that come from the MAC 
> address of M, and apply SNAT at that point so that the web server sees 
> the packet as M->P and sends the return to T back via M.

This cannot be performed with the usual stateful NAT available with
iptables (SNAT), and requires stateless NAT (RAWSNAT).

> Another possibility is simply to put an explicit route in P that directs 
> all packets to T via M.

When the outgoing packet belongs to a connection which was forwarded
from the LAN by the router. Yes, I like it. Requires just a bit of
iptables and routing rules.

[toc] | [prev] | [next] | [standalone]

#2882

On 30/03/14 14:09, Pascal Hambourg wrote:
> Hello,
> 
> David Brown a écrit :
>> On 30/03/14 09:30, Richard Kettlewell wrote:
>>>
>>> The answer is that you need an additional rewrite rule in M which
>>> rewrites the source address to M (and only applies to packets received
>>> from your local network).  If M happens to be a Linux box then the
>>> iptables SNAT target can do it.
>>
>> An alternative way to handle this situation is using DNS and different 
>> name-host resolution in different situations.
> 
> Note that this option does not work if the same name is used for several
> services/ports (ex : HTTP and FTP) which are forwarded to different hosts.

That's indeed true - but there's a good chance that the OP doesn't have
more than one server here.  If there are several hosts involved then you
need multiple names for them.

> 
>> An alternative possibility is to use iptable rules on P to check the 
>> incoming packets checking for T->P packets that come from the MAC 
>> address of M, and apply SNAT at that point so that the web server sees 
>> the packet as M->P and sends the return to T back via M.
> 
> This cannot be performed with the usual stateful NAT available with
> iptables (SNAT), and requires stateless NAT (RAWSNAT).

I haven't looked at the details of how this would be done, but that
sounds right.

> 
>> Another possibility is simply to put an explicit route in P that directs 
>> all packets to T via M.
> 
> When the outgoing packet belongs to a connection which was forwarded
> from the LAN by the router. Yes, I like it. Requires just a bit of
> iptables and routing rules.
> 

Other ideas you could use here are to put an alias on the server's
ethernet port and use that for incoming packets forwarded through M - it
will make it easier to tell where packets are coming from.

There are endless tricks that can be played using Linux networking.  All
you need are a second computer that has access to google while you break
the networking on your main machine, plenty of notepaper, wireshark, and
hair to pull out when things don't work!

[toc] | [prev] | [next] | [standalone]

#2886

On Sun, 30 Mar 2014 01:30:36 +0000, Clark Smith wrote:

> I am connected to the Internet by means of a modem/router M that exposes
> a single IP address to the world. Behind M I have a number of devices
> (PCs, phones, tablets) that can access the Internet without any
> problems.
> 
> 	Let's assume two such devices - e.g. a PC P and tablet T. P can
> reach T, and vice-versa, when both use their respective IP addresses in
> my LAN. So far so good.
> 
> 	There is a port forwarding rule in M so that any HTTP connections
> received from the Internet at M are automatically forwarded to P.
> Obviously, if I want to access my web server in P from T when T is in my
> WiFi (and therefore in my LAN) T will just use P's IP address in my LAN.
> 
> 	My question is, why can't I access the web server at P from T,
> when T is my WiFi, if T uses the IP address exposed by M? Is this an
> intrinsic limitation in my setup, or in the way TCP/IP networking works
> (I am admittedly networking-challenged)? Or is it the case that I can
> somehow change M's configuration so that this would work?

	Thanks everybody for your feedback. I think I may have misled  
you guys by talking about IP addresses alone, while ignoring DNS names. 
With this in mind, here is another, apparently simpler, suggestion that 
has come my way:

	Set up a caching/forwarding DNS server in P, so that it would 
forward all DNS queries from my LAN to M - except for one: Whenever a 
query is received from my LAN to resolve the name N associated with the 
IP exposed by M, N would be resolved by P itself as its own IP address in 
my LAN. 

	With this setup, if a) T is in my WiFi, and b) has received its 
IP address by DHCP from some system in my LAN (which may be P itself, or 
even M) at the same time getting P's (or M's internal) IP address as that 
of the DNS server to use, then applications in T could use N from inside 
my LAN, just as they would when in the external world - which is what I 
am after.

	Now I know how to set up a caching/forwarding BIND DNS server. 
What I do not know how to do is to configure it so that it will resolve 
N, and only N, itself, while forwarding all other non-cached queries to 
M. Is this at all doable? 

	I guess that if all systems in my LAN were Linux systems then I 
could simply use /etc/hosts. However, once we start adding tablets and 
phones into the mix that stops being feasible.

[toc] | [prev] | [next] | [standalone]

#2887

On 04/04/14 00:13, Clark Smith wrote:
> On Sun, 30 Mar 2014 01:30:36 +0000, Clark Smith wrote:
> 
>> I am connected to the Internet by means of a modem/router M that exposes
>> a single IP address to the world. Behind M I have a number of devices
>> (PCs, phones, tablets) that can access the Internet without any
>> problems.
>>
>> 	Let's assume two such devices - e.g. a PC P and tablet T. P can
>> reach T, and vice-versa, when both use their respective IP addresses in
>> my LAN. So far so good.
>>
>> 	There is a port forwarding rule in M so that any HTTP connections
>> received from the Internet at M are automatically forwarded to P.
>> Obviously, if I want to access my web server in P from T when T is in my
>> WiFi (and therefore in my LAN) T will just use P's IP address in my LAN.
>>
>> 	My question is, why can't I access the web server at P from T,
>> when T is my WiFi, if T uses the IP address exposed by M? Is this an
>> intrinsic limitation in my setup, or in the way TCP/IP networking works
>> (I am admittedly networking-challenged)? Or is it the case that I can
>> somehow change M's configuration so that this would work?
> 
> 	Thanks everybody for your feedback. I think I may have misled  
> you guys by talking about IP addresses alone, while ignoring DNS names. 
> With this in mind, here is another, apparently simpler, suggestion that 
> has come my way:

I assume you mean the suggestion in my post?  Your wording here makes it
look like you didn't read it, but got the suggestion elsewhere.

> 
> 	Set up a caching/forwarding DNS server in P, so that it would 
> forward all DNS queries from my LAN to M - except for one: Whenever a 
> query is received from my LAN to resolve the name N associated with the 
> IP exposed by M, N would be resolved by P itself as its own IP address in 
> my LAN. 
> 
> 	With this setup, if a) T is in my WiFi, and b) has received its 
> IP address by DHCP from some system in my LAN (which may be P itself, or 
> even M) at the same time getting P's (or M's internal) IP address as that 
> of the DNS server to use, then applications in T could use N from inside 
> my LAN, just as they would when in the external world - which is what I 
> am after.

That's the aim.

> 
> 	Now I know how to set up a caching/forwarding BIND DNS server. 

No sane person sets up BIND.  It is mind-numbingly complex to configure,
and regularly discovered to have serious security problems (although
since your DNS server will not be accessible from outside your own
network, this is a minor concern).  Use dnsmasq - it is mind-numbingly
simple to work with.

> What I do not know how to do is to configure it so that it will resolve 
> N, and only N, itself, while forwarding all other non-cached queries to 
> M. Is this at all doable? 

Set up dnsmasq as a caching proxy.  Put your ISP as the upstream server
rather than M - or consider using Google's DNS servers (some people
prefer them to their ISP's for various reasons) or OpenDNS (that will
let you do things like block "sites unsuitable for the kids" at the DNS
level, if you are interested in that).  Put the external DNS name for
your server into P's hosts file - the hosts file gets first priority
before sending queries upstream.

Then make sure that each machine has P as their DNS server (P itself
should have 127.0.0.1 in /etc/resolv.conf).  You should be able to do
that by putting the setting into M, so that it is given out along with
IP addresses by DHCP.  Alternatively, disable DHCP on M and use P as the
DHCP server (it's a single line configuration in dnsmasq).  That will
also mean that your DNS server knows about the local names of
DHCP-allocated machines on your network.

> 
> 	I guess that if all systems in my LAN were Linux systems then I 
> could simply use /etc/hosts. However, once we start adding tablets and 
> phones into the mix that stops being feasible.
> 

That is what I said in my earlier post - did you read it?

[toc] | [prev] | [next] | [standalone]

#2888

On Fri, 2014-04-04, David Brown wrote:
> On 04/04/14 00:13, Clark Smith wrote:
...
>> 	Now I know how to set up a caching/forwarding BIND DNS server. 
>
> No sane person sets up BIND.  It is mind-numbingly complex to configure,
> and regularly discovered to have serious security problems (although
> since your DNS server will not be accessible from outside your own
> network, this is a minor concern).

I'm not exactly sane ... but I use bind 9.  As supplied with Debian,
it's extremely easy to configure as just a caching name server.  The
most recent security update was CVE-2013-4854 in July last year,
which I find acceptable.

> Use dnsmasq - it is mind-numbingly simple to work with.

I admit it might be even simpler; haven't tried it.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#2892

On 04/04/14 18:33, Jorgen Grahn wrote:
> On Fri, 2014-04-04, David Brown wrote:
>> On 04/04/14 00:13, Clark Smith wrote:
> ...
>>> 	Now I know how to set up a caching/forwarding BIND DNS server.
>>
>> No sane person sets up BIND.  It is mind-numbingly complex to configure,
>> and regularly discovered to have serious security problems (although
>> since your DNS server will not be accessible from outside your own
>> network, this is a minor concern).
>
> I'm not exactly sane ... but I use bind 9.  As supplied with Debian,
> it's extremely easy to configure as just a caching name server.  The
> most recent security update was CVE-2013-4854 in July last year,
> which I find acceptable.
>

OK, I admit to exaggerating slightly :-)

With enough support, such as Debian's bind configuration system or a 
web-based front end, bind's configuration is workable.  But dnsmasq 
makes it /much/ easier.  And since dnsmasq is also a DHCP server and 
caching DNS proxy, it's a very convenient program for a small network - 
much nicer than trying to get bind and another DHCP server to talk together.


>> Use dnsmasq - it is mind-numbingly simple to work with.
>
> I admit it might be even simpler; haven't tried it.
>
> /Jorgen
>

[toc] | [prev] | [next] | [standalone]

#2889

On Fri, 04 Apr 2014 09:01:53 +0200, David Brown wrote:

> On 04/04/14 00:13, Clark Smith wrote:
>> On Sun, 30 Mar 2014 01:30:36 +0000, Clark Smith wrote:
>> 
>>> I am connected to the Internet by means of a modem/router M that
>>> exposes a single IP address to the world. Behind M I have a number of
>>> devices (PCs, phones, tablets) that can access the Internet without
>>> any problems.
>>>
>>> 	Let's assume two such devices - e.g. a PC P and tablet T. P can
>>> reach T, and vice-versa, when both use their respective IP addresses
>>> in my LAN. So far so good.
>>>
>>> 	There is a port forwarding rule in M so that any HTTP connections
>>> received from the Internet at M are automatically forwarded to P.
>>> Obviously, if I want to access my web server in P from T when T is in
>>> my WiFi (and therefore in my LAN) T will just use P's IP address in my
>>> LAN.
>>>
>>> 	My question is, why can't I access the web server at P from T,
>>> when T is my WiFi, if T uses the IP address exposed by M? Is this an
>>> intrinsic limitation in my setup, or in the way TCP/IP networking
>>> works (I am admittedly networking-challenged)? Or is it the case that
>>> I can somehow change M's configuration so that this would work?
>> 
>> 	Thanks everybody for your feedback. I think I may have misled
>> you guys by talking about IP addresses alone, while ignoring DNS names.
>> With this in mind, here is another, apparently simpler, suggestion that
>> has come my way:
> 
> I assume you mean the suggestion in my post?  Your wording here makes it
> look like you didn't read it, but got the suggestion elsewhere.
> 
> 
>> 	Set up a caching/forwarding DNS server in P, so that it would
>> forward all DNS queries from my LAN to M - except for one: Whenever a
>> query is received from my LAN to resolve the name N associated with the
>> IP exposed by M, N would be resolved by P itself as its own IP address
>> in my LAN.
>> 
>> 	With this setup, if a) T is in my WiFi, and b) has received its
>> IP address by DHCP from some system in my LAN (which may be P itself,
>> or even M) at the same time getting P's (or M's internal) IP address as
>> that of the DNS server to use, then applications in T could use N from
>> inside my LAN, just as they would when in the external world - which is
>> what I am after.
> 
> That's the aim.
> 
> 
>> 	Now I know how to set up a caching/forwarding BIND DNS server.
> 
> No sane person sets up BIND.  It is mind-numbingly complex to configure,
> and regularly discovered to have serious security problems (although
> since your DNS server will not be accessible from outside your own
> network, this is a minor concern).  Use dnsmasq - it is mind-numbingly
> simple to work with.
> 
>> What I do not know how to do is to configure it so that it will resolve
>> N, and only N, itself, while forwarding all other non-cached queries to
>> M. Is this at all doable?
> 
> Set up dnsmasq as a caching proxy.  Put your ISP as the upstream server
> rather than M - or consider using Google's DNS servers (some people
> prefer them to their ISP's for various reasons) or OpenDNS (that will
> let you do things like block "sites unsuitable for the kids" at the DNS
> level, if you are interested in that).  Put the external DNS name for
> your server into P's hosts file - the hosts file gets first priority
> before sending queries upstream.
> 
> Then make sure that each machine has P as their DNS server (P itself
> should have 127.0.0.1 in /etc/resolv.conf).  You should be able to do
> that by putting the setting into M, so that it is given out along with
> IP addresses by DHCP.  Alternatively, disable DHCP on M and use P as the
> DHCP server (it's a single line configuration in dnsmasq).  That will
> also mean that your DNS server knows about the local names of
> DHCP-allocated machines on your network.
> 
> 
>> 	I guess that if all systems in my LAN were Linux systems then I
>> could simply use /etc/hosts. However, once we start adding tablets and
>> phones into the mix that stops being feasible.
>> 
>> 
> That is what I said in my earlier post - did you read it?

	I overlooked your dnsmasq reference among your other remarks; 
sorry about that. Anyway, I did not know bout dnsmasq, but it seems to be 
exactly what I was looking for. Thanks.

[toc] | [prev] | [next] | [standalone]

#2901 — DNS caching servers [Was: Accessing devices behind a router]

On Fri, 4 Apr 2014 19:20:23 +0000 (UTC)
Clark Smith <noaddress@nowhere.net> wrote:

Clark> I overlooked your dnsmasq reference among your other remarks;
Clark> sorry about that. Anyway, I did not know bout dnsmasq, but it
Clark> seems to be exactly what I was looking for. Thanks.

There is also pdnsd [1].  Its advantage is that it saves the cache to
disk across shutdowns and reboots, and the configuration is a bit
cleaner than dnsmasq (IMHO).  The disadvantage is that currently it has
no way to listen on all interfaces _except_ one.

[1]

http://members.home.nl/p.a.rombouts/pdnsd/

-- 
Please *no* private copies of mailing list or newsgroup messages.

gpg public key: 2048R/984A8AE4
fingerprint: 7953 ADA1 0E8E AB57 FB79  FFD2 360A 88B2 984A 8AE4
Funny pic: http://bit.ly/ZNE2MX

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web