Problem with static policy nat ASA 8.04

[SCOTT PENDERGAST]

Hi I'm having some trouble understanding why the following does not work:

access-list nat_someserver_inside extended permit tcp host real_host host target_host eq smtp

access-list nat_someserver_inside extended permit tcp host eq https any

static (inside,outside) mapped_address access-list nat_someserver_inside

clear local-host (to get rid of xlates created by a static (inside,outside) mapped_address real_address

sh xlate shows

3 in use, 4 most used

PAT Global mapped_address(0) Local real_host(0)

PAT Global mapped_address(0) Local real_host(0)

PAT Global mapped_address(0) Local real_host(443)

the goal is to allow bidirectional smtp between the mapped_address and the target_host and incoming https connections to the mapped_address

while leaving all other traffic un_xlated.

I'm on 8.04 currently.

Can someone point out what I'm missing?

Thanks in advance!

Scott

[Federico Coto Fajardo]

Hi,

For example:

access-list nat permit tcp host 10.1.1.1 host 192.168.1.1 eq smtp

access-list nat permit tcp host 10.1.1.1 eq https any

static (inside,outside) 172.16.1.1 access-list nat

clear local-host

The above statements will NAT packets from 10.1.1.1 to 192.168.1.1 when the destination port is 25 and from 10.1.1.1 sourcing port 443 to any destination.

Any other connection from 10.1.1.1 will be PATed to the outside address (assuming you have PAT).

Is this what you're seeing?

Federico.

[SCOTT PENDERGAST]

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.

[Federico Coto Fajardo]

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.

[SCOTT PENDERGAST]

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

[SCOTT PENDERGAST]

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!

[Federico Coto Fajardo]

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.