topic Configuration Suggestion and Help on NAT'ing and Routing multi i in Network Security

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

raun.williams — Tue, 12 Mar 2019 03:38:15 GMT

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

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

Jouni Forss — Thu, 30 Jan 2014 18:14:49 GMT

Hi,

NAT can be used in the new software (8.4 ->) to manipulate the interface through which the traffic of certain source networks is forwarded. The NAT configurations together with multiple default routes can achieve this. Each interface will have a default route of which only one is naturally active but the NAT configuration used will first divert traffic from some networks to a second or third ISP and will after use that interfaces default route (even though normally it wouldnt be used by the ASA)

The downside of this is naturally a NAT configuration that is not very typical. Its naturally not also something that Cisco would probably suggest but its the only alternative to PBR like operation on the ASA.

Depending on the current ASA environment and especially the requirements for traffic between the local interfaces this might create a NAT configuration that is very dependant on the "nat" commands always being in the correct order.

To give a simple example a basic configuration could look like this

interface GigabitEthernet0/0

nameif ISP-CALBE

security-level 0

ip address 1.1.1.2 255.255.255.0

interface GigabitEthernet0/1

nameif ISP-T1

security-level 0

ip address 2.2.2.2 255.255.255.0

interface GigabitEthernet0/2

nameif ISP-CORP

security-level 0

ip address 3.3.3.2 255.255.255.0

interface GigabitEthernet0/3.100

vlan 100

nameif LAN-1

security-level 100

ip address 10.10.10.1 255.255.255.0

interface GigabitEthernet0/3.200

vlan 200

nameif LAN-2

security-level 100

ip address 10.10.20.1 255.255.255.0

interface GigabitEthernet0/3.300

vlan 300

nameif LAN-3

security-level 100

ip address 10.10.30.1 255.255.255.0

route ISP-CORP 0.0.0.0 0.0.0.0 3.3.3.1

route ISP-CABLE 0.0.0.0 0.0.0. 1.1.1.1 253

route ISP-T1 0.0.0.0 0.0.0.0 2.2.2.1 254

object network ANY-0.0.0.0-1

subnet 0.0.0.0 128.0.0.0

object network ANY-128.0.0.0-1

subnet 128.0.0.0 128.0.0.0

object-group network ALL

network-object object ANY-0.0.0.0-1

network-object object ANY-128.0.0.0-1

object network LAN-1

subnet 10.10.10.0 255.255.255.0

object network LAN-2

subnet 10.10.20.0 255.255.255.0

object network LAN-3

subnet 10.10.30.0 255.255.255.0

nat (LAN-1,ISP-CABLE) source dynamic LAN-1 interface destination static ALL ALL

nat (LAN-2,ISP-T1) source dynamic LAN-2 interface destination static ALL ALL

nat (LAN-3,ISP-CORP) source dynamic LAN-3 interface destination static ALL ALL

If the different LAN/DMZ networks needed to be able to reach eachother then we would have to configure NAT0 / Identity NAT configurations at the top of the Manual NAT / Twice NAT configurations (above) so that internal traffic would match those rules and rest of the traffic from the said source networks would be forced out through their set ISP.

The above configurations could also use "object-group" to define multiple source networks and also use Dynamic NAT+PAT instead of the Dynamic PAT.

Hope this helps

- Jouni

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

Azubuike Obiora — Thu, 30 Jan 2014 18:37:02 GMT

Hi Raun,

I have some questions to ask if you will.

You want sub-interface configured on your OUTSIDE interface going to your Corp router, which i believe that holds of your connection from ISPs?

Truth be told, I have never see that happen on the OUTSIDE interface, but logically thinking it! I suppose it can be done giving that you can assign different security levels to the sub-interface for your OUTSIDE connection.

The best practice I have seen in my few years of working with Cisco ASA's most sub-interface are configured on the INSIDE or DMZ interface. Execpt your ISP requires a dot1q trunk from their side to your physical interface in most cases I have seen that is usually with routers. But again anything is possible these days.

