Accessing devices behind a router

Discussion in 'Linux Networking' started by Clark Smith, Mar 30, 2014.

  1. Clark Smith

    Clark Smith Guest

    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

    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?
    Clark Smith, Mar 30, 2014
    1. Advertisements

  2. 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.
    Richard Kettlewell, Mar 30, 2014
    1. Advertisements

  3. Clark Smith

    David Brown Guest

    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.
    David Brown, Mar 30, 2014
  4. Hello,

    David Brown a écrit :
    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.
    This cannot be performed with the usual stateful NAT available with
    iptables (SNAT), and requires stateless NAT (RAWSNAT).
    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.
    Pascal Hambourg, Mar 30, 2014
  5. Clark Smith

    David Brown Guest

    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.
    I haven't looked at the details of how this would be done, but that
    sounds right.
    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!
    David Brown, Mar 31, 2014
  6. Clark Smith

    Clark Smith Guest

    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.
    Clark Smith, Apr 3, 2014
  7. Clark Smith

    David Brown Guest

    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.
    That's the aim.
    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.
    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 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.
    That is what I said in my earlier post - did you read it?
    David Brown, Apr 4, 2014
  8. Clark Smith

    Jorgen Grahn Guest

    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.
    I admit it might be even simpler; haven't tried it.

    Jorgen Grahn, Apr 4, 2014
  9. Clark Smith

    Clark Smith Guest

    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.
    Clark Smith, Apr 4, 2014
  10. Clark Smith

    David Brown Guest

    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.
    David Brown, Apr 6, 2014
  11. On Fri, 4 Apr 2014 19:20:23 +0000 (UTC)

    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.


    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:
    Ian Zimmerman, Apr 8, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.