Access public IP dst-nat from local subnet

brainchild · Tue Jul 17, 2007 5:39 am

Please reference past article titled: http access to wan ip from the lan.

Problem:
When we have a public IP address that is being NATed (via dst-nat rules and port-forwarding) to a private internal address, and a client who is on the same subnet as the server tries to access the server via the public IP address it does not work. Access works just fine when accessing the public IP address from any other network besides the local one.

What I have figured the problem to be is that the router sees that the incoming request is coming from an IP address that is in the same subnet as the end server, so it just bypasses masking the IP address of the user and forwards the packets directly to the PRIVATE IP address of the internal server.

Others have suggested changing the DNS records on the router, but this NOT a solution. If a cheap Linksys, or any other router can handle the NAT for public IP addresses properly then Mikrotik should too, WITHOUT having to do some special work around.

We NEED to have this BUG fixed. When a dst-nat rule exists for the local subnet, other nodes on that subnet should be able to access that server using the Public IP address. This is an extremely easy problem to replicate.

Please, Mikrotik, take a few moments to look at this problem and implement a solution. If a Linksys router can handle this type of routing with no problem, there should be an easy way to do it on such an advanced system as RouterOS.

Thanks.

Tue Jul 17, 2007 10:08 am

If you have any problems or issues with MikroTik RouterOS operation, the best way to get issue fixed is to contact support department (support@mikrotik.com), report them your problems include problem description and support output file, when you encounter the issue.

Few notes about your issue, the problem is related to the option that local network users that uses(that have local address as src-address) are trying to access server on the remote address that is located on the same subnet as they are, and these users being masqueraded by your src-nat rule.
In order to avoid such things, you have to add masquerade or even (src-nat) for the packets that ar coming from local network users to this server public address, these packets should be masqueraded/src-natted to the local network.
It is not RouterOS bug, existing configuration causes this ussue.

airstream · Tue Jul 17, 2007 11:43 am

You need to specify dst-address(your WAN public IP) in the DSTNAT chain:

chain=dstnat dst-address={your public wan IP} protocol=tcp dst-port=80 
     action=dst-nat to-addresses={your internal server IP} to-ports=80

So this rule will catch all packets destined for your WAN IP, and nat them to your LAN server, regardless of which interface the request came in on.

This is how it is supposed to be, there is no bug you mention. ROS will only do as it is told and nothing more, that is to say you need to make rules for packets to behave how you want them.

brainchild · Tue Jul 17, 2007 4:48 pm

Yes of course, as mentioned before ALL other interfaces work properly EXCEPT the local interface. What seems to be happening is the router will forward the packets with the from address as the local IP of the source and and to address as the local IP address of the destination. The problem is the host thinks it is communicating with the public IP address and the communication is lost.

So you are telling me that when you have a dst-nat port forward rule enabled, for an IP address that is mascaraed (all the local, private IPs use that one IP on the router to access the Internet), and when you access the service port that is forwarded it works just fine?

I hope I am being clear about the problem here, I understand there might be many ways to interpret it.

brainchild · Tue Jul 17, 2007 4:53 pm

Is there anyway we might be able to have an option for future RouterOS releases that can automatically enable such a command?

raymonvdm · Thu Aug 09, 2007 12:37 am

Hmmm im not sure that i understand this solution but i have the same problem. But my network is a little more "advanced" i think.

The Story:

I have a SFF Desktop running an Dual Port, Quad Port and Single port NIC.

The Quad port is connected to my ISP. 4 x Ethernet -> DSL Modem. To obtain 4 ip-adressen using DHCP-Client based on 4 differant mac adresses. 84.x.x.1 / 84.x.x.2 / 84.x.x.3 / 84.x.x.4

The Dual Port card is connected to DMZ 192.168.13.x/24 (Webserver Playground) and to WLAN-Bridge 192.168.50.x/24 and 192.168.10.x/24 (Neighbors)

