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

Groups > comp.os.linux.networking > #2880

Re: Accessing devices behind a router

Show all headers | View raw

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.

Back to comp.os.linux.networking | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web