Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Lower to higher security level ASA with PAT on outside if

What would be best practice if I want to permit certain traffic from a network with lower security level to one with higher given the follwing configuration?

 

ASA Version 9.1(1)

!

interface GigabitEthernet0/1.1

description Inside Main VLAN

vlan 1

nameif inside

security-level 100

ip address 10.10.1.1 255.255.255.0

!

interface GigabitEthernet0/1.2

description Inside SUP46

vlan 2

nameif Office

security-level 90

ip address 10.10.2.1 255.255.255.0

 

!

object-group network Inside-Networks

network-object 10.10.1.0 255.255.255.0

!

object-group network Inside-Office-Networks

network-object 10.10.2.0 255.255.255.0

!

 

!

nat (inside,outside) after-auto source dynamic Inside-Networks interface

nat (Office,outside) after-auto source dynamic Inside-Office-Networks interface

!

 

The after-auto part is for the outside network (public) to be allowed to connect to some hosts on the inside and Office network and works via access-lists and groups.

 

I’ve tried to do a similar thing with access from Office to Inside:

 

access-list Office-to-inside extended permit tcp any host 10.10.1.10 eq www

access-group Office-to-inside in interface Office

 

This does allow for the access described above but overrules all other access such as Office to Outside (meaning internet access). I guess I could probably write a bunch of other access rules to allow access to outside and other lower security level networks (i.e. conference, guest) from Office but is this sound practice?

Everyone's tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions
Super Bronze

Hi, I would suggest that you

Hi,

 

I would suggest that you configure an ACL for each interface and name it so that it only refers to that interface as the ACL will really control traffic from behind that interface towards any other interface on the ASA. So there is really no point naming it to refer to 2 different interfaces on the ASA. (As you can only have 1 ACL per interface per direction)

 

As for limiting the traffic from "office" to "inside" to only certain traffic but still allowing traffic from "office" to "outside"  (or to destination networks behind other interfaces) you can accomplish that with this simple ACL

 

access-list OFFICE-IN remark Allow some traffic to INSIDE
access-list OFFICE-IN permit tcp any host 10.10.1.10 eq ww
access-list OFFICE-IN remark Deny all other traffic to INSIDE
access-list OFFICE-IN deny ip any 10.10.1.0 255.255.255.0
access-list OFFICE-IN remark Allow all other traffic
access-list OFFICE-IN permit ip 10.10.2.0 255.255.255.0 any

access-group OFFICE-IN in interface office

 

As you can see the above ACL first allows the HTTP traffic to the single host behind the "inside" interface and then the same ACL blocks all other traffic towards the "inside" subnet. After this it allows traffic to "any" destination network. So since we have first allowed specific traffic and then blocked all other traffic to the same destination subnet means that the last "permit" statement allows traffic to any other destination subnet/network than the one behind "inside" as we have already blocked it earlier in the ACL.

 

If you wanted to allow some other traffic to the "inside" subnet from behind "office" then you would simply add new "permit" statements to the top of the ACL (before the "deny" statement)

 

You can follow this logic with the ACL of the "inside" interface also if you want to limit its connecitivity to the "office" subnet.

 

Hope this helps :)

 

- Jouni

3 REPLIES
Super Bronze

Hi, I would suggest that you

Hi,

 

I would suggest that you configure an ACL for each interface and name it so that it only refers to that interface as the ACL will really control traffic from behind that interface towards any other interface on the ASA. So there is really no point naming it to refer to 2 different interfaces on the ASA. (As you can only have 1 ACL per interface per direction)

 

As for limiting the traffic from "office" to "inside" to only certain traffic but still allowing traffic from "office" to "outside"  (or to destination networks behind other interfaces) you can accomplish that with this simple ACL

 

access-list OFFICE-IN remark Allow some traffic to INSIDE
access-list OFFICE-IN permit tcp any host 10.10.1.10 eq ww
access-list OFFICE-IN remark Deny all other traffic to INSIDE
access-list OFFICE-IN deny ip any 10.10.1.0 255.255.255.0
access-list OFFICE-IN remark Allow all other traffic
access-list OFFICE-IN permit ip 10.10.2.0 255.255.255.0 any

access-group OFFICE-IN in interface office

 

As you can see the above ACL first allows the HTTP traffic to the single host behind the "inside" interface and then the same ACL blocks all other traffic towards the "inside" subnet. After this it allows traffic to "any" destination network. So since we have first allowed specific traffic and then blocked all other traffic to the same destination subnet means that the last "permit" statement allows traffic to any other destination subnet/network than the one behind "inside" as we have already blocked it earlier in the ACL.

 

If you wanted to allow some other traffic to the "inside" subnet from behind "office" then you would simply add new "permit" statements to the top of the ACL (before the "deny" statement)

 

You can follow this logic with the ACL of the "inside" interface also if you want to limit its connecitivity to the "office" subnet.

 

Hope this helps :)

 

- Jouni

New Member

Thanks, this makes good sense

Thanks, this makes good sense! I will it and post feedback on how it turned out in a few days.

New Member

I had a similar problem and

I had a similar problem and your access-list helped me to resolve it.  I'm new to cisco routing and had the logic backwards for which interface to apply the access-list to.  Also, worth noting here I had to create a "no nat" network object for it to work fully.

643
Views
0
Helpful
3
Replies