Any idea how can I redirect Public to Public IP
example: I have router A Public IP :10.10.10.11 and router B Public IP: 11.11.11.11
Now from my pc from different location I want to do when I enter IP:10.10.10.11 on my Mozilla or Chrome (Router A) automatically to be redirected on router B (IP 11.11.11.11)
Tnx.
Do you mean HTTP redirect? Configure the web server to do that . . but if not HTTP…
This is the same as a hairpin NAT, but on the outside interface.
dst-nat happens before routing decision, so if you make a dst-nat action with the other public IP 11.11.11.11, the packet will be dutifully translated and sent on its merry way to the remote server.
The problem is that the source needs to get natted too - if you have a masquerade rule in srcnat chain for out-interface=wan (the actual wan interface name, not the word ‘wan’ goes here) and no other criteria, it should work for your public-to-public hairpin NAT.
I don’t get u really
redirect.jpg
MT router does not need masquerade rule its just a router somewhere configured with public static ip:10.10.10.11, just need dst rule to redirect to 11.11.11.11
What I need is when I enter ip:10.10.10.11 on my pc traffic from MT router to be redirected to web server IP:11.11.11.11 (similar to dyndns)
From your post my dsnt rule should be something like this
chain=dstnat action=dstnat to-addresses=11.11.11.11 protocol=tcp in-interface=ether1
But it cant work
I really don’t get it how can I use hairpin NAT in this case
I completely understood your problem from the first post. This IS a hairpin Nat situation. Remember that in reality, there is no such thing as a LAN or WAN interface of a Router. All interfaces are just ways to go, and there are addresses in various directions.
Hairpin means that the destination of the NAT is out the same interface from which the packet was received.
It doesn’t mean LAN host talking via pinhole on wan IP to another LAN host. (sure, that’s over 99% of the cases you see in the forums, but technically, hairpin can be a wan host talking to another wan host)
Here’s why you must have a masquerade rule:
Let’s say your computer “somewhere on the internet” has IP 9.9.9.9, the Mikrotiks have the given addresses of 10.10.10.11 and 11.11.11.11 from your example.
You type 10.10.10.11 (or some hostname for that IP) into your browser.
Packet leaves your computer with src/dst IP:
9.9.9.9 / 10.10.10.11
Packet hits first mikrotik and gets dst-nat - (but no masquerade) - and leaves with:
9.9.9.9 / 11.11.11.11
Packet arrives at server
Server replies to sender’s IP with a packet whose src/dst addresses are:
11.11.11.11 / 9.9.9.9 (see the problem yet?)
PC receives a TCP SYN+ACK packet from this un-known host 11.11.11.11 (it was trying to talk to 10.10.10.11)
PC discards this invalid SYN/ACK packet from this weirdo 11.11.11.11 host
PC wonders why 10.10.10.11 hasn’t answered yet, re-sends the TCP SYN to 10.10.10.11
Packet bounces around the triangle, and again makes it back to PC with the wrong source address.
PC drops all following SYN/ACK packets from 11.11.11.11 just like the first one
PC wonders what’s wrong with 10.10.10.11
PC gives up on 10.10.10.11 and shows a “Website cannot be displayed” error on your screen.
You come to forums and ask what’s wrong.
And here we are.
Now on the 10.10.10.11 Mikrotik, make a nat rule in the srcnat chain which matches out-interface=wan dst-address=11.11.11.11 action=src-nat to-addresses=10.10.10.11
Here’s what will happen when you try again after adding that rule to the Mikrotik:
Now the packet leaves your PC with src/dst IP addresses:
9.9.9.9 / 10.10.10.11 (same so far)
Packet leaves the first mikrotik:
10.10.10.11 / 11.11.11.11 (different, thanks to new srcnat rule)
Server replies with packet:
11.11.11.11 / 10.10.10.11 (packet now heading back to Mikrotik)
Mikrotik un-nats this packet and sends it to you as:
10.10.10.11 / 9.9.9.9
Now your PC sees the SYN/ACK from the correct remote host, completes the handshake, requests the web page, draws it on your screen.
You smile, and come back here and mark + karma on this reply.
(hehe - seriously, if this doesn’t fix, I’ll keep helping though)
I hope this illustrates why it’s still hairpin even with public IPs. It has nothing to do with public/private IP, and nothing to do with wan/lan. It has everything to do with packets arriving at the server and client with addresses that will cause the packets to flow the way they need to. Basically, without the hairpin rule, the Mikrotik never gets the chance to un-do the NAT on the replies like it does when connections flow THROUGH it.
Good luck!
Yep it works
NAT rules in MT Router 10.10.10.11
0 chain=dstnat action=dst-nat to-addresses=11.11.11.11 protocol=tcp
in-interface=ether1 dst-port=!8291 log=no log-prefix=“”
(Redirect all ports except 8291 winbox port)
1 chain=srcnat action=masquerade out-interface=ether1 log=no
log-prefix=“”
Many Tanks ZeroByte anyway how can I give u karma? or reputation?
Glad it’s working for you now, and thanks for the karma. 