View a markdown version of this page

Troubleshooting a Next Generation policy - Amazon Network Firewall
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Troubleshooting a Next Generation policy

The most common issue with a default-drop policy is traffic that you expected to be allowed being dropped, usually because no rule accepted it at one of the connection's hooks. This section describes how to find out what happened, using your logs, metrics, and monitor mode.

Check your alert logs

When the firewall default action is Drop, Reject, or Alert, or the policy is in monitor mode, the firewall engine records an alert log entry (signature ID 2201000 or 2201001) each time it applies the default action. With an Accept default action in enforce mode, default-action hits aren't logged; use the FirewallDefaultActionApplied metric instead. Look for alert records whose engine field is fw (the firewall engine) to find traffic that reached the default action. An alert whose engine is td comes from the IPS engine instead. For how to configure and read Network Firewall logs, see Logging and monitoring in Amazon Network Firewall.

Check the FirewallDefaultActionApplied metric

Network Firewall publishes the FirewallDefaultActionApplied metric to Amazon CloudWatch for a Next Generation policy, under the Engine dimension value Firewall. The metric counts how often the firewall engine applied the firewall default action. A rising value means that traffic is reaching the default action rather than being handled by a rule—with a drop default action, that is traffic being dropped. Watch this metric when you roll out or change a policy. For the full list of metrics for a Next Generation policy, see Next Generation policy metrics.

Use monitor mode to diagnose safely

If you aren't sure whether a policy will block traffic that you need, deploy or switch the policy to monitor mode. In monitor mode, the policy passes all traffic through without dropping or rejecting anything, but still evaluates your rules and the default action and records the actions it would have applied in enforce mode. The stream exception policy isn't applied in monitor mode either—Network Firewall uses Continue, and your configured Drop or Reject stream exception policy applies again when you switch to enforce mode. The exceptions that still block in monitor mode are TLS-layer resets (a missing or invalid SNI, an SNI that doesn't match the server certificate, or a failed handshake), TLS inspection certificate revocation checks whose action is Drop or Reject, and Route 53 Resolved IP validation, which applies its configured action and DNS expiry exception policy in monitor mode. Review the resulting alert logs and the FirewallDefaultActionApplied metric to see which connections the default action would catch, fix your rules, and then switch back to enforce mode. For more information, see Policy mode: enforce and monitor.

Common causes of unexpectedly dropped traffic

When an allowed connection is dropped, check for the following, which are the most frequent causes:

  • Missing TCP carrier rules. An application-layer matcher (for example, a TLS SNI or HTTP host rule) only runs after the connection passes the TCP layer. If your rule group has the application-layer matcher but not the pair of accept:hook tcp:all carrier rules, the connection is dropped at the TCP layer before the matcher runs. Add the carrier rules. For more information, see Accepting prior hooks automatically.

  • The matcher is anchored at a hook the connection never reaches. An allow-by-SNI rule anchored at a later TLS state won't match a connection that closes before reaching that state. Anchor allow-by-SNI rules at the client_hello hook, which every TLS flow passes through. For more information, see Accepting prior hooks automatically.

  • A rule's direction or address range doesn't match the traffic. Firewall rules are directional. Confirm that the connection's client is in $HOME_NET and the destination is in $EXTERNAL_NET (or that your rule's addresses match the actual traffic), and that you have carrier rules for both directions of the connection.

  • The protocol isn't what the rule expects. A rule's protocol is derived from its hook, and a connection is handled by the default action at a hook that no rule covers. If you allow tls but the traffic is plain HTTP on the same port, the TLS rule won't accept it. Check the app_proto field in your flow logs to see the protocol that Network Firewall detected.