The Single port card is connected to LAN. 192.168.100.x/24

I made the following rules to setup src-nat/dst-nat


0   ;;; Connects DMZ Webserver host to Internet
     chain=srcnat src-address=192.168.13.200 dst-address-list=!NO-SRC-NAT action=src-nat 
     to-addresses=84.x.x.2 to-ports=0-65535 

 1   ;;; DSL
     chain=srcnat src-address=192.168.10.0/24 dst-address=!192.168.0.0/16 action=src-nat 
     to-addresses=84.x.x.3 to-ports=0-65535 

 2   chain=srcnat src-address=192.168.50.0/24 dst-address=!192.168.0.0/16 action=src-nat 
     to-addresses=84.x.x.3 to-ports=0-65535 

 3 X chain=srcnat src-address=192.168.100.202 dst-address=!192.168.0.0/16 action=src-nat 
     to-addresses=84.x.x.1 to-ports=0-65535 

 4 X chain=srcnat src-address=192.168.100.1 dst-address-type="" action=src-nat 
     to-addresses=84.x.x.2 to-ports=0-65535 

 5   chain=srcnat src-address=192.168.100.0/24 dst-address-type="" dst-address-list=!NO-SRC-NAT 
     action=src-nat to-addresses=84.x.x.4 to-ports=0-65535

84.x.x.4 are examples. But i do get an netblock of 4 84.x.x.x/24 hosts


 6   ;;; SMTP Mailserver
     chain=dstnat dst-address=84.x.x.4 protocol=tcp dst-port=25 action=dst-nat 
     to-addresses=192.168.100.200 to-ports=25 

 7   chain=dstnat dst-address=84.x.x.4 protocol=tcp dst-port=465 action=dst-nat 
     to-addresses=192.168.100.200 to-ports=465 

 8   chain=dstnat dst-address=84.x.x.4 protocol=tcp dst-port=993 action=dst-nat 
     to-addresses=192.168.100.200 to-ports=993 

 15  ;;; Sun Cobalt Raq 4i 
     chain=dstnat dst-address=84.x.x.2 protocol=tcp dst-port=21 action=dst-nat 
     to-addresses=192.168.13.200 to-ports=21 

16  chain=dstnat dst-address=84.x.x.2 protocol=tcp dst-port=25 action=dst-nat 
     to-addresses=192.168.13.200 to-ports=25 

17  chain=dstnat dst-address=84.x.x.2 protocol=tcp dst-port=80 action=dst-nat 
     to-addresses=192.168.13.200 to-ports=80 

18  chain=dstnat dst-address=84.x.x.2 protocol=tcp dst-port=444 action=dst-nat 
     to-addresses=192.168.13.200 to-ports=444 

19  chain=dstnat dst-address=84.x.x.2 protocol=tcp dst-port=81 action=dst-nat 
     to-addresses=192.168.13.200 to-ports=81

No-SRC-NAT Adres list

 #   LIST       ADDRESS                        
 0   NO-SRC-NAT 172.19.3.0/24 *                  
 1   NO-SRC-NAT 192.168.0.0/16

* Note: This network is used to remote manage my DSL modem. Its ip adres is bound to one of my DSL interfaces

How do i acomplish to get an connection outbound from 192.168.100.1 to 84.x.x.2. The Outside Arround. When i scan for open ports from the inside 192.168.100.1 to 84.x.x.2 it finds open ports of MT ftp/ssh/

airstream · Thu Aug 09, 2007 3:52 am

Our setup works with DSTNAT only if the LAN server in on a different subnet. That is to say, if your LAN Clients are 192.168.1.0/24 then you need to have your server on a different net LAN2 192.168.2.0/24 and have both nets assigned to your LAN interface in MT then DSTNAT to your server on 192.168.2.xxx.

This way any incoming call to port X on your WAN ip from your LAN it gets mapped to port x on LAN2

Borage · Thu Aug 09, 2007 12:19 pm

This works for me, and my server is located on the same subnet.

