Virtual Routing and Forwarding with ACL and NAT policy support

Overview

Virtual Routing and Forwarding (VRF) enables you to create multiple isolated routing instances on a single BIG-IP Next CNF deployment. With VRF support for ACL and NAT policies, you can associate firewall (ACL) and CGNAT (NAT) policies with specific VRFs, allowing you to enforce per-tenant or per-network-segment security and address translation policies.

This page explains how to configure VRF-aware SecureContexts, VLANs, firewall policies, and NAT policies using Kubernetes Custom Resources (CRs).

Prerequisites

Before configuring VRF-aware policies, ensure you have:

• A running BIG-IP Next CNF deployment on Kubernetes.

• kubectl access to the cluster with permissions to create Custom Resources.

• The CNF CRD bundle installed, which includes the VRF, F5BigNetVlan, and F5BigContextSecure CRDs.

• Familiarity with SecureContext, VLAN, Firewall Policy, and NAT Policy configuration in CNF.

Key Concepts

CONCEPT	DESCRIPTION
VRF	An isolated routing instance that keeps network traffic separated from other VRFs. Each VRF maps to an internal Route Domain.
Route Domain	The internal CNF/TMM representation of a VRF. The default Route Domain (ID 0) is always present and acts as the parent of all other Route Domains.
SecureContext	A virtual server configuration that defines how traffic matching specific criteria is processed. Associating a SecureContext with a VRF makes it handle only traffic within that VRF.
Strict Isolation	When enabled on a VRF, traffic within the VRF is isolated from other VRFs. Traffic can still be forwarded to the default Route Domain (ID 0).
SNAT AUTOMAP	Source NAT mode that automatically maps the source address to an available self-IP. Required for forwarding SecureContexts associated with a non-default VRF.

Configuration

Configuration Resources

CRDs are deployed on Kubernetes to define objects for VRF configuration:

• VRF: Defines an isolated routing instance.

• F5BigNetVlan: Defines a network VLAN. Use the vrf field to associate a VLAN with a specific VRF.

• F5BigContextSecure: Defines a virtual server. Use the vrf field to make it VRF-aware. When a SecureContext references a VRF:

  • It handles only traffic arriving on VLANs associated with that VRF.

  • Any attached firewall (ACL) or NAT policies automatically operate within the context of that VRF.

  • Destination and source addresses are internally associated with the corresponding Route Domain.

• Application Layer Gateway (ALG) Protocols: The following ALG CRDs also support the vrf field, enabling VRF-aware traffic handling for these protocols. The vrf field works identically to the SecureContext vrf field. When associated with a VRF, the ALG handler only processes protocol traffic within that VRF.

  • F5BigAlgFtp

  • F5BigAlgTftp

  • F5BigAlgPptp

  • F5BigAlgRtsp

Configuration Example for Complete Multi-VRF Deployment

The following example demonstrates a deployment with two customer VRFs, each with their own VLAN, SecureContext, and firewall policy.

1. Copy the following example into the vrf-customer-a.yaml and vrf-customer-b.yaml file to create VRFs.

   apiVersion: "k8s.f5net.com/v1"
   kind: Vrf
   metadata:
     name: vrf-customer-a
   spec:
     strictIsolation: true
   
   ---
   
   apiVersion: "k8s.f5net.com/v1"
   kind: Vrf
   metadata:
     name: vrf-customer-b
   spec:
     strictIsolation: true
   

2. Copy the following example into the vlan-customer-a.yaml and vlan-customer-b.yaml files to create VLANs.

   apiVersion: "k8s.f5net.com/v1"
   kind: F5BigNetVlan
   metadata:
     name: vlan-customer-a
   spec:
     name: "vlan-customer-a"
     interfaces:
       - "1.1"
     tag: 1006
     selfip_v4s:
       - "101.101.101.201"
       - "101.101.101.202"
     prefixlen_v4: 24
     vrf: vrf-customer-a
   
   ---
   
   apiVersion: "k8s.f5net.com/v1"
   kind: F5BigNetVlan
   metadata:
     name: vlan-customer-b
   spec:
     name: "vlan-customer-b"
     interfaces:
       - "1.2"
     tag: 1007
     selfip_v4s:
       - "101.101.101.203"
       - "101.101.101.204"
     prefixlen_v4: 24
     vrf: vrf-customer-b
   

3. Copy the following example into the fw-policy-customer-a.yaml and fw-policy-customer-b.yaml files to create firewall policies.

   apiVersion: "k8s.f5net.com/v1"
   kind: FirewallPolicy
   metadata:
     name: fw-policy-customer-a
   spec:
     rules:
       - name: allow-http
         action: accept
         protocol: tcp
         destination:
           ports:
             - 80
             - 443
       - name: deny-all
         action: drop
   
   ---
   
   apiVersion: "k8s.f5net.com/v1"
   kind: FirewallPolicy
   metadata:
     name: fw-policy-customer-b
   spec:
     rules:
       - name: allow-all
         action: accept
   

   Note

   Firewall policies do not contain VRF-specific fields. VRF association is inherited from the SecureContext.

4. Copy the following example into the sc-customer-a.yaml and sc-customer-b.yaml files to create SecureContexts.

   apiVersion: "k8s.f5net.com/v1"
   kind: F5BigContextSecure
   metadata:
     name: sc-customer-a
   spec:
     destinationAddress: "33.33.32.0/24"
     ipProtocol: "any"
     profile: "fastL4"
     firewallEnforcedPolicy: "fw-policy-customer-a"
     logProfile: "log-profile"
     vrf: "vrf-customer-a"
     vlans:
       vlanList: ["vlan-customer-a"]
       disableListedVlans: false
   
   ---
   
   apiVersion: "k8s.f5net.com/v1"
   kind: F5BigContextSecure
   metadata:
     name: sc-customer-b
   spec:
     destinationAddress: "33.33.32.0/24"
     ipProtocol: "any"
     profile: "fastL4"
     firewallEnforcedPolicy: "fw-policy-customer-b"
     logProfile: "log-profile"
     vrf: "vrf-customer-b"
     vlans:
       vlanList: ["vlan-customer-b"]
       disableListedVlans: false
   

   Note

   Both SecureContexts can use the same destinationAddress because they operate in different VRFs. Traffic is isolated by VRF.

5. Run the following command to apply the configuration.

   kubectl apply -f vrf-customer-a.yaml
   kubectl apply -f vrf-customer-b.yaml
   kubectl apply -f vlan-customer-a.yaml
   kubectl apply -f vlan-customer-b.yaml
   kubectl apply -f fw-policy-customer-a.yaml
   kubectl apply -f fw-policy-customer-b.yaml
   kubectl apply -f sc-customer-a.yaml
   kubectl apply -f sc-customer-b.yaml
   

6. Verify the configuration.

   # Verify VRFs are created
   kubectl get vrf
   
   # Verify VLANs are associated with VRFs
   kubectl get f5bignetvlan
   
   # Verify SecureContexts reference VRFs
   kubectl describe f5bigcontextsecure sc-customer-a
   kubectl describe f5bigcontextsecure sc-customer-b
   

Use Cases

Use Case 1: VRF-Aware Traffic Forwarding

Scenario: If you want to forward traffic for different customers through isolated VRFs without any firewall or NAT policies.

Configuration Steps:

1. Create a VRF (VRF) resource for each customer.

2. Create a F5BigNetVlan resource for each customer, referencing the appropriate VRF.

3. Create a F5BigContextSecure resource for each customer, referencing the appropriate VRF.

4. Enable SNAT AUTOMAP on each SecureContext.

Traffic Flow:

• Traffic arriving on a customer’s VLAN is processed only by the SecureContext associated with the same VRF.

• Traffic can be forwarded within the VRF or to the default Route Domain.

Use Case 2: VRF-Aware Firewall (ACL) Policy

Scenario: If you want to apply different firewall policies to different customers, each in their own VRF.

Configuration Steps:

1. Create VRF, VLAN, and SecureContext resources as described in Use Case 1.

2. Create a F5BigFwPolicy CR with the desired rules.

3. Reference the firewall policy in the SecureContext’s firewallEnforcedPolicy field.

Important Notes:

• The firewall policy itself does not contain any VRF-specific configuration.

• VRF association is implicit through the SecureContext.

• ACL rules match traffic by IP address regardless of VRF. Isolation is enforced because the SecureContext only receives traffic from the associated VRF.

• The same firewall policy can be referenced by SecureContexts in different VRFs.

Use Case 3: VRF-Aware NAT Policy

Scenario: If you want to apply CGNAT policies to traffic within specific VRFs.

Configuration Steps:

1. Create VRF, VLAN, and SecureContext resources as described in Use Case 1.

2. Create a F5BigNatPolicy CR with the desired translation rules.

3. Reference the NAT policy in the SecureContext.

4. Disable SNAT on the SecureContext (SNAT is not supported when a NAT policy is attached).

Important Notes:

• NAT rules match traffic by IP address regardless of VRF.

• Translated source IP addresses are always placed in the default Route Domain (ID 0).

• Since only the destination Route Domain is used for selecting the egress VLAN, source NAT does not affect routing.

• The NAT policy itself does not contain any VRF-specific configuration.

Use Case 4: Combined ACL and NAT Policies with VRF

Scenario: If you want both firewall filtering and NAT translation for traffic within a VRF.

Configuration Steps:

1. Create VRF, VLAN, and SecureContext resources as described in Use Case 1.

2. Create a F5BigFwPolicy CR and a F5BigNatPolicy CR.

3. Reference both policies in the SecureContext.

4. Disable SNAT on the SecureContext.

Note

The firewall policy is evaluated first, and only traffic permitted by the ACL is subject to NAT translation.