Firewall policy rules logging overview

Firewall policy rules logging lets you audit, verify, and analyze the effects of your firewall policy rules. For example, you can determine if a firewall policy rule designed to deny traffic is functioning as intended. Firewall policy rules logging is also useful if you need to determine how many connections are affected by a given firewall policy rule.

You enable firewall policy rules logging individually for each firewall policy rule whose connections you need to log. Firewall policy rules logging is an option for any firewall policy rule, regardless of the action (allow or deny) or direction (ingress or egress) of the rule.

Firewall policy rules logging logs traffic to and from Compute Engine virtual machine (VM) instances. This includes Google Cloud products built on Compute Engine VMs, such as Google Kubernetes Engine (GKE) clusters and Google Kubernetes Engine flexible environment instances.

When you enable logging for a firewall policy rule, Google Cloud creates an entry called a connection record each time the rule allows or denies traffic. You can view these records in Cloud Logging, and you can export logs to any destination that Cloud Logging export supports.

Each connection record contains the source and destination IP addresses, the protocol and ports, date and time, and a reference to the firewall policy rule that applied to the traffic.

Firewall policy rules logging is available for both hierarchical and network firewall policy rules. For information about viewing logs, see Manage firewall policy rules logging.

Specifications

Firewall policy rules logging has the following specifications:

  • Supported deployments: you can enable firewall policy rules logging for firewall policy rule within hierarchical, global network, regional network, and regional system firewall policies associated with a regular VPC network, and regional network firewall policies associated with a RoCE VPC network.

  • Unsupported rules: firewall policy rules logging is not supported for rules in legacy networks, Implied deny ingress and implied allow egress rules in a regular VPC network, or Implied allow ingress and egress rules of an RoCE VPC network.

  • Protocol support: firewall policy rules logging only records TCP and UDP connections. If you want to monitor other protocols, consider using Out-of-band integration.

  • Connection-based logging: firewall policy rules logging are created when a connection is established, not for every individual packet. A connection remains active as long as packets are exchanged at least once every 10 minutes. Each new packet resets the idle timer. Therefore, a continuous stream of traffic generates only one log entry for its entire duration. If you need continuous visibility into active, long-lived streams without idle periods, use VPC Flow Logs.

  • Existing connections: if you enable logging on a rule that matches an already active TCP or UDP connection, a new log entry is not generated. The firewall policy rule logs the connection only if it remains idle for at least 10 minutes and a new packet is subsequently sent.

  • Allow and deny behavior:

    • Allow + Logging: an allowed connection is logged only once, and the entry is not repeated even if the connection endures, because firewall rules are stateful, reply traffic is allowed automatically and is not logged.

    • Deny + Logging: each dropped packet corresponding to a unique 5-tuple is logged as a failed attempt. The log entry repeats every 5 seconds as long as packets are observed for that denied connection.

  • Log generation perspective: log entries are only created if a firewall policy rule has logging enabled and if the rule applies to traffic sent to or from the VM. Entries are created subject to the connection logging limits.

  • Rate limits: the number of connections logged per unit of time is determined by the VM's machine type for regular VPC networks, or by the monitoring or logging action of the rule for RoCE VPC networks. For more information, see Connection logging limits and Monitoring and logging

  • Session-based logic for advanced inspection: when a firewall policy uses the advanced apply_security_profile_group action, the logging behavior shifts from connection-based to session-based logic.

    Cloud NGFW generates a single high-level log entry for the initial session that matches the rule and is successfully intercepted for deep packet inspection, even if multiple underlying connections belong to that same session. This high-level firewall log is distinct from the detailed Layer 7 logs, such as URL filtering or threat logs that are generated for every inspected connection.

  • Unique actions and dispositions: Cloud NGFW policy logs are the only logs that can record the INTERCEPTED disposition and the APPLY_SECURITY_PROFILE_GROUP action. If this action is used, the system logs an additional field (apply_security_profile_fallback_action).

  • Audit logs: you can view configuration changes to the firewall policy rule in Cloud NGFW audit logs. For more information, see Cloud NGFW audit logging.

Limitations

  • When you use the apply_security_profile_group action with logging enabled, Cloud NGFW doesn't capture logs of all sessions. This limitation doesn't affect traffic inspection or interception.

  • If you enable logging for a firewall policy rule that matches existing TCP or UDP connections, log entries are not generated for those active connections. Logging for these connections begins only after they have been idle for at least 10 minutes.

  • When specifying the IP protocol (IpPortInfo.ip_protocol), the value can't be set to ALL for firewall policy rules.

  • Firewall policy rules don't support logging for legacy metadata fields, specifically source_tag, target_tag, source_service_account, and target_service_accounts.

What's next