- Newest
- Most votes
- Most comments
Hi,
My first take on your case is the following:
- the routing at the Transit Gateway will be VERY tricky to define
- Indeed, you need to distinct routes from the client to the server
- the first route in TG for server destination will have to be used in step (2) when the packet in not yet inspected and need to go through the firewall to get inspected even if its destination says "server"
- the second route in TG for server destination will have to be used when the packet has been inspected and is clean
I don't know if such a status-based routing is possible: the basic IP routing just focuses on destination, which is identical before and after inspection in your case.
So, I would personally change this architecture in 2 ways:
- either, have a destination address (=server) rewrite by the firewall when inspecting packet so that the routing table has 2 separate destinations for the packet: 1/ server public address pre-inspection and 2/ server private address post inspection. That will lead you to simpler routing definitions in the TG.
- simplify the architecture by removing the TG and have a classical cascade with no loop through the inspector: so VPC client <-> packet inspector <-> VPC server . That would be simpler to implement and more secure.
Bets,
Didier
I used AWS linux EC2 to simulate fw. It just came to my mind, do you think the issue might be caused by source/destination not being checked ? As I am only focusing incoming traffic to the frontend interface now.
thanks !
answered 2 years ago
Thanks so much for a quick look. This topology is almost the same as the one Juniper training course. The lab for the course works fine, but most of resources are created by cloudFormation, the lab task only covers how to configure TGW. I purposely created all the resources manually to try to understand all the nuances. Unfortunately it does not work. I do not understand why reachability analyzer does not list the step sending the traffic to the service VPC. From reachability analyzer, it seems the first route table (gyu-tgw2service-RT) is never used. right ?
Kind of frustrating !!
answered 2 years ago
Based on the information provided, it appears you're trying to implement a centralized inspection architecture using AWS Transit Gateway and a firewall in a Service VPC. The issue you're experiencing is that traffic is not being routed through the firewall as expected. Here are some potential reasons and suggestions for troubleshooting:
-
Transit Gateway Route Table: Your TGW-Service-RT seems to be correctly configured with a default route (0.0.0.0/0) pointing to the Service VPC attachment. However, ensure that this route table is associated with both the Client and Server VPC attachments.
-
VPC Route Tables: The VPC route table you've shown (presumably for the Service VPC) looks correct, with the default route pointing to the firewall interface. Verify that the Client and Server VPCs have route tables with a default route (0.0.0.0/0) pointing to the Transit Gateway.
-
Firewall Configuration: Ensure that the firewall in the Service VPC is properly configured to allow and inspect traffic between the Client and Server VPCs.
-
Transit Gateway Attachment Configuration: For the Service VPC attachment on the Transit Gateway, verify that "Appliance Mode" is enabled. This helps maintain flow symmetry for traffic inspection.
-
Security Groups and Network ACLs: Check that the security groups for the instances in all VPCs and the network ACLs for all subnets allow the necessary traffic.
-
Reachability Analyzer Results: The Reachability Analyzer output shows that the default route is not being taken. This could indicate an issue with route propagation or association in the Transit Gateway.
To further troubleshoot:
- Double-check all route table associations in both the VPCs and the Transit Gateway.
- Verify that the firewall instance in the Service VPC is running and configured correctly.
- Use VPC Flow Logs to track the path of traffic between VPCs.
- Test connectivity between instances in different VPCs using tools like ping or traceroute to identify where traffic might be getting dropped or misrouted.
If you're still having issues after checking these points, you may want to review your entire configuration against AWS documentation for centralized inspection architectures or consider engaging AWS support for more detailed troubleshooting.
Sources
Question about Service VPC through which all the traffic goes ? | AWS re:Post
VPC-to-VPC traffic inspection - AWS Prescriptive Guidance
Troubleshoot VPN routing issues | AWS re:Post
I just tested and confirmed it is caused by source / dest check enabled. After I disabled it, it worked as expected. I could see the traffic from the client on the fw front interface.
WOW, this caused me numerous hours, but still very happy to figure it out.
thanks a lot for all !!!
answered 2 years ago
Relevant content
asked 4 years ago

Please, add your follow-up questions as comments to my own answer otherwise I won't be notified