A while back I changed my internal interface ACLs so we must explictly permit traffic between internal networks but still retain access to the internet. I chose to use an object group containing the three RFC1918 ranges to define the private networks. This is ideal because we can use this same "template" across 150+ firewalls without having to customize for each firewall's internal subnets. Here is an example that gives the inside network full access to the internet and gives the dmz SQL access to an inside server and full access to the internet.
object-group network RFC1918
network-object 10.0.0.0 255.0.0.0
network-object 172.16.0.0 255.240.0.0
network-object 192.168.0.0 255.255.0.0
access-list inside_access_in extended deny ip any object-group RFC1918
access-list inside_access_in extended permit ip any any
access-list dmz_access_in extended permit tcp any host 192.168.1.10 eq 1433
access-list dmz_access_in extended deny ip any object-group RFC1918
access-list dmz_access_in extended permit ip any any
So, I'm now running into a problem with site-to-site VPNs. I had assumed that sysopt connection permit-vpn would ensure that VPN traffic would bypass ACLs. What I'm finding is that inbound traffic from the remote location seems to work okay, but when we try to initiate a connection from the inside or dmz, the traffic is blocked by the interface ACL: Here is a log entry when I ran a ping from a server in the dmz, 192.168.2.20 to a server on the remote side of the tunnel, 10.100.0.100.
Deny icmp src dmz:192.168.2.20 dst outside:10.100.0.100 (type 0, code 0) by access-group "dmz_access_in" [0x71a13b69,0x4deab30d]
Does ACL inspection occur before the firewall can match this traffic to a crypto map? I'd really hate to have to modify our interface ACLs everytime a site-to-site tunnel includes private IPs (most do).
