Cisco IOS IPSec Encryption Counter not increasing

Dave Ng · ‎06-02-2013

Hi all,

We have recently established an IPSec tunnel with one of our business partner. The IPSec tunnel was setup but we observed the traffic from our end to our business partner are not put in the tunnel.

#pkts encaps: 0, pkts decrypt: 20642, #pkts verify: 20642

The routing and access list for the "interesting traffic" are already defined correctly on the Cisco routers at both ends. Traffic send by our business are also decrypted on our router but we cannot figure why is our router not encrypting the outgoing traffic. All the application traffic are UDP traffic.

Our internal server that is communicating with the external is static NAT on the same Cisco router that is encrypting the traffic but I don't think that would cause a proxy. Following is an extract of the Cisco router configuration:

Appreciate if any expert out there can advise. We have tried many means including adding additional static route and amending the access-list to the specific host but all didn't work.

Im reposting this in this thread. To add on, the counters on the access list 101 is not increasing at all. Do we need to define the "real" ip address instead of the translated ip address in the ACL instead?

=========================================================================================

Router at our end

crypto iskmp policy

encr aes 256

authentication pre-share

group 2

!

crypto isakmp key xxxx addresss 2.2.2.2

crypto isakmp nat keepalive 20

!

crypto ipsec transform-set aes esp-aes 256 esp-sha-hmac

!

crypto map vpn local-address loopback10

!

crypto map vpn 10 ipsec-isakmp

set peer 2.2.2.2

set transform-set aes

match address 101

!

interface loopback10

ip address 10.10.10.10

!

interface GigabitEthernet0/0

description << external interface>>

ip address 3.3.3.2 255.255.255.252

ip nat outside

ip virtual-reassembly on

crypto map vpn

!

interface GigabitEthernet 0/1

description <<internal interface>>

ip address 192.168.1.2 255.255.255.0

ip nat inside

standby 100 ip 192.168.1.1

standby priority 120

standby 100 preempt

ip tcp adjust-mss 1380

!

ip nat inside source static 10.1.1.1 10.2.2.1

!

ip route 0.0.0.0 0.0.0.0 3.3.3.1

ip route 10.1.1.0 255.255.255.0 192.168.1.254 name internal_segment

ip route 172.2.2.0 255.255.255.0 3.3.3.1 name external_partner_segment

!

access-list 101 permit uo 10.2.2.0 0.0.0.255 172.2.2.0 0.0.0.255

!

===========================================

mfurnival · ‎06-03-2013

Dave, a packet will be checked for IPSEC before it is checked for NAT so your packet should be tunnelled and not NAT'ted to the outside address. Does the tunnel itself seem to be forming correctly?

Can you do a "show crypto isakmp" and "show crypto ipsec sa"?

Your ACL should be OK if your server has a 10.2.2.x address and the remote destination is 172.2.2.x.

Dave Ng · ‎06-03-2013

Thank for the response.

Actually we have defined a static 1-to-1 NAT to translate our internal server IP to a translated ip address on the router. The ACL defined for the interesting traffic is also based on the translated address instead of the real ip address. The server is using 10.1.1.x ip address.

Yes, the tunnel is up and running but the encryption counter is not increasing. The ACL counter is also not increasing even though we'v verified that the router receive the traffic from the internal server.

#sh crypto isakmp sa

IPv4 Crypto ISAKMP SA

dst src state conn-id status

10.10.10.1 2.2.2.2 QM_IDLE 20508 ACTIVE

# sh access-list

access-list 101 permit uo 10.2.2.0 0.0.0.255 172.2.2.0 0.0.0.255

#sh crypto ipsec sa peer 2.2.2.2

interface: GigabitEthernet0/0
Crypto map tag: vpn, local addr 10.10.10.1

   protected vrf: (none)
   local ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (172.2.2.0/255.255.255.0/0/0)
   current_peer 2.2.2.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 392, #pkts decrypt: 392, #pkts verify: 392
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 10.10.10.1, remote crypto endpt.: 2.2.2.2
     path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
     current outbound spi: 0x1423B685(337884805)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x90B0E26E(2427511406)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 10265, flow_id: ISM VPN:1265, sibling_flags 80000040, crypto map: vpn
        sa timing: remaining key lifetime (k/sec): (4200221/1114)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

inbound ah sas:

inbound pcp sas:

     outbound esp sas:
      spi: 0x1423B685(337884805)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 10266, flow_id: ISM VPN:1266, sibling_flags 80000040, crypto map: vpn
        sa timing: remaining key lifetime (k/sec): (4200238/1114)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

outbound ah sas:

outbound pcp sas:

mfurnival · ‎06-03-2013

"Actually we have defined a static 1-to-1 NAT to translate our internal server IP to a translated ip address on the router. The ACL defined for the interesting traffic is also based on the translated address instead of the real ip address. The server is using 10.1.1.x ip address."

Regarding this comment - I think this could be the source of the problem. The packet from your server will hit your router inside interface, its source address being its "real" address (no NAT has taken place). The router will check the ACL and decide whether it needs to tunnel this packet. If it matches this ACL it will get tunnelled (not NAT'ted). If it does not match this ACL it will get NAT'ted (not tunnelled).

Dave Ng · ‎06-03-2013

I don't think the NAT is cause of the problem. If I'm not mistaken, the ACL defined for the "interesting" traffic shld be based on the translated address instead of the real address.

I've other IPSec tunnel configured with the static 1-to-1 NAT on other Cisco router, they are working fine.

I just couldn't figure out what is causing the router not to encrypt this traffic... The only difference with this set up is that the application is using UDP traffic but that shouldn't affect the IPSec tunnel

mfurnival · ‎06-03-2013

Yes, I agree that you are probably right.

Does the server show up in "ip nat translations".

By the way is this a typo:

# sh access-list

access-list 101 permit uo 10.2.2.0 0.0.0.255 172.2.2.0 0.0.0.255

The uo bit?

Jan Rolny · ‎06-03-2013

Hello,

I think also, that access-list is wrong. Because Dave is talking about UDP traffic what should be permitted so probbably access-list should look like this:

access-list 101 permit udp 10.2.2.0 0.0.0.255 172.2.2.0 0.0.0.255

Best regards,

Jan

Dave Ng · ‎06-03-2013

Yes, it's a typo. It is" access-list 101 permit ip 10.2.2.0 0.0.0.255 172.2.2.0 0.0.0.255" which shld be suffice for both tcp and udp traffic.

Yes, the nat translation is working as i can verify the translation is correct by running "show ip at translation".

mfurnival · ‎06-03-2013

Dave,

This document may be useful to you:

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080094634.shtml

Dave Ng · ‎06-03-2013

Thank.

Actually this document is more applicable to our environment as we require the static NAT for our internal server when communicating with the external party. I'm just puzzle why didn't the router didn't encrypt the traffic even though the NAT address is already defined in the ACL as "interesting" traffic.

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800b07ed.shtml

Is there a bug with the current Cisco IOS firmware that we are using c2900-universalk9-mz.SPA.152-1.T3.bin?