Firewall rule logging allows administrators to verify that network traffic is being handled correctly by Cloud Firewall policies and Virtual Private Cloud (VPC) firewall rules. By enabling logging on specific rules, you can see whether traffic is allowed or denied, which helps troubleshoot connectivity problems and ensure security policies are working as intended across different levels of an organization's network.
Firewall rules are processed in a strict order based on their numerical priority, where priority 0 is the highest. When a packet arrives, the system checks rules from highest to lowest priority until it finds a match. A matching rule with an ALLOW action lets the traffic through and stops checking other rules. A matching rule with a DENY action blocks the traffic and also stops. In hierarchical policies, the GOTO_NEXT action lets the system check rules at lower levels, but a rule enforced at a high level (like an organization) cannot be overridden by a rule at a lower level (like a project). If traffic doesn't match any rule, it falls through to the default implied rules.
You turn on logging for a firewall rule by setting its logging option to active. Logs show whether connections were allowed or denied. ALLOW logs create a single record when a connection starts, showing the source and destination IP addresses. DENY logs capture more detail and create a new log entry every time a blocked connection is attempted, up to once every 5 seconds. Logging cannot be enabled on the default implied rules. To log traffic that would be silently denied by a default rule, you must create an explicit deny rule for 0.0.0.0/0 with logging turned on.
The order in which firewall rules and packet mirroring rules are checked depends on the direction of the traffic. For incoming (ingress) traffic to a VM, firewall rules are checked first. If a firewall rule denies the packet, it is dropped immediately and never reaches the mirroring rules. Mirroring only happens for ingress traffic that a firewall rule explicitly allows. For outgoing (egress) traffic from a VM, mirroring rules are checked first. This ensures a copy of the packet can be sent to a security tool for inspection, even if a later egress firewall rule denies the original traffic. When a mirroring rule matches, the copied packet is wrapped in a Generic Network Virtualization Encapsulation (GENEVE) header and sent to a specified inspection endpoint.
Firewall logs help identify security risks, such as rules that are too permissive. A common risk is a rule that allows access from the entire internet (0.0.0.0/0) to sensitive ports like SSH (TCP 22) or database ports. These should be fixed by restricting the source to specific IP ranges, using secure tags, or using address groups. Logs also help confirm that necessary traffic, like health checks from Google Cloud load balancers (130.211.0.0/22 and 35.191.0.0/16) or connections from Identity-Aware Proxy (IAP) (35.235.240.0/20), is reaching its destination.
VPC Flow Logs are records of network traffic metadata for resources in a VPC network. They are the main tool for understanding traffic volume, finding performance bottlenecks, measuring delays, and investigating why traffic is being dropped or sent the wrong way, especially between VPCs or in hybrid cloud setups.
A VPC Flow Log is created for each network flow, which is a series of packets sharing the same source/destination IP, source/destination port, and protocol. The log captures metadata like the number of bytes and packets, the start and end time of the flow, and the TCP connection state. These logs are automatically sent to Cloud Logging for analysis. The logging process does not interfere with the actual network traffic; it only observes and records.
To get useful data for troubleshooting, you configure VPC Flow Logs with specific settings. The aggregation interval (like 5 seconds or 1 minute) determines how often log records are bundled and sent; shorter intervals give more real-time detail. The sampling rate (from 0.0 to 1.0) decides what percentage of flows are logged; a rate of 1.0 logs everything but costs more. You can also add custom metadata annotations to logs, such as network tags, to make it easier to filter logs for a particular application during investigation.
In Cloud Logging, you use queries to analyze the flow logs. To find throughput bottlenecks, you group logs by destination to see which IPs or ports are receiving the most data. To trace latency, you look at the duration of TCP flows to find ones that are taking too long. To investigate dropped traffic, you filter for flows with TCP reset (RST) flags or very low packet counts, which can indicate a firewall block or routing issue. For hybrid or inter-VPC traffic, you filter on the specific IP ranges that cross network boundaries to check for problems.
Choosing settings involves a trade-off between detail and cost. A 100% sampling rate with a 5-second aggregation interval provides the most complete data for deep investigation but creates a large volume of logs, increasing storage costs. For everyday monitoring, a lower sampling rate (like 10%) with a longer interval may be sufficient and more cost-effective. Your choice should depend on whether you need continuous, broad monitoring or are drilling into a specific problem.
Packet Mirroring copies live network packets from a VPC and sends them to external security or monitoring tools. This allows for deep inspection of the actual packet contents for security forensics, intrusion detection, and troubleshooting complex network protocol issues without affecting the original traffic.
When a VM sends or receives a packet, the system checks it against firewall policies. If the packet matches a mirroring rule with a MIRROR action, a copy is made. This copy is wrapped in a GENEVE encapsulation header and sent on UDP port 6081. The copied packet travels to a Google-managed endpoint, then to a mirroring group, and finally to an internal passthrough Network Load Balancer that distributes the traffic to security appliances. Those appliances remove the GENEVE header and inspect the original mirrored packet.
Mirroring rules are defined within network firewall policies. These rules have three actions: MIRROR (copy the traffic and stop checking lower-priority rules), DO_NOT_MIRROR (do not copy and stop), and GOTO_NEXT (check the next rule). Rules are evaluated in descending priority order. For ingress traffic, standard firewall rules are checked first, and only traffic that is allowed is then evaluated against mirroring rules. For egress traffic, mirroring rules are checked before the firewall rules that decide if the traffic is permitted.
To use Packet Mirroring, you create security profiles and security profile groups. A security profile specifies where the mirrored traffic should be sent, pointing to a mirroring endpoint group in your project. You then create a security profile group containing a custom security profile of type CUSTOM_MIRRORING and link it to your mirroring rules. These resources are managed at the organization or project level and require specific administrative roles to configure.
Packet Mirroring supports two integration modes. In direct mode, the mirrored traffic goes straight from your VPC to the producer's inspection tools, and the system tries to keep the traffic within the same zone. In broker mode, a Google-managed mirroring endpoint acts as a middleman. It receives the traffic, can add more metadata, and can replicate it to multiple different collectors. Broker mode requires you to create a mirroring endpoint, which is a zonal resource.
Cloud IDS is a managed intrusion detection service that uses Packet Mirroring. You create an IDS endpoint, and then create packet mirroring policies that send traffic to it. Cloud IDS uses Palo Alto Networks technology to analyze the mirrored traffic for threats like malware or intrusions. Each IDS endpoint can inspect up to 5 Gbps of traffic normally, with the ability to handle temporary spikes up to 17 Gbps. It inspects traffic from all VMs in the attached policies.
For ingress traffic, firewall rules are evaluated first. If a firewall rule denies the packet, it is discarded immediately and never reaches the mirroring rule evaluation stage. Therefore, packets blocked by an ingress firewall rule will not be mirrored.
The main trade-off is between diagnostic detail and operational cost. A 100% sampling rate captures every flow for thorough analysis but generates the most log data and highest storage cost. A lower sampling rate reduces cost and volume but may miss some flows, making it more suitable for ongoing monitoring than deep forensic investigation.
In direct mode, mirrored traffic flows directly from your VPC network to the producer's inspection tools, with the system attempting to keep traffic within the same zone. In broker mode, traffic passes through a Google-managed mirroring endpoint that can add metadata and replicate the traffic to multiple different collector destinations, providing more flexibility for complex monitoring setups.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts