1

We have a Cisco 1921 router running IOS 15.1 at one of our branches which is connected via a L2L IPsec VPN to a ASA5510 running ASA 7.2 at our headquarters. The ASA also provides IPSec Remote Access VPN to field based users using the Cisco VPN Client.

The network looks something like this:

192.168.14.0/24 - RT - Internet - ASA - 192.168.10.0/24
                   |----L2L VPN----||
                                    |----RA VPN---- 192.168.10.223-192.168.10.242

(the remote access VPN uses addresses within the 192.168.10.0/24 network)

The problem is that while the RA VPN users can access the 192.168.10.0/24 (and other connected L2L VPNs) just fine, they cannot access the 192.168.14.0/24 network.

Here are some interesting parts of the ASA config:

interface Ethernet0/0
 nameif outside
 security-level 0
 ip address EXTERNAL_IP 255.255.255.240 
!
interface Ethernet0/3
 nameif inside
 security-level 100
 ip address 192.168.10.252 255.255.255.0 
!

same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

access-list acl_in extended permit ip 192.168.8.0 255.255.248.0 192.168.8.0 255.255.248.0 
access-list acl_out extended permit ip 192.168.8.0 255.255.248.0 192.168.8.0 255.255.248.0 
access-list acl_nonat-inside extended permit ip 192.168.8.0 255.255.248.0 192.168.8.0 255.255.248.0 
access-list vpngrint_splitTunnelAcl standard permit 192.168.10.0 255.255.255.0 
access-list vpngrint_splitTunnelAcl standard permit 192.168.14.0 255.255.255.0 
access-list acl_vpn-berlin extended permit ip 192.168.14.0 255.255.255.0 192.168.8.0 255.255.248.0 
access-list acl_vpn-berlin extended permit ip 192.168.8.0 255.255.248.0 192.168.14.0 255.255.255.0 

ip local pool poolvpnclients 192.168.10.223-192.168.10.242
ip verify reverse-path interface outside
ip verify reverse-path interface web
ip verify reverse-path interface inside

nat-control
global (outside) 1 EXTERNAL_IP
nat (inside) 0 access-list acl_nonat-inside
nat (inside) 1 192.168.10.0 255.255.255.0

access-group acl_out in interface outside
access-group acl_in in interface inside

crypto dynamic-map outside_dyn_map 20 set pfs 
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-SHA
crypto map outside_map 200 match address acl_vpn-berlin
crypto map outside_map 200 set peer IOS_ROUTER_EXTERNAL_IP 
crypto map outside_map 200 set transform-set ESP-AES-SHA
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map interface outside

group-policy vpngrint internal
group-policy vpngrint attributes
 wins-server value 192.168.10.5
 dns-server value 192.168.10.5
 vpn-simultaneous-logins 2147483647
 vpn-idle-timeout 7200
 vpn-tunnel-protocol IPSec 
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value vpngrint_splitTunnelAcl
 default-domain value domain.local
 split-dns value domain.local domain.com

tunnel-group vpngrint type ipsec-ra
tunnel-group vpngrint general-attributes
 address-pool poolvpnclients
 default-group-policy vpngrint
tunnel-group vpngrint ipsec-attributes
 pre-shared-key SECRET
tunnel-group IOS_ROUTER_EXTERNAL_IP type ipsec-l2l
tunnel-group IOS_ROUTER_EXTERNAL_IP ipsec-attributes
 pre-shared-key SECRET

The split tunnel ACL is matching, the 192.168.14.0 shows up in the client's routing table and outgoing packets can be captured on the client's VPN interface. They also show up in one of captures I set up on the ASA but they do not reach the L2L VPN connected router. The nonat ACL should be matching as well as the access-lists bound to the interfaces and the interesting traffic definition for the L2L VPN (which is also identical on both sides of the tunnel), so I don't see where the problem could be at the moment.

asa# sh capture
capture frzberlin type raw-data access-list capture_frzberlin interface outside [Capturing - 280 bytes]
capture frzberlin_inside type raw-data access-list capture_frzberlin interface inside [Capturing - 0 bytes]
asa# sh capture frzberlin