/ ip firewall nat 
add chain=dstnat dst-address=<Public_IP_address> protocol=tcp dst-port=80 action=dst-nat to-addresses=<Web_Server_IP_address> \
    to-ports=0-65535 comment="" disabled=no

/ ip firewall nat 
add chain=srcnat dst-address=<Web_Server_IP_address> protocol=tcp dst-port=80 action=src-nat to-addresses=<Router_Internal_IP_address> \
    to-ports=0-65535 comment="" disabled=no

lbenzo · Wed Oct 24, 2007 9:15 pm

I'm trying to do this without possitive result.
I've a working dst-nat from public_ip:80 to local_ip:80
But if I try to access public_ip:80 from another local_ip in the local_subnet doesn't work.
Any clue in how to achieve this?

Thanks!

Chupaka · Thu Oct 25, 2007 5:40 pm

use src-nat with dst-nat

brainchild · Sat Oct 27, 2007 7:29 pm

The above commands aren't working for me either.

Mikrotik:
I hope you understand that this is a feature that needs to be implemented into the RouterOS. On any Cisco (or any consumer router like Linksys or Netgear), if I configure a port forward for the public IP address to go to an internal server, it will forward Internal src traffic just the same as from the Internet.

Thanks.

brainchild · Sat Oct 27, 2007 8:12 pm

I did get it to work actually, thank you Borage!!

I had another NAT command that was negating those during my tests.

klambrev · Mon Nov 12, 2007 9:29 am

Please help, i try this:
/ ip firewall filter
add chain=forward in-interface=wlan1 out-interface=ether1 action=accept dst-address=88.*.*.4
add chain=forward in-interface=ether1 out-interface=wlan1 action=accept src-address=88.*.*.4
then set ip 88.*.*.4 on my laptop, set gw (88.*.*.3)public ip of my MT router

Where is problem?

pekr · Mon Nov 12, 2007 10:33 am

There is several solutions to it imo. And imo it is in no way bug in Mikrotik OS. Actually I think that cheapo gear provides you with some helpers.

There is several solutions based upon scenario.

1) Add DNS static entries for your public address and domain - why don't you consider it being a solution? It is, it works

2) Use dst-nat when appropriate.

3) When you use xy nodes on your network, and those are natted, and e.g. they contain identical networks (e.g. 10.0.0.x/24), you have to use src-nat in addition. This is typical problem when your network grows - we started with ADSL, then we connected nodes, and found out, that each contains identical network. If you don't src-nat, the request reaches your server, but the router will try to reply in its 10.0.0.x/24 segment, failing

4) Use routing in combination with 1! Assign your server some adress, e.g. 10.10.10.10, and add just one static entry to your DNS

chriswoodall · Thu Nov 29, 2007 5:24 pm

using dst-nat and src-nat works very well for me too but here is the kicker... i can you impletement load balancing? everytime i go to do load balancing, my srcnat and dstnat rule no longer works.. any ideas?

airstream · Thu Nov 29, 2007 9:23 pm

using dst-nat and src-nat works very well for me too but here is the kicker... i can you impletement load balancing? everytime i go to do load balancing, my srcnat and dstnat rule no longer works.. any ideas?

Are you using connection/packet marking with mangle for the load balance?

GWISA · Thu Nov 29, 2007 11:35 pm

There is several solutions to it imo. And imo it is in no way bug in Mikrotik OS. Actually I think that cheapo gear provides you with some helpers.

Exactly... I'd be insulted if I worked at MT and someone insisted a feature found in Linksys and Netgear be implemented just to make someones life easier by not having to fully understand what he was doing!

martinkaplan · Tue Aug 23, 2016 8:07 pm

I believe this is the best solution!

1) Add DNS static entries for your public address and domain - why don't you consider it being a solution? It is, it works

alli · Tue Jan 24, 2017 5:53 pm

