Routing internal access to public IP back to internal net

Discussion in 'Linux Networking' started by Johannes Bauer, Mar 1, 2013.

  1. Hi group,

    I have a setup here that I don't currently know how to continue with.
    Let me explain the simplified topology first:

    [Client] -----------
    SWITCH ------ [ Router ] ------- Internet
    [Server] -----------

    Let the router have an internal IP 192.168.1.1 on which it is connected
    to the 192.168.1.0/24 network. It also has a second NIC which does DHCP
    and receives a public IP, let's call it 42.42.42.42 for now.

    The client and server are both in the 192.168.1.0/24 network, I'll refer
    to them as 192.168.1.CLI and 192.168.1.SRV.

    The router does masquerading for the internal network, but also does
    port forwarding for incoming connections on port 993 to 192.168.1.SRV:993.

    Pretty standard setup so far. Now for some reason the client wants to
    access the server not by its internal IP, but by its external IP. So the
    packets that are generated are:

    Initial connection request:
    192.168.1.CLI -> 42.42.42.42:993 (goes to Router)

    Router does DNAT:
    192.168.1.CLI -> 192.168.1.SRV

    Server receives packet, tries to respond LOCALLY:
    192.168.1.SRV -> 192.168.1.CLI

    This obviously fails, the client discards the answer (it doesn't expect
    anything from 192.168.1.SRV, but from the router 192.168.1.1).

    So to fix this the router would for incoming connections not only have
    to do DNAT, but SNAT as well, right? But how do I do this? I'm kind of
    puzzled right now. Obviously it would be easiest if the client would
    just locally talk to the server, but this is not possible for a
    different reason.

    Here's my NAT table:
    -P PREROUTING ACCEPT
    -P INPUT ACCEPT
    -P OUTPUT ACCEPT
    -P POSTROUTING ACCEPT
    -A PREROUTING -p tcp -m tcp --dport 993 -j DNAT --to-destination
    192.168.1.SRV
    -A POSTROUTING -o eth0 -j MASQUERADE

    And my filter table:
    -P INPUT DROP
    -P FORWARD DROP
    -P OUTPUT ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -s 127.0.0.0/8 -i eth1 -j DROP
    -A INPUT -s 127.0.0.0/8 -i eth2 -j DROP
    -A INPUT -s 127.0.0.0/8 -i eth0 -j DROP
    -A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
    -A INPUT -s 192.168.1.0/24 -p udp -m udp --dport 53 -j ACCEPT
    -A INPUT -s 192.168.2.0/24 -p udp -m udp --dport 53 -j ACCEPT
    -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
    -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
    -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
    -A INPUT -p icmp -m icmp --icmp-type 30 -j ACCEPT
    -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
    -A INPUT -j REJECT --reject-with icmp-port-unreachable
    -A FORWARD -d 192.168.1.SRV/32 -p tcp -m tcp --dport 993 -j ACCEPT
    -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -s 192.168.1.0/24 -j ACCEPT
    -A FORWARD -j REJECT --reject-with icmp-port-unreachable

    Any help is greatly appreciated.

    Best regards,
    Joe

    --
    Ah, der neueste und bis heute genialste Streich unsere großen
    Kosmologen: Die Geheim-Vorhersage.
    - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>
     
    Johannes Bauer, Mar 1, 2013
    #1
    1. Advertisements

  2. I have a similar configuration and ran into exactly the same issue. I
    used this rule:

    -A POSTROUTING -s 172.17.207.0/24 -d 172.17.207.18/32 -p tcp -m tcp --dport 993 -j SNAT --to-source 172.17.207.1

    172.17.207.18 is the IMAP server (.SRV in your description).
    172.17.207.1 is the router (.1 on your network).

    The -s is there to limit the rule to connections originated on the same
    network as the IMAP sevrer, since only those require the source NAT.

    The packets from client evolve as follows:

    As sent by client:
    192.168.1.CLI -> 42.42.42.42
    After PREROUTING:
    192.168.1.CLI -> 192.168.1.SRV
    After POSTROUTING:
    192.168.1.1 -> 192.168.1.SRV

    The server’s response is therefore:
    192.168.1.SRV -> 192.168.1.1
    ....and since this goes to the router rather than straight to the client,
    the router has can rewrite the addresses back to what the client
    expects.
     
    Richard Kettlewell, Mar 2, 2013
    #2
    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.