Azure Site-to-Site VPN with a NetScaler CloudBridge Connector

Platforms

Azure

Products

Azure VPN GatewayNetScaler

Result

An IPsec tunnel is up, and datacenter servers and Azure VMs reach each other

Overview

Connect an on-premises datacenter to an Azure virtual network with a site-to-site IPsec VPN between an Azure VPN gateway and a NetScaler CloudBridge Connector.

The CloudBridge Connector is a NetScaler (formerly Citrix ADC) feature that connects a datacenter to a public cloud such as Microsoft Azure or AWS. NetScaler encrypts the tunnel between the two sites with IPsec, so the traffic between the cloud and on-premises is protected with standard protocols and algorithms.

Like a traditional network, virtual machines in Microsoft Azure use a private network called a virtual network (VNet). To connect a VNet to an on-premises network over the internet, Azure uses a gateway as the cloud endpoint: ExpressRoute or a VPN gateway (policy-based or route-based). A policy-based VPN, used here, sends packets through IPsec tunnels based on policies built from the address prefixes of the on-premises network and the Azure VNet.

I wrote this post as one of the network prerequisites for Windows 365 Enterprise Cloud PCs with Microsoft Entra hybrid join. Hybrid joined Cloud PCs need line of sight to a domain controller, usually through Azure ExpressRoute or a site-to-site VPN like this one.

Prerequisites

Before you start, check that you have the following.

Configuration

Create the Azure side first, then the matching tunnel on NetScaler.

First create the Azure VPN gateway with a site-to-site (IPsec) connection in the Azure portal (portal.azure.com). Then configure the CloudBridge Connector tunnel on the NetScaler appliance in the datacenter to match the IPsec settings in Azure. This is my network diagram:

Azure VPN gateway

My Azure VNet CloudBridge_Network already has a subnet 10.1.0.0/16. For the gateway I added the address space 10.2.0.0/24:

Create the GatewaySubnet from that range:

Create the virtual network gateway. In 2021 I used these settings in the portal:

• Gateway type: VPN
• VPN type: Policy-based
• Virtual network: CloudBridge_Network, subnet GatewaySubnet (10.2.0.0/24)
• Public IP address: create a new one or use an existing one
• SKU: Basic, Generation: Generation1

Note: since October 1, 2023 you can't create a policy-based gateway in the Azure portal. It is only available with the Basic SKU, through PowerShell or the Azure CLI (see Create a Basic SKU VPN gateway), and Microsoft doesn't recommend Basic for production. For a new setup, create a route-based gateway (for example VpnGw1AZ) and turn on policy-based traffic selectors on the connection; the on-premises device then needs IKEv2. Creating a gateway can take 45 minutes or more.

Open the new gateway and note its public IP address; you need it for the NetScaler tunnel:

Create a local network gateway. The endpoint (IP address or FQDN) is the public IP of the NetScaler subnet IP (SNIP) used for CloudBridge. The address space is the datacenter subnet that goes through the tunnel, for example 192.168.1.0/24:

Add a connection to the local network gateway:

• Connection type: Site-to-site (IPsec)
• IKE protocol: IKEv1
• Shared key (PSK): use the same value in the NetScaler IPsec profile

NetScaler CloudBridge Connector

On NetScaler you need three objects: an IPsec profile, an IPv4 tunnel and a policy-based route (PBR) (see CloudBridge Connector tunnel between a datacenter and Azure). Go to System > CloudBridge Connector > IPSec Profile and create a profile:

• Encryption algorithm: AES
• Hash algorithm: HMAC_SHA1
• IKE protocol version: V1
• Pre-Shared Key Exists, with the shared key from the Azure connection

The IPsec profile is created:

Create the IPv4 tunnel:

• Remote IP: the public IP of the Azure VPN gateway
• Local IP type: Subnet IP
• Local IP: the SNIP behind your internet-facing public IP (NAT)
• Protocol: IPSEC, with the IPsec profile name

The tunnel status stays UNKNOWN until a PBR routes traffic between the datacenter and the Azure VNet:

Create the PBR. The source IP range is the datacenter subnet and the destination range is the Azure subnet that use the tunnel:

• Action: ALLOW
• Next hop type: IP Tunnel, with your tunnel name
• Operation: =
• Source IP: the datacenter subnet, for example 192.168.1.0 to 192.168.1.255
• Destination IP: the Azure subnet, for example 10.1.0.0 to 10.1.255.255

A new PBR is NOTAPPLIED, so select Apply in the action menu:

After a few minutes the tunnel is up: the Azure connection shows Connected and the NetScaler tunnel shows UP:

The Create/Monitor CloudBridge Connector dashboard shows the tunnel status and the traffic sent and received. Green means the bridge is up, red means it is down:

Testing and troubleshooting

Check the tunnel on NetScaler, then route the LAN traffic to Azure.

If the tunnel doesn't come up, check the NetScaler logs as described in CloudBridge Connector tunnel diagnostics and troubleshooting. Useful commands in an SSH session:

show iptunnel
show pbr
stat ipsec counters
shell cat /tmp/iked.debug

Make sure the tunnel is UP, the PBR is APPLIED and it has Hits. Output of show iptunnel and show pbr in my lab:

1)  Domain.......:          0
    Name.........:   IPsec_Tunnel_Azure (TUN1)
    Remote.......:   13.81.x.x          Mask......: 255.255.255.255
    Local........:   192.168.10.180     Encap.....: 192.168.10.180
    Protocol.....:            IPSEC     Type......:              C
    IPSec Profile Name.......: IPSec_CloudBridge_profile
    IPSec Tunnel Status......:               UP
    Number of PBRs ..........:                1
 Done
1)  Name: PBR_CloudBridge
    Action: ALLOW                       Hits: 3
    srcIP = 192.168.1.0-192.168.1.255
    destIP = 10.1.0.0-10.1.255.255
    Active Status: ENABLED              Applied Status: APPLIED
    Priority: 10
    IpTunnel: IPsec_Tunnel_Azure
 Done

To route traffic between the Azure subnet (10.1.0.0/16) and the on-premises LAN (192.168.1.0/24), I use a software router (Windows Server 2016 with Routing and Remote Access) with a static route for 10.1.0.0/16. Its gateway 192.168.1.62 is the NetScaler SNIP in my LAN, which sends the traffic through the tunnel. A ping and tracert from a LAN server reach the Azure VM 10.1.0.4:

You can also add the static route on each Windows machine. Open a Command Prompt as administrator; the mask must match the /16 Azure subnet, and -p keeps the route after a restart:

route -p ADD 10.1.0.0 MASK 255.255.0.0 192.168.1.62