NSXTICM24 M07 Services

NSX-T Data Center Services
© 2019 VMware, Inc.

Importance
NSX-T Data Center provides several layer 3 services that can help you address operational
challenges in the virtual network architecture.
© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7-2

Module Lessons
Lesson: Configuring NAT
Lesson: Configuring DHCP and DNS Services
Lesson: Configuring Load Balancing
Lesson: IPSec VPN
Lesson: L2 VPN

Configuring NAT
© 2019 VMware Inc. All rights reserved.

Learner Objectives
After completing this lesson, you should be able to complete the following objectives:
• Explain the functions of network address translation (NAT)
• Distinguish between source and destination NAT
• Recognize how reflexive NAT works
• Identify use cases for reflexive NAT

About NAT
In NSX-T Data Center, you can configure NAT on Tier-0 and Tier-1 Gateways.
You can configure different types of NAT rules:
• Source NAT (SNAT)
• Destination NAT (DNAT)
• Reflexive NAT (stateless NAT)
Tier-1 Gateways in active-standby mode support SNAT and DNAT.
Tier-1 Gateways in active-active mode support reflexive NAT rules.
Tier-0 Gateways in active-standby mode support SNAT and DNAT.
Tier-0 Gateways in active-active mode support reflexive NAT.

About SNAT
The SNAT rule changes the source address in
the IP header of a packet. The rule can also
change the source port in the TCP or UDP
headers.
In the diagram, as packets are received from
the web VM, the T1-LR-1 Tier-1 Gateway
changes the source IP address of the packets
from 172.16.101.11 to 80.80.80.1.
You can disable SNAT by creating a No SNAT
rule.

About DNAT
The DNAT rule changes the destination
address in the IP header of a packet. It can also
change the destination port in the TCP or UDP
headers.
This rule is typically used to redirect incoming
packets with a destination public IP address or
port to a private IP address or port inside the
network.
You can disable DNAT by creating a No DNAT
rule.

Reflexive NAT (Stateless NAT)
You use the reflexive NAT rule when a Tier-0
Gateway is running in active-active mode and
when stateful NAT might lead to issues due to
asymmetric paths.
For active-active gateways, you can use
reflexive NAT, which is sometimes called
stateless NAT.
For reflexive NAT, you can configure a single
source address to be translated or a range of
addresses.
If you configure a range of source addresses,
you must also configure a range of translated
addresses.

Configuring SNAT and DNAT
SNAT and DNAT are configured on the Tier-1 Gateway in the following use cases:
• You typically use SNAT to change a private address or port into a public address and or port
for packets leaving your network.
• You typically use DNAT to redirect incoming packets with a destination public address or port
to a private IP address or port inside your network.
© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 10

Configuring the No SNAT Rule
To disable SNAT, you configure the No SNAT rule on the Tier-0 or Tier-1 Gateway:
• Specify the source IP network in the rule.
• Apply this rule to the outbound traffic direction.

Configuring the No DNAT Rule
To disable the DNAT rule, you configure the No DNAT rule:
• The No DNAT rule can be configured on Tier-0 and Tier-1 Gateways.
• You use this rule for the inbound direction.
• You must specify the destination IP network in the rule.

Configuring Reflexive NAT
When a Tier-0 Gateway is running in active-active mode, you cannot configure stateful NAT:
• You can use reflexive NAT, which is sometimes called stateless NAT.
• The address translation is sequential, for example, the first address in the source range is
translated to the first address in the translated range, and so on.
• The two ranges (source range and translated range) must be of equal size.

NAT Packet Flow Logical Topology
In this setup, T1-GW1 performs SNAT. The private IP address 172.16.10.11 is translated to
80.0.0.1 to be routed outside.

NAT Packet Flow (1)
The VM (172.16.10.11) attached to Segment-5000 sends a packet to its default gateway T1-
GW1. The packet's destination is the VM (192.168.10.11) attached to Segment-5001.

NAT Packet Flow (2)
The packet is handled by the distributed router (DR) of T1-GW1.

NAT Packet Flow (3)
T1-GW1’s DR determines that this packet requires address translation, which is provided by the
service router (SR) of the Tier-1 Gateway on a remote host. T1-GW1’s DR sends the packet to
the local TEP.

NAT Packet Flow (4)
The packet is encapsulated with the GENEVE header, sent across the overlay tunnel, and arrives
at the remote host (TEP).

NAT Packet Flow (5)
The receiving TEP decapsulates the packet and sends the original packet to the SR of T1-GW1
for processing. NAT (provided by the SR) translates the source address to 80.0.0.1.

NAT Packet Flow (6)
The packet with the translated IP (80.0.0.1) is sent to the DR of the Tier-0 Gateway T0-GW1 for
routing.

NAT Packet Flow (7)
Based on its routing table, T0-GW1 routes the packet to the DR of T1-GW2.

NAT Packet Flow (8)
T1-GW2’s DR determines that the packet is destined for a remote VM and sends the packet to
the local TEP.

NAT Packet Flow (9)
The packet is encapsulated by Transport Node B and sent across the overlay tunnel.

NAT Packet Flow (10)
The destination segment, Segment-5001, is attached to T1-GW2 on Transport Node A. The DR
of T1-GW2 routes the packet to the segment based on its routing table.

NAT Packet Flow (11)
The packet arrives at the destination VM.

Lab: Configuring Network Address Translation
Configure source and destination network address translation rules on the Tier-1 Gateway
1. Prepare for the Lab
2. Create a Tier-1 Gateway for Network Address Translation
3. Create a Segment
4. Attach a VM to the NAT-LS Segment
5. Configure NAT
6. Configure Route Advertisement and Route Redistribution
7. Verify the IP Connectivity

Review of Learner Objectives
• Explain the functions of network address translation (NAT)
• Distinguish between source and destination NAT
• Recognize how reflexive NAT works
• Identify use cases for reflexive NAT

Configuring DHCP and DNS Services

Learner Objectives
• Describe how and when to use DHCP services
• Configure DHCP services
• Describe how and when to use DNS services
• Configure DNS services

About DHCP Services
Dynamic Host Configuration Protocol (DHCP)
enables clients to automatically obtain network
configurations for IP address, subnet mask,
default gateway, DNS, and so on, from a DHCP
server. DHCP services are commonly used in
one of the following ways:
• To create DHCP servers to handle DHCP
requests on a logical switch
• To create a DHCP relay service on a router
port
You should not associate a DHCP server and
DHCP relay service to the same segment.

DHCP Architecture
DHCP is a standard networking protocol for
dynamically distributing network configuration
parameters, such as IP addresses for
interfaces. DHCP services are commonly
configured on logical routers:
• A logical router always has a distributed
router (DR).
• A logical router has one or more service
routers (SR) when it is a Tier-0 Gateway, or
when it is a Tier-1 Gateway with routing
services, such as NAT or DHCP, configured.
• An NSX Edge cluster must be created to
configure DHCP on Tier-1 or Tier-0
Gateways.
• A DHCP server and DHCP relay server can
be configured on Tier-1 or Tier-0 Gateways.

DHCP Use Cases
DHCP servers run as a service in an NSX Edge
cluster.
• DHCP is used to automate IP address
assignment. The DHCP server provides the
client IP address, gateway address, DNS
server address, and other information to
clients without administrator intervention.
• You can configure a logical DHCP server for
a logical switch and a pool. A vNIC, running a
DHCP client, connects to this logical switch
and can dynamically acquire an IP address.
• A DHCP cluster with multiple edge nodes
can be created. The DHCP server running as
a cluster can provide high availability.
• DHCP can be used to integrate with
OpenStack.

DHCP Workflow

Creating the DHCP Server
The DHCP server must be created and attached to Tier-1 or Tier-0 Gateways to provide the
DHCP IP address to VMs.

Configuring the DHCP Server on the Tier-1 Gateway
To configure the DHCP server on the Tier-1 Gateway, you edit the IP Address Management
option by changing the type of server to DHCP Local Server.

Configuring the Subnet on the Segment
You create a new segment or edit an existing segment.

Editing Segments
On the Set Subnets page, you enter values for the default gateway address and the DHCP
ranges. These values provide the DHCP IP address to the VMs connected to the segments.

Viewing the DHCP Server Status
You can check the DHCP server status on the DHCP page.

DHCP Configuration Details: Advanced UI
On the Advanced Networking & Security tab, you can select the Server Profiles and Servers
tabs to review the configuration details.

DHCP Server Router Ports on Tier-1 Gateways
You can view the DHCP service configured on the logical router ports of a Tier-1 Gateway.

DHCP Server and IP Pool Information from the Advanced UI
In the advanced UI, you can view the DHCP server and DHCP IP pool information.

DHCP Relay
To add a DHCP relay service, you select the DHCP relay in the Server Type drop-down menu
and enter one or more IP addresses for the service.

Configuring the DHCP Relay Server on Tier-1 Gateways
To configure the DHCP relay server, you edit the IP Address Management option by selecting
DHCP Relay Server in the Type drop-down menu.

Configuring Segments with Gateway and DHCP IP Address Ranges
You can configure each subnet with a gateway address and DHCP address ranges.

Local and Remote DHCP Server Configuration
Tier-1 Gateways can be configured with local and remote DHCP servers.

About DNS Services
A domain name server (DNS) is a computer application that implements a service for resolving a
computer name to an IP address and vice versa.
NSX-T Data Center enables Tier-1 and Tier-0 Gateways to be configured as DNS forwarders in
DNS relay mode.

About DNS Forwarder
In NSX-T Data Center, DNS client requests can be forwarded to
the external DNS server with the DNS forwarder feature:
• DNS forwarder is a server that forwards DNS requests from
clients to upstream DNS servers.
• DNS forwarder caches the responses received from the
upstream servers.
• When a subsequent request is received, the DNS forwarder
can respond to it without hitting the upstream DNS server,
unless the cached entry (TTL) is expired.
• The Tier-1 and Tier-0 Gateways can be configured as DNS
forwarders.
• The DNS forwarder on Tier-1 or Tier-0 Gateways acts as a
DNS relay to forward DNS client requests to external DNS
servers.

DNS Forwarder Benefits
A benefit of the DNS forwarder is that you get reduced output traffic to external network through
caching.
Another benefit is that you can hide internal DNS information from external networks by
delegating the internal DNS resolution to internal DNS servers.

Configuring DNS Services and DNS Zones (1)
You can create a DNS forwarder service in NSX-T Data Center from the simplified UI.

Configuring DNS Services and DNS Zones (2)
You can configure the DNS services and DNS zones in NSX-T Data Center.

Verifying the DNS Forwarder
You can verify the DNS forwarder configuration and service status on an NSX Edge node.

Lab: Configuring the DHCP Server on the NSX Edge Node
Configure the DHCP server on the NSX Edge node
2. Configure a DHCP Server
3. Verify the DHCP Server Operation
4. Prepare for the Next Lab

• Describe how and when to use DHCP services
• Configure DHCP services
• Describe how and when to use DNS services
• Configure DNS services

Configuring Load Balancing

Learner Objectives
After completing this lesson, you should be able to meet the following objectives:
• Describe load balancer architecture and components
• Identify load balancer deployment modes
• Create and configure a load balancer
• Create and configure layer 4 and layer 7 virtual servers
• Create and configure server pools

Load Balancing Use Cases
The NSX-T Data Center load balancer distributes incoming service requests among multiple
servers and offers high availability for applications.
You use load balancing when:
• Server redundancy is required to prevent outages.
• Fast response time is required by spreading client requests across multiple servers.
• Relief is needed when certain servers are heavily loaded.

Layer 4 Load Balancing
The layer 4 load balancer is connection-based and supports the following protocols:
• TCP
• UDP

Layer 7 Load Balancing
The layer 7 load balancer is content-based:
• Supports HTTP and HTTPS
• Enables URL manipulation through user-defined rules

Load Balancer Architecture
The load balancer needs to be attached to a Tier-1 Gateway.
A load balancer includes virtual servers, profiles, server pools, and monitors.

Connecting to Tier-1 Gateways
A load balancer must be connected to a Tier-1
Gateway:
• The Tier-1 Gateway must run on an edge
cluster in an active-standby mode.
• In a typical deployment, the Tier-1 Gateway
is connected to a Tier-0 Gateway in active-
active mode.

Virtual Servers
A virtual server is a service abstraction represented by a combination of a virtual IP address, a
port, and a protocol. External clients use this IP address, port, and protocol to access the servers
behind the load balancer.

About Profiles
Profiles are used to configure the characteristics of virtual servers. You can configure the
following types of profiles:
• Application: Defines how the virtual server processes the network traffic
• Persistence: Used in stateful applications to redirect all related connections to the same back-
end server
• SSL: Defines Secure Socket Layer (SSL) protocol type and ciphers to be used by the client
and server (layer 7 only)

About Server Pools
A server pool consists of a group of servers providing a specific functionality.
Server pool membership can be static or dynamic.

About Monitors
Monitors are used to verify the status of the servers in a server pool.
Active and passive monitors are supported:
• Active monitors are used to test whether a back-end server is available.
• Passive monitors check for failures during client connections and mark servers causing
consistent failures as down.

Relationships Among Load Balancer Components
Load balancer components work together:
• A load balancer can be attached to only one
Tier-1 Gateway.
• A load balancer can host one or more virtual
servers.
• Profiles can be used by one or more virtual
servers.
• A virtual server can include one or more
server pools.
• Monitors can be used by one or more server
pools.

Load Balancer Scalability (1)
Load balancers are available in small, medium, and large sizes. Depending on its size, the load
balancer can host different virtual servers and pool members.
Small Load Medium Load Large Load
Balancer Balancer Balancer
Number of virtual servers per load 20 100 1,000
balancer
Number of pools per load balancer 60 300 3,000
Number of pool members per load 300 2,000 7,500
balancer

Load Balancer Scalability (2)
The size of the edge nodes deployed in the environment determines the size of the load
balancers (LBs) that users can configure.
Small Medium Large Maximum
LB LB LB Pool
Size
Small N/A N/A N/A N/A
Edge
Medium 1 N/A N/A 300
Edge
Large 40 4 1 7,500
Edge
Bare 750 75 18 30,000
Metal
Edge

Load Balancing Deployment Modes
In NSX-T Data Center, load balancing is commonly deployed in one of the following modes:
• Inline
• One arm

Inline Topology
With the inline topology, the
load balancer is in the traffic
path between the client and the
server.
Clients and servers must not be
connected to the same Tier-1
Gateway.
SNAT is not required.

One-Arm Topology (1)
With the one-arm topology, the
load balancer is not in the traffic
path between the client and the
server.
The client and server can be
anywhere.
SNAT is required.

One-Arm Topology (2)
In one-arm deployment mode, the load
balancer performs SNAT to force the return
traffic from the back-end servers to the client
through the load balancer:
1. The load balancer receives a request from
the client.
2. The load balancer replaces the client IP
address with the load balancer virtual IP
address.
3. The back-end server sends response to the
load balancer virtual IP address.
4. The load balancer forwards the response to
the client.

Load Balancing Configuration Steps
The simplified UI provides a nested wizard that enables you to configure load balancing.
You must configure the Tier-1 Gateway before starting the configuration of the load balancer.

Creating Load Balancers
To create a new load balancer, you navigate to Networking > Load Balancing > LOAD
BALANCERS > ADD LOAD BALANCER.

Creating Virtual Servers
When creating a new virtual server, you can select from several
protocols:
• L4 TCP: Applications running on TCP with layer 4-only load
balancing requirements
• L4 UDP: Applications running on UDP with layer 4-only load
balancing requirements
• L7 HTTP: HTTP and HTTPS applications where the load
balancer needs to take actions based on layer 7 parameters

Configuring Layer 4 Virtual Servers
When configuring a layer 4 virtual server, you specify values for several parameters.

Configuring Layer 7 Virtual Servers
When configuring a layer 7 virtual server, you specify values for several parameters.

Configuring Application Profiles
Application profiles define how the virtual server
processes network traffic:
— Several default applications profiles are
provided:
• default-http-lb-app-profile, which is for
layer 7 HTTP virtual servers.
• default-tcp-lb-app-profile, which is for layer
4 TCP virtual servers. Acceleration is
enabled.
• default-udp-lb-app-profile, which is for
layer 4 UDP virtual servers. Acceleration is
enabled.
— You can create additional application profiles,
based on TCP, UDP, and HTTP, to suit your
requirements.

Configuring Persistence Profiles
Persistence profiles ensure stability of stateful applications by directing all related connections to
the same back-end server.
Supported persistence profiles include:
• Source IP: Tracks sessions based on the client’s source IP address. This profile can be used
with both layer 4 and layer 7 virtual servers.
• Cookie: Uses a unique HTTP cookie to identify the session, enabling the client to remain with
a server for the duration of the session. This profile is used with layer 7 virtual servers only.
You can create custom persistence profiles to suit your application needs.

Layer 7 Load Balancer SSL Modes
In NSX-T Data Center, the layer 7 load balancer
supports SSL modes:
• Secure Socket Layer (SSL) offload
— The load balancer terminates the client
SSL connection (HTTPS).
— The load balancer communicates with the
servers in the pool using HTTP.
• End-to-end SSL
— The load balancer terminates the client
SSL connection (HTTPS).
— The load balancer creates a new SSL
connection (HTTPS) toward the servers in
the pool.

Configuring Layer 7 SSL Profiles
SSL profiles define the SSL protocol type and
ciphers to be used by the client and server.
You can configure different types of SSL

profiles:
• Client SSL profile
— Used to configure the SSL connection
between the client and the load balancer
— Required in SSL offload and end-to-dnd
SSL modes
• Server SSL profile
— Used to configure the SSL connection
between the load balancer and the back-
end server pool
— Required in end-to-end SSL mode only

Configuring Layer 7 Load Balancer Rules
When configuring a layer 7 virtual server, you can optionally configure load balancer rules to
customize the load balancing behavior:
• You can configure match and action rules.
• Load balancer rules support REGEX to configure match conditions.

Creating Server Pools
When configuring a server pool, you specify values for several parameters.

Configuring Load Balancing Algorithms
Load balancing algorithms control how the incoming connections are distributed among the
servers in the pool.
Load Balancing Algorithms Methods
Round Robin Client requests are cycled through the available servers.
Weighted Round Robin Each server is assigned a weight based on its performance. This weight
determines how many client requests the server receives compared to
other servers in the pool.
Least Connection New connections are sent to the server that has the fewest connections.
Weighted Least Each server is assigned a weight based on its connection capacity. This
Connection weight determines how many client requests the server receives
compared to other servers in the pool.
IP Hash A server is selected on a hash of the source IP address and the total
weight of all running servers.

Configuring SNAT Translation Modes
Depending on the topology, SNAT might be
required so that the load balancer receives the
traffic from the server destined to the client.
SNAT can be enabled per server pool.
When creating a server pool, the following

SNAT translation modes are available:
• Automap: The load balancer uses its
interface IP address and ephemeral port to
continue the communication with a client who
initially connected to one of the server's
established listening ports.
• Disabled: No SNAT
• IP Pool: Allows users to specify a single IP
address range to be used by servers for
SNAT.

Configuring Active Monitors
You use active monitors to verify whether back-end servers are available.
Active monitors support checks based on the following protocols:
• HTTP
• HTTPS
• ICMP
• TCP
• UDP

Configuring Passive Monitors
Passive monitors check for errors during client connections and mark servers causing consistent
failures as down.
The number of failures are incremented when the following conditions occur:
• Layer 7 virtual servers: TCP connection errors or SSL handshake failures
• Layer 4 TCP virtual servers: TCP connection errors
• Layer 4 UDP virtual servers: Internet Control Message Protocol (ICMP) errors

Lab: Configuring Load Balancing
Configure load balancing on the Tier-1 Gateway to distribute web traffic
2. Test the Connectivity to Web Servers
3. Create a Load Balancer
4. Configure Route Advertisement and Route Redistribution for the Virtual IP Address
5. Use the CLI to Verify the Load Balancer Configuration
6. Verify the Operation of the Backup Server
7. Prepare for the Next Lab

• Describe load balancer architecture and components
• Identify load balancer deployment modes
• Create and configure a load balancer
• Create and configure layer 4 and layer 7 virtual servers
• Create and configure server pools

IPSec VPN

Learner Objectives
• Describe IPSec VPN requirements in NSX-T Data Center
• Recognize different VPN compatibilities across products
• Create and configure IPsec VPN tunnels

NSX-T Data Center VPN Services
NSX-T Data Center supports the following VPN types:
• IPSec VPN: Route-based IPSec VPN and policy-based IPSec VPN
• Layer 2 VPN
IPSec and layer 2VPN types are supported only on Tier-0 Gateways and require NSX Edge
nodes.

IPSec VPN Use Cases
IPSec VPN has several use cases:
• Allows businesses to interconnect remote IP networks securely
• Extends IP networks to remote offices
• Uses a routing-based connection between different, nonoverlapping IP subnets
• Provides a secure communication channel for other, nonsecure protocols such as Generic
Routing Encapsulation (GRE)

IPSec VPN Methods
IPSec VPN tunnel packets can use different types of headers:
• The authentication header (AH) provides data integrity and authentication without encryption.
• The encapsulating security payload header (ESP) provides encryption, data integrity, and
authentication.

IPSec VPN Modes
IPSec VPN supports transport and tunnel
modes:
• Transport mode:
— Preserves original IP header
— Typically used for remote-access VPN
• Tunnel mode:
— Encapsulates the entire IP datagram with
a new header
— Used for site-to-site VPN between IPSec-
enabled gateways

IPSec VPN Protocols and Algorithms
IPSec VPN includes several protocols and algorithms:
• Key management:
— IPSec VPN uses the Internet Key Exchange (IKE) protocol to
negotiate security parameters:
• IKE runs over UDP/500 port.
• IKEv1 (RFC 2409) and IKEv2 (RFC 5996).
• Authentication:
— Preshared key
— Certificates
• Encryption:
— Advanced Encryption Standard (AES)
• Data integrity:
— Secure Hash Algorithm (SHA)

IPSec VPN Certificate-Based Authentication
In NSX-T Data Center, IPSec VPN supports certificate-based authentication:
• Certificate per local endpoint
• Trusted certificate authority (CA) per local endpoint and certificate chains
• Improved security and manageability over preshared keys
• Certificate revocation list (CRL)

IPSec VPN Dead Peer Detection
Dead peer detection (DPD) is a method for detecting whether an IPSec connection is alive. A
DPD profile specifies the number of seconds to wait between probes to detect whether an IPSec
peer is alive:
• NSX-T Data Center provides a system-generated DPD profile, nsx-default-l3vpn-dpdprofile,
which is assigned by default when you configure an IPSec VPN service.
• Alternatively, you can create your own DPD profile using the NSX Manager simplified UI.

IPSec VPN Types
IPSec VPN types can be policy-based or route-based:
• Policy-based VPN
— A VPN policy determines the IPSec protected traffic that passes through the VPN tunnel.
— A static configuration requires modification of the VPN policy when the network topology
changes.
• Route-based VPN
— Protected local and remote networks are learned from BGP routes.
— Routes are learned through a specific interface called a virtual tunnel interface (VTI).
— All packets routed through the VTI are protected using IPSec.
— Tunnel redundancy is supported:
• Remote subnets can be learned over multiple BGP peers.
• The primary tunnel is active, whereas the secondary tunnel is standby.
• If the peer becomes unreachable on the primary tunnel, the secondary tunnel becomes
active.
IPSec VPN Deployment Considerations
When you deploy IPSec VPN, you should consider several factors:
• IPSec VPN services are only available on Tier-0 Gateways.
• Protected networks must be segments created through the UI or policy APIs.
• Segments can be connected to either Tier-0 or Tier-1 Gateways to leverage VPN services.
• Overlapping networks require multiple Tier-0 Gateways.
• VPN services are only available on active-standby Tier-0 Gateways.
• NSX-T Data Center supports site-to-site IPSec VPNs in tunnel mode.
• IPSec tunnels leverage DPDK-accelerated performance.

IPSec VPN High Availability
With IPSec VPN high availability:
• VPN supports active-standby high availability
on the Tier-0 Gateway.
• VPN services use gateway-level failover.
• VPN configuration data is synchronized.
• No VPN state is synchronized because
tunnels are reestablished on failover.
• You can use high availability virtual IP
addresses for external connections.

IPSec VPN Scalability
In NSX-T Data Center, the IPSec VPN implementation is standard-compatible. As a result, the
IPSec tunnel can be built with the devices of other vendors.
VPN Session or Service Edge Node Size

Small Medium Large Bare Metal
Number of Tunnels per Session (policy- N/A 128 128 128
based)
Number of Sessions N/A 128 256 512
Number of IPSec Tunnels (16 tunnels N/A 2,048 4,096 8,192
per session)

IPSec VPN Configuration Steps
To create an IPSec VPN tunnel:
1. Create and enable an IPSec VPN using an existing gateway.
2. (Optional) Configure a DPD profile.
3. (Optional) Configure an IKE profile.
4. (Optional) Configure an IPSec profile.
5. Add a local endpoint.
6. Configure an IPSec session:
a. Configure route-based IPSec.
b. Configure policy-based IPSec.

Configuring an IPSec VPN Service
To configure an IPSec VPN service, you select Networking > VPN SERVICES > ADD SERVICE
> IPsec. Then you specify the values for the options.

Configuring DPD Profiles
To configure a DPD profile, you select DPD PROFILES on the PROFILES tab. This option
appears after you configure an IPSec service.

Configuring IKE Profiles
To configure an IKE profile, you select IKE PROFILES. You can perform this step after you
configure an IPSec service.

Configuring IPSec Profiles
To configure the IPSec profile, you select IPSEC PROFILES. This step is optional after you
configure an IPSec service.

Configuring Local Endpoints
To configure the local endpoint, you select Networking > VPN > LOCAL ENDPOINTS. Then you
click ADD LOCAL ENDPOINT to define the local side of the IPSec connection.

Configuring IPSec VPN Sessions (1)
You add an IPSec session to define the VPN type: either policy-based or route-based. You can
find this configuration option by selecting Networking > VPN > IPSec VPN Sessions.

When you select the policy-based option, IPSec tunnels are used to connect multiple local
subnets that are behind the NSX Edge instance, with peer subnets on the remote VPN site.

In the Profiles and Initiation Mode section, you select the predefined DPD, IKE, and IPsec profiles
from the drop-down menus. You also define which side initiates the connection.

When you select the route-based option, tunneling is provided on traffic that is based on routes
that were learned dynamically over a virtual tunnel interface (VTI) using a preferred protocol,
such as BGP. IPSec secures all the traffic flowing through the VTI.

• Describe IPSec VPN requirements in NSX-T Data Center
• Recognize different VPN compatibilities across products
• Create and configure IPsec VPN tunnels

L2 VPN

Learner Objectives
• Describe L2 VPN requirements in NSX-T Data Center
• Create and configure L2 VPN secure connections
• Identify various supported L2 VPN peers

L2 VPN Use Cases
Layer 2 VPN can be used for different purposes:
• Extends networks (VLANs or VNIs) across sites on the same broadcast domain
• Enables VM mobility use cases, such as:
— Migration (including long distance vSphere vMotion)
— Disaster recovery without IP address change
• Commonly used to enable hybrid cloud cases

L2 VPN in NSX-T Data Center
In NSX-T Data Center, the layer 2 VPN has the following characteristics:
• It introduces a new transport method (GRE over IPsec).
• The L2 VPN configuration is available through the NSX Manager simplified UI.
• The NSX-T Data Center managed edge can be configured as an L2 VPN client.
• Hub-and-spoke topology is supported.
• Tunnel redundancy is not supported, and the L2 VPN relies on edge high availability.
• The L2 VPN is an NSX-only feature. It does not support third-party interoperability.

L2 VPN Deployment Considerations
When deploying an L2 VPN, you should consider several important points:
• NSX L2 VPN services are only available on Tier-0 Gateways.
• Segments can be connected to either Tier-1 or Tier-0 Gateways to use L2 VPN services.
• Egress optimization and unstretched networks are not currently supported.
• Only the preshared key authentication method is available.
• Peer code is a Base64-encoded string available on the L2 VPN server that contains the full L2
VPN configuration.

L2 VPN Hub-and-Spoke Topology
The hub-and-spoke topology
enables remote sites (spokes)
to communicate through a
central (hub) site:
• Hub-and-spoke topology is
supported from NSX-T Data
Center 2.4.
• Up to eight L2 VPN clients
are allowed per L2 VPN
server.
• Centralized access control is
supported at the hub site.
• Hub acts as a replicator to
other client networks.

L2 VPN Packet Format

L2 VPN Edge Packet Flow

L2 VPN Scalability
For L2 VPN sessions and services, edge node size scales.
L2 VPN Session and Service Edge Node Size

Small Medium Large Bare Metal
Number of Logical Segments N/A 64 64* 64*
Number of GRE Tunnels N/A 1 1 1
Number of L2 VPN Server Sessions N/A 2,048 4,094 4,094
Number of Logical Segments (total) N/A 2,048 4,094 4,094
Number of L2 VPN Client Sessions N/A 1 1 1
Number of Spokes per Hub N/A 8 8* 8*
* Numbers are soft limits or tested maximums.

L2 VPN Server Configuration Steps
The L2 VPN configuration uses the IPSec features of the gateway. To enable the L2 VPN, you
must first configure IPSec. Then, you can configure L2 VPN details.
To set up an L2 VPN server, you take the following steps:

1. Configure the VPN service (L2 VPN server).
2. Configure the L2 VPN session.
3. Configure segments.

Configuring the L2 VPN Server (1)
To configure the L2 VPN server, you select Networking > VPN > VPN Services. To begin, you
click ADD SERVICE and select L2 VPN Server.

The next step in the L2 VPN server configuration is to add the L2 VPN sessions.

You identify which segments should be extended through the L2 VPN tunnels. You can edit an
existing segment (vertical ellipsis icon) or create a new one.

You can configure segments on the L2 VPN Session page. After selecting edit mode and clicking
SEGMENTS, you can add segments and define the tunnel ID for each.

Supported L2 VPN Clients
You can use several edge options as L2 VPN clients.
The supported L2 VPN clients are:
• Standalone Edge: The L2 VPN client is deployed and configured in a non-NSX managed
environment. Only VLAN support is provided.
• NSX-managed Edge (NSX Data Center for vSphere): The Edge Services Gateway in NSX
Data Center for vSphere environment can act as an L2 VPN client or server endpoint for an L2
VPN.
• NSX-managed Edge (NSX-T Data Center): L2 VPN client is deployed and configured in the
NSX-T Data Center managed environment. Only overlay (GENEVE) support is provided.

L2 VPN Peer Compatibility Matrix
The table shows the compatibility between different L2 VPN appliances and base protocols.
• The L2 VPN client appliance is based on the NSX Data Center for vSphere Edge and is
configured using OVF parameters and the CLI.
• Standalone edge supports IPSec-based L2 VPN (L2 tunneling), which can be used for NSX-T
Data Center L2 VPN tunnels.
Version Protocol NSX-T Data Center Network Type
2.4 Support
Client Standalone Edge* SSL No VLAN
Standalone Edge* L2T Yes VLAN
NSX Data Center for vSphere L2T Yes VLAN, VNI (VXLAN)
Managed Edge (API)
NSX-managed Edge L2T Yes VNI (GENEVE)
*NSX Standalone Edge is available for download for both NSX Data Center for vSphere and NSX-T
Data Center products.

About Standalone Edge
You can configure a standalone edge as an L2 VPN client:
• A standalone edge must be deployed as a VM in a vSphere environment.
• vSphere 6.0 or newer is required. The VM version is 11.
• The deployment bundle offers two different deployment types.
• From the deployment bundle, select the L2 OVF file (large or extra large) to install edge VM.
• During deployment, the L2T section requests the peer code. No additional L2 VPN
configuration is needed.

About NSX-Managed Edge (NSX Data Center for vSphere)
In NSX Data Center for vSphere, you can configure the managed edge as an L2 VPN client:
• Beginning with version 6.2.4, the IPSec-based L2 VPN client or server is available on the NSX
Data Center for vSphere edges.
• The IPsec configuration must be present.
• Configuration is only available through REST API and not the UI or command line.

About NSX-Managed Edge (NSX-T Data Center)
In NSX-T Data Center, you can configure the L2 VPN client on the edge:
1. Configure the VPN service (L2 VPN client).
2. Configure the L2 VPN session (L2 VPN client).
3. Configure segments.

Configuring the L2 VPN Managed Client (1)

Before creating the L2 VPN client session, you must get or download the peer code from the L2
VPN server.

You configure the local and remote IP addresses and the peer code, which was retrieved in the
previous steps. You can also set the Admin Status to enable or disable the session.

On the Set Segments page, you define the network and the tunnel ID. The same configuration is
also available by selecting the SEGMENTS option.

Lab: Deploying Virtual Private Networks
Configure the VPN tunnel and verify the operation
2. Deploy Two New NSX Gateway Nodes to Support the VPN Deployment
3. Enable SSH on the Edge Nodes
4. Configure a New Edge Cluster
5. Deploy and Configure a New Tier-0 Gateway and Segments for VPN Support
6. Create an IPSec VPN Service
7. Create an L2 VPN Server and Session
8. Deploy the L2 VPN Client
9. Verify the Operation of the VPN Setup

• Describe L2 VPN requirements in NSX-T Data Center
• Create and configure layer 2 VPN secure connections
• List various supported L2 VPN Peers

Key Points (1)
• NAT can be configured on Tier-0 and Tier-1 Gateways.
• Typically, source translation is used to change a private address or port to a public address or
port for packets leaving your network.
• Typically, destination translation is used to redirect incoming packets with a destination of a
public address or port to a private IP address or port inside your network.
• Reflexive NAT is required when a Tier-0 Gateway is running in active-active mode because
you cannot configure a stateful service where paths might be irregular.
• DHCP is a standard networking protocol for dynamically distributing network configuration
parameters, such as IP addresses for interfaces.
• A DNS is a computer application that implements a service for resolving a computer name to
an IP address.

Key Points (2)
• The NSX-T Data Center load balancer distributes incoming service requests among multiple
servers and offers high availability for applications.
• The load balancer needs to be attached to a Tier-1 Gateway and can be deployed in one-arm
or inline mode.
• IPSec VPN services are available on tier 0 Gateways to interconnect different IP networks.
• Using the GRE over IPSec, L2 VPN tunnels can be used to extend layer 2 networks.
Questions?

NSXTICM24 M07 Services

Uploaded by

Copyright:

Available Formats

You might also like

NSXTICM24 M07 Services

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NSXTICM24 M07 Services

Uploaded by

Copyright:

Available Formats

NSX-T Data Center Services

© 2019 VMware, Inc.

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7-2

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7-3

© 2019 VMware Inc. All rights reserved.

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7-5

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7-6

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7-7

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7-8

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7-9

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 10

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 11

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 12

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 13

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 14

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 15

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 16

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 17

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 18

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 19

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 20

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 21

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 22

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 23

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 24

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 25

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 26

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 27

© 2019 VMware Inc. All rights reserved.

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 29

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 30

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 31

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 32

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 33

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 34

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 35

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 36

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 37

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 38

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 39

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 40

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 41

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 42

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 43

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 44

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 45

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 46

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 47

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 48

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 49

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 50

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 51

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 52

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 53

© 2019 VMware Inc. All rights reserved.

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 55

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 56

© 2019 VMware, Inc. VMware NSX-T: Install, Configure, Manage | 7 - 57