If you’ve been using an AWS Site-to-Site VPN connection with an on-premises network secured by a FortiGate firewall, and suddenly the connection stops working without any apparent changes, don’t worry. Here’s a simple way to troubleshoot and fix the problem.
First, confirm that your VPN tunnels are still marked as UP on both the AWS and on-premise sides. If the tunnels are active, the issue is likely related to how your routes are configured. Even if the VPN connection appears normal, the traffic may not be reaching the correct destination due to routing issues.
Next, try testing connectivity from your on-prem network to AWS and vice versa. Send ICMP pings and watch if they reach their target. In some cases, pings from on-prem to AWS may not reach the instances, or responses from AWS may not make it back on the on-prem side.
One thing you may notice is that adding individual server IP addresses as /32 static routes in AWS temporarily restores connectivity. For example, if adding 10.104.8.10/32 or 10.104.9.15/32 makes the specific server reachable, but your broader 10.104.0.0/16 route does not, then the problem likely stems from how the larger subnet route is handled.
However, adding every server as a separate route isn’t practical. It’s not sustainable when you have many servers. The solution here is to re-examine your route setup. Make sure your AWS route table points to the Virtual Private Gateway with the 10.104.0.0/16 route, as before.
Since nothing changed on your side and the tunnel remains UP, it’s worthwhile to:
– Check the FortiGate firewall’s routing and NAT settings to ensure that nothing has been altered or is blocking traffic for the entire /16 subnet.
– Confirm there are no new security policies blocking traffic from the VPN.
– Make sure that the FortiGate’s routing tables include a route back to the 10.104.0.0/16 subnet via the AWS VPN.
Sometimes, issues like this are caused by subtle changes or internal updates that impact how a large CIDR block is handled. If individual IPs are working but the entire subnet isn’t, it hints at a possible problem with the firewall’s routing or NAT rules affecting the larger route.
If all settings seem correct and the problem persists, consider reaching out for support from AWS and FortiGate. They can review logs and settings to identify if something in the network chain has been misconfigured or needs an update.
In summary, focus on:
– Confirming tunnel status.
– Verifying routes on both sides.
– Checking firewall configurations.
– Testing connectivity with individual IPs.
– Ensuring no security policies are blocking the traffic.
By systematically going through these steps, you should be able to pinpoint the issue and restore full connectivity without needing to add every server individually.