VPN/IPSEC Access List

[galaga]

Hello,

We have an ASA 5510 running Version 9.1(7)9 

I have an IPSEC tunnel configured to a remote site, the tunnel is working

Having an issue with the remote site contacting internal server

With the access list on the cryptomap I get 

Nat statement is:

nat (INSIDE,OUTSIDE) source static A1&A2 A1&A2 destination static cc no-proxy-arp route-lookup

I packet trace to

packet input outside tcp 10.12.1.55 1521 192.168.6.5 1521

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

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.71.0 255.255.255.0 INSIDE

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

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

I add an access list to the outside interface I get

access-list OUTSIDE_access_in extended permit tcp object-group cc object-group local

packet input outside tcp 10.12.1.55 1521 192.168.6.5 1521 det

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xae13d3a8, priority=1, domain=permit, deny=false
hits=13866281776, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=OUTSIDE, output_ifc=any

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.71.0 255.255.255.0 INSIDE

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUTSIDE_access_in in interface OUTSIDE
access-list OUTSIDE_access_in extended permit tcp object-group cc ob ject-group local
object-group network cc
network-object host 10.12.1.55
object-group network local
network-object host 192.168.9.100
network-object host 192.168.9.110
network-object host 192.168.9.120
network-object host 192.168.9.130
network-object host 192.168.6.5
network-object host 192.168.6.5
Additional Information:
Forward Flow based lookup yields rule:
in id=0xb430ad48, priority=13, domain=permit, deny=false
hits=0, user_data=0xab6b2e80, cs_id=0x0, use_real_addr, flags=0x0, proto col=6
src ip/id=10.102.1.55, mask=255.255.255.255, port=0, tag=0
dst ip/id=192.168.71.200, mask=255.255.255.255, port=0, tag=0, dscp=0x0
input_ifc=OUTSIDE, output_ifc=any

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xa9677e68, priority=1, domain=nat-per-session, deny=true
hits=72520700, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0 x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=any, output_ifc=any

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xae143378, priority=0, domain=inspect-ip-options, deny=true
hits=62445699, 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=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=OUTSIDE, output_ifc=any

Phase: 6
Type: VPN
Subtype: ipsec-tunnel-flow
Result: DROP
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xafe1b7f8, priority=70, domain=ipsec-tunnel-flow, deny=false
hits=1, user_data=0x0, cs_id=0xaf0a8f28, reverse, flags=0x0, protocol=0
src ip/id=10.12.1.55, mask=255.255.255.255, port=0, tag=0
dst ip/id=192.168.6.5, mask=255.255.255.255, port=0, tag=0, dscp=0x0
input_ifc=OUTSIDE, output_ifc=any

[GioGonza · Accepted solution]

Hello @galaga, 

I would say the packet-tracert from the outside is not accurate for troubleshooting purposes since it will be dropped and you need to apply further ACL on the outside since this simulated packet is not really flowing through the VPN tunnel. 

I would say you need to verify if you receiving the traffic from them with the command "show crypto ipsec sa peer x.x.x.x", you need to look for the decaps. If you see them follow with the packet-tracer but this time from the inside (looking for the response from your server) in order to see if everything is fine and if this doesn´t say anything to us. 

Let´s place a capture on the ASA to see where the traffic is going and if the ASA is dropping the packets, that´s what I would recommend. 

HTH

Gio

[Pawan Raut]

I assume you have crypto map applied on outside interface and VPN created with outside interface IP address then in this case you are not required to apply the ACL on outside direction. And could not check the packet tracer for incoming traffic though VPN. Better check the you are getting encrypt/decrypt packet on IPsec sa? Check the the VPN acl applied in crypto map?