- Newest
- Most votes
- Most comments
Based off your routes provided it makes logical sence to add a new route to the NAT instance as follows for the other subnet
I am assuming eni-04682433028b75d56 is eth1 on the NAT device
10.63.3.0/24 via 10.63.2.1 dev eth1
Please can you provide route tables for the subnets in question.
Can you provide route table inside of the NAT instance also.
Your NAT instance will need a route back to subnet C out of the correct interface too. I’ve a feeling your default route inside your NAT instance my be breaking the return traffic to subnet C. Without seeing all the routes it’s hard to be sure. I assume the instances on subnet b are on the same subnet as the NAT instance. If so then naturally the route table routes subnet b out of the correct interface where as subnet c is taking the default route.
Thanks
Surely, thanks for the suggestion! I added a new answer with formatted response
Surely, thanks for the suggestion!
Main rtb:
Destination | Target |
---|---|
2a05:d014:97d:e000::/56 | local |
10.63.0.0/16 | local |
For public subnet:
Destination | Target |
---|---|
::/0 | igw-07ee2278a218a671f |
2a05:d014:97d:e000::/56 | local |
0.0.0.0/0 | igw-07ee2278a218a671f |
10.63.0.0/16 | local |
For private subnets (the same for both):
Destination | Target |
---|---|
::/0 | eigw-0f26feb7612f0017b |
2a05:d014:97d:e000::/56 | local |
0.0.0.0/0 | eni-04682433028b75d56 |
10.63.0.0/16 | local |
Routes on Linux - private B
default via 10.63.2.1 dev eth0
10.63.2.0/24 dev eth0 proto kernel scope link src 10.63.2.164
169.254.169.254 dev eth0
Routes on Linux - private C
default via 10.63.3.1 dev eth0
10.63.3.0/24 dev eth0 proto kernel scope link src 10.63.3.135
169.254.169.254 dev eth0
Routes on Linux - NAT
default via 10.63.1.1 dev eth0
default via 10.63.2.1 dev eth1 metric 10001
10.63.1.0/24 dev eth0 proto kernel scope link src 10.63.1.244
10.63.2.0/24 dev eth1 proto kernel scope link src 10.63.2.159
169.254.169.254 dev eth0
thanks for that.. is eni-04682433028b75d56 eth1 of the NAT box?
Relevant content
- asked 2 years ago
- Accepted Answerasked 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 7 months ago
- AWS OFFICIALUpdated 2 years ago
It indeed worked! Thanks a lot! Is it possible for the instances to somehow deduce it from VPC route tables?
You had an asymetric routing issue on your machine because the return traffic was trying to go via eth0 which default routes to the internet. You will have to perform the same steps for any other subnets you add. If you are adding routes manually, the routes will be lost on a reboot. You will need to make these persistant routes by adding to your eth1 config files https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configuring_static_routes_with_ip_commands https://www.configserverfirewall.com/ubuntu-linux/add-permanent-static-route-ubuntu/
You may be able to write some automation script to do this but you would need to enumerate Subnets, Route tables etc.. Theres no automation to do this. Afraid its just how IP Routing works
Just had a thought.. You could try and add your CIDR Range instead.. (confirm your CIDR Range)
10.63.0.0/16 via 10.63.2.1 dev eth1
The other 2 routes will remain which is good they have a higher preference Then you will not need to make changes for new subnets
Thanks again, I added persistence scripts to user data, fortunately with IaC it's not that much effort to make a loop through all subnets :)