Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN (2023)

Assigning SGTs

In this example we configure SGTs on a RADIUS server, and then use 802.1X access control on the EX4400 to receive them. RADIUS servers are commonly used in campus environments for access control and, for example, to govern the assignment of VLANs.

To accommodate the use of SGTs on the RADIUS server, we need to leverage vendor specific attribute (VSA), as supported by the AAA service framework (these VSA are carried as part of the standard RADIUS request reply message, and provide a built-in extension to handle implementation-specific information such as our SGTs). The exact syntax on the RADIUS server varies according to whether the authentication scheme is MAC or EAP based. For MAC based clients, the configuration looks like this:

For EAP based clients, the SGT is pushed from RADIUS server at the time of authentication. The configuration looks like this:

GBP-based filters are used as classifiers for GBP tagging. These filters classify incoming streams and assign a GBP tag.

You can see how this works in the following code samples. GBP firewall policies are framed on the basis of source and destination GBP tags. A source tag is the 16-bit field in the VXLAN header in the incoming packet and is derived from the address (IP/MAC/port and so on) lookup, while the destination tag is derived at the egress tunnel or ingress endpoint, according to the configured tag assignment.

Let's say we have this configuration (shown below) on both the ingress and egress endpoints. We recommend that you have same GBP tag assignment configuration across the system. Packets from source MAC address 00:01:02:03:04:10:10 are assigned the tag 100, and packets from source MAC address 00:01:02:03:04:20:20 are assigned 200.

For packets with GBP tag 100 and a destination MAC address of 00:01:02:03:04:10:10, the destination group tag (gbp-dst-tag) will be 100, and it will match on term t10-100. Likewise, for packets with GBP tag 100 and a destination MAC address of 00:01:02:03:04:20:20, the destination group tag will be 200, and it will match term t10-200.

The same tag assignment used to map the source MAC address to the source tag is also used to map the destination MAC address to the destination tag. This is true for port based assignments as well.

Let's look at another code sample, this time using a a GBP source tag of 300, and with packets from IPv4 address 172.16.1.0/24. As you can see below, GBP source tag 300 is assigned and in egress direction, and 300 is also GBP destination group tag.

Note that by default policy enforcement is done on the egress endpoint. If you want to do policy enforcement on the ingress leaf, see the section below. In addition, you must enable VXLAN-GBP globally on the ingress node, so it can perform the look-up on the matches and add SGT in the VXLAN header, and also on the egress node. Do this with the configuration command shown here:

Starting with Junos Release 22.4R1, you can also perform the policy enforcement on the ingress endpoint. Ingress enforcement optimizes the network bandwidth. To support policy enforcing on the ingress, we have a mechanism to propagate the MAC and IP-MAC based tags across the network using Type 2 and Type 5 routes. See EVPN Type 2 and Type 5 routes for more information. With this, the destination GBP-based policy is enforced in nodes closer to the ingress for MAC and IP-based GBP matches. Tag propagation is always in context of MAC and IP-based GBP. For VLANs, Port, and Port+VLAN matches this is not applicable.

You must enable the following statement to perform the policy enforcement at the ingress node. When ingress enforcement is enabled or disabled, the Packet Forwarding Engine (PFE) restarts.

Host-Originated Packets

When packets egress from an integrated routing and bridging (IRB) interface over a virtual tunnel endpoint (VTEP), the kernel inserts a source GBP tag in the VXLAN header and sends the packet. The source GBP tag value is configured using the following statement:

Before creating any rules, it can be helpful to organize your scheme by creating a table for all your endpoints (users and devices) and the assigned SGT value. The table below can be used to further simplify the logic and clarify your rules.

The relationship between the RADIUS server and SGTs, the EX4400 and VXLAN packet headers, and a central firewall filter to manage the access policy, is such that a matrix becomes a handy way to organize the values. In the following table, we list user roles down the first column and device types across the first row to create an access matrix. Each user role and device type is assigned an SGT and the RADIUS configuration has been updated with the information.

This example uses three types of employees, Permanent Employee (PE), Contractor (CON), and Security Staff (SS). It also uses two types of resources, Eng Server (ES) and security camera (CAM). We use Y to indicate access is permitted, and N to shown when access is blocked. The table serves as a useful resource when creating the various firewall rules in the policy and makes access mapping simple and clear.

Topology

For the sake of simplicity, all the configuration in this example is done on a single Juniper EX4400 series switch running Junos OS Release 22.4.1R1. The switch is connected to a RADIUS server for AAA. This switch functions as egress in this example. Recall that for SGTs you must define the firewall on the egress switch, whereas you would typically do it on the ingress VXLAN gateway for the access layer.

Figure 2: VXLAN GBP on an EX4400 Switch

• Requirements
• Configuration
• Configuring a Stand-Alone Juniper EX4400 Switch for VXLAN-GBP
• Limitations for EX switches and QFX switches: