cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Welcome to Cisco Firewalls Community


2434
Views
0
Helpful
10
Replies
Highlighted
Participant

Question regarding same security level ACLs

Hi All,

I've been trying to find a direct answer for this on the web, but couldn't find a clear one.

Lets say the asa has  NO same-security-traffic permit inter-interface

and I have two interfaces with same security level:

!

interface Ethernet0/1.4

vlan 10

nameif inside1

security-level 99

ip address 192.168.1.0 255.255.255.0

!

interface Ethernet0/1.6

vlan 20

nameif inside2

security-level 99

ip address 192.168.2.0 255.255.255.0

!

I know that without the same-security-traffic permit inter-interface command,  I woudn't be able to talk from host 192.168.1.1 to host 192.168.2.1 because the implicit deny.

Lets say I want traffic allowed only between these two host ( WITHOUT using same-security-traffic permit inter-interface )

So I create this access list:

!

access-list inside1_acl extended permit ip host 192.168.1.1 host 192.168.2.1

!

And apply it to inside1 interface inbound like so,

!

access-group inside1_acl in interface inside1

!

1) Should this now work? ( At least for traffic initiated from 192.168.1.1 ) Because as I understood this, it should hit the firewall rule and should allow return traffic (because the statefullness of the firewall) inbound @ inside2 interface and back in to inside1 ???

2) Orrr... If we haven't turned on same-security-traffic permit inter-interface Command, by design, there is no way I can allow traffic between two same security level interfaces? .

Thanks guys for taking time to read this..


2 ACCEPTED SOLUTIONS

Accepted Solutions
Mentor

Re: Question regarding same security level ACLs

Hi,

I tested with my home ASA (though I have witnessed the problem before even without testing)

If you have for example

  • "inside" and "outside" interface set to "security-level 100" without any ACL, traffic WONT go through the firewall  
    • (EDIT: No same-security-traffic configurations)
  • "inside" and "outside" interface set to "security-level 100" with an ACL permitting traffic from "inside" to "outside", traffic WONT go through the firewall  
    • (EDIT: No same-security-traffic configurations)
  • "inside" and "outside" interface set to "security-level 100" with an ACL and configured with "same-security-traffic permit inter-interface", traffic WILL go through the firewall  
    • (Will work even without an ACL attached to the interface behind which the traffic is initiated from)

To my understanding the commands "same-security-traffic permit inter-interface" and "same-security-traffic permit intra-interface" are meant to be used to overcome these situations.

  • "inter-interface" used to allow traffic between interfaces/networks of equal security. (For example several LAN or perhaps LAN and Server segment?)
  • "intra-interface" to make it possible for the traffic to head back through the interface the traffic came from. Most common situations might include allowing VPN Clients users accessing the ASA firewall to access Internet through the same interface they connected to (outside) or perhaps ASA is the default gateway for some network but traffic needs to be routed back to LAN for example to some VPN device or another router (where we wouldnt want to route all traffic/networks to)

Though generally I dont trust "security-level" setting do decide which traffic is allowed. I always configure an ACL to an interface.

Security-level did have a play in the below 8.3 software level regarding NAT operation (to my understanding atleast) so you had to take into account the security-levels sometimes even though access rules they didnt mean anything anymore.

Please rate if the information was helpfull and/or ask more questions if needed.

- Jouni

View solution in original post

Mentor

Re: Question regarding same security level ACLs

Ouch,

200 Vlans?

Personally I havent dealth with any FWSM / PIX / ASA that would have that much interfaces/Vlans on a single firewall. We do have devices running in multiple context mode which do have a large amount of interfaces/Vlans but naturally only a handfull per Security Context.

It would seem that your options would be the following (the ones I can think of now atleast at 2am )

  • Configure ACLs for each interface to control the traffic  
    • object-groups could be used to make the configurations easier
    • access-list configurations could perhaps be initially generated with some script (?) to get them prepared fast and then easily copy/pasted / configured to the device. ACL and interface naming policy could be made easier for the scripting with only changing the Vlan ID number in the ACL/interface name I suppose. Though this would eliminate any descriptive naming on the purpose of the Vlan question.

  • Configure a setup where Security-level allows 180 Vlans to only connect to Internet and ACL define the traffic for the other 20 Vlans  
    • 180 Vlans would have identical "security-level" value of perhaps 50
    • 20 Vlans would have varying "security-level" value perhaps down in order from 100
    • Therefore 180 couldnt connect to eachother or higher security-level interfaces of the 20 Vlans. On the other hand the "outside" interface being "security-level 0" would mean that 180 Vlans could access Internet and no ACLs would be needed for the 180 Vlans

