topic Re: ASA / Same-security interface filtering with ACLs in Network Security

ASA / Same-security interface filtering with ACLs

remitprosupport — Mon, 11 Mar 2019 19:02:31 GMT

Hello all,

I have an ASA 5505 which is trunked to a 2960 switch, which is then trunked to another 2960.

There are 4 vlans trunked to the switches on a physical interface and 4 more networks (including my "outside" and "dmz" interfaces) bound to 4 other physical interfaces on the ASA.

In order to avoid having to configure so many NAT rules for inter-vlan communication, I enabled "same-security permit inter-interface". Now all traffic is flowing freely between the networks regardless of the implicit denies I have in place by default on each of my interfaces.

I read on these forums that simply placing an allow or deny for any protocol on an ACL for the interface will cause unmatched packets to be dropped, but it's not working for me. For example, I have an interface named voip, and an interface named "infrastructure". For test purposes I have a windows node on each network that I can currently ping and telnet to on port 445. I put inbound restrictions on pind and tcp port 445, and I can still get to those hosts from others.

I need to be able to filter traffic (as with direct access vlans). Can anyone give me a hint on how to accomplish this?

Thanks,

Dan

Re: ASA / Same-security interface filtering with ACLs

Federico Coto Fajardo — Fri, 29 Oct 2010 22:19:20 GMT

Hi,

As you mentioned it should work.

Can you verify that the ACL is applied to the interface correctly (and in the right direction)?

Also by doing ''sh access-list'' you should see hitcounts in those entries.

If you use the packet tracer utility (from GUI or CLI) you can emulate a packet from one computer on one interface to another computer on another interface and the ASA will report if the traffic is being permitted/denied by the ACL.

Federico.

Re: ASA / Same-security interface filtering with ACLs

remitprosupport — Sun, 31 Oct 2010 05:19:01 GMT

Frederico,

Thanks for the reply. To test whether I'm doing this correctly, I created a service group on my firewall with all of the TCP/UDP ports necessary for Active Directory authentication (as I would need when this is in prod...). Then I created a rule allowing traffic using this service group from a vlan interface network named "soa" (192.168.150.0/24) to another named "infrastructure" (192.168.100.0/24).The only other rule in place is the implicit deny there by default.

I then used the packet tracer, specifying "soa" as the source interface, a source address on the "soa" network, and the destination address on "infrastructure". The destination port is TCP 139, which is in the service group I created. This passes through the firewall just fine. I then use packet tracer to fire off another test, using the same interface, source and destination IP, and this time TCP port 22, which is _not_ in the service group, and it also passes. If I'm understanding this correctly, shouldn't the test for port 22 have been blocked? I'm also baffled by the output of packet tracer for these tests. When I click on the link that shows which rule allowed the traffic, it points to the implicit deny rule in place on the source (soa) interface. Why would an implicit deny _allow_ traffic through the firewall?

I'm providing my firewall config below. Please let me know if there's any more information you need from me.

Many thanks in advance,

Dan

