# Troubleshooting a Next Generation policy
<a name="firewall-policy-v2-troubleshooting"></a>

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 AWS Network Firewall](logging-monitoring.md).

**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](monitoring-cloudwatch.md#metrics-policy-v2).

**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](firewall-policy-v2-policy-mode.md).

**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](firewall-rule-groups-accept-prior-hooks.md).
+ **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](firewall-rule-groups-accept-prior-hooks.md).
+ **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.