F5 Distributed Cloud Network Firewall Rule Evaluation and Packet Flow

Overview

Traditionally, the network firewall consists of policies that get applied to a network or an interface on the network. This worked fine in legacy environments, but having the knowledge of individual networks and interfaces in a dynamic multi-cloud environment is difficult. So, the F5 Distributed Cloud (XC) Network Firewall simplifies this by allowing users to specify the intent and abstract the network topologies and address assignments.

This document discusses how requests get evaluated on a F5 XC node and how firewall policies are shared across different namespaces of a tenant.

F5 XC Network Firewall supports two types of policies:

1. Firewall Policies
2. Enhanced Firewall Policies

Also, each of these can be created in the system namespace and applied to a F5 XC node, created in the shared namespace to be applied to any vk8s cluster, or created in the application namespace to be applied to the vk8s associated with the namespace only. Network Firewall can have only one type of policy at a time.

Note: It is recommended to use Enhanced Firewall Policies for applying it to the F5 XC nodes, as it supports service insertion and segmentation, in addition to the existing functionalities of regular Firewall Policies.

Evaluation of rules

Firewall Policy is comprised of three main concepts:

1. Endpoint (Local or Remote)
2. Ingress Rules
3. Egress Rules

Enhanced Firewall policy has no separate list for ingress and egress rules. Instead, it has an ordered list of rules with source, destination, and match criteria.

The firewall policies are evaluated sequentially when the Firewall policies are activated on a site. Processing stops when a rule is matched, and the corresponding action is applied to the traffic. If none of the rules match, the default behavior is to drop the packet silently.

 

 

If the Endpoint specified in the policy matches the destination in the Policy, the ingress rule is evaluated. The egress rule is evaluated for traffic where the source matches the endpoint in the Policy.

Firewall Policy – Allowed actions in rules

For an ingress rule, if the traffic source matches the endpoint in the rule, or for an egress rule if the traffic destination matches the endpoint in the rule, the corresponding action is applied to the traffic. Allowed actions are ‘Allow’ (traffic is sent to L7 processing) or ‘Deny’ (traffic is dropped)

Enhanced Firewall Policy – Allowed actions in rules

For Enhanced Firewall Policy the rules are evaluated against all traffic to match with the source, destination, and criteria specified in the rule. But in addition to ‘Allow’ and ‘Deny’ actions, it can also ‘Insert Service’ i.e., steer the traffic to an external Network Function Virtualization (NFV) service.

Note: This traffic steering feature is currently supported only for the Palo Alto network firewall and on an AWS TGW Site.

Virtual Kubernetes Network Policies

The Firewall policies are called Network Policies in the context of vk8s. The Network policies get applied to all the sites in the vk8. If the individual site also has active Firewall policies, the traffic is evaluated against all policies in both the Firewall policies and vk8s Network policies.

Enhanced Firewall policy is not currently supported for vk8s.

Shared Network Policy and policy inheritance

Network Policy created under the Shared Configurations in the console becomes part of the shared namespace of the tenant. These policies are available to all application namespaces but are not active by default. Shared Network Policies are visible in the application namespace but are not editable in the namespace view. Security admin for the tenant can create common security policies using this construct in Shared Configurations and allow each application namespace to inherit it. This way any change to these policies can be immediately applied to all apps where the policy is made active.

Note: Only vk8s Network Policy can be created in Shared Configurations. Enhanced Firewall policy is not supported as a Shared Configuration.

Network Policy in application namespace

Network Policy created in the application namespace can only be used for k8s associated with the namespace. These cannot be shared with any other namespace.

Network Policy Examples

Consider a scenario as shown in the figure below:

CE1 and CE2 are connected by a Global Network so instances in VPC1 and VPC2 can directly route to each other. Firewall policies are active on CE2 with rules as shown below:

 

When C1 tries to access an application on TCP port 80 on S1, it gets dropped. But when it tries to access an application on TCP port 8000 it is allowed. This can be seen in the traffic capture taken on CE2:

Traffic is allowed to leave CE1 but gets blocked at CE2 where the policies are active.

Note that the traffic that is not blocked is evaluated against Policy 2 with Allow all rules. Without this policy, all traffic will be denied by default.