I wanted to forward port 22 of one of the computers on my local network so I would be able to log into it from the outside. For this, I set up the following
ip firewall dst-nat add dst-address=55.155.155.55/32:8022 action=nat to-dst-address=192.168.0.103 to-dst-port=22
Unfortunately, when I tried to log into my router through ssh, the rule above kicked in and I was transported to the computer on my local network when all I wanted was to log into the router through SSH. What gives?
I have a couple of computers running webservers in my LAN. Two of them are to be accessible from outside the LAN, 192.168.0.98 and 192.168.0.103. I have the following nat rules set:
ip firewall dst-nat print
0 dst-address=55.155.155.55/32:80 protocol=tcp action=nat to-dst-address=192.168.0.98
So, if I open my web browser and go to 55.155.155.55, it correctly shows me what is running on the webserver on 192.168.0.98 (whether I do this from inside the LAN or from somewhere else on the internet). Now if I try to open 55.155.155.55:90 from outside the LAN, it works. If I try it from inside the LAN it doesn’t work except from the computer with IP 192.168.0.103 (the one running the webserver).
when you are requesting page by its external address, it gets dst-natted and resent to the local server address. now the server wants to send a reply and goes through its routing table to find out how to send it out, and discovers the reply may be sent directly to the original sender, without going through the router, so the host gets a reply from the internal servers address. however, as the sender send the request to the external servers address, it hopes to get the reply from that external address, and discards replies from other IPs, which is quite standard behavoiur.
one of the possible solutions is to use internal address inside, and external - from other networks. another solution is to put src-nat on router for these requests, to that the server would believe the requests are coming from the router.
The only rule I have is a forward rule that drops all p2p traffic.
Because I have a program on the webserver that is using the WAN IP on all the links.
Concerning your other solution, I already have this:
I think, that best solution, that does not need any rules on router, is to properly use internal DNS server and access internal web server by it’s name, not by IP address. External requests to let’s say webserver.domain.com are resolved by public DNS servers (DNS response is in this case 55.155.155.55), internal requests are resolved by internal DNS server (DNS response in this case 192.168.0.103). You can then access your web server by it’s name from both networks simillary.
no, it is the other way around: the problem is not the source address of server’s response, but destination. you should source-nat or masquerade all requests to the server from local netwrk hosts. I have already explained the reasoning, please reread the previous message.
For the first problem, SSH, you need to edit the rule so that it doesn’t apply when the dst-address is the router. I forget the exact syntax as the last few times I did it in winbox
no, it is the other way around: the problem is not the source address of server’s response, but destination. you should source-nat or masquerade all requests to the server from local netwrk hosts. I have already explained the reasoning, please reread the previous message.
Hi Lastguru,
It looks like you know your stuff. I’ve been having the same issue as Eko1 and would appreciate if you could include the correct syntax to the src-nat/masquerade rule. I’ve read this post multiple times and tried various rules without luck.
ip firewall dst-nat add dst-address=55.155.155.55/32:80 protocol=tcp
action=nat to-dst-address=192.168.0.98
and for the internal network:
ip firewall src-nat add dst-address=192.168.0.98:80 protocol=tcp
action=nat to-src-address=
this will force reply to the mikrotik and not directly to the internal
machine which originated the request.
Also note that dst-address is 192.168.0.98 since the packetes will
have already be DNAT’ed.
Also you should filter the above rule with more filters for example
in-interface should be the lan interface of the mikrotik.
OK. I have the following:
[admin@windwireless] ip firewall src-nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 dst-address=192.168.0.103/32:90 out-interface=Local protocol=tcp
action=nat to-src-address=192.168.0.1 to-src-port=90
[admin@windwireless] ip firewall dst-nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 in-interface=Public dst-address=55.155.155.55/32:90 protocol=tcp action=nat
to-dst-address=192.168.0.103 to-dst-port=90
And I still doesn’t work. Man, I can’t believe it is so difficult to get this working on Mikrotik when it works easily enough on dumb D-Link and Linksys routers.
Just imagine packet flow: CLIENT X tries to connect to your INTERNAL WEB SERVER from internet. He uses PUBLIC IP and PORT 90 of your Mikrotik as destination address and port. Mikrotik must change destination IP address of this request to your INTERNAL WEB SERVER IP address and port 90. Then this request is destined to your INTERNAL WEB SERVER.
So we have first rule:
dst-nat rule with dst-address=PUBLIC IP of your Mikrotik and dst-port=90 and to-addresses=IP of INTERNAL WEB SERVER and to-ports=90
Then INTERNAL WEB SERVER answers the request, but source address of this response is your INTERNAL WEB SERVER IP address. Mikrotik must in turn change source address of this response to PUBLIC IP of your Mikrotik.
So we have second rule:
Masquerading rule with out-interface set to output interface of your Mikrotik.
From CLIENT X’s point view it seems, that he communicates only with web server with PUBLIC IP of your Mikrotik.
Uf, is it cleaner now?
Hm, I try to draw what is going on when accessing internal web server from internal network using public address according your src and dst nat rules where:
X.X.X.X is client from internal network
55.55.55.55 is public IP of Mikrotik
192.168.1.1 is internal IP of Mikrotik
192.168.1.103 is address of web server
only with dst-nat applied
request: source address X.X.X.X:3456 destination address 55.55.55.55:90 is sent to mikrotik
dst-nat is performed, so we have source address X.X.X.X:3456 destination address 192.168.1.103:90 and request is sent to web server
problem: web server sends response directly to X.X.X.X:3456
this will not work
with dst-nat and also with src-nat
request: source address X.X.X.X:3456 destination address 55.55.55.55:90 is sent to mikrotik
dst-nat is performed, so we have source address X.X.X.X:3456 destination address 192.168.1.103:90
src-nat is performed, so we have source address 192.168.1.1:3456 and destination address 192.168.1.103:90 and request is sent to web server
web server sends response to 192.168.1.1:3456 but question is, how to redirect response back to X.X.X.X:3456, thanks to applying dst-nat and src-nat we lost original source address from request..
Correct me, if I am wrong, IMHO this task has no solution (without other helpers)…
You wrote, that your second web server (you use port 80) is accessible from both internal and external network, so I want to ask whether you have transparent Web-proxy configured on Mikrotik?
And second question: What happens if you set up web proxy on Mikrotik on port 90?
You wrote, that your second web server (you use port 80) is accessible from both internal and external network, so I want to ask whether you have transparent Web-proxy configured on Mikrotik?
And second question: What happens if you set up web proxy on Mikrotik on port 90?
No, I don’t have any kind of web proxy running anywhere.
Dst-nat is part of prerouting, src-nat is part of postrouting.
I think it is necessary to log packet flow to find out difference between your port 80 and port 90 usage. Can you log packet exchange between client and your web server in both cases? We must find the difference..
I had asked the same topic about DMZ
but no good answer like this…
told me to use domain name.. and put those domain in hosts file…
not give any answer directly how to make connection using ip address
thanks for the tips
