vpn tunnel

mehdiidrissi · ‎06-03-2008

hi , i have a VPN tunnel up but is not passing data traffic, i have also voice traffic that is ok

voice seg: 192.168.2.X

DATA SEG : 192.168.1.X

thanks

access-list outside_cryptomap permit ip 192.168.2.0 255.255.255.0 192.168.20.0 255.255.255.0

local ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.168.20.0/255.255.255.0/0/0)

current_peer: 192.168.101.3

#pkts encaps: 512, #pkts encrypt: 512, #pkts digest: 512

#pkts decaps: 1081, #pkts decrypt: 1081, #pkts verify: 1081

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 512, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#send errors: 0, #recv errors: 0

local crypto endpt.: 192.168.11.3, remote crypto endpt.: 192.168.101.3

path mtu 1500, ipsec overhead 58, media mtu 1500

current outbound spi: AD04B746

inbound esp sas:

spi: 0x0209C6ED (34195181)

transform: esp-3des esp-sha-hmac none

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 1, crypto-map: outside_map1

sa timing: remaining key lifetime (kB/sec): (3824948/28200)

IV size: 8 bytes

replay detection support: Y

outbound esp sas:

spi: 0xAD04B746 (2902767430)

transform: esp-3des esp-sha-hmac none

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 1, crypto-map: outside_map1

sa timing: remaining key lifetime (kB/sec): (3824917/28200)

IV size: 8 bytes

replay detection support: Y

Crypto map tag: outside_map1, seq num: 20, local addr: 192.168.11.3

access-list outside_cryptomap permit ip any 192.168.10.0 255.255.255.0

local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (192.168.10.0/255.255.255.0/0/0)

current_peer: 192.168.101.3

#pkts encaps: 19, #pkts encrypt: 19, #pkts digest: 19

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 19, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#send errors: 0, #recv errors: 0

local crypto endpt.: 192.168.11.3, remote crypto endpt.: 192.168.101.3

michael.leblanc · ‎06-03-2008

The following output suggests to me that your crypto ACLs may not be "exactly" mirrored.

#pkts encaps: 19, #pkts encrypt: 19, #pkts digest: 19

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

Note: the asymmetry between encaps and decaps.

I would:

1. Look for asymmetrical ACLs.

2. Refrain from using the "any" keyword in crypto ACLs. Modify existing ACLs to specify the specific addresses needing crypto treatment.

Note: I have read many Cisco documents that caution against the use of the keyword "any" in crypto ACLs.

Presumably, you are using the following ACE to match "data" traffic from 192.168.1.X, and that the destination is 192.168.10.0, and not 192.168.20.0 (per the other ACE):

access-list outside_cryptomap permit ip any 192.168.10.0 255.255.255.0

Consider changing it to:

access-list outside_cryptomap permit ip 192.168.1.0 255.255.255.0 192.168.10.0 255.255.255.0

... and the far side ACE to:

access-list outside_cryptomap permit ip 192.168.10.0 255.255.255.0 192.168.1.0 255.255.255.0

The crypto ACLs on the tunnel endpoints must be "exact" mirrors of each other.

mehdiidrissi · ‎06-03-2008

hi,

i do it before , without issue

thanks

singhsaju · ‎06-05-2008

If you are seeing encrypts but no decrypts then its quite possible that there is routing issue at remote site.

Check routing at remote side for the traffic that is not passing.

singhsaju · ‎06-05-2008

check routing for 192.168.10.0 network at remote site . The route for 192.168.10.0 network should point back to the tunnel.

singhsaju · ‎06-05-2008

Sorry my mistake i mean't network 192.168.1.0 not 192.168.10.0.

mehdiidrissi · ‎06-06-2008

hi ,

thanks for your help , i find the orign of problem ,

i have a routing mistack in my Switch in the remote site (192.168.10.0 )does not point to the correct @ of PIx

Thanks