1 Answer
- Newest
- Most votes
- Most comments
1
Hey Nick, I have seen this before. Can you confirm your VPC CIDR range?
I believe TMobile are using some of the 172.32.0.0 Cidr range. If your VPC is the same that’s the issue.
https://bgpview.io/prefix/172.32.0.0/11
If your using this range then this is the cause as it’s not a RFC1918 address space and shouldn’t be used in a private VPC.
If you are using an overlapping address space then the prefence for the return traffic will stay local to the VPC and a timeout will occur
Relevant content
- asked 6 months ago
- asked a year ago
- asked a year ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
I think this is it. VPC is 172.40.0.0/16 ... It's from like 2016 or something.
Don't suppose there is a way to readdress this space?
That looks like this could be your issue to me. You have an overlap with T mobile. Their usable range is 172.32.0.1 - 172.63.255.254
Your VPC address space is not in the private range. This may or may not be intentional but it’s certainly not in the private RFC1918 address space.
If you can confirm the source address this will helps confirm if this is the issue.
If the source IP from T Mobile is the same as your VPC range you will have issues.
You may be able to add a 2nd CIDR range to the VPC but you can’t readdress a VPC. You may be able to create an intermediate ingress VPC to front your production VPC with using another set of load balancers. Create a service endpoint in your PROD account and grant access to the intermediate VPC. Create new ALB in the intermediate VPC and send traffic to the Endpoint
Hey Nick. Does this answer your question?