Hi, i have one task, but cant figure out how to solve this. I have internal server and mikrotik with external ip for example 159.159.159.159. My users connecting to my server through mikrotik with ip 159.159.159.159 and port 8787. For now we moving server to another location (to data center) and i need temporaly redirect all requests that comes to my mikrotik from internet and redirect them to external domain name for example abc.com:8787. Is it possible to do this and how ? Thank you.
Yes get a dyndns domainname, URL many free providers and give your clients that for their connections.
You decide where the dyndns points…
If this is not possible, hmmmmmmmmmm
If by chance its a web server and if so, is there some sort of web server functionality that can point to a different URL…
Thank you for reply but i think you missunderstand me. For now i already own domain for my server in data center(abc.com for example). My main task is temporaly redirect all requests that comes to my “old” server ip adress (159.159.159.159 - mikrotik WAN IP) to my new domain server adress “abc.com”(domain name in datacenter) until i manually change adresses on my users PC. I need this so that my users won’t be interrupted after I move my server to the datacenter. And then i can leisurely change settings on my users PCs.
Not sure how, MT has a DNS service but not sure its up to the task.
Hopefully someone with better MT networking knowledge and experience can chime in.
It’s same problem as is solved by hairpin NAT. Client from 1.2.3.4 connects to 159.159.159.159, you use dstnat to redirect connection to new server (e.g. 160.160.160.160), the new server sees 1.2.3.4 as source, so it sends response directly to it from it’s 160.160.160.160. And client throws it away, because it doesn’t expect anything from 160.160.160.160.
If you don’t care about server seeing real source addresses, simply add srcnat/masquerade rule to make all dstnatted connections look as if they are from 159.159.159.159. New server will send responses there, and router will forward them correctly to clients.
If you do need original source addresses, you’d need some tunnel between router and server, and server would have to treat it as basically a multi-WAN config and send responses back depending on where they came from.
Only a few protocols support redirects explicitly … in the way that instructs client to create new connection to provided address or server name (one example is HTTP). Others don’t suppirt it. However, it is possible to kind-of proxy connection and you can use NAT on router for that. You would need to perform both DST-NAT and SRC-NAT to make it work.
Let’s say IP address is WAN IP address, actual server is behind NAT and having IP address 192.168.42.42. Currently you have DST-BAT configured on router, something like this:
/ip firewall nat
add chain=dstnat action=dst-nat dst-address=159.159.159.159 protocol=tcp dst-port=8787 to-addresses=192.168.42.42
But you want instead to send connections to new WAN address of 166.166.166.166 … One thing is to change to-addresses in the NAT rule to the new IP address. The other thing, equally important, is to add SRC-NAT rule simikar to this one:
add chain=srcnat action=src-nat dst-address=166.166.166.166 protocol=tcp dst-port=8787 to-addresses=159.159.159.159
The reason for needed src-nat hides in packet flow:
- client A.B.C.D starts connection towards 159.159.159.159:8787
- forward packet arrives at router which finds DST-NAT rule matching packet. Dst-address gets rewritten with 166.166.166.166, src-address remains A.B.C.D
- router looks at routing tables and finds egress interface (which is WAN interface) and sends it away
- forward packet arrives at router serving IP address 166.166.166.166. It does whatever necessary to deliver packet to app server, for simplicity sake let’s say it simply routes it through
- app server receives forward packet, processes it and composes return packet. Return packet’s dst-address is copied from forward packet’s src-address (A.B.C.D) and src-address is set to its own IP address (166.166.166.166). Sends it to its gateway.
- router serving 166.166.166.166 receives packet. Looks at dst-address (A.B.C.D) and sends it towards destination
- client A.B.C.D receives packet. Looks at src-address (to match packet to connection), which is 166.166.166.166 … and sees an unknown address - forward packet was sent to 159.159.159.159.
Due to that it discards packet and connection thus fails to establish.
Now, if router 159.159.159.159 performs src-nat as a part of step #2, then packet flow changes to:
- client A.B.C.D starts connection towards 159.159.159.159:8787
- forward packet arrives at router which finds DST-NAT rule matching packet. Dst-address gets rewritten with 166.166.166.166, src-address remains A.B.C.D.
Router also performs SRC-NAT, hence src-address is set to 159.159.159.159. - router looks at routing tables and finds egress interface (which is WAN interface) and sends it away
- forward packet arrives at router serving IP address 166.166.166.166. It does whatever necessary to deliver packet to app server, for simplicity sake let’s say it simply routes it through
- app server receives forward packet, processes it and composes return packet. Return packet’s dst-address is copied from forward packet’s src-address (159.159.159.159) and src-address is set to its own IP address (166.166.166.166). Sends it to its gateway.
- router serving 166.166.166.166 receives packet. Looks at dst-address (159.159.159.159) and sends it towards appropriate router
- router 159.159.159.159 receives packet, performs connection tracking magic and finds out that packet belongs to a SRC-NAT-ed connection. So router un-does SRC-NAT replacing dst-address with A.B.C.D.
Router re-evaluates connection tracking and finds out that packet belongs to DST-NATed connection, so it un-does DST-NAT by replacing src-address with 159.159.159.159. - now router consults routing tables and sends packet to client at A.B.C.D
- client A.B.C.D receives packet. Looks at src-address (to match packet to connection), which is 159.159.159.159 … and processes return packet as it belongs to a known ongoing connection.
Are the two WANIPs involved static? i
If they are dynamic then it may be more work…
Great explanation mkx!!! (s1 -c0 ) 
@mkx described a solution with an admirable pedagogical clarity. We’ve performed a similar exercise with a 24/7 service to catch clients that din’t obey dns ttl.
Tip: static dns records tend to have quite high ttl (ie> 24h or higher) so my advice is to lower ttl to 30s and wait for at least “old ttl” + a few more days before making any changes.
Second, always have a backup plan and test all scenarios thoroughly before changing anything in production. When there is no more forwarding traffic for a while you may want to increase dns ttl and stub out forwarding.
EDIT:
If it’s possible to change the client application service port number to eg 8888 you might be able to setup a test scenario, with forwarding, all the way to the data center without even change the server port using src-port=8888 dst-port=8787
Yeah, he saved me the hassle of writing that up, saved 5 years of my life jajajaja…
Nice explanation of Hairpin NAT from @mkx
I’m kind of a guy who benefits of having finger tips touching actual keyboard. If I’m typing on a touch screen (like I’m doing right now), fingers often slip beyond correct place on the screen (and B is right next to N on my keyboard) … I’m getting a habit of proof reading my own posts … and I correct some 95% of typoes. Some slip past me, my excuse is that I’m old enough to wear reading glasses. Don’t tell me that you don’t need any, granpa?
Plenty and frequently, I just found this one particularly amusing…
Not sure if this is hairpin nat?? In the sense that its redirecting wanips vice ensuring traffic gets back from server to originator on same LAN.
It is hairpin NAT in the sense it ensures that return traffic flows through same NAT device … the only difference between what people usually understand under this name and this particular use case is the size of “subnet” beyond the interface which is ingress and egress at the same time.
And I thought @sob managed to explain to you that the only difference between WAN and LAN is conceptual (you’re doing good with that inter-VLAN firewall of yours). Seems he didn’t quite succeed.
What, WAN and LAN are different… But where does the first WAN start.
If my WAN is just a LAN on another WAN, and that WAN it just another LAN on another WAN…
I was right we are in a simulation… and how do the beings/aliens know, that are watching us in their simulation, that they are not also in a simulation as well of a higher being 
You are splitting hairs, I only said it was not the same as port forwarding as us lay people know it.
The example or standard hairpin nat application is to masquerade the source address, your evil and twisted application of hairpin is masquerading what looks like the destination address…
No. Standard SRC-NAT is masquerading source address and standard DST-NAT is masquerading destination address. And hairpin NAT is masquerading both addresses, one to each end (ckient doesn’t use the correct dst-address and server doesn’t see correct src-address).
So tell me, how in this aspect my “evil and twisted application” differs from the one from MT manual? Apart from the side of the router (if you insist on conceptual difference between WAN port and LAN port) communicating with both client and server?
Usual hair-pin NAT makes sure that LAN client can talk to LAN server via some foreign (to both client and server) IP address … and in my case it’s WAN client talking to WAN server via some foreign (to both client and server) IP address (and that communication needs to pass router in both directions). And I’m sure I don’t have to remind you that any router’s own IP addresses are treated equally regardless of ingress interface of a particular packet - packet targeting router’s WAN IP address ingressing through LAN interface is treated the same way as packet targeting same IP address ingressing through WAN interface.
Thanks for the explanation, it helps!!
Can you confirm you meant WAN SERVER ???
Quote: “…and in my case it’s WAN client talking to WAN server via some foreign…” unquote.
@mkx: But… but… you’re using the wrong address, we’re used to it being the internal one! 
Yes, I meant WAN server … as per initial post in this thread.