I'm working on establishing a site-to-site IPsec VPN between our AWS environment and a customer's FortiGate firewall. The AWS setup is complete, and I've shared the FortiGate configuration with them. However, the customer insists that they cannot accept any RFC 1918 private IP ranges from our AWS side and need us to advertise public IP addresses instead. I've learned that AWS's standard site-to-site VPN through a Virtual Private Gateway doesn't support sending public IP ranges through the tunnel. I came across a suggestion that I should use a Transit Gateway along with an EC2 NAT instance in a separate VPC to convert private addresses into public ones before sending them over the VPN. My questions are: 1. Is using a NAT instance like this a reliable solution for production, or is it just a workaround? 2. Is a Transit Gateway necessary for this setup, or does AWS have a way to natively advertise public IPs over a standard IPsec VPN?
3 Answers
Another thought: you could try using 0.0.0.0/0 for your setup. It has worked for me between AWS and another cloud provider.
One option you can consider is adding a secondary CIDR block to your VPC that doesn’t fall within the RFC1918 range—like using 100.64.0.0/10. You can set up subnets from this range for the workloads that need to communicate with the customer. Then, you can use your existing VPN with BGP, which will advertise this new CIDR to the FortiGate without needing a Transit Gateway.
Just a heads-up: you can't actually add 100.64.0.0/10 as a secondary block to your VPC. The blocks you can add have to be a max size of /16, but your idea is solid otherwise!
Thanks for the input! I’m thinking about creating a new VPC with a /16 block under the 100.70.0.0 range and connecting that via VPN.
You should be cautious because RFC1918 addresses are private and not managed by a governing body, which means your customer might already use those ranges internally. If you announce them over BGP, it could mess up their internal routing. They have valid reasons to refuse those announcements. It would be best to work together with their networking team to establish a network that only uses public IP addresses or a non-overlapping address range like 100.64.0.0/10, ensuring proper traffic forwarding without direct layer-3 routing.
I appreciate this breakdown! I’m going to steer clear of complex setups or NAT configurations, and I’ll go with the suggestion to create a new VPC with 100.70.0.0/16 to advertise via BGP.
That might not work as intended...BGP requires specific CIDR ranges to be advertised, and your customer needs to know these ranges upfront.