Cisco ASA setting interfaces up and understanding security-level and access rules

Simple steps to set-up Cisco ASA interfaces:

interface GigabitEthernet0/0
 nameif link_to_asa
 security-level 100
 ip address 172.28.0.1 255.255.255.0
 no shutdown

interface GigabitEthernet0/1
 nameif link_to_region
 security-level 90
 ip address 172.16.43.26 255.255.255.0
 no shutdown

nameif shows alias for the interface, which can be used in access-group, access-list, nat commands.

security-level from HIGH level to the LOW level traffic and return traffic is permitted (no access-list needed but you can add if you want and acl is checked before the security-level), from LOW level to the HIGH level traffic is dropped. Return traffic is permitted for bidirectional connections (TCP / UDP - connections are tracked).
 In routed mode (ASA has routed and transparent mode) security-levels are implicit permitting or denying only IPv4 and IPv6 traffic (in transparent mode ARP, STP traffic controlled by security-levels). To control other types of traffic you need to set-up access-lists.

In Cisco ASA ICMP is treated as unidirectional connection so you need to permit ICMP in both directions. To allow ICMP to ASA interfaces itself use:
`icmp permit <IP or Net_IP/mask> <ICMP destination ASA interface name>`
i.e. : 

icmp permit 172.16.43.0 255.255.255.0 link_to_asa

By default ICMP ping is permitted to all ASA interfaces

Access-lists
Access-list can be per interface (must specify direction when applying -> `in` or `out`) and global.
Global acls based on source and destination IP addresses and not using interface names and disabling all security-level affects because of implicit deny at the end. But you still need `same-security-traffic permit inter-interface` to permit communication between different interfaces with the same security level and `same-security-traffic permit intra-interface` to permit communication between peers connected to the same interface.
If you'll apply both per-interface and global access-lists, then arriving packet first goes through interface acl, then through global acl and in the end to the implicit deny of the global acl (interface acl has no implicit deny rule).
Access-lists don't have implicit deny and we must take security-levels into consideration:
Traffic from the higher to the lower will be dropped only if ACL on this lower security-level interface denies traffic from higher security-level interface and vice-versa to allow traffic from lower to higher an ACL must be applied to the lower interface.
To allow VPN traffic regardless of access-lists use: sysopt connection permit-vpn
If you want to control VPN traffic with VPN filter use:
group-policy gp_test attributes
 vpn-filter value acl_vpn_filter


Access-groups
To apply an access-list use access-group command:
access-group acl_inside_in in interface inside
access-group acl_inside_out out interface inside
access-group acl_global global
 

 

PS Need to add acl and acl-group, global acl