If you would go with the harder option that is to configure ACLs for all interfaces I guess you could consider the following things.

  • Configure an "object-group network BLOCKED-NETWORKS-180"  
    • description Vlan range 1 - 180
    • define all of the networks/subnets related to the local 180 Vlans here
  • Configure an "object-group network BLOCKED-NETWORKS-20"  
    • description Vlan range 181 - 200
    • define all of the networks/subnets related to the local 20 Vlans here
  • Configure ACL for each of the 180 Vlans in a very basic format 
    • access-list VLAN-180-IN remark Deny traffic between Vlans
    • access-list VLAN-180-IN deny ip any object-group BLOCKED-NETWORKS-180
    • access-list VLAN-180-IN deny ip any object-group BLOCKED-NETWORKS-20
    • access-list VLAN-180-IN remark Allow all other traffic
    • access-list VLAN-180-IN permit ip any
  • Provided you want to also limit the Vlans 20 from connecting to Vlans 180 you could configure ACLs in the following way 
    • access-list VLAN-20-IN remark Deny traffic to Vlans 180
    • access-list VLAN-20-IN deny ip any object-group BLOCKED-NETWORKS-180
    • access-list VLAN-20-IN remark Lines allowing traffic between Vlans 20
    • access-list VLAN-20-IN permit tcp x.x.x.x y.y.y.y a.a.a.a b.b.b.b eq xyz
    • etc, etc, etc
    • access-list VLAN-20-IN remark Deny all other traffic between Vlans 20
    • access-list VLAN-20-IN deny ip any object-group BLOCKED-NETWORKS-20
    • access-list VLAN-20-IN remark Allow all other traffic
    • access-list VLAN-20-IN permit ip x.x.x.x y.y.y.y any

But I guess as you have yourself noticed, it might be easier just to never configure the "same-security-traffic permit inter-interface" setting and let the security-levels handle most of the work for the 180 Vlans and configure the 20 Vlans with different security-levels and handle all of those interfaces access rules with their own specific ACLs

Hopefully there are no errors there (both in command format and my thoughts/logic). Getting abit late here

Hopefully the above was of some help. Rate the answer(s) if you have found the information to be helpfull

- Jouni

View solution in original post

10 REPLIES 10
Mentor

Re: Question regarding same security level ACLs

Hi,

I tested with my home ASA (though I have witnessed the problem before even without testing)

If you have for example

  • "inside" and "outside" interface set to "security-level 100" without any ACL, traffic WONT go through the firewall  
    • (EDIT: No same-security-traffic configurations)
  • "inside" and "outside" interface set to "security-level 100" with an ACL permitting traffic from "inside" to "outside", traffic WONT go through the firewall  
    • (EDIT: No same-security-traffic configurations)
  • "inside" and "outside" interface set to "security-level 100" with an ACL and configured with "same-security-traffic permit inter-interface", traffic WILL go through the firewall  
    • (Will work even without an ACL attached to the interface behind which the traffic is initiated from)

To my understanding the commands "same-security-traffic permit inter-interface" and "same-security-traffic permit intra-interface" are meant to be used to overcome these situations.

  • "inter-interface" used to allow traffic between interfaces/networks of equal security. (For example several LAN or perhaps LAN and Server segment?)
  • "intra-interface" to make it possible for the traffic to head back through the interface the traffic came from. Most common situations might include allowing VPN Clients users accessing the ASA firewall to access Internet through the same interface they connected to (outside) or perhaps ASA is the default gateway for some network but traffic needs to be routed back to LAN for example to some VPN device or another router (where we wouldnt want to route all traffic/networks to)

Though generally I dont trust "security-level" setting do decide which traffic is allowed. I always configure an ACL to an interface.

Security-level did have a play in the below 8.3 software level regarding NAT operation (to my understanding atleast) so you had to take into account the security-levels sometimes even though access rules they didnt mean anything anymore.

Please rate if the information was helpfull and/or ask more questions if needed.

- Jouni

View solution in original post

Participant

Question regarding same security level ACLs

Hi Jouni,

Thanks for your reply..

What if,

"inside" and "outside" interface set to "security-level 100" without an ACL and configured with "same-security-traffic permit inter-interface" , WILL go through the firewall ???

Mentor

Question regarding same security level ACLs

Hi,

IF

  • Both interfaces have security-level 100
  • Have NO ACLs (on the interface where the host initiates the connection)
  • The setting "same-security-traffic permit inter-interface" is configured

Then the traffic will go through.