I had same problem accessing our net cameras from local subnet, I added a static address for the cloud domain pointing to the router local IP, and masquerade the local network and it works ok!

arnaldo · Tue May 08, 2018 3:04 am

I've been trying to make heads and tail about this, specially since all "basic" routers seem to do it without requiring any special configuration.

As there are some "solutions" but no explanation of the flow, I was looking at the solutions that claim to be working, so I dare to state that problem occurs because of the following packet flow:

Assume source host-A and server-B on the same internal network.

- Packet arrives on the "internal" interface and the destination is the router's external IP. Source: host-A on internal network, destination: router (external IP)
- in pre-routing, DST-NAT changes the destination (and port) to the internal server's IP (and port). Source: host-A on internal network, destination: server-B on internal network
- Packet leaves the router, to server-B with the origin still set to host-A.
- server-B will accept the connection and will reply to host-A directly.
- host-A have no connection to server-B, but rather to router.

So it will not work (the TCP/UDP connection).

This is why solutions that use SCR-NAT to change the source of all packages destined to the internal server works. This will correctly set the packet source as comming from the router, so server-B will reply to the router, that in turn will forward the packet to the real source (host-A).

One chanllenge for using SRC-NAT is when the external IP is dynamic. No problem, this is what "masquerade" is for. I'm using the following rule, a type a "single rule catch it all":

add action=masquerade chain=srcnat comment="Allow internal access to servers using router's external IP addresses" \
      dst-address=<internal network> src-address=<internal network>

So masquerade on the internal interfaces, if the destination is on the internal network. This will cover ANY service on any network that can be specified using CIDR notation. Also, {src,dst}-address-list can also be used to refine the rule.

Sob · Tue May 08, 2018 3:28 am

Congratulations for figuring it out. But it looks like you missed this page, it could save you some effort, everything is described there, even with images. But it doesn't hurt when something makes you think and discover stuff by yourself.

arnaldo · Tue May 08, 2018 1:52 pm

Congratulations for figuring it out. But it looks like you missed this page, it could save you some effort, everything is described there, even with images. But it doesn't hurt when something makes you think and discover stuff by yourself.

Thanks for the pointer. it's indeed the same explanation (with graphics). But you are right: figuring out by myself helps. ROS has many features and tricks that understanding what's going on under the hood is always worth the time.

One final comment: I do use a split DNS, and for many years I agree that this is the right approach. Names do resolve internally directly to the internal IP address of the servers. However, recently, some users are complaining that their iPhones are not connecting to the mail server (IMAP). For some reason iOS is caching the "external" DNS entry past the assigned TTL, so when they connect to the internal network the mail client will still attempts to use the external IP for a good amount of time. Really weird. Allowing them to connect with the external IP mitigates the problem (my guess a bug Apple introduced in the latest iOS).

Sob · Wed May 09, 2018 12:21 am

I'm big fan of hairpin NAT, because it's simple, effortless and foolproof. Set it up once using universal rule like yours, never have to touch it again and it will always work. I do acknowledge that it's not effective solution when there's a lot of traffic, because instead of taking a shorter local path, it's forced to go to router and back. But in many cases it's not a problem. And if it is, you can always combine hairpin NAT with split DNS, with DNS directing most of traffic to local address and hairpin as fallback.

rafsanulhasan · Sat Oct 31, 2020 5:59 am

This works for me, and my server is located on the same subnet.

/ ip firewall nat 
add chain=dstnat dst-address=<Public_IP_address> protocol=tcp dst-port=80 action=dst-nat to-addresses=<Web_Server_IP_address> \
    to-ports=0-65535 comment="" disabled=no

/ ip firewall nat 
add chain=srcnat dst-address=<Web_Server_IP_address> protocol=tcp dst-port=80 action=src-nat to-addresses=<Router_Internal_IP_address> \
    to-ports=0-65535 comment="" disabled=no

It worked for me

Access public IP dst-nat from local subnet

Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet

Re: Access public IP dst-nat from local subnet