08-05-2011 07:52 AM
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 *******
08-17-2011 08:24 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide