If you want to see actual source IP addresses, then you must not use hairpin NAT ... i.e. use split DNS where A record for public internet points at your router's WAN IP address (and plain dst-nat is enough to have connection working). And A record for "same subnet" clients points directly to server's LAN IP address so clients can talk to server directly, without (un-necessarily) involving router and its dst-nat.

Or close server into dedicated subnet .. which means that communication with LAN clients will have to pass touter and hair-pin nat is not necessary any more.

Some of my internal services run on different source ports and I would still require a dot-net to do the port translation

Example service runs on port 1050 and the clients use 5050

In this case the best solution is to move server(s) into dedicated IP subnet. The dst-nat would then work the same way for both internet and LAN clients (no hairpin NAT necessary).

BTW, DNS records have nothing to do with the way NAT is executed, NAT simply works on individual connections (and those are characterized by IP addresses).

If servers need to communicate with each other, then ... I don't see why you couldn't configure them to communicate directly (over real ports)?

Well, in such a convoluted setup you'll have to think it out yourself. I'm not willing to guess the size of your problem and all the interactions.

But the fact is that NAT isn't exactly piece'a'cake in certain conditions.