aws-samples / vpn-gateway-strongswan Goto Github PK

So that we can go back and inspect older events

The REGION parameter in manage-stack is set to us-east-2.
Update notes in README that users need to set the appropriate region in line 81 for REGION=< > if it needs to be other than us-east-2

Highlighting the roles played by:

• StrongSWAN
• Quagga components

If another process on the EC2 instance has the Yum repo locked while the following yum operations are attempted, the yum client could timeout and an error could occur stating that one of the following packages could not be found.

        04-config-vpn-gateway-config:
          packages:
            yum:
              strongswan: []
              ntp: []
              quagga: []
              jq: []

For example, if your organization has an automated patching process that attempts to perform a yum update operation immediately when an EC2 instance is powered on the first time, that yum operation might conflict with the cfn-init first boot script contained in the CloudFormation template.

See if it is feasible with Strongswan and then consider optionally supporting it.

To account for EC2 bootstrapping work that can sometimes take longer than the current timeout of 300 seconds / 5 minutes.

Provide same automation via AWS Cloud Development Kit (CDK).

Provide a parameter to automatically configure source IP address translation for traffic leaving the strongSwan VPN gateway so that remotely sourced traffic can be routed beyond the local VPC via, for example, either an Internet Gateway or NAT Gateway. See the Advanced Usage section of the README.md for manual configuration instructions.

See https://fedoraproject.org/wiki/How_to_edit_iptables_rules for examples of how to persist iptables rules.

Automating and persisting this configuration will require installation of the following package and enablement of the iptables service:

$ sudo yum install iptables-services

$ sudo systemctl enable iptables.service

As a user, I need the troubleshooting docs to highlight what goes wrong when a PSK value is incorrect so that I can more quickly understand the root cause of a problem.

For example, when a PSK value is bad, you might notice that the associated tunnel doesn't come up and the charon.log contains entries such as:

I am thinking of convert this to CDK typescript, however, I am stuck at how to automatically download and parse the configuration. Any one has any suggestion?

The current CloudFormation template doesn't support certificate authentication.

A person who attempted to modify a working non-cert auth configuration based on this template was unable to get the connection to work towards the end of phase 2 (no meaningful error messages from charon.log).

This issue will collect notes on how to get this working so that we can eventually enhance the CloudFormation template to support it.

Enhance the troubleshooting section to help people figure out conditions in which the tunnels are shown as down but IPSEC is up. This may be due to BGP not being established across both tunnels.

As a user, I need the README to be more clear about the on-premises environment networking requirements so that I address those before attempting to deploy the stack.

For example, the requirement for an Internet gateway and the option to use a NAT gateway.

See To Do comment in latest version of the template for an overview of the approach to be implemented.

For example, provide a script to translate the AWS VPN configuration file to a standard CloudFormation parameter file and provide an example of using the CLI to create the stack.

CDK could be an even more effective means to accept the VPN config file as one of the inputs.

The template had been using an outdated and more complicated method than the latest recommended approach. No modifications are needed to the CloudFormation template parameters.

After several minutes, the stack failed and roll-back

WaitCondition received failed message: 'Configuration failed.' for uniqueId: i-01b63746b6787182e

logical id

rVpnGatewayWaitCondition1

I encountered this condition during a stack deployment attempt, but have not encountered it again.

First boot configuration fails via a CloudFormation event:

WaitCondition received failed message: 'Configuration failed.' for uniqueId: i-0....

Digging into cfn-init.log shows the cause of the stack creation failure, but it's unclear as to what caused ntpd to fail to restart. Requires further investigation.

2021-09-22 16:27:20,378 [DEBUG] Running command 02-enable-ip-forwarding
2021-09-22 16:27:20,379 [DEBUG] No test for command 02-enable-ip-forwarding
2021-09-22 16:27:20,387 [INFO] Command 02-enable-ip-forwarding succeeded
2021-09-22 16:27:20,387 [DEBUG] Command 02-enable-ip-forwarding output: net.ipv4.ip_forward = 1
net.ipv4.conf.eth0.disable_xfrm = 1
net.ipv4.conf.eth0.disable_policy = 1

2021-09-22 16:27:20,387 [DEBUG] Running command 03-enable-start-ntpd
2021-09-22 16:27:20,387 [DEBUG] No test for command 03-enable-start-ntpd
2021-09-22 16:27:20,479 [ERROR] Command 03-enable-start-ntpd (systemctl enable ntpd &&  systemctl start  ntpd) failed
2021-09-22 16:27:20,479 [DEBUG] Command 03-enable-start-ntpd output: Created symlink from /etc/systemd/system/multi-user.target.wants/ntpd.service to /usr/lib/systemd/system/ntpd.service.Failed to start ntpd.service: Transaction is destructive.
See system logs and 'systemctl status ntpd.service' for details.

