Security Policies with VRF-Aware Security Zones
VRF-Aware Zone-Based Policy Enforcement
- Overview
- VRF-Aware Zone-Based Security Policies
- VRF-Aware Zone-Based Policy Configuration Limitations
Overview
The VRF-aware zone-based policy enforcement feature introduces a strategic approach to managing security policies at the VRF level.
You can now create zones for each VRF instance and apply policies between VRF instances to simplify Layer 3 VPN (L3VPN) policy management for MPLS and VXLAN. By defining VRF-aware security zones, you gain a more granular level of control of both intra-VRF and inter-VRF traffic and control across L3VPN deployments. The policy lookup process adapts to integrate VRF-based zones alongside interface-based zones, allowing comprehensive policy enforcement.
You define security zones by VRF instance (not by VRF group). The VRF-group restriction in the policy rule set remains unchanged. For incoming traffic, the firewall evaluates the L3VPN zone first, and then the physical interface zone; if no zone matches, the firewall drops packets.
Configure security zones per VRF using the vrf option under the
[edit security zones security-zone zone-name]
hierarchy level. Verify your configuration using the show security
policies and show security zones
operational
commands. These commands display the VRF-based zone names in the existing syslog’s
source-zone-name and destination-zone-name
fields. Also, new syslog fields, src-vrf and
dst-vrf, display the source and destination VRF
instances. See
System Log Explorer | Juniper Networks
Pathfinder.
VRF-Aware Zone-Based Security Policies
Previously, zone changes were handled in a single-level zone model, and any change in the zone would tear down the session entirely.
Overview
You can now define zones using VRF instances (VRF-aware zones), similar to how you define zones with interfaces. The policy lookup process incorporates VRF zones, enabling cross-combinations with interface-based zones for comprehensive policy enforcement.
Define zones using VRF instances: VRF-aware zones behave the same way as interface-based zone contexts when it comes to policy evaluation. Similar to how interface-based from zone and to zone combinations are considered as contexts, VRF zones are considered the same way. The firewall flow sends the VRF zones to the policy in the same way as it sends interface zone details for policy lookup.
We now support two-level zones, where MPLS and VXLAN traffic are matched within VRF-specific zones. This approach ensures that sessions are governed by VRF-specific policies without affecting other overlay or underlay zones.
Traffic evaluation (based on type):
- For MPLS or VXLAN traffic, the highest priority is given to VRF-based zones.
- For IP traffic, the device checks only interface-based zones.
Policy evaluation (based on traffic type):
-
For MPLS and VXLAN traffic, policy evaluation uses VRF-based zones.
-
For IP traffic, policy evaluation uses only interface-based zones.
The single VRF-group policy limitation remains to prevent ambiguous matches.
VRF-aware zones and interface-based zones remain segregated; VRF-aware zones cannot include interfaces; interface zones cannot reference VRF-aware zones.
VRF-aware zone-based policy enforcement is backward compatible, ensuring that existing VRF-level enforcement remains functional while incorporating new VRF-based zone configurations.
To maintain backward compatibility, configuring both VRF-based zone and VRF match criteria in the same policy is not supported, and doing so results in a commit error.
For MPLS and VXLAN traffic, sessions are created based on the VRF-specific zone policies. Packets are matched against the VRF zone, and if a match occurs, the device establishes a session accordingly.
Flow Session Behavior
This section describes the behavior of flow sessions across three scenarios: overlay-to-overlay, underlay-to-underlay, and overlay-to-underlay flows.
You can manage zone and VRF changes with predictable session behavior to maintain traffic continuity.
If the traffic is matched to an overlay zone, then the sessions do not terminate when you add an interface to an underlay zone or delete an unused interface. The device also preserves traffic when you add a VRF instance to the traffic-matched overlay zone or delete an unused VRF instance from that overlay zone.
If the traffic is matched to an overlay zone, then the sessions terminate when you rename the underlay zone or delete the interface carrying overlay-zone-matched traffic in the underlay zone.
Configuration Overview
VRF-based zones are exclusive to VRF instances and do not support direct interface configurations, similarly interface-based zones do not accommodate VRF instances. Virtual network identifier (VNI)-aware zones are not supported.
Configure VRF zones: Define VRF zones and associate them with specific policies using the CLI, Security Director, or Security Director Cloud.
Verify VRF zones configuration: Use the existing policy and zone show commands. The command outputs are now updated to include VRF zone details, granting visibility into the current configurations and any potential discrepancies.
VRF-Aware Zone-Based Policy Configuration Limitations
- You can configure zones only based on a VRF instance and not based on a VRF group.
- For each VRF instance, choose either VRF group or a VRF zone; configuring both causes a commit failure, generating a commit error.
- Traffic between VRF group and a VRF zone is not permitted. Flow processing explicitly denies and drops any traffic between a VRF group and a VRF zone.
- Configuring interfaces and VRF instances under the same zone results in a commit
error as show below:
user@host# commit [edit security zones security-zone vrf-zone1] 'vrf' vrf and interfaces cannot be configured together error: commit failed: (statements constraint check failed) [edit] - Configuring both VRF-based zone and VRF match criteria in the same policy results
in a commit error as shown
below:
user@host# commit [edit security policies from-zone trust to-zone untrust policy zone-pol1] 'match' VRF match criteria addition to VRF based zone is invalid error: configuration check-out failed [edit]
- Configuring more than 32 VRF instances in a zone results in a commit error as
shown below:
user@host# commit [edit security zones security-zone vrf-zone1 vrf] 'VRF-c6' Exceeded the max number of vrfs (32) error: configuration check-out failed [edit]
- Associating the same VRF instance to multiple zones results in a commit error as
shown below:
user@host# commit [edit security zones] 'security-zone vrf-zone1' vrf VRF-a cannot be configured to multiple zones error: configuration check-out failed [edit]
- Configuring the same VRF instance in the VRF zone and the VRF group results in a
commit error as shown below:
# set security zones security-zone VRF2_ZONE vrf VRF1 set security zones security-zone VRF1_ZONE vrf VRF1 [edit] user@host# set security l3vpn vrf-group G1 vrf VRF1 [edit] root@10.205.54.84# commit check [edit security l3vpn vrf-group G1 vrf] 'VRF1' same vrf should not be in vrf-group and vrf-zone error: configuration check-out failed: (statements constraint check failed)
Example: Configure Security Policies with VRF-Aware Security Zones to Manage VRF-Based Traffic
This example shows how to configure security policies with VRF-aware security zones to manage VRF-based traffic.
Requirements
-
Understand how to create a security zone. See Example: Creating Security Zones.
-
Supported SRX Series Firewall with any supported Junos OS release.
-
Configure network interfaces on the device. See Interfaces User Guide for Security Devices.
Overview
In Junos OS, security policies enforce rules for transit traffic, in terms of what traffic can pass through the device and the actions that need to take place on the traffic as it passes through the device. An SRX Series Firewall is deployed in an SD-WAN to control traffic using the VRF-aware zone based security policies.
You can configure VRF-aware zone-based security policies with VRF instances, security zones, and inter-zone communication.
In this configuration example, you create two isolated virtual routing instances (VRF-a and VRF-b) that maintain separate routing and forwarding tables while enabling MPLS L3VPN functionality. Each VRF instance is associated with its own security zone, allowing granular security policy enforcement.
The configuration includes security policies that permit controlled communication between VRF instances and external networks through the trust zone. You can verify the configuration by checking VRF routing table isolation, security zone associations, and policy enforcement through traffic flow testing and monitoring commands.
Configuration
Configure VRF-aware zone-based security policies with VRF instances, security zones, and inter-zone communication to permit traffic.
Procedure
To quickly configure this example, copy the following commands, paste them into a
text file, remove any line breaks, change any details necessary to match your
network configuration, copy and paste the commands into the CLI at the
[edit] hierarchy level, and then enter commit
from configuration mode.
CLI Quick Configuration
set routing-instances VRF-a instance-type vrf set routing-instances VRF-a route-distinguisher 10:200 set routing-instances VRF-a vrf-target target:100:100 set routing-instances VRF-a vrf-table-label set routing-instances VRF-b instance-type vrf set routing-instances VRF-b route-distinguisher 20:200 set routing-instances VRF-b vrf-target target:200:100 set routing-instances VRF-b vrf-table-label set security zones security-zone vrf-zone1 vrf VRF-a set security zones security-zone vrf-zone2 vrf VRF-b set security policies from-zone vrf-zone1 to-zone vrf-zone2 policy pol1 match source-address any set security policies from-zone vrf-zone1 to-zone vrf-zone2 policy pol1 match destination-address any set security policies from-zone vrf-zone1 to-zone vrf-zone2 policy pol1 match application any set security policies from-zone vrf-zone1 to-zone vrf-zone2 policy pol1 match dynamic-application any set security policies from-zone vrf-zone1 to-zone vrf-zone2 policy pol1 then permit set security zones security-zone trust interfaces ge-0/0/0.0 set interfaces ge-0/0/0 unit 0 family inet address 4.0.0.254/8 set security policies from-zone vrf-zone1 to-zone trust policy pol2 match source-address any set security policies from-zone vrf-zone1 to-zone trust policy pol2 match destination-address any set security policies from-zone vrf-zone1 to-zone trust policy pol2 match application any set security policies from-zone vrf-zone1 to-zone trust policy pol2 match dynamic-application any set security policies from-zone vrf-zone1 to-zone trust policy pol2 then permit
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
Configure the VRF-a and VRF-b instances.
[edit routing-instances] user@host# set VRF-a instance-type vrf user@host# set VRF-b instance-type vrf-
Assign a route distinguisher to each VRF routing instance.
[edit routing-instances] user@host#set VRF-a route-distinguisher 10:200 user@host#set VRF-b route-distinguisher 20:200
-
Set a VRF target for each VRF routing instance.
[edit routing-instances] user@host#set VRF-a vrf-target target:100:100 user@host#set VRF-b vrf-target target:200:100Setting different VRF targets ensures controlled route sharing between the VRF instances.
-
Assign a single VPN label for all the routes in the VRF instances.
[edit routing-instances] user@host#set VRF-a vrf-table-label user@host#set VRF-b vrf-table-label Associate security zones to their respective defined VRF instances.
[edit security] user@host#set security zones security-zone vrf-zone1 vrf VRF-a user@host#set security zones security-zone vrf-zone2 vrf VRF-b
Configure the trust zone interface.
[edit security] user@host#set security zones security-zone trust interfaces ge-0/0/0.0 user@host#set interfaces ge-0/0/0 unit 0 family inet address 4.0.0.254/8
Assign the management or shared services interface to the trust zone. This interface operates in the global routing table context. It provides access to shared services or management networks outside the VRF instance.
-
Configure an inter-VRF communication policy.
[edit security policies from-zone vrf-zone1 to-zone vrf-zone2] user@host#set policy pol1 match source-address any user@host#set policy pol1 match destination-address any user@host#set policy pol1 match application any user@host#set policy pol1 match dynamic-application any user@host#set policy pol1 then permit
The policy
pol1allows traffic fromvrf-zone1tovrf-zone2. Ifpol1matches any source address, destination address, or applications, thethen permitaction allows the matched traffic to flow between VRF instances. This configuration creates a controlled bridge between otherwise isolated VRF instances. Configure a policy to enable communication between VRF-a and the trust zone.
[edit security policies from-zone vrf-zone1 to-zone trust] user@host#set policy pol2 match destination-address any user@host#set policy pol2 match application any user@host#set policy pol2 match dynamic-application any user@host#set policy pol2 then permit
Policy
pol2enables communication from vrf-zone1 to the trust zone. The policy also allows the VRF-a traffic to reach shared services in the global routing table and maintains broad matching criteria for maximum connectivity flexibility.
Results
From configuration mode, confirm your configuration by entering the
show security policies and show
routing-instances commands. If the output does not display the
intended configuration, repeat the instructions in this configuration to
correct it.
[edit]
user@host#show security policies
from-zone vrf-zone1 to-zone vrf-zone2 {
policy pol1 {
match {
source-address any;
destination-address any;
application any;
dynamic-application any;
}
then {
permit;
}
}
}
from-zone vrf-zone1 to-zone trust {
policy pol2 {
match {
source-address any;
destination-address any;
application any;
dynamic-application any;
}
then {
permit;
}
}
[edit]
user@host# show routing-instances
VRF-a {
instance-type vrf;
route-distinguisher 10:200;
vrf-target target:100:100;
vrf-table-label;
}
VRF-b {
instance-type vrf;
route-distinguisher 20:200;
vrf-target target:200:100;
vrf-table-label;
}
If you are done configuring the device, enter commit from
configuration mode.
Verification
Verify Policy Configuration
Purpose
Verify information about the configured security policies.
Action
From operational mode, enter the show security policies
command to display a summary of all the security policies configured on the
device.
user@root> show security policies
Default policy: deny-all
Default policy log Profile ID: 0
Pre ID default policy: permit-all
Default HTTP Mux policy: permit-all
From zone: vrf-zone1, To zone: vrf-zone2
Policy: pol1, State: enabled, Index: 4, Scope Policy: 0, Sequence number: 1, Log Profile ID: 0
Source vrf group: any
Destination vrf group: any
Source addresses: any
Destination addresses: any
Applications: any
Dynamic Applications: any
Source identity feeds: any
Destination identity feeds: any
Gbp source tags: 0
Gbp destination tags: 0
Action: permit
From zone: vrf-zone1, To zone: trust
Policy: pol2, State: enabled, Index: 5, Scope Policy: 0, Sequence number: 1, Log Profile ID: 0
Source vrf group: any
Destination vrf group: any
Source addresses: any
Destination addresses: any
Applications: any
Dynamic Applications: any
Source identity feeds: any
Destination identity feeds: any
Gbp source tags: 0
Gbp destination tags: 0
Action: permit
Verify Zone Configuration
Purpose
Verify information about the configured security zones.
Action
From operational mode, enter the show security zones command
to display a summary of all the security zones configured on the device.
user@root> show security zones
Security zone: vrf-zone1
Zone ID: 7
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 0
Interfaces:
Vrfs bound: 1
Vrf:
VRF-a
Advanced-connection-tracking timeout: 1800
Unidirectional-session-refreshing: No
Security zone: vrf-zone2
Zone ID: 8
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 0
Interfaces:
Vrfs bound: 1
Vrf:
VRF-b
Advanced-connection-tracking timeout: 1800
Unidirectional-session-refreshing: No
Security zone: trust
Zone ID: 9
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 1
Interfaces:
ge-0/0/1.0
Vrfs bound: 0
Vrf:
Advanced-connection-tracking timeout: 1800
Unidirectional-session-refreshing: No