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

[raun.williams]

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

[Jouni Forss · Accepted solution]

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

[Azubuike Obiora]

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!

[Azubuike Obiora · Accepted solution]

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.

[raun.williams]

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

[Azubuike Obiora]

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!)

NB

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.

[Jouni Forss]

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

[raun.williams]

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.

[Jouni Forss]

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

[Azubuike Obiora]

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

[raun.williams]

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

[raun.williams]

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.

[Jouni Forss]

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

[raun.williams]

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.

[Jouni Forss]

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