This is a cache of https://docs.openshift.com/rosa/rosa_cluster_admin/cloud_infrastructure_access/dedicated-aws-vpn.html. It is a snapshot of the page at 2024-11-27T03:08:09.190+0000.
Configuring AWS VPN - Configuring private connections | Cluster administration | Red Hat OpenShift Service on AWS
×

This sample process configures an Amazon Web Services (AWS) Red Hat OpenShift Service on AWS cluster to use a customer’s on-site hardware VPN device.

AWS VPN does not currently provide a managed option to apply NAT to VPN traffic. See the AWS Knowledge Center for more details.

Routing all traffic, for example 0.0.0.0/0, through a private connection is not supported. This requires deleting the internet gateway, which disables SRE management traffic.

For more information about connecting an AWS VPC to remote networks using a hardware VPN device, see the Amazon VPC VPN Connections documentation.

Creating a VPN connection

You can configure an Amazon Web Services (AWS) Red Hat OpenShift Service on AWS cluster to use a customer’s on-site hardware VPN device using the following procedures.

Prerequisites
  • Hardware VPN gateway device model and software version, for example Cisco ASA running version 8.3. See the Amazon VPC Network Administrator Guide to confirm whether your gateway device is supported by AWS.

  • Public, static IP address for the VPN gateway device.

  • BGP or static routing: if BGP, the ASN is required. If static routing, you must configure at least one static route.

  • Optional: IP and Port/Protocol of a reachable service to test the VPN connection.

Configuring the VPN connection

Procedure
  1. Log in to the Red Hat OpenShift Service on AWS AWS Account Dashboard, and navigate to the VPC Dashboard.

  2. Click on Your VPCs and identify the name and VPC ID for the VPC containing the Red Hat OpenShift Service on AWS cluster.

  3. From the VPC Dashboard, click Customer Gateway.

  4. Click Create Customer Gateway and give it a meaningful name.

  5. Select the routing method: Dynamic or Static.

  6. If Dynamic, enter the BGP ASN in the field that appears.

  7. Paste in the VPN gateway endpoint IP address.

  8. Click Create.

  9. If you do not already have a Virtual Private Gateway attached to the intended VPC:

    1. From the VPC Dashboard, click on Virtual Private Gateway.

    2. Click Create Virtual Private Gateway, give it a meaningful name, and click Create.

    3. Leave the default Amazon default ASN.

    4. Select the newly created gateway, click Attach to VPC, and attach it to the cluster VPC you identified earlier.

Establishing the VPN Connection

Procedure
  1. From the VPC dashboard, click on Site-to-Site VPN Connections.

  2. Click Create VPN Connection.

    1. Give it a meaningful name tag.

    2. Select the virtual private gateway created previously.

    3. For Customer Gateway, select Existing.

    4. Select the customer gateway device by name.

    5. If the VPN will use BGP, select Dynamic, otherwise select Static. Enter Static IP CIDRs. If there are multiple CIDRs, add each CIDR as Another Rule.

    6. Click Create.

    7. Wait for VPN status to change to Available, approximately 5 to 10 minutes.

  3. Select the VPN you just created and click Download Configuration.

    1. From the dropdown list, select the vendor, platform, and version of the customer gateway device, then click Download.

    2. The Generic vendor configuration is also available for retrieving information in a plain text format.

After the VPN connection has been established, be sure to set up Route Propagation or the VPN may not function as expected.

Note the VPC subnet information, which you must add to your configuration as the remote network.

Enabling VPN route propagation

After you have set up the VPN connection, you must ensure that route propagation is enabled so that the necessary routes are added to the VPC’s route table.

Procedure
  1. From the VPC Dashboard, click on Route Tables.

  2. Select the private Route table associated with the VPC that contains your Red Hat OpenShift Service on AWS cluster.

    On some clusters, there may be more than one route table for a particular VPC. Select the private one that has a number of explicitly associated subnets.

  3. Click on the Route Propagation tab.

  4. In the table that appears, you should see the virtual private gateway you created previously. Check the value in the Propagate column.

    1. If Propagate is set to No, click Edit route propagation, check the Propagate checkbox next to the virtual private gateway’s name and click Save.

After you configure your VPN tunnel and AWS detects it as Up, your static or BGP routes are automatically added to the route table.

Verifying the VPN connection

After you have set up your side of the VPN tunnel, you can verify that the tunnel is up in the AWS console and that connectivity across the tunnel is working.

Prerequisites
  • Created a VPN connection.

Procedure
  1. Verify the tunnel is up in AWS.

    1. From the VPC Dashboard, click on VPN Connections.

    2. Select the VPN connection you created previously and click the Tunnel Details tab.

    3. You should be able to see that at least one of the VPN tunnels is Up.

  2. Verify the connection.

    To test network connectivity to an endpoint device, nc (or netcat) is a helpful troubleshooting tool. It is included in the default image and provides quick and clear output if a connection can be established:

    1. Create a temporary pod using the busybox image, which cleans up after itself:

      $ oc run netcat-test \
          --image=busybox -i -t \
          --restart=Never --rm \
          -- /bin/sh
    2. Check the connection using nc.

      • Example successful connection results:

        / nc -zvv 192.168.1.1 8080
        10.181.3.180 (10.181.3.180:8080) open
        sent 0, rcvd 0
      • Example failed connection results:

        / nc -zvv 192.168.1.2 8080
        nc: 10.181.3.180 (10.181.3.180:8081): Connection refused
        sent 0, rcvd 0
    3. Exit the container, which automatically deletes the Pod:

      / exit

Troubleshooting the VPN connection

Tunnel does not connect

If the tunnel connection is still Down, there are several things you can verify:

  • The AWS tunnel will not initiate a VPN connection. The connection attempt must be initiated from the Customer Gateway.

  • Ensure that your source traffic is coming from the same IP as the configured customer gateway. AWS will silently drop all traffic to the gateway whose source IP address does not match.

  • Ensure that your configuration matches values supported by AWS. This includes IKE versions, DH groups, IKE lifetime, and more.

  • Recheck the route table for the VPC. Ensure that propagation is enabled and that there are entries in the route table that have the virtual private gateway you created earlier as a target.

  • Confirm that you do not have any firewall rules that could be causing an interruption.

  • Check if you are using a policy-based VPN as this can cause complications depending on how it is configured.

  • Further troubleshooting steps can be found at the AWS Knowledge Center.

Tunnel does not stay connected

If the tunnel connection has trouble staying Up consistently, know that all AWS tunnel connections must be initiated from your gateway. AWS tunnels do not initiate tunneling.

Red Hat recommends setting up an SLA Monitor (Cisco ASA) or some device on your side of the tunnel that constantly sends "interesting" traffic, for example ping, nc, or telnet, at any IP address configured within the VPC CIDR range. It does not matter whether the connection is successful, just that the traffic is being directed at the tunnel.

Secondary tunnel in Down state

When a VPN tunnel is created, AWS creates an additional failover tunnel. Depending upon the gateway device, sometimes the secondary tunnel will be seen as in the Down state.

The AWS Notification is as follows:

You have new non-redundant VPN connections

One or more of your vpn connections are not using both tunnels. This mode of
operation is not highly available and we strongly recommend you configure your
second tunnel. View your non-redundant VPN connections.