2021-09-22 16:27:20,479 [ERROR] Error encountered during build of 06-config-vpn-gateway-commands: Command 03-enable-start-ntpd failed
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py", line 573, in run_config
    CloudFormationCarpenter(config, self._auth_config).build(worklog)
  File "/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py", line 273, in build    self._config.commands)
  File "/usr/lib/python3.7/site-packages/cfnbootstrap/command_tool.py", line 127, in apply
    raise ToolError(u"Command %s failed" % name)
cfnbootstrap.construction_errors.ToolError: Command 03-enable-start-ntpd failed
2021-09-22 16:27:20,487 [ERROR] -----------------------BUILD FAILED!------------------------
2021-09-22 16:27:20,487 [ERROR] Unhandled exception during build: Command 03-enable-start-ntpd failed
Traceback (most recent call last):
  File "/opt/aws/bin/cfn-init", line 176, in <module>
    worklog.build(metadata, configSets)
  File "/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py", line 135, in build
    Contractor(metadata).build(configSets, self)
  File "/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py", line 561, in build
    self.run_config(config, worklog)
  File "/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py", line 573, in run_config
    CloudFormationCarpenter(config, self._auth_config).build(worklog)
  File "/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py", line 273, in build
    self._config.commands)
  File "/usr/lib/python3.7/site-packages/cfnbootstrap/command_tool.py", line 127, in apply
    raise ToolError(u"Command %s failed" % name)
cfnbootstrap.construction_errors.ToolError: Command 03-enable-start-ntpd failed

Include the AWS region identifier in the IAM roles and instance profiles created by the template so that the template can be more easily used within the same account in multiple regions.

A workaround is to set either the pApp or pEnvPurpose parameters to distinguish between instances of the stack in different regions. e.g. pAppEnvPurpose = prod-us-west-2.

Validate that the gateway function properly after EC2 instance is restarted. e.g. that all settings are persistent and system services come up automatically upon OS restart.

The recent change to use Secrets Manager for fetching the PSKs defaults to US-East-2. Please create a parameter or mention this in prerquisites. This causes the stack create to fail if you're not using US-East-2.

https://github.com/aws-samples/vpn-gateway-strongwswan/blob/b090ae222e1f6813cc1a0faffa29a2b0fd1bd7e3/vpn-gateway-strongswan.yml#L760

This repository is named vpn-gateway-strongwswan (note the extra w between strong and swan), which makes use of strongSwan. So, should it be named vpn-gateway-strongswan instead?

As a user, I need a screenshot of an AWS Secrets Manager configuration for both PSK and client private key passphrase so that it's more clear to me how to configure entries in Secrets Manager to support the VPN connection.

As a user, I need the stack to support updating parameter values that impact the cfn-init configuration process so that I can reconfigure the VPN connection without needing to delete and recreate the stack.

For example, when one of the PSK or client private key passphrase values is incorrect and you need to update it.

Hello,

Thanks for this sample! I'm surely doing something wrong but I cannot initiate the stack. I'm using the CLI way (same problem using the Web UI) and PSK mode. It always fails with "The following resource(s) failed to create: [rVpnGatewayWaitCondition1]. Rollback requested by user." (from scfn stack creation event stream).

Before this, everything looks fine (EIP association seems OK, the instance comes up, ...), but I cannot verify anything because even though the Cloudwatch Log Group is created (with the default path from the script /infra/vpngw/ec2/test15), no Log Stream is created.

What can I do to get more information and troubleshoot the issue?

Thanks a lot!

Similar to how the passphrase for the client private key is obtained from AWS Secrets Manager, implement support for obtaining the PSK values from AWS Secrets Manager.

Basically changing the parameters pTunnel1Psk and pTunnel2Psk to be pTunnel1PskSecretName and pTunnel2PskSecretName and requiring those secrets to be added to AWS Secrets Manager as a prerequisite. The cfn-init scripts will need to change to perform similar actions as it already performed in support of obtaining the client private key passphrase from AWS Secrets Manager and populating the proper strongSwan configuration file.

When a command or script during execution of cfn-init during first boot of the EC2 instance fails, the subsequent invocation of cfn-signal to inform CloudFormation is not occurring. Consequently, upon such failures, CloudFormation stack creation continues until the overall timeout expires.