When talking about VPNs it is almost always clear that they are encrypted. However, it is not so clear on which security level a VPN is established. Since the Perfect Forward Secrecy (PFS) values of “DH group 5″ etc. do not clearly specify the “bits of security”, it is a misleadingly assumption that the security is 256 bits due to the symmetric AES-256 cipher. It is not! Diffie-Hellman group 5 has only about 89 bits of security…
Therefore, common firewalls implement DH group 14 which has a least a security level of approximately 103 bits. I tested such a site-to-site VPN tunnel between a Palo Alto and a Juniper ScreenOS firewall which worked without any problems.
Bits of Security
The traffic over a VPN is encrypted with a symmetric cipher such as AES, but the encryption key is generated with an asymmetric cipher such as Diffie-Hellman. An attacker who captures the complete traffic of a VPN might be able to brute-force the used keys of this Diffie-Hellman key exchange OR he could do a brute-force attack of the encrypted traffic with AES. Of course he would do that attack on the weaker cipher, i.e., on DH and not on AES.
On this Crypto++ wiki, a table that lists the bits of security for different symmetric and asymmetric functions can be found, taken from this PDF file from NIST on p. 64. Another resource is the ECRYPT2 Yearly Report on Algorithms and Keysizes (2010) which has the following (lower) values on p. 30:
- DH with 1024 bits (group 2) has 73 bits of security
- DH with 1536 bits (group 5) has 89 bits of security
- DH with 2048 bits (group 14) has 103 bits of security
That is: If a really secure VPN connection is needed, the phase 1 and phase 2 parameters should use at least Diffie-Hellman group 14 to gain 103 bits of security. Furthermore, at least AES-128 can be used, which has a security of almost 128 bits. However, since AES-256 can be used without any troubles, I don’t know why AES-128 should be used instead (except high CPU load issues).
Test VPN Palo <-> Juniper
While I expect that such VPN settings between firewalls of the same vendor work without any problems, I configured DH group 14 with AES-256 and SHA-256 (also new, instead of SHA-1) for both IKE and IPsec (ESP) on my test VPN between a Palo Alto PA-200 (6.0.1) and a Juniper SSG 5 (6.3.0r16a.0) firewall. It worked. 
Here is an appropriate listing from the Palo Alto firewall that shows these correct values for the VPN (DH14/…):
weberjoh@fd-wv-fw02> show vpn ike-sa gateway fd-wv-fw01
phase-1 SAs
GwID/client IP Peer-Address Gateway Name Role Mode Algorithm Established Expiration V ST Xt Phase2
--------------- ------------ ------------ ---- ---- --------- ----------- ---------- - -- -- ------
1 172.16.1.1 fd-wv-fw01 Init Main PSK/DH14/A256/SHA256 Mar.27 12:38:57 Mar.27 20:38:57 v1 12 4 1
Show IKEv1 IKE SA: Total 1 gateways found. 1 ike sa found.
phase-2 SAs
GwID/client IP Peer-Address Gateway Name Role Algorithm SPI(in) SPI(out) MsgID ST Xt
--------------- ------------ ------------ ---- --------- ------- -------- ----- -- --
1 172.16.1.1 fd-wv-fw01 Init DH14/tunl/ESP/A256/SHA256 A2C9F430 38921FFB D8170C56 9 1
Show IKEv1 phase2 SA: Total 1 gateways found. 1 ike sa found.
And similarly, two Juniper listings (grp14/…):
fd-wv-fw01-> get ike cookies 80102f/0003, 172.16.1.2:500->172.16.1.1:500, PRESHR/grp14/AES256/SHA2-256, xchg(5) (fd-wv-fw02/grp-1/usr-1) resent-tmr 322 lifetime 28800 lt-recv 28800 nxt_rekey 21359 cert-expire 0 responder, err cnt 0, send dir 1, cond 0x0 nat-traversal map not available ike heartbeat : disabled ike heartbeat last rcv time: 0 ike heartbeat last snd time: 0 XAUTH status: 0 DPD seq local 0, peer 2491
fd-wv-fw01-> get sa id 00000002 index 0, name fd-wv-fw02, peer gateway ip 172.16.1.2. vsys auto key. tunnel if binding node, tunnel mode, policy id in:<-1> out:<-1> vpngrp:<-1>. sa_list_nxt:<-1>. tunnel id 2, peer id 0, NSRP Local. site-to-site. Local interface is ethernet0/6 <172.16.1.1>. esp, group 14, a256 encryption, s256 authentication autokey, IN active, OUT active monitor<1>, latency: 2, availability: 100 DF bit: clear app_sa_flags: 0x24001a7 proxy id: local 0.0.0.0/0.0.0.0, remote 0.0.0.0/0.0.0.0, proto 0, port 0/0 ike activity timestamp: 1987333985 DSCP-mark : disabled nat-traversal map not available incoming: SPI 38922007, flag 00004000, tunnel info 40000002, pipeline life 3600 sec, 3397 remain, 0 kb, 0 bytes remain anti-replay on, last 0x47, window 0xffffffff, idle timeout value <0>, idled 1 seconds next pak sequence number: 0x0 bytes/paks:51371280/706390; sw bytes/paks:51371280/706390 outgoing: SPI fd1321fd, flag 00000000, tunnel info 40000002, pipeline life 3600 sec, 3397 remain, 0 kb, 0 bytes remain anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 1 seconds next pak sequence number: 0x47 bytes/paks:51371600/706400; sw bytes/paks:51371600/706400
I also tried to configure group 14 values on my VPNs to a Cisco ASA 5505 (9.1(4)) firewall, but an error message said that DH14 is only supported on IKEv2. Hm. Maybe the two other vendors implemented it on their own, or Cisco did not want to implement it for IKEv1. I don’t know.