Office Network Needs Private Azure Access? Configure a Site-to-Site VPN

Published on:
#networking

CloudTrips now supports private access from an individual laptop, but asking every employee in an office to start a separate VPN client does not provide a shared network connection. The office network needs one secure path to Azure.

A site-to-site (S2S) VPN creates an encrypted IPsec/IKE tunnel between two network gateways. The office VPN device represents one site, and the Azure VPN Gateway in the CloudTrips hub represents the other. Computers behind the office device can then reach permitted private Azure addresses without each computer running Azure VPN Client.

This trip builds on: Private Azure Access Needs a VPN Endpoint? Create a VPN Gateway.

Understand What Is Required

The Azure resources can be prepared in the portal, but a working tunnel requires a real compatible VPN device or router at the office and someone who can configure it. That device must have a public IPv4 address or an FQDN that resolves to one public IPv4 address.

Use the office’s real values. The example private range below is not a value to copy if the office uses a different range:

Office private network: 192.168.50.0/24
Office VPN public endpoint: <your-vpn-device-public-ip-or-fqdn>
Local network gateway: lng-cloudtrips-office-test-weu
Azure VPN gateway: vng-cloudtrips-hub-test-weu
Connection: conn-cloudtrips-office-to-hub-test-weu
Protocol: IKEv2 over IPsec

The office range must not overlap the CloudTrips hub, application, services, VPN-client, or any other connected network range. An overlap makes routing ambiguous because Azure cannot determine which side owns the destination.

The existing point-to-site configuration can remain on the same Azure VPN Gateway. Point-to-site connects individual devices; site-to-site connects a whole network behind a VPN device.

Create the Local Network Gateway

Search the Azure portal for Local network gateways, open the service, and select Create.

Configure:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Region: West Europe
Name: lng-cloudtrips-office-test-weu
Endpoint: IP address or FQDN
IP address/FQDN: <your-vpn-device-public-ip-or-fqdn>
Address space: <your-office-private-address-range>
Configure BGP settings: No

The Local Network Gateway is not a gateway deployed at the office. It is an Azure resource that describes the real office side:

  • The endpoint tells Azure where the office VPN device is on the internet.
  • The address space tells Azure which private destinations exist behind that device.

Select Review + create, and then select Create.

Create the Site-to-Site Connection

Open vng-cloudtrips-hub-test-weu, select Settings > Connections, and select Add.

On Basics, configure:

Connection type: Site-to-site (IPSec)
Name: conn-cloudtrips-office-to-hub-test-weu
Region: West Europe

On Settings, configure:

Virtual network gateway: vng-cloudtrips-hub-test-weu
Local network gateway: lng-cloudtrips-office-test-weu
Shared key: <generate-a-strong-shared-key>
IKE protocol: IKEv2
Use Azure private IP address: Disabled
Enable BGP: Disabled
FastPath: Disabled
IPsec/IKE policy: Default
Use policy-based traffic selector: Disabled
DPD timeout in seconds: 45
Connection mode: Default

The connection joins Azure’s VNG to the Local Network Gateway description. The shared key is a secret used to authenticate the two VPN endpoints. Generate a strong value, store it securely, and configure exactly the same value on the office VPN device. Do not commit it to a repository.

Leave ingress and egress NAT rule associations empty. NAT is not required because the planned address spaces do not overlap.

Select Review + create, and then select Create.

Configure the Office VPN Device

The Azure connection cannot become connected until the other side is configured. Give the office network administrator:

Remote VPN endpoint: public IP of vng-cloudtrips-hub-test-weu
Authentication: the same shared key used in Azure
Protocol: IKEv2/IPsec
Office prefixes: the private ranges behind the office VPN device
Azure prefixes: 10.60.0.0/16, 10.20.0.0/16, 10.40.0.0/16

The exact menus and IPsec settings depend on the VPN-device vendor and model. Use a configuration supported by both that device and Azure VPN Gateway. The public gateway IP can be found on vng-cloudtrips-hub-test-weu under Settings > Properties.

The hub prefix belongs to the VNet containing the gateway. The application and services prefixes belong to the directly peered spokes. Gateway transit on the hub peerings and remote-gateway use on the spoke peerings make those spokes reachable through the shared gateway.

Verify the Tunnel

Open vng-cloudtrips-hub-test-weu > Settings > Connections, and open conn-cloudtrips-office-to-hub-test-weu.

The status progresses through Unknown or Connecting and becomes Connected only after the office VPN device establishes the matching tunnel. If no real device is configured, a disconnected status is expected; creating Azure objects alone cannot simulate the other site.

You can check the same status from Cloud Shell:

az network vpn-connection show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name conn-cloudtrips-office-to-hub-test-weu \
  --query "{Status:connectionStatus,IngressBytes:ingressBytesTransferred,EgressBytes:egressBytesTransferred}" \
  --output table

After the status is Connected, test from a computer inside the office network to an allowed private workload in 10.20.0.0/16. The workload’s NSG must allow the required port from the real office address range. The test must use the workload’s private IP, not its public IP.

The path is now:

Office computer
  -> office VPN device
  -> encrypted IPsec/IKE tunnel
  -> VPN Gateway in the CloudTrips hub
  -> VNet peering
  -> private CloudTrips workload

If this was only a configuration exercise and no real office device will use the connection, remove the unused connection and Local Network Gateway:

az network vpn-connection delete \
  --resource-group rg-cloudtrips-network-test-weu \
  --name conn-cloudtrips-office-to-hub-test-weu \
  --yes

az network local-gateway delete \
  --resource-group rg-cloudtrips-network-test-weu \
  --name lng-cloudtrips-office-test-weu

Keep vng-cloudtrips-hub-test-weu when it is still required for the earlier point-to-site configuration. Deleting the VNG would also remove that private entry point.