I have two ASA 5512-Xs running 9.8.(2) in multi-context mode. I have Untrusted customers reaching the internet via our core and am using crypto-maps to isolate whatever traffic they send as it passes though our core. I set up a quick model to test this -
OUTSIDE INSIDE OUTSIDE
10.10.10.0 -----[ASA1 >--tunnel-->]---172.16.1.0/30---[<--tunnel--< ASA2]----- 20.20.20.0
When I telnet from 10.10.10.1 to 20.20.20.1 though the ASA's , it fails. With all SA's cleared, the telnet session is matched as interesting, triggers IKE and IPSec SA's are fully established.
On ASA 1 for example -
interface: INSIDE
Crypto map tag: TUNNEL, seq num: 1, local addr: 172.16.1.1
access-list INSIDE-OUT extended permit ip 10.10.10.0 255.255.255.0 20.20.20.0 255.255.255.0
local ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (20.20.20.0/255.255.255.0/0/0)
current_peer: 172.16.1.2
Packet tracer
Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 172.16.1.2 using egress ifc INSIDE
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group TEMP!! in interface OUTSIDE
access-list TEMP!! extended permit ip any any
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fe8cb26f3a0, priority=13, domain=permit, deny=false
hits=8, user_data=0x7fe8d6a5b200, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=DMZ-VPN-INSIDE, output_ifc=any
Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fe8cac346a0, priority=0, domain=nat-per-session, deny=false
hits=804, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=any
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fe8cb23bf50, priority=0, domain=inspect-ip-options, deny=true
hits=74, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=DMZ-VPN-INSIDE, output_ifc=any
Phase: 5
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x7fe8cb89a040, priority=70, domain=encrypt, deny=false
hits=9, user_data=0x6c6474, cs_id=0x7fe8cb2a8070, reverse, flags=0x0, protocol=0
src ip/id=20.20.20.0, mask=255.255.255.0, port=0, tag=any
dst ip/id=10.10.10.0, mask=255.255.255.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=INSIDE
Phase: 6
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group INSIDE-OUT out interface INSIDE
access-list INSIDE-OUT extended deny ip any any log
Additional Information:
Forward Flow based lookup yields rule:
out id=0x7fe8cb2cdd70, priority=13, domain=permit, deny=true
hits=7, user_data=0x7fe8d6a5bd40, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=INSIDE
Result:
input-interface: OUTSIDE
input-status: up
input-line-status: up
output-interface: INSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
The packet 10.10.10.1->20.20.20.1 is being allowed at the VPN encryption Phase5, BUT it gets dropped at the outbound ACL -
%ASA-6-106100: access-list INSIDE-OUT denied tcp OUTSIDE/10.10.10.1(20851) -> INSIDE/20.20.20.1(23) hit-cnt 1 first hit [0x1780340d, 0x00000000]
If I add an acl stanza to allow my _inside_ addressing (that should be hidden by the tunnel) out the INSIDE interface -
access-list INSIDE-OUT extended permit ip 10.10.10.0 255.255.255.0 20.20.20.0 255.255.255.0
Phase 6 becomes -
Phase: 6
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group INSIDE-OUT out interface INSIDE
access-list INSIDE-OUT extended permit ip 10.10.10.0 255.255.255.0 20.20.20.0 255.255.255.0
Additional Information:
Forward Flow based lookup yields rule:
out id=0x7f37dabfa400, priority=13, domain=permit, deny=false
hits=4, user_data=0x7f37e8e6ed00, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=10.10.10.0, mask=255.255.255.0, port=0, tag=any
dst ip/id=20.20.20.0, mask=255.255.255.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=INSIDE
However, the packet as sniffed exiting the INSIDE interface is indeed tunnelled with addressing 172.16.1.1-->172.16.1.2
Ergo, the inside IP packet is being tunnel-encrypted but the subsequent outbound acl check is being done on the PRE-encryption addressing and being dropped.
I'm about to drop everything back to 9.6 unless anyone has any ideas why the ASA should be doing this.