ASA Version 8.2(3)
!
hostname officefw1
enable password XXXX encrypted
passwd XXXX encrypted
names
dns-guard
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
switchport access vlan 50
!
interface Ethernet0/2
switchport trunk allowed vlan 100,125,150,200
switchport trunk native vlan 1
switchport mode trunk
!
interface Ethernet0/3
switchport access vlan 250
!
interface Ethernet0/4
switchport access vlan 251
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
interface Vlan1
shutdown
nameif inside
security-level 100
no ip address
!
interface Vlan2
nameif outside
security-level 0
ip address dhcp setroute
!
interface Vlan50
nameif dmz
security-level 10
ip address 192.158.50.1 255.255.255.0
!
interface Vlan100
nameif infrastructure
security-level 100
ip address 192.168.100.1 255.255.255.0
!
interface Vlan125
nameif voip
security-level 100
ip address 192.168.125.1 255.255.255.0
!
interface Vlan150
nameif soa
security-level 100
ip address 192.168.150.1 255.255.255.0
!
interface Vlan200
nameif itdev
security-level 100
ip address 192.168.200.1 255.255.255.0
!
interface Vlan250
nameif systems
security-level 100
ip address 192.168.250.1 255.255.255.0
!
interface Vlan251
nameif management
security-level 100
ip address 192.168.251.1 255.255.255.0
!
interface Vlan999
no nameif
no security-level
no ip address
!
boot system disk0:/asa823-k8.bin
ftp mode passive
dns domain-lookup management
dns domain-lookup systems
dns domain-lookup infrastructure
dns domain-lookup voip
dns domain-lookup soa
dns server-group DefaultDNS
name-server 68.105.28.12
name-server 68.105.29.11
same-security-traffic permit inter-interface
object-group service WindowsShares
description Ports necessary to access Windows network shares.
service-object tcp range 135 netbios-ssn
service-object tcp eq 445
service-object udp range 135 139
service-object udp eq 445
object-group service ActiveDirectoryAuth
description Ports necessary for Active Directory authentication.
service-object tcp eq 1025
service-object tcp eq 1026
service-object tcp eq 135
service-object tcp eq 445
service-object tcp eq domain
service-object tcp eq ldap
service-object tcp eq netbios-ssn
service-object udp eq 88
service-object udp eq domain
service-object udp eq netbios-dgm
service-object udp eq netbios-ns
object-group service NetworkPrinting
description Ports necessary for network printing.
service-object tcp eq 9100
object-group network SOA_DHCP_Pool_Members
network-object host 192.168.150.10
network-object host 192.168.150.11
network-object host 192.168.150.12
network-object host 192.168.150.13
network-object host 192.168.150.14
network-object host 192.168.150.15
network-object host 192.168.150.16
network-object host 192.168.150.17
network-object host 192.168.150.18
network-object host 192.168.150.19
network-object host 192.168.150.20
network-object host 192.168.150.21
network-object host 192.168.150.22
network-object host 192.168.150.23
network-object host 192.168.150.24
network-object host 192.168.150.25
network-object host 192.168.150.26
network-object host 192.168.150.27
network-object host 192.168.150.28
network-object host 192.168.150.29
network-object host 192.168.150.30
access-list infrastructure_access_in remark Allow SOA network to auth to AD domain.
access-list infrastructure_access_in extended permit object-group ActiveDirectoryAuth 192.168.150.0 255.255.255.0 192.168.100.0 255.255.255.0 log notifications
pager lines 24
logging enable
logging asdm informational
mtu inside 1500
mtu outside 1500
mtu management 1500
mtu systems 1500
mtu dmz 1500
mtu infrastructure 1500
mtu voip 1500
mtu soa 1500
mtu itdev 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-634-53.bin
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
access-group infrastructure_access_in in interface infrastructure
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
dynamic-access-policy-record DfltAccessPolicy
http server enable
http 192.168.251.0 255.255.255.0 management
http 192.168.250.0 255.255.255.0 systems
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 192.168.250.0 255.255.255.0 systems
telnet timeout 5
ssh 192.168.250.0 255.255.255.0 systems
ssh timeout 5
console timeout 0
management-access management
dhcpd auto_config outside
!
dhcpd address 192.168.125.10-192.168.125.30 voip
dhcpd dns 68.15.28.11 68.105.29.12 interface voip
!
dhcpd address 192.168.150.10-192.168.150.30 soa
dhcpd dns 68.105.28.12 68.105.29.11 interface soa
dhcpd enable soa
!

threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
ntp server 198.123.30.132 source outside prefer
webvpn
anyconnect-essentials
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
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
!
service-policy global_policy global
prompt hostname context
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome@cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily

Cryptochecksum:3960e4c529ccd86bddffb17268b7b370

Re: ASA / Same-security interface filtering with ACLs

Maykol Rojas — Sun, 31 Oct 2010 05:44:31 GMT

Hello,

The same security traffic will override any ACL that you have apply on the interfaces with the same security. If you take a look at the ASDM says "Permit traffic to flow between same security interfaces". No ACL can override this rule.

Hope it helps.

Mike

Re: ASA / Same-security interface filtering with ACLs

Maykol Rojas — Sun, 31 Oct 2010 05:48:43 GMT

Hello,

Also to back me up over here, you can find the information here

"•You can allow traffic to flow freely between all same security interfaces without access lists"

http://www.cisco.com/en/US/docs/security/asa/asa72/command/reference/s1_72.html#wp1289167

Since the same security traffic is checked prior an ACL, if this command is present, all the traffic will be allowed. If you want to do filtering, I would suggest you to take out the command and put the ACL's in all of the interfaces.

Cheers

Mike

Re: ASA / Same-security interface filtering with ACLs

Federico Coto Fajardo — Sun, 31 Oct 2010 15:38:19 GMT

I think that is incorrect.

The ASA will not allow communication between different interfaces with the same security level by default (this comes from the old days with PIXes).

The ASA now can allow communication between interfaces with the same security level by adding the command ''same-security-traffic permit inter-interface''

And you are correct, the above command allows communication without ACLs.

But what if I want to filter communication between interfaces with the same security level?

