cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1691
Views
0
Helpful
1
Replies

L2L Tunnel gets built and passes traffic, then stops passing traffic in one direction

whitemike
Level 1
Level 1

Hello All,

I have created an L2L tunnel between my self and a 3rd party. I am using a Cisco ASA 5520 and the other end is using a Cisco 3005 VPN concentrator. The tunnel will get established and pass traffic both ways for a little while, it varies, sometimes 1 hour or last time we built it it was working for 17 hours, but at some point my ASA will stop transmitting but it will still be receiving packets. These errors start to show up when I look at the traffic going through my ASA interfaces:

713042       IKE Initiator unable to find policy: Intf Outside, Src: 192.168.xx.16, Dst: 10.1.xx.30

Then when I try to ping their hosts .30 and .27 I get:

713041          Group = 68.23.xx.xx, IP = 68.23.xx.xx, IKE Initiator: New Phase 2, Intf private, IKE Peer 68.23.xx.xx  local Proxy Address 192.168.xx.16, remote Proxy Address 10.1.xx.30,  Crypto map (Outside_map)

713041          Group = 68.23.xx.xx, IP = 68.23.xx.xx, IKE Initiator: New Phase 2, Intf private, IKE Peer 68.23.xx.xx  local Proxy Address 192.168.xx.16, remote Proxy Address 10.1.xx.27,  Crypto map (Outside_map)

713050          Group = 68.23.xx.xx, IP = 68.23.xx.xx, Connection terminated for peer 68.23.xx.xx.  Reason: Peer Terminate  Remote Proxy 10.1.xx.27, Local Proxy 192.168.xx.16

When I first configured this tunnel it was with 3DES and SHA for phase 1 & 2, but when the tunnel would come up  my phase 1 would negotiate to an MD5 hash, even though I specifically entered SHA, so me and the 3rd party decided to bring all the hashes for phase 1 & 2 down to MD5, and that was when it was up for the longest, but the problem still came back eventually. My ASA config posted below:

ASA Version 8.2(3)

name 192.168.xx.16 Server description  Server

name 10.1.xx.27 XYZ_01

name 10.1.xx.28 XYZ_02

name 10.1.xx.29 XYZ_03

name 10.1.xx.30 XYZ_04

interface Ethernet0/0

description Outside

speed 100

nameif Outside

security-level 0

ip address 71.4.xx.xx 255.255.255.224 

interface Ethernet0/2

description private

nameif private

security-level 100

ip address 192.168.xx.16 255.255.255.0 

object-group network XYZ_GRP

network-object host 10.1.xx.27

network-object host 10.1.xx.28

network-object host 10.1.xx.29

network-object host 10.1.xx.30

access-list private_nat0_outbound extended permit ip host 192.168.xx.16 object-group XYZ_GRP

access-list Outside_14_cryptomap extended permit ip host 192.168.xx.16 object-group XYZ_GRP

crypto map Outside_map 14 match address Outside_14_cryptomap

crypto map Outside_map 14 set peer 68.23.xx.xx

crypto map Outside_map 14 set transform-set ESP-3DES-MD5

group-policy XYZ internal

group-policy XYZ attributes

vpn-idle-timeout none

vpn-tunnel-protocol IPSec 

tunnel-group 68.23.xx.xx type ipsec-l2l

tunnel-group 68.23.xx.xx general-attributes

default-group-policy XYZ

tunnel-group 68.23.xx.xx ipsec-attributes

pre-shared-key *******

1 Reply 1

whitemike
Level 1
Level 1

This has been solved:

The 3rd party gave a list of 4 hosts to be used on their side so we entered the 4 hosts on our side, although when they did it on their side they used a CIDR /30 and turned 2 of their hosts into network and broadcast addresses. My belief is that they would send from one of those excluded addresses and my side would reply back thinking that it was a host, but their side would drop it thinking it was broadcast traffic.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: