When configuring a IPSec VPN tunnel, it is recommended to enable PFS, or Perfect Forward Secrecy if both side of the VPN devices support the technology. It provides a more secure VPN tunnel. What is IPSec VPN PFS Perfect Forward Secrecy? To understand how PFS works, let’s quickly recap how IPSec tunnel works.
Basic IPSec VPN Tunnel Setup
Phase one
The basic function of Internet Key Exchange (IKE) phase one is to authenticate the VPN peers and setup a secure channel between the peers for further SA (Security Association) exchange in Phase two. Under the hood, it performs an authenticated Diffe-Hellman exchange and making sure the Pre-share Key (PSK) matches. It also negotiates a mutually agreeable IKE SA policy to start IKE exchange.
Phase two
The basic function of IKE phase two is to negotiate IPSec SAs and setup the IPSec tunnel. During phase two, IPSec SAs are established and used to encrypt IP packets sent across the tunnel. The SAs are periodically renegotiated to ensure security.
Post Phase two
After IKE phase two is complete and IPSec SAs are established, information is exchanged by an IPSec tunnel. Packets are encrypted and decrypted using the encryption specified in the IPSec SA.
What is IPSec VPN PFS Perfect Forward Secrecy and Why Recommended?
Instead of making use of the DH Keys Calculated during Phase-1, PFS forces DH-Key calculation during Phase-2 Setup as well as Phase-2 periodic Rekey. The PFS ensures that the same key will not be generated and used again.
Think about a scenario that a private key has compromised by a hacker. The hacker would be able to access the data in network transit which is protected by the same key. If we keep using the same key, all future data will be compromised as well. By utilizing PFS, we force the IPSec VPN tunnel to generate and use a different key when it first setup as well as during the periodic rekey. No future data would have been compromised when using a new key.
On a Cisco ASA, if the peer initiates the negotiation and the local configuration specifies PFS, the peer must perform a PFS exchange or the negotiation fails. If the local configuration does not specify a group, the ASA assumes a default of group2. If the local configuration does not specify PFS, it accepts any offer of PFS from the peer. The best practice is to configure all VPN peers with PFS and matching group.
With PFS, every time a new security association (SA) is negotiated, a new Diffie-Hellman exchange occurs, which requires additional processing time. On most modem hardware based VPN appliances the overhead is negligible.
How to configure PFS
Here is an example configuration on Cisco ASA. It forces to use PFS, and IPSec should use the 1536-bit Diffie-Hellman prime modulus group 5 when performing the new Diffie-Hellman exchange.
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac crypto map MyVPN 1 match address VPN-ACL crypto map MyVPN 1 set pfs group5 crypto map MyVPN 1 set peer 123.123.123.123 crypto map MyVPN 1 set transform-set ESP-AES-256-SHA
Here are differences among Group 1, 2 and 5. Group 5 uses the highest bit DH, and is supposed to be more secure than the others.
Group 1: 768-bit Diffie-Hellman prime modulus Group 2: 1024-bit Diffie-Hellman prime modulus Group 5: 1536-bit Diffie-Hellman prime modulus
Verify PFS is being used
On a Cisco ASA, issue “show crypto ipsec sa” to verify PFS is being utilized.
inbound esp sas: spi: 0x492AAFA3 (1227534243) transform: esp-aes-256 esp-sha-hmac no compression in use settings ={L2L, Tunnel, PFS Group 5, } slot: 0, conn_id: 3022848, crypto-map: MyVPN sa timing: remaining key lifetime (kB/sec): (3914699/25364) IV size: 16 bytes replay detection support: Y Anti replay bitmap: 0xFFFFFFFF 0xFFFFFFFF outbound esp sas: spi: 0x879FC1F3 (2275394035) transform: esp-aes-256 esp-sha-hmac no compression in use settings ={L2L, Tunnel, PFS Group 5, } slot: 0, conn_id: 3022848, crypto-map: MyVPN sa timing: remaining key lifetime (kB/sec): (3908257/25364) IV size: 16 bytes replay detection support: Y Anti replay bitmap: 0x00000000 0x00000001
In this session we covered What is ipsec vpn pfs Perfect Forward Secrecy and why it is recommended for enhanced VPN security. The key takeaway is that if you manage both end of the tunnel, you may enable PFS on both ends. If you are working with a vendor and you do not have control over their VPN configuration, you’ll need to match their settings or disable PFS to bring up a tunnel.
The best explanation
Hi thanks for this explanation. I have a question…
In my lab i’ve configured ASA1 to use PFS and ASA2 to not use PFS.
I’ve set the SA lifetime to 120 seconds.
The connection is still working fine and traffic is passing. I was expecting this configuration not to work? I was under the impression that PFS needs to be configured on both sides or it won’t work?
ASAv1# show run crypto map
crypto map LON_to_AMS 10 match address AMS_VPN
crypto map LON_to_AMS 10 set pfs group31
crypto map LON_to_AMS 10 set peer 22.0.0.1
crypto map LON_to_AMS 10 set ikev2 ipsec-proposal IPSEC-PROPOSAL
crypto map LON_to_AMS 10 set security-association lifetime seconds 120
crypto map LON_to_AMS interface OUTSIDE
ASAv2# show run crypto map
crypto map AMS_to_LON 10 match address LON_VPN
crypto map AMS_to_LON 10 set peer 11.0.0.1
crypto map AMS_to_LON 10 set ikev2 ipsec-proposal IPSEC-PROPOSAL
crypto map AMS_to_LON 10 set security-association lifetime seconds 120
crypto map AMS_to_LON interface OUTSIDE
ASAv1# show crypto ipsec sa
inbound esp sas:
spi: 0x425687AC (1112967084)
SA State: active
transform: esp-aes-256 esp-sha-256-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 31, IKEv2, }
slot: 0, conn_id: 9, crypto-map: LON_to_AMS
sa timing: remaining key lifetime (kB/sec): (4193280/87)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0xBCB75C94 (3166133396)
SA State: active
transform: esp-aes-256 esp-sha-256-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 31, IKEv2, }
slot: 0, conn_id: 9, crypto-map: LON_to_AMS
sa timing: remaining key lifetime (kB/sec): (4239360/87)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
ASAv2# show crypto ipsec sa
inbound esp sas:
spi: 0xBCB75C94 (3166133396)
SA State: active
transform: esp-aes-256 esp-sha-256-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, }
slot: 0, conn_id: 9, crypto-map: AMS_to_LON
sa timing: remaining key lifetime (kB/sec): (4101120/85)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0x425687AC (1112967084)
SA State: active
transform: esp-aes-256 esp-sha-256-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, }
slot: 0, conn_id: 9, crypto-map: AMS_to_LON
sa timing: remaining key lifetime (kB/sec): (4147200/85)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
PC1> show ip
NAME : PC1[1]
IP/MASK : 192.168.1.10/24
GATEWAY : 192.168.1.1
DNS :
MAC : 00:50:79:66:68:05
LPORT : 20000
RHOST:PORT : 127.0.0.1:30000
MTU : 1500
PC1> ping 192.168.2.10
84 bytes from 192.168.2.10 icmp_seq=1 ttl=64 time=29.699 ms
84 bytes from 192.168.2.10 icmp_seq=2 ttl=64 time=13.902 ms
84 bytes from 192.168.2.10 icmp_seq=3 ttl=64 time=11.481 ms
84 bytes from 192.168.2.10 icmp_seq=4 ttl=64 time=11.017 ms
84 bytes from 192.168.2.10 icmp_seq=5 ttl=64 time=14.581 ms