Hairpin nat weirdness

RouterOS General
21

i just want to have access to nated ports via external_ip:port from my lan without masquerading like in any other routers

22

Ok. But you still need to masquerade the external wan traffic, right? So, what’s the difference to masquerading the internal traffic as well. I mean, all traffic still needs to pass through the router in both directions when doing the harpin-dance and there is no actual performance gain skipping the masquerade (that I know of at least). Just curious to hear why…

And as I suggested before, if you skip hairpin-nat you will only need one set of dst-nat rules.

23

Main problem is source ip of hairpined connection, all these connects coming with router ip and i’m unable to understand who is connected.

24

This is by design when using hairpin-nat , i.e. source ip is always the router interface. If you try to explain what you are trying to accomplish, it might be easier to understand your needs and possible figure out a solution for your problem.

25

Hi Larsa

I see why the need.

We are currently using multiple MX and hosting boxes that traverse emails/services and when trying to source out which MX or service (Internal IP) box had sent or not been able send emails or service comms this makes the task a bit frustrating when trying to locate an IP assigned to a local host running MX or hosted services which need communication to other internal server services which have been hairpin’d. Communicating with Internal NAT’d hosted servers using Hairpin could use some method of statically keeping Bridged/Switched IP traffic by keeping it’s original internal IP to the local subnetted networks. This would help me out in many cases. Running hosts files internally with hairpin points reverts to the reverseDNS path of course, so it’s kinda pointless with Static DNS if reverseDNS public side is mandatory these days for SSL / MX etc..

Any ideas to further expand on getting internal boxes communicating the originating local host IP while using hairpin would be great… having a local gateway/router IP for troubleshooting is a bit maddening.
thanks