Redirect private LAN traffic to internal server when DNS answers with external IP

Question

I have a mikrotik RB2011 router/firewall. Inside the firewall I have a web server that has an private IP (lets say it's 192.168.1.5)

On the WAN side of the firewall I have a static IP (assume it's 192.0.43.10 - www.example.com).

The firewall/router is running NAT.

I have a dstnat rule to pass through HTTPS traffic to the server and that works.

Now the age old problem is that if an internal PC tries to connect https://www.example.com it fails to load the page with this error in chrome:

Google Chrome's connection attempt to www.example.com was rejected. The website may be down or your network may not be properly configured.

Here are some suggestions: Reload this web page later. Check your Internet connection. Reboot any routers, modems or other network devices that you may be using. Add Google Chrome as a permitted programme in your firewall or antivirus software's settings. If it is already a permitted programme, try deleting it from the list of permitted programmes and adding it again. If you use a proxy server, check your proxy settings or contact your network administrator to make sure the proxy server is working. If you don't believe you should be using a proxy server, adjust your proxy settings: Go to the Chrome menu > Settings > + Show advanced settings > Change proxy settings... and make sure your configuration is set to "no proxy" or "direct." Error 102 (net::ERR_CONNECTION_REFUSED): The server refused the connection.

Traditionally I have solved this by using a split DNS or dual DNS type of setup where dns lookups to www.example.com returned the internal IP of the server rather than the external. However I don't have the luxury of that setup here.

There should be a way to solve this on the mikrotik using a prerouting rule but I'm unsure how to set that up. How would I do that?

This is what I have in my nat table. But again, it doesn't. I am running tcpdump on the server but I can see that the and the packets are not actually reaching it.

[admin@MikroTik] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic 
 0   chain=dstnat action=dst-nat to-addresses=192.168.0.10 protocol=tcp 
     dst-address=114.134.xxx.xxx in-interface=wan dst-port=22 

 1   chain=dstnat action=dst-nat to-addresses=192.168.0.10 protocol=tcp 
     dst-address=114.134.xxx.xxx in-interface=wan dst-port=443 

 2   chain=srcnat action=masquerade src-address=192.168.0.0/24 
     dst-address=192.168.0.0/24 

 3   ;;; default configuration
     chain=srcnat action=masquerade to-addresses=114.134.xxx.xxx
     out-interface=wan

As in the solution within the link didn't seem to work for me. Found some more detail here which I'm working through: http://gregsowell.com/?p=4242 — hookenz, Mar 18 '13 at 01:00
ok, I fixed it by dropping the in-interface=wan on the first 2 rules. Michael if you post that as an answer I'll accept it. — hookenz, Mar 18 '13 at 01:32
Sometimes it's just a matter of googling the right terminology... in this case "hairpin NAT". — hookenz, Mar 18 '13 at 01:44

score 2 · Accepted Answer · answered Apr 30 '14 at 01:57

2

If complicated "Hairpin_NAT" isn't your scene, solution for the lazy:

simply add a static DNS entry in the MT device that points to the local server.. sorted. All local requests get correctly resolved, bypassing the router, all external stuff ignores your DNS entry so goes the dstnat route.

/ip dns
set allow-remote-requests=yes cache-size=8048KiB servers=\
    8.8.8.8,8.8.4.4
/ip dns static
add address=192.168.1.5 name=www.example.com

answered Apr 30 '14 at 01:57

Grizly

2,063
15
21

This works also. – hookenz Oct 05 '14 at 19:59
Its even possible to "divert" external dns requests to your local MT cache.. I do that for certain devices which shall remain nameless and happen to resolve google every sec for some reason. Yay dstnat! ``/ip firewall nat; add action=dst-nat chain=dstnat comment="4.1: Hijack DNS" dst-port=53 protocol=udp src-address=LUSER_IP to-addresses=MT_IP to-ports=53`` – Grizly Oct 06 '14 at 00:18

score 0 · Answer 2 · answered Oct 04 '14 at 18:31

Presuming you are running your own internal DNS server, you can be authoritative for the "example.com" zone and then forward all other queries to something like OpenDNS or Google's public resolvers (or act as a recursing resolver, which is not hard). In your internal authoritative "example.com" zone, you will need to have records corresponding to all of the records in your world-facing authoritative zone, but offering the non-public IP numbers. The example below demonstrates a DNS server providing separate answers to internal and external clients, keeping internal traffic local.

So your non-public zone (stored in file example.com_internal) might look like:

$TTL 7D
$ORIGIN example.com

@  IN  SOA  example.com.  hostmaster.example.com (
     1000001 ; serial number
     8H ; refresh interval
     2H ; retry interval
     4W ; expiration
     1D ; minimum
)

@    IN  NS     dns.example.com
@    IN  A      192.168.1.5
dns  IN  A      192.168.1.3
dns  IN  A      192.168.1.4
www  IN  CNAME  @

and your public zone (stored in file example.com_public) might look like

$TTL 7D
$ORIGIN example.com

@  IN  SOA  example.com.  hostmaster.example.com (
     249590 ; serial number
     8H ; refresh interval
     2H ; retry interval
     4W ; expiration
     1D ; minimum
)

@    IN  NS     dns.example.com
@    IN  A      192.0.43.10
www  IN  CNAME  @ 
dns  IN  A      192.0.43.10

You would then configure your nameserver to look something like:

options {
    directory "/var/named";
};

controls {
    inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
};

key "rndc_key" {
    algorithm hmac-md5;
    secret "ht3pp9a4cik1aq530g6uri06p9g28yrvikqdzr7h";
};




acl internal {
    127.0.0.0/8;
    192.168.1.0/24;
}

acl external {
    !192.168.1.0/24;
    !240.0.0.0/4;
}



view internal {
    match-clients { internal; };
    forwarders {8.8.8.8; 8.8.4.4;} ;
    forward only;
    zone "0.0.127.in-addr.arpa" {
        type master;
        file "zone/127.0.0";
        allow-query {192.168.1.0/24;};
    };

    zone "1.168.192.in-addr.arpa" {
        type master;
        file "zone/192.168.1";
        allow-query {192.168.1.0/24;};
    };

    zone "example.com" {
        type master;
        file "zone/example.com_internal";
        allow-query {192.168.1.0/24;};
    };

} 




view external {
    match-clients { external; };
    recursion no;
    zone "example.com" {
        type master;
        file "zone/example.com_public";
    };
    zone "43.0.192.in-addr.arpa" {
        type master;
        file "zone/192.0.43";
    };
}

This is all very off-the-cuff, and you should test it in a lab setting before deploying it to production. For anything in "example.com", your machines would get the internal addresses, and customers would get the public addresses. You will also need to setup a master-slave arangement between your DNS servers, so that you can ensure replication and consistency.

Redirect private LAN traffic to internal server when DNS answers with external IP

2 Answers2