- Jouni

Mentor

Re: Question regarding same security level ACLs

Hi,

I edited the original reply to clarify the situation abit more.

Participant

Question regarding same security level ACLs

Hi Jouni,

Sorry for bugging you..

That clarifies a lot. Just one further clarification.. ( This is the background issue I had which lead me to this question )

Let's say I have 200 different VLANs/Interfaces to be set in ASA, And 180 of them should be absolutely isolated from every other VLAN (within the same security level) but 20 of them should have limited connectivity to each other. (And all 200 VLANs are in the same security level).  What would be the best way to tackle this scenario?, turn on same security traffic and apply  "deny acl" to all 180 interfaces and have "permit acl" for the rest 20 VLANs ?? or  is there any other simple way ??

PS: Before bumping in to this issues, my initial thought was to disable same-security-traffic permit command, put all interfaces in to same security level and Apply ACL's only on the 20 Interfaces that needs access to other vlans. And by default rest of the 180 VLANs(Interface) will be blocked  and will only be allowed to access Internet which is in lower security level.  I thought this way, because it involves the lesser number of steps.

Mentor

Re: Question regarding same security level ACLs

Ouch,

200 Vlans?

Personally I havent dealth with any FWSM / PIX / ASA that would have that much interfaces/Vlans on a single firewall. We do have devices running in multiple context mode which do have a large amount of interfaces/Vlans but naturally only a handfull per Security Context.

It would seem that your options would be the following (the ones I can think of now atleast at 2am )

  • Configure ACLs for each interface to control the traffic  
    • object-groups could be used to make the configurations easier
    • access-list configurations could perhaps be initially generated with some script (?) to get them prepared fast and then easily copy/pasted / configured to the device. ACL and interface naming policy could be made easier for the scripting with only changing the Vlan ID number in the ACL/interface name I suppose. Though this would eliminate any descriptive naming on the purpose of the Vlan question.

  • Configure a setup where Security-level allows 180 Vlans to only connect to Internet and ACL define the traffic for the other 20 Vlans  
    • 180 Vlans would have identical "security-level" value of perhaps 50
    • 20 Vlans would have varying "security-level" value perhaps down in order from 100
    • Therefore 180 couldnt connect to eachother or higher security-level interfaces of the 20 Vlans. On the other hand the "outside" interface being "security-level 0" would mean that 180 Vlans could access Internet and no ACLs would be needed for the 180 Vlans

If you would go with the harder option that is to configure ACLs for all interfaces I guess you could consider the following things.

  • Configure an "object-group network BLOCKED-NETWORKS-180"  
    • description Vlan range 1 - 180
    • define all of the networks/subnets related to the local 180 Vlans here
  • Configure an "object-group network BLOCKED-NETWORKS-20"  
    • description Vlan range 181 - 200
    • define all of the networks/subnets related to the local 20 Vlans here
  • Configure ACL for each of the 180 Vlans in a very basic format 
    • access-list VLAN-180-IN remark Deny traffic between Vlans
    • access-list VLAN-180-IN deny ip any object-group BLOCKED-NETWORKS-180
    • access-list VLAN-180-IN deny ip any object-group BLOCKED-NETWORKS-20
    • access-list VLAN-180-IN remark Allow all other traffic
    • access-list VLAN-180-IN permit ip any
  • Provided you want to also limit the Vlans 20 from connecting to Vlans 180 you could configure ACLs in the following way 
    • access-list VLAN-20-IN remark Deny traffic to Vlans 180
    • access-list VLAN-20-IN deny ip any object-group BLOCKED-NETWORKS-180
    • access-list VLAN-20-IN remark Lines allowing traffic between Vlans 20
    • access-list VLAN-20-IN permit tcp x.x.x.x y.y.y.y a.a.a.a b.b.b.b eq xyz
    • etc, etc, etc
    • access-list VLAN-20-IN remark Deny all other traffic between Vlans 20
    • access-list VLAN-20-IN deny ip any object-group BLOCKED-NETWORKS-20
    • access-list VLAN-20-IN remark Allow all other traffic
    • access-list VLAN-20-IN permit ip x.x.x.x y.y.y.y any

But I guess as you have yourself noticed, it might be easier just to never configure the "same-security-traffic permit inter-interface" setting and let the security-levels handle most of the work for the 180 Vlans and configure the 20 Vlans with different security-levels and handle all of those interfaces access rules with their own specific ACLs

Hopefully there are no errors there (both in command format and my thoughts/logic). Getting abit late here

Hopefully the above was of some help. Rate the answer(s) if you have found the information to be helpfull

- Jouni

View solution in original post

Participant

Question regarding same security level ACLs

Thanks for that Jouni. 

Actually 200 VLANs is a hypothetical scenario. We are looking at starting some Could based services. We already have about 30 customers(subnets) and it's growing really fast and I thought it's a good idea to find a easy and proper way to provision future customers.

As you mentioned security contexts is also some thing I should be looking at. ( Thanks for the tip ).

Thanks a lot for taking time to explain this. Awesome explanation..

Beginner

Question regarding same security level ACLs

I have a question that applies but doesnt seem to be answered on this forum.

What if I wanted to create an ACL to block lets say Telnet to a host to router that are on the same subnet, same vlan, inside, on an asa5505.  I have disabled same security becaues they are inside with 100 level security.  Is this possible? Or am I running a fools errand?

ASA Version 8.2(5)

!

hostname ciscoasa

enable password 8Ry2YjIyt7RRXU24 encrypted

passwd 2KFQnbNIdI.2KYOU encrypted

names

!

interface Ethernet0/0

!

interface Ethernet0/1

switchport access vlan 2

!

interface Ethernet0/2

switchport access vlan 2

!

interface Ethernet0/3

switchport access vlan 2

!

interface Ethernet0/4

shutdown

!

interface Ethernet0/5

shutdown

!

interface Ethernet0/6

shutdown

!

interface Ethernet0/7

shutdown

!

interface Vlan1

nameif Outside

security-level 0

ip address 198.x.x.x 255.255.255.240

!

interface Vlan2

nameif Inside

security-level 100

ip address 192.168.1.1 255.255.255.0

!

ftp mode passive

clock timezone DST 0

dns domain-lookup Outside

dns server-group DefaultDNS

name-server 167.x.x.x

name-server 167.x.x.x

access-list Block_Telnet extended deny tcp host 192.168.1.4 host 192.168.1.2 eq telnet

pager lines 24

mtu Outside 1500

mtu Inside 1500

icmp unreachable rate-limit 1 burst-size 1

asdm image disk0:/asdm-643.bin

no asdm history enable

arp timeout 14400

global (Outside) 1 198.x.x.x netmask 255.255.255.240

nat (Inside) 1 192.168.1.0 255.255.255.0

nat (Inside) 1 172.16.0.0 255.255.0.0

nat (Inside) 1 172.30.0.0 255.255.0.0

!

router rip

network 192.168.1.0

version 2

!

route Outside 0.0.0.0 0.0.0.0 198.46.122.193 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

timeout floating-conn 0:00:00

dynamic-access-policy-record DfltAccessPolicy

aaa authentication ssh console LOCAL

http server enable

http 192.168.1.0 255.255.255.0 Inside

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

telnet timeout 5

ssh 115.124.125.0 255.255.255.0 Outside

ssh 192.168.1.0 255.255.255.0 Inside

ssh timeout 5

console timeout 0

dhcpd dns 167.x.x.x8 167.x.x.x

!

dhcpd address 192.168.1.4-192.168.1.25 Inside

dhcpd enable Inside

!

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

webvpn

username jrodriguez password ifOxNUbshE8ud5Rm encrypted privilege 15

!

class-map inspection_default

match default-inspection-traffic

!

!

policy-map type inspect dns preset_dns_map

parameters

  message-length maximum client auto

  message-length maximum 512

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect rsh

  inspect rtsp

  inspect esmtp

  inspect sqlnet

  inspect skinny

  inspect sunrpc

  inspect xdmcp

  inspect sip

  inspect netbios

  inspect tftp

  inspect ip-options

!

prompt hostname context

call-home reporting anonymous prompt 2

Cryptochecksum:c1c56941a09c4f7aa99883455c3812d1

: end

ciscoasa#

Mentor

Question regarding same security level ACLs

Hi,

If the PC and the Router are connected to same network they naturally dont use the ASA at all to communicate with eachother. They will communicate directly since they can see eachother.

I would imagine you could limit the Telnet connections on the actual router. If were talking about a Cisco router this should be pretty easy to do with an ACL attached to the "vty 0 4" configurations. If its some other type of router then naturally I dont know if it has that kind of setting but I would imagine it should have.

- Jouni

Mentor

Question regarding same security level ACLs

Also,

Since we are talking about an ASA5505,

Check this configuration command for the ASA5505 Switch Ports

http://www.cisco.com/en/US/docs/security/asa/asa84/command/reference/s8.html#wp1567386

If lets you isolate hosts on the same Vlan to my understanding.

- Jouni

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here