That is the intent but does not seem to be working.  The actual traffic fails, as does running the packet_trace function on the asa, the traffic falls through to the implicit deny.

static (in,out) tcp NAT_ADDRESS 25 REAL_ADDRESS 25
static (in,out) tcp NAT_ADDRESS 443 REAL_ADDRESS 443

The above configuration will translate incoming connections to the NAT_ADDRESS on port 25 to the real server.
Also, incoming connections to the NAT_ADDRESS on port 443 to the real server.
Everything else will be untranslated.

Is this not what you want to do, or I'm missing something?

Federico.

I think I tried that already with the same results.  There is one other issue to consider, I also need to exempt the same real server from any translation when communicating with particular subnets.

I've been doing similar things on IOS and PIX for years but the ASA does not seem to behave the same, or I'm missing something.

Let me try your static pat example again.

Thanks again

OK, let me see if I can clarify.

The problem is not really so much one of doing the translations for the traffic I want but rather, more correctly one of exempting all other traffic from the real_address when destined for a range or ranges of addresses.

I have anyconnect vpn clients on the outside interface being issued addresses from the same subnet as the real_address, which works great, as vpn clients then appear to the rest of the network as if they reside on the local lan, rather than on some arbitrary subnet which exists only on the VPN.

The problem is, once the NAT rules are in place to allow the external smtp and https, the real_address becomes unavailable to clients on the vpn as the response traffic from the real_address gets NAT'd.  This is similar to a client on the inside attempting to access an external NAT'd address except that the client (while they have an ip address from the inside, actually reside on the outside).  Again, this works great until the NAT comes into play.

Does this make sense?

Thanks!

What I don't understand is the following:
You say:

The problem is, once the NAT rules are in place to allow the external smtp and https,
the real_address becomes unavailable to clients on the vpn as the response traffic
from the real_address gets NAT'd.

To fix the above problem what you do is this:

access-list nonat permit ip host REAL_ADDRESS VPN_POOL
static (in,out) NAT_ADDRESS REAL_ADDRESS

With the above two commands, only the VPN clients will reach the internal real address of the server,
any other access will reach the NAT_ADDRESS of the server.

In this way, you can get the Anyconnect VPN clients to reach the internal addresses, while external access
will be reaching the public NATed addresses.

Federico.