06-14-2006 08:52 AM
Hello -
I am having difficulty passing traffic over a VPN tunnel to a remote office. This is newly engineered, but can't figure out what the problem can be. I am calling out to all you experts to hopefully provide some much needed help. Thanks in advance.
VPN Info:
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key {key} address x.x.x.x 255.255.255.0
!
!
crypto ipsec transform-set TRIBDDBATL esp-3des esp-md5-hmac
!
crypto map DDBATL 10 ipsec-isakmp
set peer x.x.x.x
set transform-set TRIBDDBATL
match address 100
!
DDB-ATL-Router#sh access-list 100
Extended IP access list 100
10 permit ip 192.168.3.0 0.0.0.255 172.20.0.0 0.0.255.255 (1008 matches)
20 permit ip 192.168.3.0 0.0.0.255 10.50.100.0 0.0.0.255 (13 matches)
30 permit ip 192.168.3.0 0.0.0.255 10.50.101.0 0.0.0.255 (15 matches)
40 permit ip 192.168.3.0 0.0.0.255 192.168.182.0 0.0.0.255
50 permit ip 192.168.3.0 0.0.0.255 172.90.0.0 0.0.255.255
60 permit ip 192.168.3.0 0.0.0.255 10.40.19.0 0.0.0.255
70 permit ip 192.168.3.0 0.0.0.255 172.38.0.0 0.0.255.255 (6 matches)
80 permit ip 192.168.3.0 0.0.0.255 10.255.4.0 0.0.0.255
90 permit ip 192.168.3.0 0.0.0.255 10.255.254.0 0.0.0.255
100 permit ip 192.168.3.0 0.0.0.255 10.253.35.0 0.0.0.255
DDB-ATL-Router#sh run int tun 1
Building configuration...
Current configuration : 169 bytes
!
interface Tunnel1
description VPN Tunnel 2 to DDB Chicago
ip unnumbered Loopback0
tunnel source Loopback0
tunnel destination x.x.x.x
crypto map DDBATL
end
SA info
DDB-ATL-Router#sh crypto isakmp sa
dst src state conn-id slot status
x.x.x.x x.x.x.x QM_IDLE 225 0 ACTIVE
DDB-ATL-Router#sh crypto ipsec sa det
interface: Tunnel1
Crypto map tag: DDBATL, local addr x.x.x.x
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.50.100.0/255.255.255.0/0/0)
current_peer x.x.x.x port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 1, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
From what I see, at this is at both ends, it looks like IKE has passed and the tunnel is up, both end are tx encrypted traffic, but the other end is not rxing. Any thoughts?
06-14-2006 10:09 AM
i could really use just a full sh run off your router and post it. and what inside ip's are these 2 network using
also do a
sh crypto isakmp sa
and
sh crypto ipsec sa
and post the output
06-14-2006 11:20 AM
06-15-2006 06:43 AM
Well, I have it working now, but why this makes it work is beyond me. I applied access-list to for ingress and egress traffic on my ethernet side to capture traffic. This didn't give me any indication what was going on, so to see real-time traffic, I enter log at the end of each statement. When there is an access-list with logging turned on per statement, only then do I have L7 connectivity. Does anyone know the explanation for this?
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: