cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1295
Views
0
Helpful
19
Replies

Configuration Suggestion and Help on NAT'ing and Routing multi interafaces

raun.williams
Level 3
Level 3

Can you tell me if this is possible with a 5510 on 9.1x code and the best approach?

I need a way to setup the ASA so it has an Interface e0/0.1 (Outside-Cable, 10.100.255.5), Interface e0/0.2 (Outside, T-1, 10.100.255.4), and Interface e0/1, (Outside-Corp).   All e0 interfaces will go to a single router, and each e0 interface will be ip’d seperately so that the rotuer can distinquish the traffic and policy route to it’s appropriate outside interface (cable or t1).  E0/1 will be ip’d with the corporate public ip so that specific traffic can be routed to the corporate router and use it’s links and policy routes.

Internally on the ASA,  E0/2.1 through .5 will have individual subnets (10.100.33 through 10.100.37.0) for guest network access and should go out e0/0.1.  Meanwhile, E0/2.6, 10.100.100.38, should go out e0/0.2.   E0/2.7 or E0/3, 10.100.38.0 should go out E0/1 for corporate internet access.

I wouldn’t think this would be to hard, but there seems to be quite a bit of confusion on the forums as to exactly the limitations of the ASA with multiple outside interfaces.  And/or if this can just been done with NAT, but perhaps version dependent?

Thanks,

Raun

19 Replies 19

so... i loaded up 8.4(6) and a packet tracer shows it to be working.  very interesting.  I'm not on site, so i have some one going to physically test it.  hmm.. i'm curious if this is a bug or a feature removal or what the deal is.

Hi,

Just spend some time testing some of the software levels supported by the new ASA5500-X Series (as they dont support 8.4)

It seems that 8.6(1) , 9.0(4) and 9.1(4) all completely ingnore the NAT configuration when determining the egress interface. The ASA simply performs a Route Lookup even though the document states that it should not.

I remember trying this with 9.1(1) even on the original ASA5500 Series and booted up that software and it worked just fine.

So Cisco must have changed something.

I really getting fed up these changes to the ASA operation especially when they are undocumented changes.

Either I am missing something or there are simply softwares that act totally different compared to the documentation.

Here is example from the very latest documentation

Determining the Egress Interface

When the ASA receives traffic for a mapped address, the ASA  unstranslates the destination address according to the NAT rule, and  then it sends the packet on to the real address. The ASA determines the  egress interface for the packet in the following ways:

Transparent  mode—The ASA determines the egress interface for the real address by  using the NAT rule; you must specify the source and destination  interfaces as part of the NAT rule.

Routed mode—The ASA determines the egress interface in one of the following ways:

You  configure the interface in the NAT rule—The ASA uses the NAT rule to  determine the egress interface. However, you have the option to always  use a route lookup instead. In certain scenarios, a route lookup  override is required; for example, see the "NAT and VPN Management Access" section.

You do not configure the interface in the NAT rule—The ASA uses a route lookup to determine the egress interface.

The above section bolded above to my understanding states that if you have a translation for the destination address and if you specify the interface in the "nat" command then NAT should determine the egress interface NOT the routing table.

Obviously this seems to be dependant on the software level for some reason

Command Reference also states this

If you specify an optional interface, then the ASA uses the NAT configuration to determine the egress interface.

- Jouni

Yes, I agree, that's completely rediculous.  I'm hitting up my Cisco Security SE on this to see if I can get a comment.  I appreciate your help. 

So now, when doing a software upgrade, it looks like additional testing will be required prior to a go live to determine if the code variant behaves as documented

Jouni,

What level of code were you able to get this to work on the X line?  I'm on a 5512-x with 9.1(1) code and i'm getting the route lookup phase first.  I just don't get the logic behind this.  I spoke with TAC several times, and they refer to the NAT lookup method over route as a 'bug' and only support 'pbr' behavior in clusters.

Unfortunately, i'm actually replacing the 5510 that the above configuration was applied to with the 12-x.

Thanks,

Raun

Hi,

I only tested with 9.1(1) so far with my ASA5515-X

I am not sure what the Cisco TAC engineer meant in your case.

Naturally what we are doing with the NAT is something that probably was not the first idea on Ciscos mind when they were implementing the new NAT but what we are doing is essentially nothing new even compared to 8.2 (and older) Static NAT or Static Identity NAT.

When you have a NAT configuration for a destination IP address of a connection it has always resulted on the ASA following the NAT configurations rather than the routing table. Its a very common problem in some older customer setups where it starts to cause problems when for example Static Identity NAT has been configured with large enough network mask.

To give you an example

A customer originally planned its network so that the address space 10.10.0.0/16 would be used only behind a single interface on the ASA therefore they configured a route for that network and also configured the following Static Identity NAT between "inside" and "dmz" (to avoid matching Dynamic PAT configuration and traffic getting dropped between these interfaces)

static (dmz,inside) 10.10.0.0 10.10.0.0 netmask 255.255.0.0

What the above essentially does is that a connection coming from behind "inside" interface towards any destination IP address matching 10.10.0.0/16 would get diverted towards "dmz" whatever the routing table said.

Later the customer merged with another network which had a network 10.10.150.0/24.

This essentially caused problems as the customer "inside" was not able to connect towards this network as all of the 10.10.0.0/16 connections were forwarded still to the "dmz" interface. The solution to avoid this was to essentially configure another more specific Static Identity NAT, remove the existing one and finally add it again which resulted in the new rule being before the original rule and therefore getting applied first.

So essentially

static (newint,inside) 10.10.150.0 10.10.150.0 netmask 255.255.255.0

no static (dmz,inside) 10.10.0.0 10.10.0.0 netmask 255.255.0.0

static (dmz,inside) 10.10.0.0 10.10.0.0 netmask 255.255.0.0

I am not sure what the exact answers you have gotten from TAC were (though I would be interested in seeing them) but I don't buy that explanation. This is because they are essentially telling that they have had that "bug" for several years (since the old software levels!) and they have also redone the NAT and decided to keep that "bug" in the new NAT format too. I just don't buy it. It would also mean that they decided to give wrong information in the configuration guide which also mentions the behaviour I described above.

The most common situation where you can confirm this behaviour is if you have Static NAT configured for some server you have towards the external/public network. If you would now use the "packet-tracer" command and simulate a packet incoming from external/public network towards this public IP address on a specified port/service you would initially see a UN-NAT phase where the packets destination IP address it matched against an existing NAT configuration and this destination IP address would be untranslated to the local IP address of the server and the traffic would be diverted towards the local interface specified in the NAT configurations. So if they are telling me that this behaviour is some sort of bug then I dont understand what they mean. What we are doing with the destination 0.0.0.0/0 NAT or 0.0.0.0/1 and 128.0.0.0/1 NAT is essentially creating a NAT for ANY destination IP address so connections could be diverted to the correct interface no matter what the routing table says.

I will get be getting some new X-Series ASAs next month and I will need to get an answer to this question myself from Cisco. I think you might need to push to get the TAC case handled further up the chain because the initial TAC engineer might not be able to give an satisfactory explanation on the situation.

- Jouni

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: