Welcome to part 4 of the NSX VRF series. In part 3, I discussed VRF route leaking that allows communication between 2 data plane isolated VRF gateways in NSX. 

In this post, I will discuss Inter-VRF routing.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: NSX VRF Gateway – Architecture & Configuration

2: VRF Config Validation & Traffic Flows

3: VRF Route Leaking

Inter-VRF routing was first introduced in NSX 4.1.0, and it allows exchanging routes between VRFs. The route exchange happens between VRFs over an internally plumbed Inter-VRF transit link. 

You can configure Inter-VRF routing between:

• Parent Tier-0 gateway and Tier-0 VRF gateway.
• From Tier-0 VRF gateway to parent Tier-0 gateway.
• From one Tier-0 VRF gateway to another Tier-0 VRF gateway.

To exchange routes between the gateways, you can use one of the following methods:

• Inter-VRF Route Advertisement – Advertise routes that are not BGP, such as static, connected, NAT, etc, that are available as inter-vrf static routes on the connected gateway.

… Read the rest

Welcome to part-2 of the NSX VRF series. Part 1 of this series discussed VRF architecture, and part 2 demonstrated data plane isolation between the VRF instances.

In this post, I will demonstrate how to establish communication between 2 VRFs using VRF Route Leaking.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: NSX VRF Gateway – Architecture & Configuration

2: VRF Config Validation & Traffic Flows

By default, the data plane traffic between VRF instances is isolated in NSX. You can exchange traffic between 2 VRFs by configuring VRF Route Leaking. In this technique, static routes are configured on the VRF gateways to steer traffic towards other VRF gateways.

There are 2 supported topologies for VRF route leaking:

• Local VRF-to-VRF route leaking
• Northbound VRF leaking

Note: A multi-tier routing architecture is required for traffic to be exchanged in a VRF leaking topology, as static routes pointing to Tier-1 distributed router (DR) uplinks are necessary.… Read the rest

Welcome to part-2 of the NSX VRF series. Part 1 of this series discussed VRF architecture and its use cases and the advantages that VRF offers over traditional routing isolation techniques. In this post, I will demonstrate VRF configuration validation to ensure things are working as expected. 

The following configuration was done in vSphere before VRF validation:

• VRF-Red VM is deployed and connected to segment “red-ls01” and has IP 192.168.40.2
• VRF-Blue VM is deployed and connected to segment “blue-ls01” and has IP 192.168.50.2

Connectivity Test

The blue VRF VM can:

• Ping its default gateway.
• Uplink interface used for BGP peering.
• An IP from the physical network.

However, the Blue VRF VM can’t ping the Red VRF gateway or any of its VMs.

The same tests were performed on the Red VFR VM and validated that it can’t reach the Blue VRF gateway or its VM.

You can run similar tests using the NSX Traceflow tool.… Read the rest

Introduction

VMware NSX has been providing multi-tenancy capabilities to an SDDC since its inception. There are various ways to achieve it, depending on the use cases. In the simplest architecture, multi-tenancy is achieved by creating and connecting various Tier-1 gateways to a Tier-0 gateway, where each Tier-1 gateway belongs to a dedicated tenant with a non-overlapping network. Having several Tier-0 gateways, each owned by a different tenant, is another way of achieving multi-tenancy.

Multi-tenancy without NSX VRF

The concept of VRF is not new with NSX. It has been since v3.x of NSX. The VRF functionality has changed and gained new features with the latest iterations of NSX.

Virtual Routing and Forwarding (VRF) allows NSX admins to virtualize the routing table on a Tier-0 gateway and provide tenant separation from a routing perspective. With VRF, you can configure per-tenant data plane isolation up to the physical network without creating a Tier-0 gateway per tenant.… Read the rest

Welcome to part-3 of the NSX IDFW series. The first post discussed the overview and architecture of NSX IDFW, and the second post discussed implementing NSX IDFW using Active Directory Event Scraping.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: Introduction to NSX Identity Firewall

2: Implement IDFW using Event Log Scraping

In this post, I will discuss NSX Guest Introspection, which is another logon detection method that NSX uses to enforce identity-based firewall rules.

What is NSX Guest Introspection?

Guest Introspection for VMware NSX is a user space agent installed inside a virtual machine to provide network connection control and monitoring capability. This daemon provides network connection control and monitoring capabilities by utilizing the capabilities offered by the netfilter libraries and the netfilter kernel subsystem. For Windows OS, guest introspection is packaged and delivered with VMTools. … Read the rest

Welcome to part-2 of the NSX IDFW series. The last post of this series discussed the overview and architecture of NSX IDFW and the logon detection method.

This post discusses how to implement NSX IDFW using Active Directory Event Scraping.

Event Log Scraping provides the logging information from different sources to the NSX Manager. This information is used in the distributed firewall rule and extends IDFW support outside virtual workloads. Event Log Scraping supports the following logging sources:

• Active Directory
• PAN GlobalProtect
• Aruba ClearPass
• BYOD (custom attributes)

In an Active Directory environment, NSX reads the security event log for the user from the AD and, based on configured firewall rules, takes the appropriate action. To pull events from the AD security event log, the AD event log scraper is configured in the NSX Manager and points to an instance of the domain controller in the infrastructure.

For other types of logging sources, you need to deploy Aria Operations for Logs (vRLI) to aggregate logs in one place.… Read the rest

Introduction

Typically, firewall rules are based on security groups that contain IP addresses, a subnet, or virtual machines. These security groups can be used as a source or destination in an NSX environment, but this doesn’t cover all use cases. Let’s take an example where an NSX admin has to allow/block access to specific applications to a given set of users, independent of the source address of the end-user. How do I implement rules, as the source address can vary for each user (local machine, VDI, terminal server). That’s where NSX Identity Based Firewall (IDFW) helps you. 

NSX IDFW allows you to create distributed firewall rules based on Active Directory users and groups. You can allow or deny access to applications based on user identity. IDFW requires integration with Active Directory so that the NSX can consume AD users and groups.

 

Use Cases for Identity Firewall

Identity Firewall can be used for Virtual Desktops or a Remote Desktop Session Host.… Read the rest

In my last post on the NSX SSL certificate rotation, I discussed the types of certificates in NSX and why you should use a certificate with a SAN attribute. The ability to generate a CSR with Subject Alternative Names was first introduced in NSX v4.2. Before NSX v4.2, creating certificates with SAN attributes was possible only through API. This post is focused on demonstrating the certificate generation and replacement procedure through API.

… Read the rest