quick question about ipsec tunnel

Unanswered Question
Dec 7th, 2009
User Badges:

Hi All,


We have a working IPSEC tunnel to another Provider to encrypt everything going to 10.109.x.x - this works great!!


I've added another IP range 192.74.x.x to go via the same IPSEC tunnel but can not see the packets being encapsulated and encrypted? Basically I've just added this new range to the current ACL 101.


Should I be seeing packets encapsulated when destined for 192.74.x.x (which I'm not) or does the tunnel need to come up first??? I am seeing matches in the ACL though, just nothing being encapsulated/encrypted.


router#sh crypto ipsec sa

   local  ident (addr/mask/prot/port): (210.15.x.x/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.74.x.x/255.255.255.0/0/0)
   current_peer 203.41.142.x port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #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 582, #recv errors 0



crypto isakmp key KEY address 203.41.142.x

!
!
crypto ipsec transform-set STRONG esp-3des esp-md5-hmac
!
crypto map IPSEC_VPN 1 ipsec-isakmp
set peer 203.41.142.x
set transform-set STRONG
set pfs group2
match address 101

!

interface FastEthernet0/0.41
description IPSECGateway
encapsulation dot1Q 41
ip address 203.17.98.x 255.255.255.248
crypto map IPSEC_VPN

!

ip route 10.109.x.x 255.255.0.0 FastEthernet0/0.41
ip route 192.74.x.x 255.255.255.0 FastEthernet0/0.41

!

access-list 101 permit ip 210.15.x.x 0.0.0.255 10.109.x.x 0.0.255.255

access-list 101 permit ip 210.15.x.x 0.0.0.255 192.74.x.x 0.0.0.255


Thanks.


Andy

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
bmcginn Mon, 12/07/2009 - 14:59
User Badges:
  • Bronze, 100 points or more

Hi Andy,


The provider on the other side of the encryption tunnel will also need to add that range into their ACL.


It sets up the IPSEC SA using that and a few other settings (eg transform set, encryption, hash etc).  They all need to be the same on both sides.  If you have added an extra line to your ACL, then they will need to add a corresponding line to their ACL.


I hope that helps, and if it does could you please rate?


thanks


Brad

asaykao73 Mon, 12/07/2009 - 18:26
User Badges:

Hi Brad,


The Provider has replied that they have set everything up on their end to allow our host from 210.15.x.x to communicate with their host 192.74.x.x.


When I try to ping the provider's host, I am not seeing any packets being encapsulated/encrypted on my end. I am seeing the tunnel come up though.


router#sh crypto isakmp sa
dst             src             state          conn-id slot status
203.41.142.x    203.17.98.x     QM_IDLE              1    0 ACTIVE


router#sh crypto ipsec sa

   local  ident (addr/mask/prot/port): (210.15.x.x/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.74.x.x/255.255.255.0/0/0)
   current_peer 203.41.142.x port 500
     PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #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 51, #recv errors 0


     local crypto endpt.: 203.17.98.x, remote crypto endpt.: 203.41.142.x
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0.41


Any other ideas as to why packets are not being encap/encrpted. Like I said, the ACL count increases on the router, so the packets are hitting the ACL, but not sure why they aren't being encap/encrypted.


Thanks.


Andy

Praveena Shanubhogue Mon, 02/15/2010 - 19:56
User Badges:
  • Bronze, 100 points or more

hi Andy,


I am answering to your post after a long time. BUt still, if you are still facing issues with getting the tunnel up, hope this post helps:


1. . Could you please post the whole output of "show crypto ipsec sa detai". with that i will know if the outbound and inbound SAs are getting created or not.

As the packets are not getting encrypted at your end, i doubt if they are up.


2. Please check the PFS and Transform-set settings on your device and the peer device.


3. Run debugs on both the devices (if the other device is Cisco) as belwo:

debug crypto isakmp (if it is an ASA, run debug crypto isakmp 127)

debug crypto ipsec (if it is an ASA, run debug crypto ipsec 127)


And please analyze or post it here. that should give a fair idea of what is happening.


Regards,

Praveen

Actions

This Discussion