I need the command above and also ACLs restricting the traffic to flow.

So if you want to filter communication between interfaces with the same security interface you need:

same-security-traffic permit inter-interface

and also filter the traffic with ACLs.

Federico.

Re: ASA / Same-security interface filtering with ACLs

Maykol Rojas — Sun, 31 Oct 2010 16:01:52 GMT

Hello,

Federico is completely right, I doubt it for a second but nothing better than a lab recreation. The first ACL check is the one that corresponds to the same security traffic, I just thought it would bypass any access-group on the interface but it didnt.

pixfirewall(config)# packet-tracer input inside icmp 200.20.20.2 8 0 10.10.10.2

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 10.10.10.0 255.255.255.0 dmz

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group test in interface inside
access-list test extended deny icmp host 200.20.20.2 host 10.10.10.2
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: dmz
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

pixfirewall(config)#

So yes, please go ahead and double check the ACL and also try to do this packet tracer command and check your results.

Mike

Re: ASA / Same-security interface filtering with ACLs

remitprosupport — Sun, 31 Oct 2010 16:57:04 GMT

Federico and Mike,

After more experimentation I finally found a combination of commands that works. With same-security permit inter-interface enabled, initially I was able to access any vlan from any other vlan. When I tried adding ACL's nothing was still being blocked.

I finally found out that I was applying my ACL's to the wrong interface. I was applying them to the destination interface, when I needed to add them to the source interface. Once I added the ACL to the correct interface, I was able to connect to the hosts matched in the allow rules but denied by the explicit rule when it didn't.

Also, on any interface where I only need to authorize inbound traffic, I added another deny all for all IP traffic that that disabled any outbound traffic.

Thanks guys for all your input!

Dan

Re: ASA / Same-security interface filtering with ACLs

remitprosupport — Mon, 08 Nov 2010 14:57:55 GMT

One more thing I thought I'd share with the community, or at least users who are having trouble getting hosts on different networks to communicate through an ASA 5505.

After I had my ACL's worked out, communication between hosts on different interfaces worked fine. Then I added dynamic NAT entries on my ASA to allow hosts on three of the interfaces to get to the internet. I had to of course add rules to allow outbound DNS, HTTP, HTTPS, etc, by everything was working fine. Until I needed to communicate to a host on another interface.

As it turns out, even with nat-control disabled, if you enable ANY NAT on the firewall, you're then required to NAT _all_ traffic. To see if the dynamic NATs were at fault, I removed it from one interface and sure enough I could communicate to another interface. So to remedy the issue, I had to create pairs of static identity NATs for each pair if interfaces that needed to talk. The trick was not using the identity nat settings under the "dynamic" nat function under ASDM. Instead, I used the "static" nat function, specifying the source and source interface as, for example, my "soa" network, and the destination of the "soa" network, but using the destination interface, such as "infrastructure". I then had to do the same, in reverse, for the other interface.

Unfortunately, I don't have access to the firewalls at this time, but as soon as I do I'll post the correct config snippets.

Re: ASA / Same-security interface filtering with ACLs

ronald.wilson1 — Sat, 26 May 2018 19:57:30 GMT

"....The trick was not using the identity nat settings under the "dynamic" nat function under ASDM. Instead, I used the "static" nat function, specifying the source and source interface as, for example, my "soa" network, and the destination of the "soa" network, but using the destination interface, such as "infrastructure". I then had to do the same, in reverse, for the other interface....."
Does anyone have the correct configuration for this command using 8.4 and higher plaftform. I've used it before on the older 8.3 platform and it worked. Now I have 9.1 platform and can't seem to get it to working.

Re: ASA / Same-security interface filtering with ACLs

Florin Barhala — Wed, 30 May 2018 11:13:58 GMT

Just post your old config and we can make it to the after 8.3 NAT config 😉

Re: ASA / Same-security interface filtering with ACLs

ronald.wilson1 — Thu, 31 May 2018 19:47:20 GMT

Hi Florin,

Here is a snippet of the command I used. I'm away from the office today and if you need more just let me know. I'll return tomorrow and grab the config and post it.

static (inside3,inside1) 192.168.30.0 192.168.30.0 netmask 255.255.255.0

static (inside1,inside3) 192.168.10.0 192.168.10.0 netmask 255.255.255.0

Re: ASA / Same-security interface filtering with ACLs

Florin Barhala — Tue, 05 Jun 2018 09:16:58 GMT

Try this:

object network 192.168.30.0_obj
network 192.168.30.0 255.255.255.0

nat (inside1,inside3) source static 192.168.30.0_obj 192.168.30.0_obj