cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1003
Views
0
Helpful
2
Replies

ASA 5506-x permit services between VLANs of differing security-level

paul_j_teeter
Level 1
Level 1

I thought I had this sorted out earlier today but...not so much. Deploying a Cisco ASA 5506-x as firewall/router.

 

Trying to accomplish some smarter VLAN'ing to segment traffic on my office/home network. Core switch is Cisco 3560cg. There's some other dumb, PoE switches and a Cisco 2960c further downstream.

 

I have 4 VLANs - 100 = 10.0.20.0/22, 101 = 192.168.20.0/23, 102 = 172.16.20.0/23. and 103 = 10.100.100.0/24. 100 is most secure on the ASA at level 100. 101 and 102 are at level 80. Lastly 103 is at 50. (VLAN 103 is mostly inconsequential b/c it bypasses my switched network.)

 

I'd like clients on VLANs 101 and 102 to rely on DNS servers that exist on VLAN 100.

 

I feel I've tried to accomplish this DNS ACL on the ASA via...

  • individual destination hosts

  • named interfaces

  • multiple services

  • just udp / port 53

  • object-group of source VLANs

  • object destination network

Etc. etc.

 

I'll post the whole ASA config as well but the pertinent config for this issue in the current semi-broken deployment is:

object-group service DNS
 description DNS over tcp & udp
service-object tcp-udp destination eq domain 
!
object-group network Lesser-VLANs
 description Network object group for VLANs 101 & 102
 network-object object HomeFamily
 network-object object Testing
!
object-group network VLAN100_DNS_Servers
 description iMac5k, iMac27 DNS Server group
 network-object host 10.0.20.80
 network-object host 10.0.20.19
!
access-list AllowDNStoVLAN100 extended permit object-group DNS object-group Lesser-VLANs object-group VLAN100_DNS_Servers
!
access-group AllowDNStoVLAN100 in interface insideHomeFamily
access-group AllowDNStoVLAN100 in interface insideTesting

Adding the access-group config instantly makes DNS lookups to 10.0.20.80 / 10.0.20.19 from a client on VLAN 101 or 102 succeed. But doing so renders that same client unable to send/receive HTTP/HTTPS traffic. Which is...umm...suboptimal.

Just looking for clues on how to make this work I hope.

 

The whole, sanitized ASA config is attached. I'm fairly adept at the ASA's VPN setup. But am feeling my way through the network, firewall, & router config. Feel free to make overall suggestions / ask questions / etc.

 

Thanks so much to anyone who cares to take a peek and comment. Appreciate the help.

1 Accepted Solution

Accepted Solutions

gbekmezi-DD
Level 5
Level 5
The access list has an implicit deny any any at the end. As soon as you put an access-group on an interface the security level becomes insignificant and you must explicitly allow traffic or add a permit any any there.

George

View solution in original post

2 Replies 2

gbekmezi-DD
Level 5
Level 5
The access list has an implicit deny any any at the end. As soon as you put an access-group on an interface the security level becomes insignificant and you must explicitly allow traffic or add a permit any any there.

George

My main misunderstanding is that 'access-list <name> extended' implies that additional ACL statements with the same <name> append to the overall ACL.

 

Sigh.

 

So...appending a 'permit ip any any' to the end of the ACL that is applied via an access-group to the interface in question allows outbound traffic from a client on the VLAN in question fixes the traffic flow problem.

 

Also, 'packet-tracer' is very helpful in debugging this issue.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: