Diego Balgera
asked on
Cisco VPN gateway doesn't decrypt packets
Hi,
I have a VPN setup problem with my Cisco IOS.
I set up the VPN and when I trigger the traffic to the other peer's VPN domain the VPN comes up smoothly and the IKE and IPSec security assotiation are generated.
I start generating traffic (i.e. ping) to an host at the other side of the VPN: I can see the traffic reaching the other host and the replies are sent back to me in the VPN. The problem consists in the fact that the traffic is not decrypted and do not reach my originating host. The same happens if the traffic is originated by the other host, the traffic doesn't arrive to me.
This is confirmed by "show crypto ipsec sa": see below, 155 packets encrypted, 0 packet decrypted, and the other side is correctly decrypting from me and encrypting packet to me (that I cannot see on my side).
Can you please suggest where I'm wrong?
Thank you very much in advance!
Diego.
-------------------------- ---------- ---
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.141.0/255.255.255 .0/0/0)
remote ident (addr/mask/prot/port): (10.163.74.0/255.255.255.0 /0/0)
current_peer <other peer address> port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 155, #pkts encrypt: 155, #pkts digest: 155
#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
#send errors 1, #recv errors 0
local crypto endpt.: <my peer address>, remote crypto endpt.: <other peer address>
path mtu 1500, ip mtu 1500, ip mtu idb Dialer0
current outbound spi: 0x1000C3E9(268485609)
inbound esp sas:
spi: 0x64EE8D8E(1693355406)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: C83X_MBRD:1, crypto map: mymap
sa timing: remaining key lifetime (k/sec): (4447862/85545)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound esp sas:
spi: 0x1000C3E9(268485609)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 2002, flow_id: C83X_MBRD:2, crypto map: mymap
sa timing: remaining key lifetime (k/sec): (4447845/85545)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
-------------------------- ---------- -
I have a VPN setup problem with my Cisco IOS.
I set up the VPN and when I trigger the traffic to the other peer's VPN domain the VPN comes up smoothly and the IKE and IPSec security assotiation are generated.
I start generating traffic (i.e. ping) to an host at the other side of the VPN: I can see the traffic reaching the other host and the replies are sent back to me in the VPN. The problem consists in the fact that the traffic is not decrypted and do not reach my originating host. The same happens if the traffic is originated by the other host, the traffic doesn't arrive to me.
This is confirmed by "show crypto ipsec sa": see below, 155 packets encrypted, 0 packet decrypted, and the other side is correctly decrypting from me and encrypting packet to me (that I cannot see on my side).
Can you please suggest where I'm wrong?
Thank you very much in advance!
Diego.
--------------------------
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.141.0/255.255.255
remote ident (addr/mask/prot/port): (10.163.74.0/255.255.255.0
current_peer <other peer address> port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 155, #pkts encrypt: 155, #pkts digest: 155
#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
#send errors 1, #recv errors 0
local crypto endpt.: <my peer address>, remote crypto endpt.: <other peer address>
path mtu 1500, ip mtu 1500, ip mtu idb Dialer0
current outbound spi: 0x1000C3E9(268485609)
inbound esp sas:
spi: 0x64EE8D8E(1693355406)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: C83X_MBRD:1, crypto map: mymap
sa timing: remaining key lifetime (k/sec): (4447862/85545)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound esp sas:
spi: 0x1000C3E9(268485609)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 2002, flow_id: C83X_MBRD:2, crypto map: mymap
sa timing: remaining key lifetime (k/sec): (4447845/85545)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
--------------------------
Have you verified that the crypto ACL's on both sides match, but with source/destination addresses reversed? I would look at that first thing. Also, is the NAT exemption of that traffic set up? It should be exempt from the NAT process unless you have overlapping networks between network segments on either side of the tunnel.
ASKER
Hi batry_boy,
yes, I did both.
> Have you verified that the crypto ACL's on both sides match
Yes, VPN encryption domains are set up correctly on both sides. On my side it is defined by access list 111
> is the NAT exemption of that traffic set up
Yes, it is set up. On my side it is defined by route map "internetonly" that makes uses of the access list 120, defining that the traffic going to be encapsulated in the VPN have not to be natted.
I'm attaching a summary of the configuration regarding the VPN part. As you can read, the VPN domain at my side is 192.168.141.0/24 and the other side is 10.163.74.0/24.
The problem is on my side, as the other side is correctly encrypting and decrypting traffic from / to ESP.
Thank you again! Diego.
-------------------------- ---------- --
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
lifetime 3600
crypto isakmp key <presharedkey> address <remote peer>
!
crypto ipsec transform-set ca-mi-transformset esp-3des esp-md5-hmac
no crypto ipsec nat-transparency udp-encaps
!
crypto map mymap 1 ipsec-isakmp
set peer <remote peer>
set security-association lifetime seconds 86400
set transform-set ca-mi-transformset
match address 111
!
interface Ethernet0
ip address 192.168.141.1 255.255.255.0
ip nat inside
!
interface Dialer0
ip address negotiated
ip nat outside
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname <pppusername>
ppp chap password 0 <ppppassword>
crypto map mymap
!
ip route 0.0.0.0 0.0.0.0 Dialer0
!
ip nat inside source route-map internetonly interface Dialer0 overload
!
access-list 111 permit ip 192.168.141.0 0.0.0.255 10.163.74.0 0.0.0.255
access-list 120 deny ip 192.168.141.0 0.0.0.255 10.163.74.0 0.0.0.255
access-list 120 permit ip 192.168.141.0 0.0.0.255 any
dialer-list 1 protocol ip permit
!
route-map internetonly permit 10
match ip address 120
!
-------------------------- ---------- --
yes, I did both.
> Have you verified that the crypto ACL's on both sides match
Yes, VPN encryption domains are set up correctly on both sides. On my side it is defined by access list 111
> is the NAT exemption of that traffic set up
Yes, it is set up. On my side it is defined by route map "internetonly" that makes uses of the access list 120, defining that the traffic going to be encapsulated in the VPN have not to be natted.
I'm attaching a summary of the configuration regarding the VPN part. As you can read, the VPN domain at my side is 192.168.141.0/24 and the other side is 10.163.74.0/24.
The problem is on my side, as the other side is correctly encrypting and decrypting traffic from / to ESP.
Thank you again! Diego.
--------------------------
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
lifetime 3600
crypto isakmp key <presharedkey> address <remote peer>
!
crypto ipsec transform-set ca-mi-transformset esp-3des esp-md5-hmac
no crypto ipsec nat-transparency udp-encaps
!
crypto map mymap 1 ipsec-isakmp
set peer <remote peer>
set security-association lifetime seconds 86400
set transform-set ca-mi-transformset
match address 111
!
interface Ethernet0
ip address 192.168.141.1 255.255.255.0
ip nat inside
!
interface Dialer0
ip address negotiated
ip nat outside
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname <pppusername>
ppp chap password 0 <ppppassword>
crypto map mymap
!
ip route 0.0.0.0 0.0.0.0 Dialer0
!
ip nat inside source route-map internetonly interface Dialer0 overload
!
access-list 111 permit ip 192.168.141.0 0.0.0.255 10.163.74.0 0.0.0.255
access-list 120 deny ip 192.168.141.0 0.0.0.255 10.163.74.0 0.0.0.255
access-list 120 permit ip 192.168.141.0 0.0.0.255 any
dialer-list 1 protocol ip permit
!
route-map internetonly permit 10
match ip address 120
!
--------------------------
ASKER
Hi,
unfortunately we arrived to a dead point, I tried again and again, apparently everything is correct but the VPN refuses to work. The suggestion by batry_boy is valuable, but I applied it already prior to writing this post, with no success.
Do you have any idea of the reason of my problem? If not, I would like to thank you anyway, then I'm going to ask to delete the question.
Diego.
unfortunately we arrived to a dead point, I tried again and again, apparently everything is correct but the VPN refuses to work. The suggestion by batry_boy is valuable, but I applied it already prior to writing this post, with no success.
Do you have any idea of the reason of my problem? If not, I would like to thank you anyway, then I'm going to ask to delete the question.
Diego.
Would it be possible to see the other side VPN device's configuration?
ASKER
Hi,
> Would it be possible to see the other side VPN device's configuration?
yes, it is. But it is identical, just with the peers and VPN encryption domain swapped. That's the reason why I haven't posted it, it doesn't add any value to the discussion. Anyway, I'm going to fetch it and post this as well.
Thank you again!
Diego.
> Would it be possible to see the other side VPN device's configuration?
yes, it is. But it is identical, just with the peers and VPN encryption domain swapped. That's the reason why I haven't posted it, it doesn't add any value to the discussion. Anyway, I'm going to fetch it and post this as well.
Thank you again!
Diego.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Great...glad you got it resolved...thanks for the points!
Closed, 500 points refunded.
Vee_Mod
Community Support Moderator
Vee_Mod
Community Support Moderator