For the fact that you want a sub-interfaced scenario and looking at different different subnet reaching different OUTSIDE sub-interface connections, I suggest you use TWICE NAT style for your different natting of those subnets on your INSIDE. Basically creating object and embedding them into your nat statements.

You can look up the following document for guide on the NATTING, it's was put together by one of the guys I have respect for in this community Jouni! He explains things simple.

https://supportforums.cisco.com/docs/DOC-31116

I hope this helps.

Tedd.

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

Azubuike Obiora — Thu, 30 Jan 2014 18:40:43 GMT

I see Jouni you beat me to it!

I just made a ref to a documentation you wrote which has helped me in getting to understand different nat with ASA.

There you have it Raun! Jouni in e-flesh and e-blood!

Re: Configuration Suggestion and Help on NAT'ing and Routing mul

raun.williams — Thu, 30 Jan 2014 18:45:21 GMT

Thank you to both of you! I've never got my head wrapped around the new nat since it changed in 8.3. I'm gong to study the link you gave me and the config makes sense, in some aspects. I'll have to give it a shot and will let you know. More then likely, I'll be back wtih questions

Teddy, I agree with you the outside subinterfaces and it is certainly unusual from my standpoint. However, in reality, although they are 'outside' their still on my network. I have a OUTSIDE switch that I can provide a trunk to for the ASA, and break out the vlans to the appropriate routers, guest and corporate, which i own. So from that aspect, I don't see a big issue in doing it that way to conserve physical ports. Although, i was going to set the security level teh same on all of them since they still can't talk to one another by default. Do you see an issue with this?

Thanks,

Raun

Re: Configuration Suggestion and Help on NAT'ing and Routing mul

Azubuike Obiora — Thu, 30 Jan 2014 18:54:23 GMT

Hi Raun,

Definitely not a problem with that!!! I mean with the version 8.3+ of the ASA a code, there's just way too much of flexibility to do nat with it!

Good enough Cisco had to wake up to the call. I mean Juoni poured it out for you in a black int and white canvas for you! just copy his config and edit to your suiting.

Believe me I went thru same phase of getting my head around the nat in ver 8.3+ i felt it was difficult at first, but once it down well with me....i feel it's the best thing ever since slice bread!!!! mmmhmmmm....

Also don't forget to rate Jouni's and I reply if it does answer your question.

Thanks

Tedd ( in reality i gat ma glasses on hehe!)

I never appreciated the idea of drawing out your problem, not untill recently I had to help troubleshoot and saw the importance of having drawing to explain problems. So If you can next time just put up a drawing no matter how it is! It helps to understand your problem easily and solution would be provided ASAP.

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

Jouni Forss — Thu, 30 Jan 2014 19:08:04 GMT

Hi,

The above configuration is just a really simple example of how to get traffic forwarded through different external interfaces of the ASA based on the source network. Even though you could do the same even if the source networks were behind a single LAN interface.

I would stress that the above configuration doesnt take into account at all possible VPN related NAT0 configurations, possible Static NAT configurations that you might need for servers or traffic between the LAN interfaces. All of those would require additional configurations.

So trying out something like this would be good if you can lab it or atleast plan the change before trying it and having a plan to revert back to the old if you are doing it in production environment.

This is something I have not added to my document that I wrote. I am not sure when I will add more information to the document. I do know that there is a lot of things that could be added there. Hopefully I get myself around to it at some point

To give a short summary what the above "nat" commands are supposed to do is the following:

We first define the source and destination interface of the traffic. Where is the source network located and where do we want to forward it?
- nat (LAN-1,ISP-CABLE)
We define the source network(s) in object and PAT it to the external interface specified in the command
- source dynamic LAN-1 interface
We use an "object-group" that contains all the possible destination networks.
- destination static ALL ALL
When traffic from the defined source network from the defined source interface comes to the ASA towards any destination IP address, that destination IP address will get matched to the destination object-group "ALL" and therefore get forced out through the destination interface which we have used in the "nat" command.

