Cisco ASA NAT - internal host see its public ip

Does your host use a DNS name? If so, ask for DNS rewrite to be enabled on the Cisco ASA NAT rule for your host.

Does the application allow manual override of where it binds? I assume this is ruled-out already.

Is the external IP listed in /etc/hosts?

From here, I'm going to go out there a little with this answer and focus on the application, not the nat. In particular, I'm going to explore what you can do outside the application to trick it. This would only be for the desperate. This will assume a Linux operating system.

First, the application must somehow obtain the IP address from outside itself. This will ultimately be a file access (/sys/...), a C library call, or an external executable (/sbin/ifconfig). We can try to find how it obtains this information via strace.

strace -f /path/to/app

The output will be very verbose and technical, but may help you determine the mechanism used by the app to determine the IP.

Here is an example of "hostname -i", which resolves the main IP of my desktop machine:

strace hostname -i
execve("/bin/hostname", ["hostname", "-i"], [/* 69 vars */]) = 0
...
socket(PF_NETLINK, SOCK_RAW, 0)         = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=17272, groups=00000000}, [12]) = 0
...
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
...
open("/etc/nsswitch.conf", O_RDONLY)    = 3
...
open("/etc/host.conf", O_RDONLY)        = 3
...
open("/etc/resolv.conf", O_RDONLY)      = 3
...
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 3
read(3, "127.0.0.1\tlocalhost\n192.168.1.4\t"..., 4096) = 338
close(3)                                = 0
...
write(1, "192.168.1.4\n", 12192.168.1.4

We can see that it tries several techniques, then actually finds a match in the /etc/hosts file.

Now, ways to trick it:

1) If the app reads from /sys, then a little hard to trick short of a hand-crafted chroot environment.

2) If the app makes a C library call, a custom shared library may be loaded with the app to override and alter the behavior of the corresponding library call. Unrelated, I've used this trick to temporarily disable the "fsync" call for an application that requires it under normal operation.

3) If the app calls an executable (/sbin/ifconfig?), the it is possible to replace this executable with a version that selectively alters its behavior for this application only. Consider setting an environment variable for the app only and checking in the custom executable.

This may be way off topic and is not real specific, but I just want to share a high level idea of how you can trick an application when all other options have been exhausted and you just have to "make it work".

ok, I gotchya. I have this same complaint about NAT routers in general. It is so frustrating when you cannot connect to the external point of view from inside. This is quite often the case with many routers.

You can work around this issue by using NAT within your Linux iptables to redirect an attempt to connect to the outside IP with a connection to the internal IP. The application will not even know its connection destination has been altered. For all purposes, it'll think it has connected outside.

It would be something like:

/sbin/iptables -t nat -A OUTPUT \
  -p tcp \
  -d $EXTERNAL_IP \
  --dport $EXTERNAL_PORT \
  -j DNAT --to-destination $INTERNAL_IP:$INTERNAL_PORT

You can be as selective as you want, even doing this NAT only for specific users with the "-m owner ! --uid-owner 0" type of match.