Working IPSEC VPN Security

TomT

Hi
I've setup an IPSEC VPN on my pfSense box. All seems to be working and my mobile and Windows 10 client can connect.

I'd now like to consider the security, so have a couple of questions.

The VPN has IKE Extensions enabled and the tunnel has 3DES SHA1 configured.
Phase2 has AES, SHA1, SHA256 enabled and the Local subnet is OPT2.

Is 3DES Secure ? or is there a better option that will work with Android and Windows 10 ?

Does setting the Local Subnet to OPT2 limit the VPN clients to just that interface ?

OPT2 has an any rule and two additional rules to block LAN and OPT1. Should that stop traffic from OPT2 to OPT1 and LAN ?

Last one how secure is this ?
I'm assuming that users can only connect with a valid username & password and the certificate.
is that right ?

Thanks

TomT

Last night I noticed this is my IPSEC Log:

Feb 6 01:34:40	charon		06[NET] <28> sending packet: from x.x.x.x[500] to 216.218.206.118[47587] (56 bytes)
Feb 6 01:34:40	charon		06[ENC] <28> generating INFORMATIONAL_V1 request 2516524686 [ N(NO_PROP) ]
Feb 6 01:34:40	charon		06[IKE] <28> no proposal found
Feb 6 01:34:40	charon		06[CFG] <28> configured proposals: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072, IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_MD5_96/HMAC_SHA1_96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_2048_256/MODP_1024, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_2048_256/MODP_1024
Feb 6 01:34:40	charon		06[CFG] <28> received proposals: IKE:CAST_CBC
Feb 6 01:34:40	charon		06[IKE] <28> 216.218.206.118 is initiating a Main Mode IKE_SA
Feb 6 01:34:40	charon		06[ENC] <28> parsed ID_PROT request 0 [ SA ]
Feb 6 01:34:40	charon		06[NET] <28> received packet: from 216.218.206.118[47587] to x.x.x.x[500] (64 bytes)

I've replaced my IP Address with x.x.x.x
The originating IP Address is from 'The Shadowserver Foundation'.

So back to my original question, is IPSEC with 3DES secure ?
Do you need username, password and the certificate to connect ?

Thanks

lst_hoe

To my knowledge 3DES is not a problem regarding security. The cipher is well tested and in the triple form secure enough, although slower than for example AES. The main problem from my point of view with Windows VPN client is the key exchange which can not use anything other than PFS Group 2 (1024Bit) which has issues as explained here:

https://weakdh.org/
https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html

The solution can be to use the somewhat undocumented registry key NegotiateDH2048_AES256 as explained here:
https://github.com/trailofbits/algo/issues/9

Regards

Andreas

TomT

Thanks for the Advise.
I've reconfigured the IPSEC VPN to use AES (256 bits) SHA384
As per : https://forum.pfsense.org/index.php?topic=124394.0

From my mobile the connection works, just need to check from the remote Windows 10 user.

I assume the CRT file is needed as well as the username and password. ?

Thanks

lst_hoe

I don't know about username/password as we use certificate based authentication…

I also have to apologize for my statement about 3DES. There actually is a recent attack on common implementations of 3DES so it should be phased out soon.

https://www.openssl.org/blog/blog/2016/08/24/sweet32/

Regards

Andreas

TomT

Hi
I changed for 3DEs and it all seems to be working fine.

No issues with drops etc.

Thanks

seanmcb

You can also consult this list:

https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

for broken/dubious security choices.

TomT

Cheers, looks like the choice I'm using is OK