NAT issue on 8.4.2

[Kevin Marcan]

Hi Everyone!

I was hoping you guys could assist me with an issue ive been running into.

We are trying to do some policy NATing, and running into issues because the ASA is looking at the route table before making a NAT decision.

According to the document http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/nat_overview.html#wp1102289

This should not be happening

The document claims:

In routed mode, the ASA determines the egress interface for a NAT packet in the following way:

• If you specify an optional interface, then the ASA uses the NAT configuration to determine the egress interface. (8.3(1) through 8.4(1)) The only exception is for identity NAT, which always uses a route lookup, regardless of the NAT configuration. (8.4(2) and later) For identity NAT, the default behavior is to use the NAT configuration, but you have the option to always use a route lookup instead.
  
• If you do not specify a specific interface, then the ASA uses a route lookup to determine the egress interface.
  

I tried using both object NAT and twice NAT, with a statement that looks as follows

nat (Transit,Outside) source static 192.168.0.220 10.10.10.1 service svc-80 svc-80

To my understanding, since we are specifying the destination interface, NAT should be making this decision, and it should not be looking at the routing table.

This doesnt seem to be the case. We have run into this issue with both 8.4.2 and 8.4.3

Anyone run into this or have any input?

[Jouni Forss]

Hi,

Can you elaborate abit on what you're doing with the NAT configuration above? I mean whats the situation for which you need to use policy NAT

[Kevin Marcan]

Basically we have an ASA with 2 ISP's interfaces

One being the primary, the other the secondary.

We want to basically be able to point certin servers out the secondary ISP.

In this case:

nat (Transit,Outside) source static 192.168.0.220 10.10.10.1 service svc-80 svc-80

We want to take our server 192.168.0.220 , source port 80, and NAT it out to 10.10.10.1 port 80

The issue is, its looking at the routing table before NATs, and chosing to direct it out the primary ISP, instead of the secondary.

[Jouni Forss]

So even after the above NAT configuration the server hasn't been reachable from that ISPs interface with that ISPs IP address on port TCP/80 ?

Is there any possibility that there is some old xlate active that causes problems?

I haven't personally configured the setup you are doing but might just lab the setup tomorrow at work if I have the time.

[Kevin Marcan]

Sorry I might try to reword it a bit.

We havent had an issue opening ports on the secondary ISP for traffic coming it.

What we are trying to do is direct traffic being sourced from inside our network, out the secondary ISP.

Lets  say If server/client 192.168.0.220 tries to go to   www.google.com, we  want him to be directed out the secondary ISP,   instead of going out the  primary.

In other words, any  traffic sourced from   192.168.0.220, destined to any public network,  destination port 80,  will  get sent out ISP2

Previously this was doable via NAT.

I  did manage   to find a odd way of getting it work, but it is by all  means not   proper,  I was able to setup a reverse NAT. But this is  definitely not   ideal.

Here is an example of the reverse NAT statement

nat (ISP2,Transit) source static any any destination static interface netPRIVATE-192 service svc-80 svc-80

[Jouni Forss]

Hi,

Did you try only using the statement nat (Transit,Outside) source static 192.168.0.220 10.10.10.1

As I said I havent done this kind of setup myself so havent tested it myself.

[Kevin Marcan]

Yea, It still looks at the route table first, so it gets pointed out the default interface.

[llamaw0rksE]

It appears to me that originally you articulated a problem with a server in that you could not force the server to respond with outgoing on a specific secondary assigned WANIP (from your ISP).   First of all, any server will respond to the WANIP in which the initial request inbound came in on (assuming this is setup in the router to allow incoming).  Secondly this is determined by the IP you give users or dyndns name for example It is not something the router has control over.

Then I believe you clarified that this was not the case but in reality you simply wish to ensure a group of hosts should be guided to use the internet via a specific WANIP (the secondary one).

So, let see is we can clarify the requirement.  Put yes or no besides the letter

a.   control users on lan to use specific WANIP.

b.   ensure that servers are accessible and queries routed back thru the same associated WANIP

c.  ensure that regardless of which external WANIP is used to access server, the response will only go out on a specified WANIP {note I do not know if this is even a feasible concept).

This implies

     i.  both WANIPs receiving server requests require nat and ACLs to allow incoming.

     ii.  need nat and acl rules to control routing of  responses by server.....

[Kevin Marcan]

Lets try to simplify the requirements a little.

   Lets say all we are trying to do, is option A.    We want to send specific clients to go out the backup ISP,  (Not the default route)

[llamaw0rksE]

Can you narrow it down a bit further , (lets say lan is 192.168.2.1), is it one host 192.168.2.5,  a contiguous range of hosts

192.168.2.25 - 192.168.2.35 or serveral groupings of hosts, or the entire lan??  

Also, normally do you allow all hosts access to the internet in general or are you of the ilk to deny all traffic and only want these users access to specific outside servers on the secondary WANIP address. 

Its hard for me with (hey I can read the docs) little experience to come up with reasonable answers without more info.

[gregbeifuss]

Kevin,

Did you ever get this resolved? I'm trying to do the same thing in sending certain clients out our secondary link (not the default route), but encounter the same issue - the route lookup is occurring first and that sidesteps the NAT rules.
There's a posted document (6069 - https://supportforums.cisco.com/docs/DOC-6069) that claims the documentation is wrong per TAC and the routing table is always consulted first.

I'm debating whether or not to downgrade to < 8.3 to get this feature as I've seen users claim to have luck doing this under that asa version.

Thanks,
Greg