- Newest
- Most votes
- Most comments
Hello, Ensure correct routing in the route tables for both subnets, allowing traffic from User VM Subnet (Subnet2) to reach the Firewall Subnet (Subnet62) and outbound to the internet via the internet gateway (IGW). Review Firewall configuration, including stateful rules, to permit outbound access. Verify security group settings for both Firewall and User VM instances, ensuring appropriate outbound traffic permissions. Check Network ACLs to confirm they're not blocking traffic. Utilize CloudWatch Logs for monitoring. Test connectivity by pinging or tracerouting from User VMs to Firewall's IP. refer document for more info : https://docs.aws.amazon.com/vpc/ i hope this will help full
Hello,
please try this solution.
Firewall Configuration:
Verify that your AWS Firewall (e.g., AWS Network Firewall) is correctly configured to allow outbound internet access to permitted sites like google.com.
Confirm that the stateful rule allowing access to google.com is properly configured and associated with the firewall policy assigned to the firewall subnet (Subnet62).
Routing Configuration:
Check the route table associated with Subnet62 (the subnet containing the firewall). Ensure it has a route to direct traffic to the internet gateway or NAT gateway for outbound internet access. The route should have a destination of 0.0.0.0/0 pointing to the internet gateway or NAT gateway.
Confirm that the route table associated with the User VM Subnet (Subnet2) has a route to direct traffic destined for the firewall subnet (Subnet62) to the firewall's private IP address. This route should have a destination of Subnet62's CIDR range (10.10.62.0/28) pointing to the private IP address of the firewall.
Security Group Configuration:
Review the security group associated with the firewall instance to ensure it allows inbound traffic from the User VM Subnet (Subnet2) on the necessary ports for communication with the firewall (e.g., SSH for management purposes).
Verify that the security group allows outbound traffic from the firewall to the internet on the required ports (e.g., HTTP/HTTPS for web access).
Network ACLs:
Check the network ACLs associated with both the firewall subnet (Subnet62) and the User VM Subnet (Subnet2) to ensure they permit the necessary inbound and outbound traffic. Network ACLs can block traffic even if the route tables and security groups are properly configured.
I don't see a NAT gateway referenced anywhere in your configuration. You'll need to route traffic from the firewall to the internet through a NAT gateway in order for the private 10.* source IPs to be translated to a public IP on their way out to the public internet.
You also have a direct route from the IGW to the user subnet pointing to the firewall. This route won't be needed when connections to the internet will have been hidden behind the NAT gateway's EIP. Return traffic from the internet will have a destination IP of the NAT gateway's public IP instead of the original 10.* IP in the user subnet. Instead, the subnet where you place the NAT gateway must have a route table attached containing a route towards the user subnet that points to the firewall's VPC endpoint.
Relevant content
- asked 2 years ago
- asked 4 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 24 days ago
- AWS OFFICIALUpdated 7 months ago
Indeed, an esoteric detail about AWS Network Firewall is the absence of address translation capability. For the sake of completeness, it's possible to have a design similar to the original, without a NAT gateway, by attaching public IPs directly to the EC2 instances instead and having your original IGW route table divert incoming internet traffic to the FW. Of course, your final design with the NAT GW is superior, because it doesn't waste public IPs or needlessly give the servers IPs that anyone on the internet could attempt to connect to, even if the attempts would be blocked by the FW.
I think the missing route that I also didn't consider is from the IGW towards the firewall for the subnet(s) where the NAT gateway(s) are located, which I take it is 10.10.63.x/y. That's because the VPC's internal routing only considers the private IP of the NAT gateway for routing purposes, even though the final IP packets on the internet will have the NAT gateway's public Elastic IP in its place. Anyhow, since the broader route 10.10.0.0/18 also covers the NAT gateway's subnet, it'll work with the shorter prefix as well, as you saw happening.
Hello Leo, I wasn't aware that USER VLAN > NAT > FIREWALL > INTERNET GATEWAY was a viable option, the videos i reviewed never mentioned the NAT. You've pointed me in the right direction.
I have found the following https://docs.aws.amazon.com/network-firewall/latest/developerguide/arch-igw-ngw.html
So, for now the routing setup is as follows
User Subnet2 > NAT Gateway Subnet63 - This NAT gateway was alluded to before but removed as I was under the impression it wasn't needed. 10.10.0.0/18 local 10.20.0.0/16 vgw-******* 0.0.0.0/0 nat-********
NAT Gateway Subnet63 > Firewall Subnet62 10.10.0.0/18 local 0.0.0.0/0 vpce-**********
Firewall subnet> Internet Gateway 10.10.0.0/18 local 0.0.0.0./0 igw-*********
I can confirm, user VM on 10.10.2.0/24 can reach the NAT Gateway and then the internet.
I wasn't able to say for sure that the traffic was hitting the firewall, not immediately anyway, as the cloudwatch logs take a while to catchup. PING and Curl were passing without issue despite rules in place however, after setting a stateless rule to drop ALL protocols traffic stopped so, looks like it is indeed hitting the firewall!
I just need to work on my rules, thank you!
Thanks again, that make sense. I also need to add a route I forgot to mention. Its the route that has the Edge Association with the firewall vpce-********* 10.10.0.0/18 targets vpce-********* - without this the internet doesn't work.