Outbound ACL on ASA 9.1(3)

[rfranzke]

Greetings all. My company just purchased some new ASA 5515CX firewalls which I am working on deploying. These are replacing some aged Pre 8.3 PIX 515E firewalls so I am in the process of manually converting the configuration over to the new 9.x codebase. I want to confirm the syntax of an outbound ACL for the new post 8.3 commandset. So current on the PIX firewalls I have an ACL on the inside interface which controls traffic destined to the Internet. Here is an example of one of the lines in the ACL and supporting configurations:

access-list inside-out remark DCs to any for DNS

access-list inside-out extended permit udp object-group dc-int any eq domain

access-list inside-out extended permit tcp object-group dc-int any eq domain

object-group network dc-int

network-object dc1-int 255.255.255.255

network-object dc2-int 255.255.255.255

name 10.10.x.x dc1-int

name 10.10.x.x dc2-int

access-group inside-out in interface inside

So now these hosts will be getting natted to a public address outbound. With the new order of operation rules in 8.3+ will I think I need to create ACLs that use the natted source address in them instead of the private address as I have now. Something like this:

access-list inside-out remark DCs to any for DNS

access-list inside-out extended permit udp object-group dc-ext any eq domain

access-list inside-out extended permit tcp object-group dc-ext any eq domain

object-group network dc-ext

network-object dc1-ext 255.255.255.255

network-object dc2-ext 255.255.255.255

object network dc1-ext

host x.x.x.x

object network dc2-ext

host x.x.x.x

My point here is that in the ACL I need to use the natted source address (the address which the internal private source address will be changed to going out) instead of the private source address like in the pre-8.3 code. Can anyone confirm this for me please or set me straight?

Thanks in advance

NewtoASA

[jpeterson6]

You're close

To my knowledge this only affects inbound NAT connections that used the external IP addresses as a destination in an ACL. "Inbound" is defined as traffic that originates from a low-sec interface to a higher-sec interface.

For example, using the same object groups you defined above, let's say you want to permit HTTPS access inbound to them from the internet:

(pre-8.3)

access-list outside-in extended permit tcp any object-group dc-ext eq 443

(post-8.3)

access-list outside-in extended permit tcp any object-group dc-in eq 443

In the above example, you use the Internal/Real IP addresses as the destination for the inbound rule, instead of the External/Mapped IP address as used previously. This is of course assuming you have a Static NAT (in this example) to handle those translations.

EDIT: Forgot to mention that, long story short, you shouldn't need to change your "inside-out" ACL.

[Jouni Forss]

Hi,

Almost got confused because of the topic

So we are actually talking about inbound interface ACL for outbound traffic from its networks. In the sense that we are controlling traffic that is inbound to interface "inside" but its traffic outbound from the networks behind "inside", on its way to the external network.

Basically the interface ACLs should be pretty simply. You always use the local/real IP address to allow or deny traffic. Not the public/mapped IP address.

- Jouni

[rfranzke]

Yes the sorry for the confusion. As listed in the example, the ACL is affecting traffic coming into the inside interface from internal networks that is destined for the External interface. I should have been more clear.

With traffic from outside to inside, the ACL needs to have the real IP in the ACL as NAT occurs first and then the ACL is applied which is different than it used to be. My thinking was that since the ACL I am talking about affects traffic flows from the inside (inbound to inside interface) to the outside interface, I would need to again allow the public address in the ACL as the source address would be changed when going to the outside interface since nat would occur first and then the ACL is applied. So the source addresses would be public since NAT has already occurred and then the ACL would be applied. Am I missing this. Sorry for being dense. Trying to get my head around the new operations rules with ASA. Thanks for all the replies.

[Jouni Forss · Accepted solution]

Hi,

Its probably a thing that I can not explain to the degree that it would be enough.

What I know is that for a destination IP address of a connection that comes to an ASA interface the ASA first UN-NAT the destination IP address and then does the ACL check.

Since you were talking about outbound traffic I actually decided to test something out that I had not even tried so far. I configure an ACL to my own ASAs external interface in the direction outbound.

So basically now I have an ACL on my LAN interface that is attached inbound and ACL on my WAN that is attached outbound. So traffic from my LAN to WAN gets checked twice. What is funny is that the source IP address of the ACL that is on the WAN interface and controls outbound traffic still has to be the real IP address.

Just to give you an example with "packet-tracer" command on my ASA

ASA(config)# packet-tracer input LAN tcp 10.0.0.100 12345 8.8.8.8 80

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         WAN

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group LAN-IN in interface LAN

access-list LAN-IN extended permit ip any any

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (any,WAN) after-auto source dynamic LAN-NETWORK interface

Additional Information:

Dynamic translate 10.0.0.100/12345 to x.x.x.x/12345

Phase: 6

Type: HOST-LIMIT

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group WAN-OUT out interface WAN

access-list WAN-OUT extended permit ip host 10.0.0.100 any log

Additional Information:

Phase: 8

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (any,WAN) after-auto source dynamic LAN-NETWORK interface

Additional Information:

Phase: 9

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 10

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: LAN

input-status: up

input-line-status: up

output-interface: WAN

output-status: up

output-line-status: up

Action: allow

So as you can see, seems we just have to use the real/local IP address always on the interface ACL. There is some other features on the ASA that need to be configured to use the NAT IP address though but interface ACL seems to just use the local/real IP address no matter what the direction is.

- Jouni

[rfranzke]

OK thanks for checking this. I'll just configure the addresses as I have them in the original PIX configuration. Thats what I started doing in the first place but then thought I would check with the experts on if I needed to do what is proposed in the post. Thanks again for checking this.

[rfranzke]

OK I tired a few tracer expirements and it seems that the order of operations is different depending on the traffic flow:

packet-tracer input outside tcp 12345 www

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
object network host-int
nat (inside,outside) static host-ext dns
Additional Information:
NAT divert to egress interface inside
Untranslate x.x.x.x/80 to 10.10.x.x/80

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group outside-in in interface outside

packet-tracer input inside udp 10.10.10.20 12345 8.8.8.8 53

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside-out in interface inside
access-list inside-out extended permit udp object-group dc-int any eq domain
object-group network dc-int
description: Internal Domain Controllers
network-object object dc1
network-object object dc2
Additional Information:

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
object network server-int-net
nat (inside,outside) dynamic server-public
Additional Information:
Dynamic translate 10.10.10.x/12345 to x.x.x.x/12345

So it seems going inside to outside its acl---->nat and going outside to inside its nat----->acl. So this explains why using the private addresses in the outbound ACL works. Understood it depends on the configurations in place. I added the inside/inbound list back as I had it originally and the trace output is what I see. Love the packet-tracer command. Very useful stuff. Thanks again for the help to an ASA noob.

[Jouni Forss]

Hi,

Was thinking about the same thing as you with regards to the order of NAT/ACL depending on where the connection is coming from.

Notice my example though,

Traffic from LAN to WAN first gets checked against ACL and local IP address is used as source  then we see the Dynamic PAT translations that translates the source to a public IP address. Finally we see the ACL check of the ACL attached to the WAN interface in outbound direction. Again the traffic still matches the real IP address even though we have seen the Dynamic PAT getting applied.

So there is clearly something else with the NAT/ACL ordering as one would expect to allow outbound traffic on the WAN interface to already be source from a public IP address.

There are some things that are a bit unclear as Cisco doesn't really share specific enough information about the ASA operation. So some things just seem to work in a certain way yet you dont really know how to explain why they work the way they do.

I agree with regards to "packet-tracer". Its a great tool. I think every Cisco device should have it to help determine problem with the traffic forwarding

- Jouni