Not necesarily the clearest explanation but feel free to ask more questions and I'll try to answer those.

- Jouni

Re: Configuration Suggestion and Help on NAT'ing and Routing mul

raun.williams — Thu, 30 Jan 2014 21:47:16 GMT

Well, you guys obviously know your stuff so I went ahead and put it as the correct answer, i'll just have to implement in toy with it. Originally, I saw this as step 1. Since your quite good at this, I'll through the other catch at you now to think about it.

So all of these 'DMZs" are wireless networks. On the other side is a wireless controller and the wireless controller has the option of 'proxying' the dhcp request for the client basically turn it into a unicast request.

Now that request needs to be able to get through say LAN-1 to INSIDE-1 for the DHCP server as well as DNS lookups, at 10.100.90.x.

But that is the ONLY access they should have to that INSIDE-1. Anything else is a big no no.

Optionally, I could tell the controller to let the clients on LAN-1 make their own request and setup dhcp relays on the ASA to INSIDE-1 if that would be easier...

I'm actually doing the unicast way through an old PIX 515E right now.

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

Jouni Forss — Thu, 30 Jan 2014 22:03:08 GMT

Hi,

So if there is traffic that needs to pass between local interface then the above configuration is not enough to achieve that as the current NAT configuration would forward ALL destination traffic to the ISP interface of choice.

This means we need to determine the LAN networks between which connections are required and between which interface this traffic is supposed to flow.

If I use my own previous example and for example say that I need that traffic can flow between LAN-1 and LAN-2 wihtout getting forwarded to the ISP interfaces then I would configure this

nat (LAN-1,LAN-2) 1 source static LAN-1 LAN-1 destination static LAN-2 LAN-2

Key things to notice in the above configuration

We add the rule to the top of these Section 1 Manual NAT rules as we mentioned the line/order/priority number "1" in the command. So it will be first to be matched before the special "nat" configurations we have for the ISP traffic.
This "nat" command is bidirectional. If LAN-1 initiates connection towards LAN-2 then this traffic will get matched to this rule. If LAN-2 initiates connection to LAN-1 then this traffic will get matched to this rule. Though if we didnt move this rule to the top in the previously mentioned way this rule would never be matched.
As we use the same "object" for both the real and mapped source/destination it essentially means we are doing NAT0 / Static Identity NAT. This means the networks can communicate with their original IP addresses.

Naturally you will have to use the interface ACLs to control what traffic is allowed. Naturally you could only configure the same NAT above for only certain hosts between the networks but I guess thats up to you. I personally prefer to do traffic control purely in the ACL and not use NAT for it.

Hope this helps

- Jouni

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

Azubuike Obiora — Thu, 30 Jan 2014 22:18:41 GMT

Hi Raun!

Jouni is absolutely correct. Using ACL in my opinion gives you more dexterity in controlling your traffic.

For you ACL remember that going from Higher interface level to a Lower one no bueno to it(no problems)! But from the Lower to the higher you need the ACL to go with it!

So you thinking about allowing your request from your DMZ to your LAN1, you need the ACL to match the traffic. I personally like creating my ACL in this order:

FROM TO SERVICE

SOURCE DESTINATION SERVICE

DMZ LAN1 udp/dhcp

Makes the flow easy to understand and implement.

Hope it helps.

Tedd

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

raun.williams — Thu, 30 Jan 2014 23:34:00 GMT

Hmm.. I don't seem to be selecting the appropriate route. If i remove the other default route statements, it works fine.. add the others back and it doesn't. So I built the config and started messing with teh 10.100.39.0 or VIP-VENDOR network

object network VIP-VENDOR
subnet 10.100.39.0 255.255.255.0

