Redirect to external domain

kelarlee · Tue Mar 15, 2022 10:19 pm

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.

anav · Tue Mar 15, 2022 10:30 pm

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............

kelarlee · Tue Mar 15, 2022 11:03 pm

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

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.

anav · Tue Mar 15, 2022 11:44 pm

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.

Sob · Wed Mar 16, 2022 12:08 am

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.

mkx · Wed Mar 16, 2022 12:23 am

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.

anav · Wed Mar 16, 2022 1:42 am

Are the two WANIPs involved static? i
If they are dynamic then it may be more work...........

Great explanation mkx!!! (s1 -c0 )

Larsa · Wed Mar 16, 2022 12:36 pm

@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

anav · Wed Mar 16, 2022 5:48 pm

@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.

Yeah, he saved me the hassle of writing that up, saved 5 years of my life jajajaja..............

anav · Sun Mar 27, 2022 5:56 pm

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:
Code: Select all
Are you sure you didnt mean   dst-chiroptera ?  ;-))

Zacharias · Sun Mar 27, 2022 6:24 pm

Nice explanation of Hairpin NAT from @mkx

mkx · Sun Mar 27, 2022 7:23 pm

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:
Are you sure you didnt mean dst-chiroptera ? )

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?

anav · Sun Mar 27, 2022 7:29 pm

Plenty and frequently, I just found this one particularly amusing..........

anav · Sun Mar 27, 2022 7:30 pm

Nice explanation of Hairpin NAT from @mkx

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.

mkx · Sun Mar 27, 2022 8:08 pm

Nice explanation of Hairpin NAT from @mkx
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.

anav · Sun Mar 27, 2022 9:14 pm

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.........

mkx · Sun Mar 27, 2022 9:34 pm

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.

anav · Sun Mar 27, 2022 11:39 pm

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.

Sob · Mon Mar 28, 2022 5:09 am

@mkx: But... but... you're using the wrong address, we're used to it being the internal one!

mkx · Mon Mar 28, 2022 8:33 am

Can you confirm you meant WAN SERVER ???

Yes, I meant WAN server ... as per initial post in this thread.

@mkx: But... but... you're using the wrong address, we're used to it being the internal one!

anav · Mon Mar 28, 2022 2:17 pm

Who would use such a term..........??
What purpose is this WAN Server, is it an FTP server, a video server etc etc...
So fine you are using WAN server but what is it serving...... Dinner??

anav · Mon Mar 28, 2022 2:18 pm

@mkx: But... but... you're using the wrong address, we're used to it being the internal one!

See even Sob agrees that you are being technically correct but not explaining it down to the masses so its palatable. Sigh, IT elitists............

Zacharias · Mon Mar 28, 2022 4:19 pm

Nice explanation of Hairpin NAT from @mkx
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.

Well i think @mkx answered your question...
Same technique...

mkx · Mon Mar 28, 2022 4:22 pm

What purpose is this WAN Server, is it an FTP server, a video server etc etc...

From the context of discussion in this thread I'm assuming that OP wanted to implement a temporary solution where he moved some server from one IP address to another one and he wanted to make sure clients can connect server until all clients start to use new address this way or another.
You won't believe, but there are (brain-dead?) clients with server configured as IP address not FQDN ... so it might take days (or even weeks) to re-configure all the clients. And if one wants all clients (those using old address and those using new address) to communicate with very same server instance, then there are only two possibilites: hairpin-NAT or reverse proxy (third possibility, redirect, is only available for certain protocols and even then some brain-dead clients might not support it). Reverse proxy is not available on ROS, so the choice is obvious.
Even if clients are not completely brain-dead and do support DNS, it still might cause considerable service disturbance if one can not deal with DNS records properly (reduction of TTL in several steps, change of record, verification everything works correctly, ...).

anav · Mon Mar 28, 2022 5:16 pm

All good, just trying to pry some gems from you for the user article to help the overall understanding............

You never did answer my question of what type of WAN server it is,........... serves coffee??
The reason for my sarcasm is that I yearn for consistency and this statement was very clear to me.....

Quote: "..... in the case of masquerading (redirecting) WANIPs, then the case becomes the WAN client talking to LAN server via some foreign (to both client and server) IP address (and that communication needs to pass router in both directions).... " unquote.

The genius who wrote that seemed to be talking about a WAN client and a LAN server !!!!

Conclusion, when you wrote its a WAN server, you were drunk out of your tree and slurring your words together.... ;-PP

mkx · Mon Mar 28, 2022 7:37 pm

I wrote:

.... 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 that's exactly what I meant, word by word.

And I don't see what's the signifficance of information what exactly that server is serving. Can be bull shit for what it's worth.

If it was WAN client talking to LAN server, then simple DST NAT would do. But that's not what OP was asking for. So go back to post #1 and try to understand the requirements. OP did excellent job describing needs in plain words (I wonder who has habit of requiring that from forum users with questions

) and I provided explanation why hairpin NAT fits the task at hand.

anav · Mon Mar 28, 2022 7:50 pm

Trust me, I did before I made the observation " I have internal server "
Doesnt sound smell or touch like a WAN server.

I'm not the IT pro so you have to be technically accurate whereas I can be forgiven for trespassing on nomenclature...............
Its clear in my head now, no such thing as a WAN server, which was the confusion I was trying to overcome.

mkx · Mon Mar 28, 2022 8:04 pm

I give up, explaining this to you seems mission impossible.

anav · Mon Mar 28, 2022 11:28 pm

No worries, I dont blame you, few have the energy to keep up.

Plus I am thicker than a post, so very few make a dent.

Sob · Tue Mar 29, 2022 6:34 am

@mkx: Watch the master.

@anav: It's really simple. Imagine yourself as computer enthusiast who was given big server for free. Server, meaning the big heavy noisy professional computer found in datacenters. You start to play with it, install some OS, web server and stuff. It's great fun. So you put it in your pantry, because you don't have space for it elsewhere. And it's fine, because who would mind a server in there. First you run your own hobby website on it (you have the usual dstnat from your router's public address), then you let your friends run their own websites there too, because it's big server and it's nothing for it. Everything is just great.

Until one day your wife appears in front of you and she doesn't look happy at all. She explains to you that she accidently kicked that damn thing for the last time, that she had enough of the noise it's making, adds something about electricity bill being too high, and long story short, that thing will be gone tomorrow, or else. Your sense of self-preservation kicks in, so you quickly buy a VPS (virtual server), transfer everything to it and with heavy heart turn off the good old physical server.

But there's problem. There was too many things there and you didn't have complete control over everything. Your website is fine, because you already updated DNS for your domain, so it now points to public address of new server. But your friends, whose websites you also hosted, have their own domains and you don't have access to their DNS. And you can't reach all of them so quickly. One is on holiday out of civilization, another was just hit by bus yesterday, you name it. It means that their websites will be offline until they are able to update their DNS. Unless...

And that's the solution described is this thread. Clear?

mkx · Tue Mar 29, 2022 8:10 am

@anav: It's really simple. Imagine yourself as computer enthusiast who was given big server for free. Server, meaning the big heavy noisy professional computer found in datacenters. ...

I fear you've list @anav here

But kudos, it's a great story. Sounds like the first guy, out of civilitation, might be lost in Nova Scotia and the other one was actually hit by snow plough?

anav · Tue Mar 29, 2022 2:14 pm

Great story very entertaining, luv the explanation of the WAN based servers, now why couldnt mkx have done that....... ;-P

mkx · Tue Mar 29, 2022 2:38 pm

'cause I didn't want to drag your better half into this mess.

Redirect to external domain

Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Re: Redirect to external domain

Who is online