Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

PFS shown as disabled in 'show crypto ipsec sa' even tough configured

Hi,

I have PFS configured (at least I think) but when I do a 'show crypto ipsec sa', it says 'PFS: N' ...

interface: Tunnel0

    Crypto map tag: Tunnel0-head-0, local addr 1.1.1.1

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/47/0)

   remote ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)

   current_peer 2.2.2.2 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 163, #pkts encrypt: 163, #pkts digest: 163

    #pkts decaps: 340, #pkts decrypt: 340, #pkts verify: 340

    #pkts compressed: 5, #pkts decompressed: 8

    #pkts not compressed: 157, #pkts compr. failed: 1

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 0, #recv errors 0

     local crypto endpt.: 1.1.1.1, remote crypto endpt.: 2.2.2.2

     path mtu 1500, ip mtu 1500, ip mtu idb Port-channel1.10

     current outbound spi: 0x2093BFD5(546553813)

     PFS (Y/N): N, DH group: none

Here's the relevant config:

crypto isakmp policy 10

encr aes 256

hash sha256

authentication pre-share

group 20

lifetime 3600

crypto ipsec transform-set vpn-s2s-ts esp-aes 256 esp-sha256-hmac comp-lzs

mode transport require

crypto ipsec profile vpn-s2s

set transform-set vpn-s2s-ts

set pfs group20

interface Tunnel0

  tunnel protection ipsec profile vpn-s2s

A 'show crypto map' shows it enabled AFAICT:

Crypto Map IPv4 "Tunnel0-head-0" 65537 ipsec-isakmp

    Map is a PROFILE INSTANCE.

    Peer = 2.2.2.2

    Extended IP access list

        access-list  permit gre host 1.1.1.1 host 2.2.2.2

    Current peer: 2.2.2.2

    Security association lifetime: 4608000 kilobytes/3600 seconds

    Responder-Only (Y/N): N

    PFS (Y/N): Y

    DH group:  group20

    Transform sets={

        vpn-s2s-ts:  { esp-256-aes esp-sha256-hmac  } , { comp-lzs  } ,

    }

    Interfaces using crypto map Tunnel0-head-0:

        Tunnel0

Any idea ?

Cheers,

     Sylvain

6 REPLIES

Re: PFS shown as disabled in 'show crypto ipsec sa' even tough c

Interesting.

Any special reason for using DH group 20 ? does same situation comes if DH 2 or 5 in use?

I would say even using Group 20 - crypto key generate ec keysize 384 < Keysize should be 384 .

Thanks

Ajay

New Member

Re: PFS shown as disabled in 'show crypto ipsec sa' even tough c

No reason ... I just like Elliptic Curves

Same issue with DH2 or 5.

I tried the crypto generate key but no changes. And AFAIK, you don't need a fixed key for a Diffie Hellman key exchange so that shouldn't be needed.

Something even weirder is that the other side of the ip sec tunnel now seems to show PFS: Y  !?! ...

Re: PFS shown as disabled in 'show crypto ipsec sa' even tough c

Ok Can you post both end configuration I will test ?

New Member

Re: PFS shown as disabled in 'show crypto ipsec sa' even tough c

I can't post the complete config (way too long), but the crypto part is pretty much limited to what I originally posted on both end.

The end displaying "PFS: N" was a 1921 running 15.2(1)T and

the end displaying "PFS: Y" is a 1812 running 15.1(4)M3

I now have updated the 1921 to 15.2(2)T and it works without changing the config ...

New Member

Hi,I have the same problem

Hi,

I have the same problem with an ASR1001, running asr1001-universalk9.03.10.03.S.153-3.S3-ext.bin.

Im am using IKEv2 and IPSec with PFS group20. Here's the relevant config (lab):

crypto ikev2 proposal ikev2-prop_1
 encryption aes-cbc-256
 integrity sha512
 group 20

crypto ikev2 policy ikev2-pol_1
 match address local 10.10.0.1
 proposal ikev2-prop_1

crypto ikev2 profile ikev2-prof_1
 match address local interface GigabitEthernet0/0/1
 match identity remote address 10.10.0.2 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local keyring_1
 dpd 10 3 on-demand

crypto ipsec profile ipsec-prof_1
 set transform-set tset_1
 set pfs group20
 set ikev2-profile ikev2-prof_1

interface Tunnel1
 ip address 10.20.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0/1
 tunnel destination 10.10.0.2
 tunnel protection ipsec profile ipsec-prof_1

As soon as the IPSec SA is established, the "show crypto ipsec sa" command shows:

PFS (Y/N): N, DH group: none

But after the first rekeying (after default time of 3600 secs) it shows:

PFS (Y/N): Y, DH group: group20

I consider this a cosmetical problem only, since PFS is doing its job. This can be told from the debugs during the first rekeying:

000492: Jul  2 11:20:41.790 CEST: IKEv2:(SESSION ID = 210,SA ID = 2):Checking for PFS configuration
000493: Jul  2 11:20:41.790 CEST: IKEv2:(SESSION ID = 210,SA ID = 2):PFS configured, DH group 20
000494: Jul  2 11:20:41.790 CEST: IKEv2:(SESSION ID = 210,SA ID = 2):[IKEv2 -> Crypto Engine] Computing DH secret key, DH Group 20
000495: Jul  2 11:20:41.798 CEST: IKEv2:(SA ID = 2):[Crypto Engine -> IKEv2] DH key Computation PASSED
000496: Jul  2 11:20:41.798 CEST: IKEv2:(SESSION ID = 210,SA ID = 2):Request queued for computation of DH secret
000497: Jul  2 11:20:41.798 CEST: IKEv2:(SESSION ID = 210,SA ID = 2):Checking if IKE SA rekey
000498: Jul  2 11:20:41.798 CEST: IKEv2:(SESSION ID = 210,SA ID = 2):Load IPSEC key material
000499: Jul  2 11:20:41.798 CEST: IKEv2:(SA ID = 2):[IKEv2 -> IPsec] Create IPsec SA into IPsec database

 

 

 

Bronze

A few more details on this

A few more details on this time-wasting cosmetic bug:

...unlike in IKEv1, the Perfect Forwarding Secrecy (PFS) Diffie-Hellman (DH) group value displays as 'PFS (Y/N): N, DH group: none' during the first tunnel negotiation; after a rekey occurs, the correct values appear. This is not a bug even though the behavior is described in Cisco bug ID CSCug67056.

The difference between IKEv1 and IKEv2 is that, in IKEv2, the Child SAs are created as part of the AUTH exchange itself. The DH Group configured under the crypto map is used only during a rekey. Thus, you see 'PFS (Y/N): N, DH group: none' until the first rekey. With IKEv1, you see a different behavior because Child SA creation happens during Quick Mode, and the CREATE_CHILD_SA message has the provision for carrying the Key Exchange payload, which specifies the DH parameters to derive the new shared secret.

 

2197
Views
0
Helpful
6
Replies
CreatePlease login to create content