# Encrypting data in transit This topic explains the different options available for encrypting your file data while it is in-transit between an FSx for ONTAP file system and connected clients. It also provides guidance to help you choose which encryption method is best suited for your workflow. All data flowing across AWS Regions over the AWS global network is automatically encrypted at the physical layer before it leaves AWS secured facilities. All traffic between Availability Zones is encrypted. Additional layers of encryption, including those listed in this section, provide additional protections. For more information about how AWS provides protection for data flowing across AWS Regions, Available Zones, and instances, see [Encryption in transit](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit) in the Amazon Elastic Compute Cloud User Guide for Linux Instances. Amazon FSx for NetApp ONTAP supports the following methods for encrypting data in transit between FSx for ONTAP file systems and connected clients: + Automatic Nitro-based encryption over all supported protocols and clients running on supported Amazon EC2 [ Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit) and [Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/data-protection.html#encryption-transit) instance types. + Kerberos-based encryption over NFS and SMB protocols. + IPsec-based encryption over NFS, iSCSI, and SMB protocols All of the supported methods for encrypting data in transit use industry standard AES-256 cryptographic algorithms that provide enterprise strength encryption. **Topics** + [ ## Choosing a method for encrypting data in transit ](#choosing-encryption-in-transit) + [ ## Encrypting data in transit with AWS Nitro System ](#nitro-encryption) + [ ## Encrypting data in-transit with Kerberos-based encryption ](#kerberos-encryption) + [ ## Encrypting data in transit with IPsec encryption ](#ipsec-encryption) + [ # Enabling SMB encryption of data in transit ](enable-smb-encryption.md) + [ # Configuring IPsec using PSK authentication ](config-ipsec-psk-auth.md) + [ # Configuring IPsec using certificate authentication ](config-ipsec-ca-auth.md) ## Choosing a method for encrypting data in transit This section provides information that can help you decide which of the supported encryption in transit methods is best for your workflow. Refer back to this section as you explore the supported options described in detail in the sections that follow. There are several factors to consider when choosing how you are going to encrypt data in transit between your FSx for ONTAP file system and connected clients. These factors include: + The AWS Region that your FSx for ONTAP file system is running in. + The instance type that the client is running on. + The location of the client accessing your file system. + Network performance requirements. + The data protocol you want to encrypt. + If you are using Microsoft Active Directory. **AWS Region** The AWS Region that your file system is running in determines whether or not you can use Amazon Nitro-based encryption. For more information, see [Encrypting data in transit with AWS Nitro System](#nitro-encryption). **Client instance type** You can use Amazon Nitro-based encryption if the client accessing your file system is running on any of the supported Amazon EC2 Mac, [Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit) or [Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/data-protection.html#encryption-transit) instance types, and your workflow meets all other requirements for using [Nitro-based encryption](#nitro-encryption). There aren't any client instance type requirements for using Kerberos or IPsec encryption. **Client location** The location of the client accessing data with respect to the location of your file system impacts which in-transit encryption methods are available to use. You can use any of the supported encryption methods if the client and file system are located in the same VPC. The same is true if the client and file system are located in peered VPCs, as long as the traffic does not pass through a virtual network device or service, such as a transit gateway. Nitro-based encryption is not an available option if the client is not in the same or peered VPC, or if the traffic passes through a virtual network device or service. **Network performance** Using Amazon Nitro-based encrypted has no impact on network performance. This is because the supported Amazon EC2 instances utilize the offload capabilities of the underlying Nitro System hardware to automatically encrypt in-transit traffic between instances. Using Kerberos or IPsec encryption has an impact on network performance. This is because both of these encryption methods are software-based, which requires the client and server to use compute resources to encrypt and decrypt in-transit traffic. **Data protocol** You can use Amazon Nitro-based encryption and IPsec encryption with all of the supported protocols – NFS, SMB, and iSCSI. You can use Kerberos encryption with the NFS and SMB protocols (with an Active Directory). **Active Directory** If you are using Microsoft Active Directory, you can use [Kerberos encryption](#kerberos-encryption) over the NFS and SMB protocols. Use the following diagram to help you decide which encryption in-transit method to use. ![\[Flowchart showing which encryption in transit method to use based on five decision points.\]](http://docs.aws.amazon.com/fsx/latest/ONTAPGuide/images/fsx-ontap-encrypt-n-transit-decision-flow.png) IPsec encryption is the only option available when all of the following conditions apply to your workflow: + You are using the NFS, SMB, or iSCSI protocol. + Your workflow does not support using Amazon Nitro-based encryption. + You are not using a Microsoft Active Directory domain. ## Encrypting data in transit with AWS Nitro System Nitro-based encryption With Nitro-based encryption, data in-transit is encrypted automatically when clients accessing your file systems are running on supported Amazon EC2 [Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit) or [Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/data-protection.html#encryption-transit) instance types in AWS Regions where it's available on FSx for ONTAP. Using Amazon Nitro-based encryption has no impact on network performance. This is because the supported Amazon EC2 instances utilize the offload capabilities of the underlying Nitro System hardware to automatically encrypt in-transit traffic between instances. Nitro-based encryption is enabled automatically when the supported client instance types are located in the same AWS Region and in the same VPC or in a VPC peered with the file system's VPC. Additionally, if the client is in a peered VPC, then data cannot traverse a virtual network device or service (such as a transit gateway) in order for Nitro-based encryption to be automatically enabled. For more information about Nitro-based encryption, see the Encryption in transit section of the Amazon EC2 User Guide for [Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit) or [Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/data-protection.html#encryption-transit) instance types. The following table details the AWS Regions that Nitro-based encryption is available in. **Support for Nitro-based encryption** | Generation | Deployment types | AWS Region | | --- | --- | --- | | First-generation file systems1 | Single-AZ 1 Multi-AZ 1 | US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland) | | Second-generation file systems | Single-AZ 2 Multi-AZ 2 | US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Europe (Frankfurt), Europe (Ireland), Asia Pacific (Sydney) | 1 First-generation file systems created on or after November 28, 2022 support Nitro-based in-transit encryption in the listed AWS Regions. For more information about the AWS Regions where FSx for ONTAP is available, see [Amazon FSx for NetApp ONTAP Pricing](https://aws.amazon.com/fsx/netapp-ontap/pricing/). For more information about the performance specifications for FSx for ONTAP file systems, see [Impact of throughput capacity on performance](performance.md#impact-throughput-cap-performance). ## Encrypting data in-transit with Kerberos-based encryption Encrypting data in-transit with Kerberos If you are using Microsoft Active Directory, you can use Kerberos-based encryption over the NFS and SMB protocols to encrypt data in-transit for child volumes of [SVMs that are joined to a Microsoft Active Directory](ad-integration-ontap.md). ### Encrypting data in transit over NFS using Kerberos Encrypting NFS with Kerberos Encryption of data in-transit using Kerberos is supported for NFSv3 and NFSv4 protocols. To enable encryption in transit using Kerberos for the NFS protocol, see [ Using Kerberos with NFS for strong security](https://docs.netapp.com/us-en/ontap/pdfs/sidebar/Using_Kerberos_with_NFS_for_strong_security.pdf) in the NetApp ONTAP Documentation Center. ### Encrypting data in transit over SMB using Kerberos Encrypting SMB with Kerberos Encrypting data in transit over the SMB protocol is supported on file shares that are mapped on a compute instance that supports SMB protocol 3.0 or newer. This includes all Microsoft Windows versions from Microsoft Windows Server 2012 and later, and Microsoft Windows 8 and later. When enabled, FSx for ONTAP automatically encrypts data in transit using SMB encryption as you access your file system without the need for you to modify your applications. FSx for ONTAP SMB supports 128 and 256 bit encryption, which is determined by the client session request. For descriptions of the different encryption levels, see the *Set the SMB server minimum authentication security level* section of [Manage SMB with the CLI](https://docs.netapp.com/us-en/ontap/pdfs/sidebar/Manage_SMB_with_the_CLI.pdf) in the NetApp ONTAP Documentation Center. **Note** The client determines the encryption algorithm. Both NTLM and Kerberos authentication work with both 128 and 256 bit encryption. The FSx for ONTAP SMB Server accepts all standard Windows client requests, and the granular controls are handled by Microsoft Group Policy or Registry settings. You use the ONTAP CLI to manage the encryption in transit settings on FSx for ONTAP SVMs and volumes. To access the NetApp ONTAP CLI, establish an SSH session on the SVM on which you are making encryption in transit settings, as described in [Managing SVMs with the ONTAP CLI](managing-resources-ontap-apps.md#vsadmin-ontap-cli). For instructions on how to enable SMB encryption on an SVM or volume, see [Enabling SMB encryption of data in transit](enable-smb-encryption.md). ## Encrypting data in transit with IPsec encryption IPsec encryption FSx for ONTAP supports using the IPsec protocol in transport mode to ensure data is continuously secure and encrypted, while in-transit. IPsec offers end-to-end encryption of data in-transit between clients and FSx for ONTAP file systems for all supported IP traffic – NFS, iSCSI, and SMB protocols. With IPsec encryption, you establish an IPsec tunnel between an FSx for ONTAP SVM configured with IPsec enabled, and an IPsec client running on the connected client accessing the data. We recommend that you use IPsec to encrypt data in transit over NFS, SMB, and iSCSI protocols when accessing your data from clients that do not support [Nitro-based encryption](#nitro-encryption), and if your client and SVMs are not joined to an Active Directory, which is required for Kerberos-based encryption. IPsec encryption is the only option available for encrypting data in-transit for iSCSI traffic when your iSCSI client doesn't support Nitro-based encryption. For IPsec authentication, you can use either pre-shared keys (PSKs) or certificates. If you are using a PSK, the IPsec client you use must support Internet Key Exchange version 2 (IKEv2) with a PSK. The high level steps for configuring IPsec encryption on both FSx for ONTAP and the client are as follows: 1. Enable and configure IPsec on your file system. 1. Install and configure IPsec on your client 1. Configure IPsec for multiple client access For more information about how to configure IPsec using PSK, see [Configure IP security (IPsec) over wire encryption](https://docs.netapp.com/us-en/ontap/networking/configure_ip_security_@ipsec@_over_wire_encryption.html) in the NetApp ONTAP documentation center. For more information about how to configure IPsec using certificates, see [Configuring IPsec using certificate authentication](config-ipsec-ca-auth.md). # Enabling SMB encryption of data in transit By default, when you create an SVM, SMB encryption is turned off. You can either enable SMB encryption required on individual shares, or on an SVM, which turns it on for all shares on that SVM. **Note** When SMB encryption required is enabled on an SVM or share, SMB clients that do not support encryption cannot connect to that SVM or share. **To require SMB encryption for incoming SMB traffic on an SVM** Use the following procedure to require SMB encryption on a SVM using the NetApp ONTAP CLI. 1. To connect to the SVM management endpoint with SSH, use user name `vsadmin` and the vsadmin password that you set when you created the SVM. If you did not set a vsadmin password, use user name `fsxadmin` and the fsxadmin password. You can SSH into the SVM from a client that is in the same VPC as the file system, using the management endpoint IP address or DNS name. ``` ssh vsadmin@svm-management-endpoint-ip-address ``` The command with sample values: ``` ssh vsadmin@198.51.100.10 ``` The SSH command using the management endpoint DNS name: ``` ssh vsadmin@svm-management-endpoint-dns-name ``` The SSH command using a sample DNS name: ``` ssh vsadmin@management.svm-abcdef01234567892fs-08fc3405e03933af0.fsx.us-east-2.aws.com ``` ``` Password: vsadmin-password This is your first recorded login. FsxIdabcdef01234567892::> ``` 1. Use the [https://docs.netapp.com/us-en/ontap-cli-9131/vserver-cifs-security-modify.html](https://docs.netapp.com/us-en/ontap-cli-9131/vserver-cifs-security-modify.html) NetApp ONTAP CLI command to require SMB encryption for incoming SMB traffic to the SVM. ``` vserver cifs security modify -vserver vserver_name -is-smb-encryption-required true ``` 1. To stop requiring SMB encryption for incoming SMB traffic, use the following command. ``` vserver cifs security modify -vserver vserver_name -is-smb-encryption-required false ``` 1. To see the current `is-smb-encryption-required` setting on an SVM, use the [https://docs.netapp.com/us-en/ontap-cli-9131/vserver-cifs-security-show.html](https://docs.netapp.com/us-en/ontap-cli-9131/vserver-cifs-security-show.html) NetApp ONTAP CLI command: ``` vserver cifs security show -vserver vs1 -fields is-smb-encryption-required vserver is-smb-encryption-required -------- ------------------------- vs1 true ``` For more information about managing SMB encryption on an SVM, see [ Configuring required SMB encryption on SMB servers for data transfers over SMB](https://docs.netapp.com/us-en/ontap/smb-admin/configure-required-encryption-concept.html) in the NetApp ONTAP Documentation Center. **To enable SMB encryption on a volume** Use the following procedure to enable SMB encryption on a share using the NetApp ONTAP CLI. 1. Establish a secure shell (SSH) connection to the SVM's management endpoint as described in [Managing SVMs with the ONTAP CLI](managing-resources-ontap-apps.md#vsadmin-ontap-cli). 1. Use the following NetApp ONTAP CLI command to create a new SMB share and require SMB encryption when accessing this share. ``` vserver cifs share create -vserver vserver_name -share-name share_name -path share_path -share-properties encrypt-data ``` For more information, see [https://docs.netapp.com/ontap-9/topic/com.netapp.doc.dot-cm-cmpr-9101/vserver__cifs__share__create.html](https://docs.netapp.com/ontap-9/topic/com.netapp.doc.dot-cm-cmpr-9101/vserver__cifs__share__create.html) in the NetApp ONTAP CLI Command man pages. 1. To require SMB encryption on an existing SMB share, use the following command. ``` vserver cifs share properties add -vserver vserver_name -share-name share_name -share-properties encrypt-data ``` For more information, see [https://docs.netapp.com/ontap-9/topic/com.netapp.doc.dot-cm-cmpr-9101/vserver__cifs__share__properties__add.html](https://docs.netapp.com/ontap-9/topic/com.netapp.doc.dot-cm-cmpr-9101/vserver__cifs__share__properties__add.html) in the NetApp ONTAP CLI Command man pages. 1. To turn off SMB encryption on an existing SMB share, use the following command. ``` vserver cifs share properties remove -vserver vserver_name -share-name share_name -share-properties encrypt-data ``` For more information, see [https://docs.netapp.com/ontap-9/topic/com.netapp.doc.dot-cm-cmpr-9101/vserver__cifs__share__properties__remove.html](https://docs.netapp.com/ontap-9/topic/com.netapp.doc.dot-cm-cmpr-9101/vserver__cifs__share__properties__remove.html) in the NetApp ONTAP CLI Command man pages. 1. To see the current `is-smb-encryption-required` setting on an SMB share, use the following NetApp ONTAP CLI command: ``` vserver cifs share properties show -vserver vserver_name -share-name share_name -fields share-properties ``` If one of the properties returned by the command is the `encrypt-data` property, then that property specifies that SMB encryption must be used when accessing this share. For more information, see [https://docs.netapp.com/ontap-9/topic/com.netapp.doc.dot-cm-cmpr-9101/vserver__cifs__share__properties__show.html](https://docs.netapp.com/ontap-9/topic/com.netapp.doc.dot-cm-cmpr-9101/vserver__cifs__share__properties__show.html) in the NetApp ONTAP CLI Command man pages. # Configuring IPsec using PSK authentication If you are using PSK for authentication, the steps for configuring IPsec encryption on both FSx for ONTAP and the client are as follows: 1. Enable and configure IPsec on your file system. 1. Install and configure IPsec on your client 1. Configure IPsec for multiple client access For details on configuring IPsec using PSK, see [Configure IP security (IPsec) over wire encryption](https://docs.netapp.com/us-en/ontap/networking/configure_ip_security_@ipsec@_over_wire_encryption.html) in the NetApp ONTAP documentation center. # Configuring IPsec using certificate authentication The following topics provide instructions for configuring IPsec encryption using certificate authentication on an FSx for ONTAP file system and a client running Libreswan IPsec. This solution uses AWS Certificate Manager and AWS Private Certificate Authority to create a private certificate authority and for generating the certificates. The high-level steps for configuring IPsec encryption using certificate authentication on FSx for ONTAP file systems and connected clients are as follows: 1. Have a certificate authority in place for issuing certificates. 1. Generate and export CA certificates for the file system and client. 1. Install certificate and configure IPsec on the client instance. 1. Install certificate and configure IPsec on your file system. 1. Define the security policy database (SPD). 1. Configure IPsec for multiple client access. ## Creating and installing CA certificates For certificate authentication, you need to generate and install certificates from a certificate authority on your FSx for ONTAP file system and the clients that will access the data on your file system. The following example uses AWS Private Certificate Authority to set up a private certificate authority, and generate the certificates to install on the file system and the client. Using AWS Private Certificate Authority, you can create an entirely AWS hosted hierarchy of root and subordinate certificate authorities (CAs) for internal use by your organization. This process has five steps: 1. Create a private certificate authority (CA) using AWS Private CA 1. Issue and install the root certificate on the private CA 1. Request a private certificate from AWS Certificate Manager for your file system and clients 1. Export the certificate for the file system and clients. For more information, see [Private CA administration](https://docs.aws.amazon.com/privateca/latest/userguide/creating-managing.html) in the AWS Private Certificate Authority User Guide. **To create the root private CA** 1. When you create a CA, you must specify the CA configuration in a file that you supply. The following command uses the Nano text editor to create the `ca_config.txt` file, which specifies the following information: + The name of the algorithm + The signing algorithm that the CA uses to sign + X.500 subject information ``` $ > nano ca_config.txt ``` The text editor appears. 1. Edit the file with the specifications for your CA. ``` { "KeyAlgorithm":"RSA_2048", "SigningAlgorithm":"SHA256WITHRSA", "Subject":{ "Country":"US", "Organization":"Example Corp", "OrganizationalUnit":"Sales", "State":"WA", "Locality":"Seattle", "CommonName":"*.ec2.internal" } } ``` 1. Save and close the file, exiting the text editor. For more information, see [Procedure for creating a CA](https://docs.aws.amazon.com/privateca/latest/userguide/Create-CA-CLI.html) in the AWS Private Certificate Authority User Guide. 1. Use the [create-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/create-certificate-authority.html) AWS Private CA CLI command to create a private CA. ``` ~/home > aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config.txt \ --certificate-authority-type "ROOT" \ --idempotency-token 01234567 --region aws-region ``` If successful, this command outputs the Amazon Resource Name (ARN) of the CA. ``` { "CertificateAuthorityArn": "arn:aws:acm-pca:aws-region:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012" } ``` **To create and install a certificate for your private root CA (AWS CLI)** 1. Generate a certificate signing request (CSR) using the [https://docs.aws.amazon.com/cli/latest/reference/acm-pca/get-certificate-authority-csr.html](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/get-certificate-authority-csr.html) AWS CLI command. ``` $ aws acm-pca get-certificate-authority-csr \ --certificate-authority-arn arn:aws:acm-pca:aws-region:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012 \ --output text \ --endpoint https://acm-pca.aws-region.amazonaws.com \ --region eu-west-1 > ca.csr ``` The resulting file `ca.csr`, a PEM file encoded in base64 format, has the following appearance. ``` -----BEGIN CERTIFICATE----- MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6 b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ 21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4 nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE= -----END CERTIFICATE----- ``` For more information, see [Installing a root CA certificate](https://docs.aws.amazon.com/privateca/latest/userguide/PCACertInstall.html#InstallRoot) in the AWS Private Certificate Authority User Guide. 1. Use the [https://docs.aws.amazon.com/cli/latest/reference/acm-pca/issue-certificate.html](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/issue-certificate.html) AWS CLI command to issue and install the root certificate on your private CA. ``` $ aws acm-pca issue-certificate \ --certificate-authority-arn arn:aws:acm-pca:aws-region:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012 \ --csr file://ca.csr \ --signing-algorithm SHA256WITHRSA \ --template-arn arn:aws:acm-pca:::template/RootCACertificate/V1 \ --validity Value=3650,Type=DAYS --region aws-region ``` 1. Download the root certificate using the [https://docs.aws.amazon.com/cli/latest/reference/acm-pca/get-certificate.html](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/get-certificate.html) AWS CLI command. ``` $ aws acm-pca get-certificate \ --certificate-authority-arn arn:aws:acm-pca:aws-region:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012 \ --certificate-arn arn:aws:acm-pca:aws-region:486768734100:certificate-authority/12345678-1234-1234-1234-123456789012/certificate/abcdef0123456789abcdef0123456789 \ --output text --region aws-region > rootCA.pem ``` 1. Install the root certificate on your private CA using the [https://docs.aws.amazon.com/cli/latest/reference/acm-pca/import-certificate-authority-certificate.html](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/import-certificate-authority-certificate.html) AWS CLI command. ``` $ aws acm-pca import-certificate-authority-certificate \ --certificate-authority-arn arn:aws:acm-pca:aws-region:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012 \ --certificate file://rootCA.pem --region aws-region ``` **Generate and export the file system and client certificate** 1. Use the [https://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html](https://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html) AWS CLI command to request an AWS Certificate Manager certificate to use on your file system and clients. ``` $ aws acm request-certificate \ --domain-name *.ec2.internal \ --idempotency-token 12345 \ --region aws-region \ --certificate-authority-arn arn:aws:acm-pca:aws-region:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012 ``` If the request is successful, the ARN of the issued certificate is returned. 1. For security, you must assign a passphrase for the private key when exporting it. Create a passphrase and store it in a file named `passphrase.txt` 1. Use the [https://docs.aws.amazon.com/cli/latest/reference/acm/export-certificate.html](https://docs.aws.amazon.com/cli/latest/reference/acm/export-certificate.html) AWS CLI command to export the private certificate issued previously. The exported file contains the certificate, the certificate chain, and the encrypted private 2048-bit RSA key associated with the public key that is embedded in the certificate. For security, you must assign a passphrase for the private key when exporting it. The following example is for a Linux EC2 instance. ``` $ aws acm export-certificate \ --certificate-arn arn:aws:acm:aws-region:111122223333:certificate/12345678-1234-1234-1234-123456789012 \ --passphrase $(cat passphrase.txt | base64) --region aws-region > exported_cert.json ``` 1. Use the following `jq` commands to extract the private key and the certificate from the JSON response. ``` $ passphrase=$(cat passphrase.txt | base64) cat exported_cert.json | jq -r .PrivateKey > prv.key cat exported_cert.json | jq -r .Certificate > cert.pem ``` 1. Use the following `openssl` command to decrypt the private key from the JSON response. After entering the command, you are prompted for the passphrase. ``` $ openssl rsa -in prv.key -passin pass:$passphrase -out decrypted.key ``` ## Installing and configuring Libreswan IPsec on an Amazon Linux 2 client Installing the Libreswan client The following sections provide instructions for installing and configuring Libreswan IPsec on an Amazon EC2 instance running Amazon Linux 2. **To install and configure Libreswan** 1. Connect to your EC2 instance using SSH. For specific instructions on how to do this, see [Connect to your Linux instance using an SSH client](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html#AccessingInstancesLinuxSSHClient) in the Amazon Elastic Compute Cloud User Guide for Linux Instances. 1. Run the following command to install `libreswan`: ``` $ sudo yum install libreswan ``` 1. (Optional) When verifying IPsec in a later step, these properties might be flagged without these settings. We suggest testing your set up first without these settings. If your connection has problems, return to this step and make the following changes. After the installation completes, use your preferred text editor to add the following entries to the `/etc/sysctl.conf` file. ``` net.ipv4.ip_forward=1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.lo.accept_redirects = 0 net.ipv4.conf.lo.send_redirects = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0 ``` Save the changes and exit the text editor. 1. Apply the changes. ``` $ sudo sysctl -p ``` 1. Verify the IPsec configuration. ``` $ sudo ipsec verify ``` Verify that the version of `Libreswan` you installed is running. 1. Initialize the IPsec NSS database. ``` $ sudo ipsec checknss ``` **To install the certificate on the client** 1. Copy the [certificate you generated](#generate-certificate) for the client to the working directory on the EC2 instance. You 1. Export the certificate generated previously into a format compatible with `libreswan`. ``` $ openssl pkcs12 -export -in cert.pem -inkey decrypted.key \ -certfile rootCA.pem -out certkey.p12 -name fsx ``` 1. Import the reformatted key, providing the passphrase when prompted. ``` $ sudo ipsec import certkey.p12 ``` 1. Create an IPsec configuration file using the preferred text editor. ``` $ sudo cat /etc/ipsec.d/nfs.conf ``` Add the following entries to the config file: ``` conn fsxn authby=rsasig left=172.31.77.6 right=198.19.254.13 auto=start type=transport ikev2=insist keyexchange=ike ike=aes256-sha2_384;dh20 esp=aes_gcm_c256 leftcert=fsx leftrsasigkey=%cert leftid=%fromcert rightid=%fromcert rightrsasigkey=%cert ``` You will start IPsec on the client after configuring IPsec on your file system. ## Configuring IPsec on your file system This section provides instructions on installing the certificate on your FSx for ONTAP file system, and configuring IPsec. **To install the certificate on your file system** 1. Copy the root certificate (`rootCA.pem)`, the client certificate (`cert.pem`) and the decrypted key (`decrypted.key`) files to your file system. You will need to know the passphrase for the certificate. 1. To access the ONTAP CLI, establish an SSH session on the management port of the Amazon FSx for NetApp ONTAP file system or SVM by running the following command. Replace `management_endpoint_ip` with the IP address of the file system's management port. ``` [~]$ ssh fsxadmin@management_endpoint_ip ``` For more information, see [Managing file systems with the ONTAP CLI](managing-resources-ontap-apps.md#fsxadmin-ontap-cli). 1. Use **cat** on a client (not on your file system) to list out the contents of the `rootCA.pem`, `cert.pem` and `decrypted.key` files so that you can copy the output of each file and paste it when prompted in the following steps. ``` $ > cat cert.pem ``` Copy the certificate contents. 1. You must install all CA certificates used during the mutual authentication, including both ONTAP-side and client-side CAs, to ONTAP certificate management unless it is already installed (as is the case of an ONTAP self-signed root-CA). Use the `security certificate install` NetApp CLI command as follows to install the client certificate: ``` FSxID123:: > security certificate install -vserver dr -type client -cert-name ipsec-client-cert ``` ``` Please enter Certificate: Press when done ``` Paste in the contents of the `cert.pem` file that you copied previously and press Enter. ``` Please enter Private Key: Press when done ``` Paste in the contents of the `decrypted.key` file, and press enter. ``` Do you want to continue entering root and/or intermediate certificates {y|n}: ``` Enter `n` to complete entering the client certificate. 1. Create and install a certificate for use by the SVM. The issuer CA of this certificate must already be installed to ONTAP and added to IPsec. Use the following command to install the root certificate. ``` FSxID123:: > security certificate install -vserver dr -type server-ca -cert-name ipsec-ca-cert ``` ``` Please enter Certificate: Press when done ``` Paste in the contents of the `rootCA.pem` file, and press enter. 1. To ensure that the CA installed is within the IPsec CA searching path during authentication, add the ONTAP certificate management CAs to the IPsec module using the “security ipsec ca-certificate add” command. Enter the following command to add the root certificate. ``` FSxID123:: > security ipsec ca-certificate add -vserver dr -ca-certs ipsec-ca-cert ``` 1. Enter the following command to create the required IPsec policy in the security policy database (SPD). ``` security ipsec policy create -vserver dr -name policy-name -local-ip-subnets 198.19.254.13/32 -remote-ip-subnets 172.31.0.0/16 -auth-method PKI -action ESP_TRA -cipher-suite SUITEB_GCM256 -cert-name ipsec-client-cert -local-identity "CN=*.ec2.internal" -remote-identity "CN=*.ec2.internal" ``` 1. Use the following command to show the IPsec policy for the file system to confirm. ``` FSxID123:: > security ipsec policy show -vserver dr -instance Vserver: dr Policy Name: promise Local IP Subnets: 198.19.254.13/32 Remote IP Subnets: 172.31.0.0/16 Local Ports: 0-0 Remote Ports: 0-0 Protocols: any Action: ESP_TRA Cipher Suite: SUITEB_GCM256 IKE Security Association Lifetime: 86400 IPsec Security Association Lifetime: 28800 IPsec Security Association Lifetime (bytes): 0 Is Policy Enabled: true Local Identity: CN=*.ec2.internal Remote Identity: CN=*.ec2.internal Authentication Method: PKI Certificate for Local Identity: ipsec-client-cert ``` ## Start IPsec on the client Now IPsec is configured on both the FSx for ONTAP file system and the client, you can start IPsec on the client. 1. Connect to your client system using SSH. 1. Start IPsec. ``` $ sudo ipsec start ``` 1. Check the status of IPsec. ``` $ sudo ipsec status ``` 1. Mount a volume on your file system. ``` $ sudo mount -t nfs 198.19.254.13:/benchmark /home/ec2-user/acm/dr ``` 1. Verify the IPsec setup by showing the encrypted connection on your FSx for ONTAP file system. ``` FSxID123:: > security ipsec show-ikesa -node FsxId123 FsxId08ac16c7ec2781a58::> security ipsec show-ikesa -node FsxId08ac16c7ec2781a58-01 Policy Local Remote Vserver Name Address Address Initator-SPI State ----------- ------ --------------- --------------- ---------------- ----------- dr policy-name 198.19.254.13 172.31.77.6 551c55de57fe8976 ESTABLISHED fsx policy-name 198.19.254.38 172.31.65.193 4fd3f22c993e60c5 ESTABLISHED 2 entries were displayed. ``` ## Setting up IPsec for multiple clients When a small number of clients need to leverage IPsec, using a single SPD entry for each client is sufficient. However, when hundreds or even thousands of clients need to leverage IPsec, we recommend that you use IPsec multiple client configuration. FSx for ONTAP supports connecting multiple clients across many networks to a single SVM IP address with IPsec enabled. You can accomplish this using either the `subnet` configuration or the `Allow all clients` configuration, which are explained in the following procedures: **To configure IPsec for multiple clients using a subnet configuration** To allow all clients on a particular subnet (192.168.134.0/24 for example) to connect to a single SVM IP address using a single SPD policy entry, you must specify the `remote-ip-subnets` in subnet form. Additionally, you must specify the `remote-identity` field with the correct client side identity. **Important** When using certificate authentication, each client can use either their own unique certificate or a shared certificate to authenticate. FSx for ONTAP IPsec checks the validity of the certificate based on the CAs installed on its local trust store. FSx for ONTAP also supports certificate revocation list (CRL) checking. 1. To access the ONTAP CLI, establish an SSH session on the management port of the Amazon FSx for NetApp ONTAP file system or SVM by running the following command. Replace `management_endpoint_ip` with the IP address of the file system's management port. ``` [~]$ ssh fsxadmin@management_endpoint_ip ``` For more information, see [Managing file systems with the ONTAP CLI](managing-resources-ontap-apps.md#fsxadmin-ontap-cli). 1. Use the `security ipsec policy create` NetApp ONTAP CLI command as follows, replacing the *sample* values with your specific values. ``` FsxId123456::> security ipsec policy create -vserver svm_name -name policy_name \ -local-ip-subnets 192.168.134.34/32 -remote-ip-subnets 192.168.134.0/24 \ -local-ports 2049 -protocols tcp -auth-method PSK \ -cert-name my_nfs_server_cert -local-identity ontap_side_identity \ -remote-identity client_side_identity ``` **To configure IPsec for multiple clients using an allow all clients configuration** To allow any client, regardless of their source IP address, to connect to the SVM IPsec-enabled IP address, use the `0.0.0.0/0` wild card when specifying the `remote-ip-subnets` field. Additionally, you must specify the `remote-identity` field with the correct client side identity. For certificate authentication, you can enter `ANYTHING`. Also, when the 0.0.0.0/0 wild card is used, you must configure a specific local or remote port number to use. For example, NFS port 2049. 1. To access the ONTAP CLI, establish an SSH session on the management port of the Amazon FSx for NetApp ONTAP file system or SVM by running the following command. Replace `management_endpoint_ip` with the IP address of the file system's management port. ``` [~]$ ssh fsxadmin@management_endpoint_ip ``` For more information, see [Managing file systems with the ONTAP CLI](managing-resources-ontap-apps.md#fsxadmin-ontap-cli). 1. Use the `security ipsec policy create` NetApp ONTAP CLI command as follows, replacing the *sample* values with your specific values. ``` FsxId123456::> security ipsec policy create -vserver svm_name -name policy_name \ -local-ip-subnets 192.168.134.34/32 -remote-ip-subnets 0.0.0.0/0 \ -local-ports 2049 -protocols tcp -auth-method PSK \ -cert-name my_nfs_server_cert -local-identity ontap_side_identity \ -local-ports 2049 -remote-identity client_side_identity ```