ON THIS PAGE
Tunnel Inspection for EVPN-VXLAN Traffic on SRX Series Devices
Summary
Read this topic to understand how to setup your security device to perform tunnel inspection for EVPN-VXLAN to provide embedded security.
EVPN-VXLAN decouples the underlay network (physical topology) from the overlay network (virtual topology). By using overlays, you gain the flexibility of providing Layer 2/Layer 3 connectivity between endpoints across campus and data centers, while maintaining a consistent underlay architecture. You can use SRX Series devices in your EVPN-VXLAN solution to connect end-points in your campus, data center, branch and public cloud environments while providing embedded security.
Configure Security Policies for VXLAN
In this example, we are focusing on configuring the SRX Series device which is a part of a working EVPN-VXLAN network that consist of two DC locations each with an IP fabric. The SRX Series device is placed in a Data Center Interconnect (DCI) role between the two DCs. In this configuration, the SRX Series device performs stateful inspection of VXLAN encapsulated traffic flowing between the DCs when you enable tunnel inspection.
Requirements
This example uses the following hardware and software components:
SRX4600 device
Junos OS Release 20.4R1
This example assumes that you already have an EVPN-VXLAN based network and want to enable tunnel inspection on SRX Series device.
Before you begin:
Make sure you understand how EVPN and VXLAN works. See EVPN-VXLAN Campus Architectures to detail understanding EVPN-VXLAN
This example assumes that you already have an EVPN-VXLAN based network fabric and want to enable tunnel inspection on the SRX Series device. You can see the sample configuration of leaf and spine devices used in this example at Complete Device Configurations.
Overview
In this example, we are focusing on configuring the SRX Series device which is a part of a working EVPN-VXLAN network that consist of two DC locations each with an IP fabric. The SRX Series device is placed in a Data Center Interconnect (DCI) role between the two DCs. In this configuration, the SRX Series device performs stateful inspection of VXLAN encapsulated traffic flowing between the DCs when you enable tunnel inspection.
We are using the topology shown in Figure 1 in this example.
As given in the topology, the SRX Series device is inspecting transit VLAN encapsulated traffic from the VXLAN tunnel endpoint (VTEP) on the leaves in both the DC-1 and DC-2 data centers. Any Juniper Networks device, both physical and virtual, that functions as a Layer 2 or Layer 3 VXLAN gateway can act as VTEP device to perform encapsulation and de-encapsulation.
Upon receipt of a Layer 2 or Layer 3 data packet from server 1, The leaf 1 VTEP adds the appropriate VXLAN header and then encapsulates the packet with a IPv4 outer header to facilitate tunneling the packet through the IPv4 underlay network. The remote VTEP at leaf 2 then de-encapsulates the traffic and forwards the original packet towards the destination host. With the Junos software release 20.4 SRX Series devices can perform tunnel inspection for VXLAN encapsulated overlay traffic passing through it.
In this example, you’ll create a security policy to enable inspection for traffic that is encapsulated in a VXLAN tunnel .
We're using the parameters described Table 1in this example.
Table 1: Configuration Parameters
Parameter | Description | Parameter Name |
|---|---|---|
Security policy | Policy to create a flow session triggered by VXLAN overlay traffic. This policy references the outer IP source and destination address. That is, the IP addresses of the source and destination VTEPs. In this example this is the loopback address of the leaves. | P1 |
Policy set | Policy for the inspection of inner traffic. This policy operates on the contents of matching VXLAN tunnel traffic. | PSET-1 |
Tunnel inspection profile | Specifies parameters for security inspection on VXLAN tunnels. | TP-1 |
Name of a VXLAN network identifier (VNI) list or range | Used to uniquely identify a list or range of VXLAN tunnel IDs. | VLAN-100 |
VXLAN | tunnel identifier name. Used to symbolically name a VXLAN tunnel in a tunnel inspection profile. | VNI-1100 |
When you configure tunnel inspection security policies on the SRX Series device, it decapsulates the packet to access the inner header when a packet matches a security policy. Next, it applies the tunnel inspection profile to determine if the inner traffic is permitted. The security device uses inner packet content and the applied tunnel inspection profile parameters to do a policy lookup and to then perform stateful inspection for the inner session.
Configuration
In this example, you'll configure the following functionality on the SRX Series device:
Define a trust and untrust zone to permit all host traffic. This supports the BGP session to the spine devices and allow SSH etc from either zone (DC).
Inspect traffic flowing from DC1 to DC2 in VNI 1100 (Layer 2 stretched for VLAN 100) for all hosts in the 192.168.100.0/24 subnet. Your policy should permit pings but deny all other traffic.
Allow all return traffic from DC2 to DC1 with no tunnel inspection.
Allow all other underlay and overlay traffic without VXLAN tunnel inspection from DC1 to DC2.
Use the following steps to enable tunnel inspection on your security device in a VXLAN-EVPN environment:
CLI Quick Configuration
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.
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
- Configure security zones, interfaces, and address-books. [edit]user@r4-dci-ebr# set security zones security-zone trustuser@r4-dci-ebr# set security zones security-zone untrustuser@r4-dci-ebr# set interfaces ge-0/0/0 description "Link to DC1 Spine 1"user@r4-dci-ebr# set interfaces ge-0/0/0 mtu 9000user@r4-dci-ebr# set interfaces ge-0/0/0 unit 0 family inet address 172.16.1.2/30user@r4-dci-ebr# set interfaces ge-0/0/1 description "Link to DC2 Spine 1"user@r4-dci-ebr# set interfaces ge-0/0/1 mtu 9000user@r4-dci-ebr# set interfaces ge-0/0/1 unit 0 family inet address 172.16.2.2/30user@r4-dci-ebr# set security zones security-zone trust host-inbound-traffic system-services alluser@r4-dci-ebr# set security zones security-zone trust host-inbound-traffic protocols alluser@r4-dci-ebr# set security zones security-zone trust interfaces ge-0/0/0.0user@r4-dci-ebr# set security zones security-zone untrust host-inbound-traffic system-services alluser@r4-dci-ebr# set security zones security-zone untrust host-inbound-traffic protocols alluser@r4-dci-ebr# set security zones security-zone untrust interfaces ge-0/0/1.0user@r4-dci-ebr# set security address-book global address vtep-untrust 10.255.2.0/24user@r4-dci-ebr# set security address-book global address vtep-trust 10.255.1.0/24user@r4-dci-ebr# set security address-book global address vlan100 192.168.100.0/24
Note that /24 prefix lengths are used to specify the outer (VTEP) and inner (server) addresses. While you could use /32 host routes for this simple example, using a /24 will match traffic from other leaves (VTEPs) or hosts in the 192.168.100/0/24 subnet.
- Define the tunnel-inspection profile. You can specify
a range or a list of VNIs that should be inspected. [edit]user@r4-dci-ebr# set security tunnel-inspection vni VLAN-100 vni-id 1100user@r4-dci-ebr# set security tunnel-inspection inspection-profile TP-1 vxlan VNI-1100 vni VLAN-100user@r4-dci-ebr# set security tunnel-inspection inspection-profile TP-1 vxlan VNI-1100 policy-set PSET-1
In this example only one VNI is needed so the vni-id keyword is used instead of the vni-range option. The tunnel inspection profile links to both the VNI list/range as well as to the related policy that should be applied to VXLAN tunnel with matching VNIs.
- Create a security policy to match on the outer session. [edit]user@r4-dci-ebr# set security policies from-zone trust to-zone untrust policy P1 match source-address vtep-trustuser@r4-dci-ebr# set security policies from-zone trust to-zone untrust policy P1 match destination-address vtep-untrustuser@r4-dci-ebr# set security policies from-zone trust to-zone untrust policy P1 match application junos-vxlanuser@r4-dci-ebr# set security policies from-zone trust to-zone untrust policy P1 then permit tunnel-inspection TP-1
This policy refers to the global address book entries you defined earlier to match source and destination VTEP addresses. These addresses are used in the underlay to support VXLAN tunnels in the overlay. Matching traffic is directed to the TP-1 tunnel inspection profile you defined in the previous step. In this example the goal is to inspect VXLAN tunnels that originate in DC1 and terminate in DC2. As a result a second policy to match on return traffic (with DC2 Leaf 1 the source VTEP) is not needed.
- Create the policy-set for the inner session. [edit][edit security policies]user@r4-dci-ebr# set security policies policy-set PSET-1 policy PSET-1-P1 match source-address vlan100user@r4-dci-ebr# set security policies policy-set PSET-1 policy PSET-1-P1 match destination-address vlan100user@r4-dci-ebr# set security policies policy-set PSET-1 policy PSET-1-P1 match application junos-icmp-alluser@r4-dci-ebr# set security policies policy-set PSET-1 policy PSET-1-P1 then permit
This policy performs security inspection against the payload of matching VXLAN traffic. In this example this is the traffic sent from Server 1 on VLAN 100 in DC1 to Server 1 in DC2. By specifying the junos-icmp-all match condition you ensure that both ping request and replies can pass from server 1 ion DC1 to server 1 in DC2. If you specify junos-icmp-ping only pings that originate from DC1 will be permitted.
Recall that in this example only ping is permitted to help facilitate testing of the resulting functionality. You can match on application any to permit all traffic, or alter the match criteria to suit your specific security needs.
- Define the policies needed to accept all other traffic
between the data centers without any tunnel inspection.[edit]set security policies from-zone trust to-zone untrust policy accept-rest match source-address anyset security policies from-zone trust to-zone untrust policy accept-rest match destination-address anyset security policies from-zone trust to-zone untrust policy accept-rest match application anyset security policies from-zone trust to-zone untrust policy accept-rest then permitset security policies from-zone untrust to-zone trust policy accept-all-dc2 match source-address anyset security policies from-zone untrust to-zone trust policy accept-all-dc2 match destination-address anyset security policies from-zone untrust to-zone trust policy accept-all-dc2 match application anyset security policies from-zone untrust to-zone trust policy accept-all-dc2 then permit
Results
From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
user@host# show security policiesIf you are done configuring the feature on your device, enter commit from configuration mode.
Verification
At this time you should generate ping traffic between server 1 in DC1 to server 1 in DC2. The pings should succeed. Allow this test traffic to run in the background while you complete the verification tasks.
r5-dc1_server1> ping 192.168.100.102 PING 192.168.100.102 (192.168.100.102): 56 data bytes 64 bytes from 192.168.100.102: icmp_seq=0 ttl=64 time=565.451 ms 64 bytes from 192.168.100.102: icmp_seq=1 ttl=64 time=541.035 ms 64 bytes from 192.168.100.102: icmp_seq=2 ttl=64 time=651.420 ms 64 bytes from 192.168.100.102: icmp_seq=3 ttl=64 time=303.533 ms
Verify Inner Policy Details
Purpose
Verify the details of the policy applied for the inner session.
Action
From operational mode, enter the show security policies policy-set PSET-1 command.
user@host> show security policies policy-set
PSET-1From zone: PSET-1, To zone: PSET-1
Policy: PSET-1-P1, State: enabled, Index: 7, Scope Policy: 0, Sequence number: 1, Log Profile ID: 0
From zones: any
To zones: any
Source vrf group: any
Destination vrf group: any
Source addresses: vlan100
Destination addresses: vlan100
Applications: junos-icmp-all
Source identity feeds: any
Destination identity feeds: any
Action: permitCheck Tunnel Inspection Traffic
Purpose
Display the tunnel inspection traffic details.
Action
From operational mode, enter the show security flow tunnel-inspection statistics command.
user@host> show security flow tunnel-inspection
statistics Flow Tunnel-inspection statistics:
Tunnel-inspection type VXLAN:
overlay session active: 4
overlay session create: 289
overlay session close: 285
underlay session active: 3
underlay session create: 31
underlay session close: 28
input packets: 607
input bytes: 171835
output packets: 418
output bytes: 75627
bypass packets: 0
bypass bytes: 0Meaning
The output displays details of tunnel inspection traffic. Note that the Tunnel-inspection type is displayed as VXLAN.
Check Tunnel Inspection Profile and VNI
Purpose
Display the tunnel inspection profile and VNI details.
Action
From operational mode, enter the show security tunnel-inspection profiles and show security tunnel-inspection vnis commands.
user@host> show security tunnel-inspection profilesLogical system: root-logical-system
Profile count: 1
Profile: TP-1
Type: VXLAN
Vxlan count: 1
Vxlan name: VXT-1
VNI count: 1
VNI:VNI-1
Policy set: PSET-1
Inspection level: 1user@host> show security tunnel-inspection vnisLogical system: root-logical-system
VNI count: 2
VNI name: VLAN-100
VNI id count: 1
[1100 - 1100]
VNI name: VNI-1
VNI id count: 1
[1100 - 1100] Check Security Flows
Purpose
Display VXLAN security flow information on the SRX to confirm that VXLAN tunnel inspection is working.
Action
From operational mode, enter the show security flow session vxlan-vni 1100 command.
user@host> show security flow session vxlan-vni
1100Session ID: 3811, Policy name: PSET-1-P1/7, State: Stand-alone, Timeout: 2, Valid In: 192.168.100.101/47883 --> 192.168.100.102/82;icmp, Conn Tag: 0xfcd, If: ge-0/0/0.0, Pkts: 1, Bytes: 84, Type: VXLAN, VNI: 1100, Tunnel Session ID: 2193 Out: 192.168.100.102/82 --> 192.168.100.101/47883;icmp, Conn Tag: 0xfcd, If: ge-0/0/1.0, Pkts: 0, Bytes: 0, Type: VXLAN, VNI: 0, Tunnel Session ID: 0 Session ID: 3812, Policy name: PSET-1-P1/7, State: Stand-alone, Timeout: 2, Valid In: 192.168.100.101/47883 --> 192.168.100.102/83;icmp, Conn Tag: 0xfcd, If: ge-0/0/0.0, Pkts: 1, Bytes: 84, Type: VXLAN, VNI: 1100, Tunnel Session ID: 2193 Out: 192.168.100.102/83 --> 192.168.100.101/47883;icmp, Conn Tag: 0xfcd, If: ge-0/0/1.0, Pkts: 0, Bytes: 0, Type: VXLAN, VNI: 0, Tunnel Session ID: 0 . . .
Meaning
The output displays VXLAN traffic session through SRX Series.
Confirm That SSH is Blocked
Purpose
Try to establish an SSH session between server 1 in DC1 and server 2 in DC2. Based on the policy that allows only ping traffic this session should be blocked at the SRX Series.
Action
From operational mode, SSH to the server at DC2
r5-dc1_server1> ssh 192.168.100.102ssh: connect to host 192.168.100.102 port 22: Operation timed out r5_dc1_server1>
Meaning
The output displays that operation timed out indicating now traffic flow.
See also
WHAT'S NEXT
See Tunnel Inspection for EVPN-VXLAN by SRX Series Devices for more details.