4 packets captured
   1: 17:46:41.563508 192.168.10.239.58452 > 192.168.14.1.22: R 1017791382:1017791382(0) ack 2592136529 win 65535
   2: 17:46:44.853334 192.168.10.239.58455 > 192.168.14.1.22: R 668258002:668258002(0) ack 1048856085 win 65535
   3: 17:46:47.602889 192.168.10.239.58458 > 192.168.14.1.22: R 2479281909:2479281909(0) ack 2603933177 win 65535
   4: 17:47:42.913877 192.168.10.239.58490 > 192.168.14.1.22: R 1494613342:1494613342(0) ack 344737469 win 65535
4 packets shown

Any ideas on debugging this would be very much appreciated.

Edit: Added packet-tracer output:

asa# packet-tracer input outside tcp 192.168.10.238 1337 192.168.14.1 22 detailed

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x481b320, priority=12, domain=capture, deny=false
        hits=12333239, user_data=0x49a4ba8, cs_id=0x0, l3_type=0x0
        src mac=0000.0000.0000, mask=0000.0000.0000
        dst mac=0000.0000.0000, mask=0000.0000.0000

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x3d81c88, priority=1, domain=permit, deny=false
        hits=4437186449, 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

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 4
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 5
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   192.168.10.238  255.255.255.255 outside

Phase: 6
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group acl_out in interface outside
access-list acl_out extended permit ip 192.168.8.0 255.255.248.0 192.168.8.0 255.255.248.0
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x401f738, priority=12, domain=permit, deny=false
        hits=9263075, user_data=0x401f6f8, cs_id=0x0, flags=0x0, protocol=0
        src ip=192.168.8.0, mask=255.255.248.0, port=0
        dst ip=192.168.8.0, mask=255.255.248.0, port=0, dscp=0x0

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x3d84930, priority=0, domain=permit-ip-option, deny=true
        hits=115197791, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 8
Type: CP-PUNT
Subtype:
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x4e53c10, priority=79, domain=punt, deny=true
        hits=8524, user_data=0x3a2e750, cs_id=0x0, flags=0x0, protocol=0
        src ip=192.168.10.238, mask=255.255.255.255, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 9
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x3e43da8, priority=69, domain=ipsec-tunnel-flow, deny=false
        hits=396, user_data=0x265722ac, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=192.168.10.238, mask=255.255.255.255, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 10
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0x4a2f450, priority=70, domain=encrypt, deny=false
        hits=1499, user_data=0x252bccdc, cs_id=0x4729788, reverse, flags=0x0, protocol=0
        src ip=192.168.8.0, mask=255.255.248.0, port=0
        dst ip=192.168.14.0, mask=255.255.255.0, port=0, dscp=0x0

Phase: 11
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in  id=0x490a410, priority=69, domain=ipsec-tunnel-flow, deny=false
        hits=1547, user_data=0x252c08dc, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=192.168.14.0, mask=255.255.255.0, port=0
        dst ip=192.168.8.0, mask=255.255.248.0, port=0, dscp=0x0

Phase: 12
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in  id=0x3d84930, priority=0, domain=permit-ip-option, deny=true
        hits=115197792, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 13
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 out id=0x402da30, priority=70, domain=encrypt, deny=false
        hits=0, user_data=0x266af5ac, cs_id=0x4729788, reverse, flags=0x0, protocol=0
        src ip=192.168.14.0, mask=255.255.255.0, port=0
        dst ip=192.168.8.0, mask=255.255.248.0, port=0, dscp=0x0

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (ipsec-spoof) IPSEC Spoof detected
Mtz
  • 13
  • 1
  • 5
  • Can you check what a `packet-tracer` gets for this traffic? I suspect that the cause of this is that the nonat ACL is attached to the inside interface while the VPN traffic is coming from the outside interface. – Shane Madden Dec 11 '13 at 21:45
  • @ShaneMadden I have added the packet-tracer output but I'm not sure what kind of NAT configuration would be necessary for the outside interface. Currently only the above mentioned NAT configuration is in place. If you have any suggestions I would be happy to try them! – Mtz Dec 12 '13 at 11:16
  • That `packet-tracer` flow actually looks like it's working great.. anything relevant in the logs? – Shane Madden Dec 12 '13 at 18:15

0 Answers0