@anav: Really? Do I end my strike for RouterOS v7 (*) and come back to this? 
Didn’t you get your guru handbook? You can’t ask questions like this anymore. You can’t be perplexed by simple double NAT or basic routing and firewalling. You need to make a new incognito account for such questions (no, don’t, it was a joke).
About the “complexity of hairpin NAT”: link (also check the author of post above this one)
And on top of that, you don’t need to worry about additional filter rules, because any connection via public address between your internal subnets (client in one and server in another) will be allowed by same old trusty “allow all dstnatted connections” rule as every other dstnatted connection, no matter where it came from. There’s no complexity at all, in fact, it can’t be any simpler and more foolproof.
There’s only one downside of hairpin NAT when compared to DNS method. When both client and server are in same LAN subnet, DNS method is more efficient, because it means direct connection between them. Hairpin NAT requires all packets to unnecessarily go to router and back. But guess what, you can have both at the same time, hairpin NAT as basic always working solution and DNS override for selected services with lot of required bandwidth or something.
And since it seems that the DNS method may not be clear enough, it’s just:
/ip dns static
add address=192.168.<whatever your server has> name=www.websitehostedonyourserver.tld
So when client in same LAN (using this router as DNS resolver, this part is mandatory) asks for address of www.websitehostedonyourserver.tld, it gets 192.168. and simply makes direct connection. And yes, if it’s not in the same LAN subnet, but in another on same router and you block access between them by default, you’ll need to specifically allow these connections.
For the case of having the public address and not really having it at the same time, it’s simple 1:1 NAT. ISP keeps the real public address on their router and dstnats/netmaps all incoming traffic coming to this address to private address on customer’s router. And srcnats/netmaps anything coming from customer’s router to public address. This config works fine for all simple things and only gets annoying for something more complex like IPSec.
The configuration of customer’s router is exactly the same as any other, LAN, WAN, srcnat or masquerade for outgoing traffic, dstnat rules for incoming. Only difference is when you need hairpin NAT as OP wants, then you also need to work with public address (which is actually on ISP’s router) on your router, e.g:
/ip firewall nat
add chain=dstnat dst-address=192.168.47.9 protocol=tcp dst-port=80 action=dst-nat to-addresses=192.168.88.x comment="port forward for outside clients"
add chain=dstnat dst-address=90.46.65.88 protocol=tcp dst-port=80 action=dst-nat to-addresses=192.168.88.x comment="port forward for inside clients"
add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.0/24 action=masquerade comment="hairpin rule"
Or you can change the last one to:
/ip firewall nat
add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.0/24 action=src-nat to-addresses=90.46.65.88
and it will make all connections from LAN to server via public address look as if they came from the same public address. Completely optional, it will make no difference in functionality, it just may look better in logs than 192.168.88.1.
–
(*) Nah, not really, but sounds as good reason for not being here for a while, doesn’t it? Also, if that would have been the case, notifying someone in advance would have been better choice than saying it only now, but hey… 
