How do I troubleshoot common BYOIP configuration errors in my VPC?

Last updated: 2022-04-05

I'm trying to configure Bring Your Own IP (BYOIP) for my Amazon Virtual Private Cloud (Amazon VPC). How can I troubleshoot common errors?

Short description

The following are common errors that might occur when configuring BYOIP in your VPC:

  • The Route Origin Authorization (ROA) is not valid or isn't found for the provided CIDR and Amazon ASNs.
  • An X509 certificate wasn't found in the WHOIS remarks.
  • The IP range is not an acceptable allocation type in the associated internet registry.
  • The CidrAuthorizationContext signature couldn't be verified with the X509 certificates in the Regional Internet Registries (RIR) records.
  • Your IP address is stuck in the pending-provision state.

Resolution

Error: The ROA is not valid or isn't found for the provided CIDR and Amazon ASNs

Create an ROA to authorize Amazon ASNs 16509 and 14618 to advertise your address ranges. It might take up to 24 hours for the ROA to make the ASNs available for Amazon.

To confirm ROA creation and ASN mapping, use WHOIS:

$ whois -h whois.bgpmon.net " --roa 16509 <Customer IP/CIDR> "
$ whois -h whois.bgpmon.net " --roa 14618 <Customer IP/CIDR> "

Example of valid output:

$ whois -h whois.example.com " --roa 14618 X.X.X.X/24"
0 - Valid
------------------------
ROA Details
------------------------
Origin ASN: AS14618
Not valid Before: 2019-02-20 05:00:00
Not valid After: 2020-02-20 05:00:00 Expires in 266d11h4m39s
Trust Anchor: rpki.arin.net
Prefixes: X.X.X.X/24 (max length /24)

Example of non-valid output:

$ whois -h whois.example.com " --roa 14618 X.X.X.X/24"
2 - Not Valid: Invalid Origin ASN, expected 16509

To avoid this error:

  • The ROA must be valid for both ASNs for the period in use and be specific for the address ranges that you're bringing into AWS. For more information, see the Preparing your IP address range section in Introducing Bring Your Own IP (BYOIP).
  • Wait 24 hours after creating an ROA before re-provisioning.

Error: No X509 certificate could be found in the WHOIS remarks

Common reasons for this error include the following:

  • A certificate wasn't provided in the RDAP record for the RIR.
  • There are new line characters in the certificate.
  • The certificate provided isn’t valid.
  • The certificate isn't generated from the valid key pair.

Make sure that you create and upload the certificate correctly. For more information, see Create a key pair for AWS authentication.

To troubleshoot this error, verify that the uploaded certificate is valid. You can use WHOIS to check the record for the network range in the RIR.

For ARIN:

whois -a <Public IP>

Check the Comments section for the NetRange (network range). Make sure that the certificate is added in the Public Comments section for your address range.

For RIPE:

whois -r <Public IP>

Check the descr section for the inetnum object (network range) in the WHOIS display. Make sure that the certificate is added in the desc field for your address range.

For APNIC:

whois -A <Public IP>

Check the remarks section for the inetnum object (network range) in the WHOIS display. Make sure that the certificate is in the remarks field for your address range.

After completing the preceding check, do the following:

1.    If there isn't a certificate, create a new certificate, and then upload it following the recommendations outlined in this Resolution section.

2.    If there is a certificate, then make sure that there are no new lines. If there are any new lines, remove as shown in the following example:

openssl req -new -x509 -key private.key -days 365 | tr -d "\n" > publickey.cer

3.    Verify that the provided certificate is valid. To do this, copy the certificate content into a new file and run the following command:

openssl x509 -in example.crt -text -noout

If you receive an unable to load certificate error, add a new line after BEGIN CERTIFICATE and another new line before END CERTIFICATE.

4.    If none of the above apply, then the certificate was generated using an incorrect key pair.

Error: The IP range isn't an acceptable allocation type in the associated internet registry

Possible reasons for this error include the following:

  • The RIR allocation type for the address range is wrong.
  • The registry is unsupported.

There are five regional internet registries (RIR) - AFRINIC, ARIN, APNIC, LACNIC and RIPE. AWS supports ARIN, RIPE, and APNIC registered prefixes.

To verify the RIR, use WHOIS:

whois <public ip>

For RIPE: Verify that the Status is ALLOCATED PA, LEGACY or ASSIGNED PI.

For ARIN: Verify that the NetType is Direct Allocation or Direct Assignment.

For APNIC: Verify that the Status is ALLOCATED PORTABLE or ASSIGNED PORTABLE.

Note: Some comments might state Addresses within this block are non-portable. This comment is an additional confirmation that the RIR can't provision that address range.

The preceding error occurs for the following reasons:

  • If the Status (for RIPE and APNIC) or NetType (for ARIN) is none of the above.
  • If it is an unsupported registry.

Error: The CidrAuthorizationContext signature could not be verified with the X509 certificates in the RIR records

When you provision the address ranges, AWS uses the public key derived from the certificate to verify the signature in the aws ec2 provision-byoip-cidr API call. This error indicates a failure to cryptographically verify the provided signature.

The following are common reasons for this error:

  • You aren't using the right signature when provisioning.
  • You signed the message with the wrong private key.
  • You uploaded the wrong certificate in the RDAP record with the RIR

Error: Stuck in "pending-provision" state

It can take up to one week to complete the provisioning process for publicly advertisable ranges. Use the describe-byoip-cidrs command to monitor progress, as shown in the following example:

aws ec2 describe-byoip-cidrs --max-results 5 --region us-east-1

If the status changes to failed-provision, you must run the provision-byoip-cidr command again after the issues have been resolved.

For more information, see Provision a publicly advertised address range in AWS.


Did this article help?


Do you need billing or technical support?