object network ANY-0.0.0.0-1
subnet 0.0.0.0 128.0.0.0
object network ANY-128.0.0.0-1
subnet 128.0.0.0 128.0.0.0

object-group network ALL

network-object object ANY-0.0.0.0-1

network-object object ANY-128.0.0.0-1

nat (Guest-1,Outside-Cable) source dynamic Guest-1 interface destination static ALL ALL

nat (Guest-2,Outside-Cable) source dynamic Guest-2 interface destination static ALL ALL

nat (Guest-3,Outside-Cable) source dynamic Guest-3 interface destination static ALL ALL

nat (Guest-4,Outside-Cable) source dynamic Guest-4 interface destination static ALL ALL

nat (Guest-5,Outside-Cable) source dynamic Guest-5 interface destination static ALL ALL

nat (VIP-DOC,Outside-t1) source dynamic VIP-DOC interface destination static ALL ALL

nat (VIP-VENDOR,Outside-Corp) source dynamic VIP-VENDOR interface destination static ALL ALL

access-group acl-vip-vendor in interface VIP-VENDOR

route Outside-Cable 0.0.0.0 0.0.0.0 10.100.255.254 1

route Outside-t1 0.0.0.0 0.0.0.0 10.100.254.254 253

route Outside-Corp 0.0.0.0 0.0.0.0 PUBLICIP 254

Here's the packet trace:

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 0.0.0.0 0.0.0.0 Outside-Cable

Phase: 4

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group acl-vip-vendor in interface VIP-VENDOR

access-list acl-vip-vendor extended permit ip any any

Additional Information:

Phase: 5

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 900, packet dispatched to next module

Result:

input-interface: VIP-VENDOR

input-status: up

input-line-status: up

output-interface: Outside-Cable

output-status: up

output-line-status: up

Action: allow

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

raun.williams — Fri, 31 Jan 2014 16:16:05 GMT

Well after researching, I saw on a blog where this might have changed in 9.1 so backed down to 8.4.1 but no results. One suggestion was sysopt noproxyarp on the interface, nothing. I don't see any info in sh nat details, it's not even hitting it a nat since there isn't one built for VIP-VENDOR to Outside-Cable. So obviously it's just skipping the nat statements that are there all together.

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

Jouni Forss — Fri, 31 Jan 2014 16:24:14 GMT

Hi,

If you are going to try some 8.4 code I would suggest trying 8.4(5) or 8.4(6). To my understanding 8.4(1) still did not follow the NAT configurations but actually the routing table.

Though I am not sure what the problem is with the 9.1 since I have tested this on that software version.

In your earlier post where you mentioned the configurations that didnt seem to match at all, what was the exact software level used? I might try to lab that up again myself as I am currently trying something out on an ASA. Could perhaps test this after I done with the previous test.

- Jouni

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

raun.williams — Fri, 31 Jan 2014 16:30:21 GMT

Okie, will try 8.4(6). Not sure what you mean by 'configurations that didnt seem to match at all', but I started out on 9.1.4.

Sure, if you have time to lab it, I would greatly appreciate it. If you want my config, let me know.

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

Jouni Forss — Fri, 31 Jan 2014 16:32:23 GMT

Hi,

I just meant the "nat" command that should all forward the traffic from the specified LAN networks to specific ISP link. Just wondered what software was used when if they werent work.

But as you mentioned its 9.1(4). Will see if I can try that out a bit later.

- Jouni

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

raun.williams — Fri, 31 Jan 2014 16:54:23 GMT

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.

Re: Configuration Suggestion and Help on NAT'ing and Routing mul

Jouni Forss — Fri, 31 Jan 2014 17:16:58 GMT

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

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

raun.williams — Fri, 31 Jan 2014 17:26:56 GMT

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

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

raun.williams — Tue, 25 Feb 2014 15:51:53 GMT

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

Re: Configuration Suggestion and Help on NAT'ing and Routing mul

Jouni Forss — Tue, 25 Feb 2014 17:38:59 GMT

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