Have a Question?
Table of Contents
< All Topics
Print

Configure Strong Encryption IKEv2 on WatchGuard Firewall for FedRAMP and CMMC

WatchGuard Notes:

Virtual IP address pools do not affect whether VPN users are considered as trusted users on the local network. For example, if you specify an IP address pool for Mobile VPN with IKEv2 that overlaps with the IP address range of your local network, mobile VPN users are still not considered as trusted users on the local network.

WatchGuard Recommended Best Practices for IKEv2 Policies

We recommend that you limit which network resources Mobile VPN with IKEv2 users can access through the VPN. To do this, you can replace the Allow IKEv2-Users policy.

To replace the Allow IKEv2-Users policy:

  1. Determine the ports and protocols your users require. To determine this, assess your network with baseline tests and view logs.
  2. Add Mobile VPN with IKEv2 groups and users to existing Firebox polices that specify those ports and protocols. For example, you can add Mobile VPN with IKEv2 groups and users to policies for web traffic.
  3. If required, add new policies:
    1. When you select a policy type for the new policy, you can specify a protocol and port.
    2. In the From list of the policy, specify users or groups. You must specify groups or users included in the Mobile VPN with IKEv2 configuration. For example, you can specify the default IKEv2-Users group. Or, specify groups and users that you added to the Mobile VPN with IKEv2 configuration.
    3. In the To list of the policy, remove the Any alias and add other destinations.
  4. Before you disable the Allow IKEv2-Users policy, make sure your policies allow Mobile VPN with IKEv2 users to access all required network resources.
  5. Disable the Allow IKEv2-Users policy.

 

StrongSwan Guidance Statements:

Attacks on IKEv2 PSK Authentication
If user credentials don’t have enough entropy what is usually the case if you let the users freely choose their passwords, then PSK-based IKEv2 authentication is vulnerable to active Man-In-The-Middle (MITM) attacks.

Since a VPN client is usually the IKEv2 initiator, it sends its AUTH payload containing the password hash in the IKE_AUTH request to an unauthenticated and thus untrusted VPN server. If an attacker inserts herself into the IKE connection between client and server she can intercept the AUTH payload and start an offline dictionary or brute force attack on the PSK.

Thus it is of utmost importance that cryptographically strong PSKs are used with PSK-based authentication. Since in most cases this cannot be enforced, we highly recommend to use EAP-based authentication instead where the VPN server is authenticated first based on a X.509 server certificate, so that the VPN client can then send its [potentially weak] password hash later on to a trusted peer.

Certificate-based Authentication

Certificate-based authentication is inherently stronger than PSK-based authentication. A properly built PKI architecture has usually one root CA and one or several intermediate CAs, where the private key of the intermediate CA is used to sign the end entity certificates and the private key of the root CA can be kept on a smartcard stored in a safe or at lease on a system disconnected from the Internet. The private root CA key is never stored on an insecure or online system. Securing the root CA enables the PKI administrator to revoke any certificates and recreate the PKI from scratch, if any intermediate CAs are compromised.

Using the default revocation plugin, Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) can be used to check if a given certificate has been revoked for some reason. strongSwan supports locally-stored CRLs, as well as fetching fresh CRLs and OCSP information via the fetcher plugins curl, soup or winhttp.

CRL Distribution Points (CDPs) are either retrieved from the certificate or can be added manually using an authorities section in swanctl.conf.

X.509 certificates should be based on RSA public keys with a modulus of at least 2048 bits (preferably 3072 bits for end entity certificates and 4096 bits for CA certificates). Alternatively ECDSA public keys with at least 256 bits (preferably 384 bits) can be used. For certificate signatures at least SHA-256 must be used since both SHA-1 and MD5 are hopelessly broken. All X.509 certificates must conform to the PKIX Internet standard (RFC 5280).

Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) is strongly recommended to make IPsec peers negotiate an independent session key for each IPsec or CHILD SA. This protects the long-term confidentiality of the IPsec traffic if the IKE shared secret is leaked. Note that the session keys of the first CHILD_SA of a new IKEv2 connection are derived from the IKE shared secret. However, subsequent CHILD_SAs will use independent keys if PFS is used.

PFS is enabled by appending a DH group to the ESP or AH cipher proposal. Using PFS introduces no significant performance overhead, unless you rekey more than about 80 CHILD_SAs per second.

Configure IKEv2

Start IKEv2 Configuration by defining our Phase 1 options.

Start by going to VPN on the left side WatchGuard web client.  Then select IKEv2 Shared Settings.

Then select Configure under Phase 1 Transforms. Configure settings recommended for organizations that require strong encryption. Organization that are, or perhaps looking for specific recommendations standards whom maybe engaged with CMMC 2.0, FedRAMP or other requirements meeting Department of Defense and/or Civilian agencies can look down under references for additional information.

We are configuring AES-GCM(256bit) With Diffie-Hellman Group 20, another configuration for Group 19 which aligns with recommendations. 

(Refer to the VPN Encryption References and Guidance documented below.)

Configure IKEv2

Next move on to the configuration of the VPN client will include additional steps on configuring of the types of Phase 1 Transforms and Phase 2.

Lets start by going to VPN on the left side WatchGuard web client.  Then select Mobile VPN, then select Configure under IKEv2.

Configure IKEv2

Check the Activate Mobile VPN with IKEv2.

Under Firebox Addresses, Edit and enter in the External/Public IP adddress(es) that you will use for your clients to connect too.

Under the Virtual IP Address Pool, enter in the IP's and or subnet that the Firebox will provide as DHCP addresses to connecting clients. This configuration essentially provides the NAT translation for connecting clients.

By leveraging the WatchGuard firewall as the connection point for VPN clients and not the actual Microsoft RRAS server is administrators can benefit from the drastically enhanced capabilities of the WatchGuard diagnostics and logging.

Under DNS Settings select the option which works best for your origination. If your network is fairly basic and does not employ various VLANS and other network services you can get away with  Assign the Network DNS/WINS settings to mobile clients. If you would like to provide custom DNS configurations to mobile clients you can go ahead and input it here.

Configure IKEv2

Move next to the Authentication Tab under Configuration.

You want to add the domain name that you configured earlier when configuring the Radius Client under Authentication --> Servers --> RADIUS. 

You can additionally include the Firebox-DB and local user setup, though these local WatchGuard firewall users will not leverage the DUO MFA authentication. Local users will essentially bypass DUO MFA.

Under Users and Groups you will see the default user group IKEV2-Users.

You will also be required to define the individual users that will be authenticating.

Configure IKEv2

Move next to the Phase 1 Settings tab, under the Security Tab under Configuration.

You can keep the WatchGuard Self-Signed Certificate here. This certificate will be used to deploy to mobile clients.

Configure IKEv2

Move next to the Phase 2 Settings tab, under the Security Tab under Configuration.

Here is where administrators can configure the level of authentication requirements for clients to connect.

Based on guidance from the  NSA U/OO/148260-20 | PP-20-0712 | October 2020 ver. 1.2, we are configuring Phase 2 requirements with:

  • ESP-AES256-GCM DH Group 20
  • ESP-AES256-GCM DH Group 19

VPN Encryption References and Guidance:

Microsoft Azure VPN References:

  • https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-compliance-crypto

AWS VPN References:

  • https://aws.amazon.com/about-aws/whats-new/2020/08/aws-site-to-site-vpn-now-supports-additional-encryption-integrity-key-exchange-algorithms/
  • https://aws.amazon.com/premiumsupport/knowledge-center/vpn-tunnel-phase-2-ipsec/
  • https://aws.amazon.com/vpn/faqs/
Tags: