This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure storage, databases, and networking (25–30%)
   --> Implement security for Azure network services
      --> Implement and configure security for virtual private network (VPN) connections

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

A virtual private network (VPN) provides an encrypted connection between networks, users, and Azure resources over an underlying network. VPN connections are commonly used to connect:

On-premises datacenters to Azure
Branch offices to Azure
Remote users to Azure
Azure virtual networks to other networks
Virtual WAN hubs to branch locations
Azure resources to on-premises services

For the SC-500 exam, securing VPN connections involves more than simply creating a tunnel. You must understand:

The difference between site-to-site and point-to-site VPN
VPN authentication and encryption
IPsec and IKE
VPN gateway configuration
Microsoft Entra authentication
Certificates and preshared keys
Routing and traffic inspection
High availability
Monitoring and troubleshooting
Security limitations of private connectivity

Azure VPN Gateway and Azure Virtual WAN support site-to-site and point-to-site connectivity. Azure Virtual WAN also provides centralized routing and connectivity across multiple hubs and connected networks.

VPN Connection Types

Site-to-site VPN

A site-to-site (S2S) VPN connects an entire network to Azure.

Typical examples include:

A corporate datacenter connecting to an Azure VNet
A branch office connecting to an Azure Virtual WAN hub
A retail location connecting to cloud-based applications
A manufacturing facility connecting to Azure-hosted services

The connection is normally established between:

An on-premises VPN device and an Azure VPN gateway
An on-premises VPN device and a Virtual WAN VPN gateway

The VPN device can be a hardware appliance, software appliance, or supported Virtual WAN partner device.

Site-to-site VPN connections use IPsec/IKE to establish encrypted tunnels. In Azure Virtual WAN, site-to-site connectivity uses IPsec/IKE, including IKEv1 and IKEv2 scenarios.

Important characteristics

Connects networks rather than individual users
Usually remains available continuously
Requires compatible VPN devices
Requires matching tunnel configuration
Uses routing to determine which traffic enters the tunnel
Can support redundant tunnels and connections

Point-to-site VPN

A point-to-site (P2S) VPN connects an individual computer or device to Azure.

Typical examples include:

An employee working from home
An administrator connecting from a remote location
A developer accessing private Azure resources
A contractor connecting to a restricted environment

The connection is initiated by the client computer rather than by a permanent VPN device.

Point-to-site VPN requires:

A route-based VPN gateway
A supported VPN client
A client address pool
A supported tunnel protocol
An authentication method

Point-to-site VPN supports OpenVPN, IKEv2, and, in supported scenarios, SSTP. Microsoft Entra ID authentication is supported only with OpenVPN and requires the Azure VPN Client.

Site-to-site versus point-to-site

Characteristic	Site-to-site VPN	Point-to-site VPN
Primary purpose	Connects networks	Connects individual users or devices
Initiated by	VPN device or gateway	User VPN client
Typical users	Branches, datacenters	Remote employees and administrators
Required endpoint	VPN device	VPN client
Common protocols	IPsec/IKE	OpenVPN, IKEv2, SSTP
Authentication	Preshared keys or certificates, depending on configuration	Certificates, Microsoft Entra ID, or RADIUS
Routing	Network routes	Client routes and address pools
Common Azure service	VPN Gateway or Virtual WAN	VPN Gateway or Virtual WAN User VPN

Azure VPN Gateway

Azure VPN Gateway is a managed Azure service that provides encrypted connectivity between Azure virtual networks and other networks.

It can support:

Site-to-site VPN
Point-to-site VPN
VNet-to-VNet VPN
VPN connections over ExpressRoute private peering in supported designs
Active-active gateway configurations
BGP-based route exchange

VPN Gateway is deployed into a dedicated subnet named:

GatewaySubnet

The GatewaySubnet must be appropriately sized for the selected gateway configuration. It should not contain network security groups or user-defined routes that interfere with gateway operation unless specifically supported by the design.

Azure Virtual WAN VPN Connectivity

Azure Virtual WAN provides a centralized architecture for VPN connectivity.

A Virtual WAN hub can contain:

Site-to-site VPN gateways
Point-to-site User VPN gateways
ExpressRoute gateways
A hub router
Azure Firewall
Supported network virtual appliances

Basic Virtual WAN supports site-to-site VPN connectivity. Standard Virtual WAN supports additional capabilities, including point-to-site VPN, ExpressRoute, inter-hub transit, VNet-to-VNet transit, Azure Firewall, and supported network virtual appliances.

Virtual WAN is useful when an organization needs to connect many:

Branch offices
Azure VNets
Remote users
Regional hubs
On-premises environments

A secured Virtual WAN design can route VPN traffic through Azure Firewall for centralized inspection.

IPsec and IKE

IPsec

Internet Protocol Security, or IPsec, provides security for IP traffic.

IPsec can provide:

Encryption
Data integrity
Authentication
Protection against tampering
Protection against replay attacks

IPsec is commonly used to secure site-to-site VPN tunnels.

IKE

Internet Key Exchange, or IKE, is used to negotiate security parameters and establish keys for the VPN connection.

IKE establishes the security association used by IPsec.

The two major versions are:

IKEv1
IKEv2

IKEv2 is generally preferred for modern VPN deployments because it provides improved reliability and mobility support compared with IKEv1.

A successful VPN connection requires compatible settings on both sides, including:

Encryption algorithms
Integrity algorithms
Diffie-Hellman group
PFS settings
Authentication method
Lifetime settings, where applicable

If the settings do not match, the tunnel may fail during negotiation.

VPN Encryption and Integrity

VPN security depends on selecting compatible cryptographic settings.

Common encryption algorithms include:

AES128
AES256
GCMAES128
GCMAES256

Integrity algorithms may include:

SHA256
SHA384
GCM-based integrity

GCM algorithms combine encryption and integrity protection. When GCM is selected for IPsec encryption or integrity, the corresponding IPsec settings must use compatible GCM algorithms.

For example, a configuration using GCMAES256 for IPsec encryption must use a compatible GCMAES256 integrity setting.

Virtual WAN point-to-site VPN gateways have default IPsec policies and also support selected custom IPsec policies. The supported combinations include encryption, integrity, Diffie-Hellman, and Perfect Forward Secrecy settings.

Diffie-Hellman and Perfect Forward Secrecy

Diffie-Hellman

Diffie-Hellman groups are used during key exchange to establish shared cryptographic material.

Examples include:

DHGroup14
DHGroup24
ECP256
ECP384

The selected group must be supported by both VPN endpoints.

Perfect Forward Secrecy

Perfect Forward Secrecy, or PFS, provides additional protection by using new key material during IPsec rekeying.

If a session key is compromised, PFS helps prevent the compromise from being used to decrypt other sessions.

When configuring custom VPN policies, the PFS group must be supported by the gateway and compatible with the remote VPN device.

Preshared Keys

A preshared key (PSK) is a shared secret configured on both VPN endpoints.

For example:

Azure VPN Gateway  <---- shared secret ---->  On-premises VPN device

The tunnel cannot be established if the keys do not match.

Preshared-key security practices

Use long, randomly generated keys.
Avoid dictionary words and predictable patterns.
Do not store keys in source code.
Store keys in a secure secrets-management system.
Restrict access to VPN configuration.
Rotate keys according to organizational policy.
Coordinate key changes to avoid service interruption.
Avoid sharing keys through email or chat.
Use separate keys for separate connections when practical.

Preshared keys authenticate the VPN endpoints, but they do not replace authorization controls for the resources accessed through the tunnel.

Certificate-Based VPN Authentication

Certificate-based authentication uses certificates to establish trust between VPN endpoints or clients.

Certificates can provide stronger security than preshared keys in appropriate scenarios.

For site-to-site certificate authentication, certificates can be stored in Azure Key Vault, and the VPN gateway can access them using a user-assigned managed identity. Site-to-site certificate authentication is not supported on Basic SKU VPN gateways.

Certificate security considerations

Protect the private key.
Use a trusted certificate authority.
Monitor certificate expiration.
Rotate certificates before expiration.
Revoke compromised certificates.
Restrict access to certificate stores.
Avoid exporting private keys unnecessarily.
Validate the complete certificate chain.
Ensure the certificate subject and usage are appropriate.

A certificate-based design can reduce the risks associated with manually managed shared secrets, but it introduces certificate lifecycle-management responsibilities.

Point-to-Site Authentication Methods

Azure point-to-site VPN supports several authentication methods.

Certificate authentication

With certificate authentication:

The gateway is configured with a trusted root certificate.
The client receives a certificate issued by that trusted root.
The client uses the certificate when establishing the VPN connection.
The gateway validates the certificate.

The root certificate’s public information is uploaded to the gateway. The client certificate must be installed on the connecting device.

Microsoft Entra ID authentication

Microsoft Entra ID authentication allows users to authenticate using their organizational identity.

Benefits include:

Centralized identity management
Single sign-on
Multifactor authentication
Conditional Access
Easier user lifecycle management
Reduced dependence on manually distributed certificates

Microsoft Entra authentication for point-to-site VPN is supported only with OpenVPN and requires the Azure VPN Client.

RADIUS authentication

RADIUS authentication can integrate VPN access with an existing authentication infrastructure.

RADIUS may be appropriate when an organization already uses:

Network access servers
Centralized authentication services
Existing identity infrastructure
Multifactor authentication through a RADIUS-compatible provider

The authentication method must be compatible with the selected VPN tunnel protocol.

Microsoft Entra ID, MFA, and Conditional Access

Microsoft Entra ID authentication can improve the security of remote-access VPN connections.

For example, an organization can require:

Multifactor authentication
Authentication from compliant devices
Access only from approved locations
Risk-based sign-in controls
Specific user or group membership
Strong authentication methods

However, Microsoft Entra authentication does not automatically authorize a user to access every Azure resource.

After the VPN connection is established, access is still controlled by mechanisms such as:

Network routing
Network security groups
Azure Firewall
Private endpoints
Azure RBAC
Application authentication
Database permissions
Operating-system permissions

VPN authentication answers:

Who is allowed to establish the VPN connection?

It does not necessarily answer:

Which resources is that user allowed to access?

Azure VPN Client

The Azure VPN Client is used for supported point-to-site VPN configurations, particularly Microsoft Entra ID authentication with OpenVPN.

A typical configuration process includes:

Configure the point-to-site VPN gateway.
Select the tunnel protocol.
Configure the authentication method.
Define the client address pool.
Download the VPN client profile.
Install the Azure VPN Client.
Import the profile.
Sign in or provide the required certificate.
Establish the VPN connection.

The client profile must match the gateway’s configuration.

For Microsoft Entra authentication, the client must use the supported Azure VPN Client and OpenVPN protocol.

Client Address Pools

Point-to-site VPN clients receive IP addresses from a configured client address pool.

For example:

P2S client address pool: 172.16.100.0/24

When a user connects, the VPN gateway assigns an available address from that pool.

Client pool considerations

The pool must not overlap with Azure VNets.
It must not overlap with on-premises networks.
It must not overlap with other connected networks.
It must provide enough addresses for expected users.
It should be planned for growth.
It may be divided into separate pools for different user groups.

In Virtual WAN, different user groups can be mapped to different address pools. This can allow firewall policies to distinguish users indirectly by their assigned VPN address range. Azure Firewall and Virtual WAN do not natively filter traffic based directly on a user’s Microsoft Entra group name.

User Groups and Network-Level Segmentation

Organizations may need to provide different levels of access to different groups of VPN users.

For example:

Administrators require access to management subnets.
Developers require access to development resources.
Employees require access only to business applications.
Contractors require access to a limited application environment.

A secure approach is to:

Define user groups.
Assign different client address pools to the groups.
Configure routing and firewall policies based on those address pools.
Restrict access to only the required destinations.
Monitor access and review group membership.

This is network-level segmentation. It should be combined with identity-based authorization at the application and resource layers.

VPN Routing

A VPN connection is useful only if traffic is routed correctly.

Routing determines:

Which traffic enters the VPN tunnel
Which Azure networks are reachable
Which on-premises networks are reachable
Whether users can access the internet through the VPN
Whether traffic is inspected by a firewall
Whether traffic can move between connected branches

Route-based VPN

Modern Azure VPN Gateway deployments generally use route-based VPN gateways.

Route-based VPNs use routing tables and traffic selectors to determine how traffic is sent through the tunnel.

Point-to-site VPN requires a route-based VPN gateway.

Address-space overlap

Overlapping address spaces can cause serious routing problems.

Avoid overlap between:

Azure VNets
On-premises networks
Branch networks
VPN client pools
Virtual WAN hubs
Other connected networks

For example, if both Azure and on-premises use 10.0.0.0/16, the gateway may not be able to determine the intended destination correctly.

BGP and Dynamic Routing

Border Gateway Protocol (BGP) can dynamically exchange routes between Azure and an on-premises network.

BGP can reduce the need to manually configure routes when networks change.

Benefits include:

Dynamic route exchange
Support for larger network environments
Automatic learning of network prefixes
Improved failover behavior
Reduced manual route maintenance

Security considerations include:

Advertise only approved prefixes.
Avoid advertising overly broad routes.
Validate learned routes.
Monitor unexpected route changes.
Prevent unintended transit between networks.
Ensure the on-premises device is configured correctly.
Review route propagation after changes.

BGP does not itself provide encryption. Encryption is provided by the VPN tunnel when IPsec/IKE is used.

High Availability for VPN Connections

A VPN connection can become a critical dependency. If the tunnel fails, users may lose access to applications and data.

High-availability options include:

Active-active VPN gateways
Redundant VPN devices
Multiple site-to-site tunnels
Multiple branch connections
Multiple Virtual WAN hubs
Multiple internet links
ExpressRoute combined with VPN where appropriate

Active-active gateways

In an active-active configuration, both gateway instances establish site-to-site VPN tunnels with the on-premises VPN device.

The on-premises device must be configured to support the corresponding redundant tunnels.

Active-active gateway configurations are an important part of highly available VPN designs.

High-availability best practices

Use redundant VPN devices.
Use independent network paths where possible.
Avoid a single internet provider for critical locations.
Test failover regularly.
Monitor both tunnel instances.
Verify that routing converges correctly.
Ensure firewall policies support both paths.
Document recovery procedures.

VPN and Azure Firewall

A VPN tunnel provides encrypted connectivity, but it does not automatically provide application-level access control.

For centralized inspection, traffic can be routed through Azure Firewall.

A common architecture is:

			
Branch Office
     |
     | IPsec VPN
     |
Virtual WAN Hub
     |
Azure Firewall
     |
Azure VNet

		

Azure Firewall can enforce policies based on:

Source address
Destination address
Protocol
Port
Application destination
Threat intelligence
Network segmentation requirements

For example, a branch may be allowed to access an application subnet over HTTPS but denied access to management ports such as SSH or RDP.

The VPN connection establishes the network path. Azure Firewall and other controls determine what traffic is permitted over that path.

VPN and Network Security Groups

Network security groups (NSGs) can provide additional traffic filtering for Azure subnets and network interfaces.

NSGs can restrict:

Source addresses
Destination addresses
Source ports
Destination ports
Protocols
Inbound traffic
Outbound traffic

For example, a VPN client address pool might be permitted to access only TCP 443 on an application subnet.

However, NSGs should not be considered a replacement for:

VPN authentication
Azure Firewall
Application authentication
Azure RBAC
Database authorization
Endpoint security

A defense-in-depth design uses multiple controls at different layers.

VPN Encryption Limitations

VPN encryption protects traffic while it travels through the VPN tunnel.

It does not necessarily encrypt traffic after it reaches Azure.

For example:

			
On-premises network
       |
   Encrypted VPN
       |
Azure VPN gateway
       |
Azure VNet
       |
Unencrypted internal traffic

		

If traffic must remain encrypted inside Azure, use additional controls such as:

Application-level TLS
HTTPS
Database encryption protocols
IPsec between appropriate endpoints
Private connectivity combined with application encryption

Azure Virtual WAN provides encryption through its VPN gateways for IPsec/IKE and supported point-to-site protocols. However, traffic between a Virtual WAN hub and connected VNets, or between hubs, is not automatically encrypted by a separate Virtual WAN encryption capability. Application-level encryption may be required when encryption is needed after traffic enters the Azure network.

Monitoring and Troubleshooting VPN Connections

Important VPN monitoring areas include:

Connection status
Tunnel status
Authentication failures
IKE negotiation failures
IPsec negotiation failures
Packet drops
Route propagation
BGP sessions
Gateway health
Throughput
Latency
Failover behavior
Firewall denies

Common causes of VPN failure

Mismatched preshared keys

The key configured on Azure and the remote device must match.

Incompatible cryptographic settings

The two endpoints must support compatible:

Encryption algorithms
Integrity algorithms
Diffie-Hellman groups
PFS settings
IKE versions

Incorrect address spaces

Overlapping networks can prevent correct routing.

Incorrect local network gateway configuration

The local network gateway must contain the correct:

Public IP address
Address prefixes
BGP settings, if used

Incorrect client profile

Point-to-site users may have an outdated or incorrect VPN profile.

Authentication problems

Possible causes include:

Expired certificates
Incorrect certificate chain
Incorrect Microsoft Entra configuration
Missing user permissions
Incorrect RADIUS configuration
Unsupported tunnel and authentication combination

Firewall or NSG restrictions

The VPN tunnel may be established successfully while traffic is blocked by:

Azure Firewall
Network security groups
On-premises firewalls
Operating-system firewalls
Application firewalls

Security Best Practices

1. Prefer strong authentication

Use Microsoft Entra ID with MFA and Conditional Access for supported point-to-site OpenVPN scenarios.

2. Use strong cryptographic settings

Avoid weak or obsolete algorithms. Ensure both VPN endpoints support the selected configuration.

3. Protect preshared keys and certificates

Store secrets securely and restrict administrative access.

4. Rotate credentials

Rotate preshared keys and certificates according to policy.

5. Use route-based VPN gateways

Route-based gateways are required for point-to-site VPN and support modern routing scenarios.

6. Avoid address-space overlap

Plan all Azure, on-premises, branch, and client address spaces before deployment.

7. Restrict route propagation

Advertise only the routes that each connection requires.

8. Inspect traffic where appropriate

Use Azure Firewall, network security groups, and application controls to restrict traffic over the VPN.

9. Use high availability

Deploy redundant gateways, tunnels, devices, or network paths for critical connectivity.

10. Monitor and test

Enable appropriate diagnostics, monitor tunnel health, and test failover regularly.

11. Do not trust VPN users automatically

A successful VPN connection should not grant unrestricted access to the environment.

12. Use application-level encryption when required

VPN encryption protects the tunnel, not necessarily all traffic after it enters Azure.

Common SC-500 Exam Traps

Trap 1: Microsoft Entra authentication works with every P2S protocol

Microsoft Entra ID authentication for P2S VPN is supported only with OpenVPN and requires the Azure VPN Client.

Trap 2: A VPN tunnel automatically authorizes access to all Azure resources

The VPN establishes connectivity. NSGs, firewalls, RBAC, application authentication, and other controls still determine access.

Trap 3: Private connectivity means traffic is always encrypted

Private connectivity does not necessarily provide encryption throughout the entire path. Application-level encryption may still be required.

Trap 4: P2S VPN can use a policy-based gateway

Point-to-site VPN requires a route-based VPN gateway.

Trap 5: A preshared key is the same as authorization

A preshared key authenticates VPN endpoints. It does not define which resources a user or network may access.

Trap 6: BGP provides encryption

BGP exchanges routes. IPsec/IKE provides VPN encryption.

Trap 7: One successful tunnel provides high availability

A single tunnel or device can be a single point of failure. Use redundant connections for critical environments.

Practice Exam Questions

Question 1

A company wants remote employees to connect to Azure using Microsoft Entra ID authentication and multifactor authentication.

Which configuration should the company use?

A. Site-to-site VPN with IKEv1
B. Point-to-site VPN using OpenVPN and the Azure VPN Client
C. ExpressRoute without a VPN client
D. Site-to-site VPN using only a preshared key

Correct answer: B

Explanation: Microsoft Entra ID authentication for point-to-site VPN is supported with OpenVPN and requires the Azure VPN Client. Microsoft Entra Conditional Access and MFA can then be used for remote access.

Question 2

An administrator needs to connect an on-premises datacenter to an Azure VNet so that all servers in the datacenter can access Azure resources.

Which solution is most appropriate?

A. Site-to-site VPN
B. Point-to-site VPN
C. Azure Bastion
D. Azure Private DNS only

Correct answer: A

Explanation: Site-to-site VPN connects entire networks. Point-to-site VPN is intended for individual users or devices.

Question 3

A point-to-site VPN connection fails because the selected gateway is policy-based.

What should the administrator do?

A. Add a public IP address to every client
B. Convert the policy-based gateway directly to route-based
C. Replace the gateway with a route-based VPN gateway
D. Enable Azure Firewall on the client

Correct answer: C

Explanation: Point-to-site VPN requires a route-based VPN gateway. A policy-based gateway cannot simply be converted to route-based; the gateway must be replaced with an appropriate route-based configuration.

Question 4

A site-to-site VPN tunnel cannot be established after a security policy change. The Azure gateway and the on-premises device use different encryption and Diffie-Hellman settings.

What is the most likely cause?

A. The VPN client address pool is too large
B. The cryptographic parameters are incompatible
C. Azure RBAC is denying data-plane traffic
D. The VNet has no storage account

Correct answer: B

Explanation: Both VPN endpoints must support compatible IKE and IPsec settings, including encryption, integrity, and Diffie-Hellman parameters.

Question 5

An organization wants to provide different VPN access levels to administrators and contractors.

Which design is most appropriate?

A. Give every user the same client address pool and unrestricted routing
B. Use different client address pools and apply firewall rules to those address ranges
C. Disable authentication after the VPN tunnel is established
D. Use only a shared preshared key for all users

Correct answer: B

Explanation: Different point-to-site user groups can be mapped to different address pools. Firewall and routing policies can then restrict access based on the assigned source address ranges.

Question 6

A company requires site-to-site VPN connectivity to remain available if one VPN gateway instance fails.

Which configuration should it consider?

A. Active-active VPN gateway with redundant tunnels
B. A single point-to-site client
C. A larger VPN client address pool
D. A storage account firewall rule

Correct answer: A

Explanation: Active-active gateway configurations allow both gateway instances to establish site-to-site tunnels and can improve availability when the remote VPN device is configured appropriately.

Question 7

An organization uses Azure Virtual WAN and wants all traffic from connected branches to be inspected by Azure Firewall before reaching Azure VNets.

What should the organization configure?

A. Only a point-to-site VPN profile
B. Routing that directs the appropriate private traffic through Azure Firewall
C. A certificate on every Azure VM
D. A public IP address for every subnet

Correct answer: B

Explanation: Establishing a VPN connection does not automatically force traffic through Azure Firewall. Routing and security configuration must direct the traffic through the inspection point.

Question 8

A VPN tunnel is successfully established, but users cannot access an Azure application on TCP port 443.

Which control should the administrator investigate first?

A. The Azure Firewall or NSG rules governing the application traffic
B. The Azure subscription display name
C. The VPN client’s desktop wallpaper
D. The storage account replication type

Correct answer: A

Explanation: A successful tunnel establishes connectivity, but Azure Firewall, NSGs, host firewalls, and application controls can still block the traffic.

Question 9

An organization is planning a point-to-site VPN client address pool. Which address-space choice is appropriate?

A. A range that overlaps the Azure VNet
B. A range that overlaps the on-premises network
C. A unique, nonoverlapping range sized for expected clients
D. The same range used by another Virtual WAN hub

Correct answer: C

Explanation: The client address pool must not overlap with Azure, on-premises, branch, or other connected network address spaces. It must also provide enough addresses for current and future users.

Question 10

A security engineer states that BGP will encrypt all traffic exchanged between Azure and the datacenter.

How should this statement be evaluated?

A. Correct, because BGP provides AES encryption
B. Correct, because BGP replaces IPsec
C. Incorrect, because BGP exchanges routes while IPsec/IKE provides VPN encryption
D. Incorrect, because VPN connections cannot use dynamic routing

Correct answer: C

Explanation: BGP is a dynamic routing protocol. It exchanges network prefixes but does not encrypt traffic. IPsec/IKE provides encryption for the VPN tunnel.

Key Takeaways

For the SC-500 exam, remember:

Site-to-site VPN connects networks.
Point-to-site VPN connects individual users or devices.
Point-to-site VPN requires a route-based gateway.
Microsoft Entra authentication for P2S VPN requires OpenVPN and the Azure VPN Client.
MFA and Conditional Access can strengthen remote-access authentication.
IPsec provides encryption and integrity; IKE negotiates security parameters.
Preshared keys authenticate VPN endpoints but do not authorize resource access.
Certificates require secure lifecycle management.
BGP exchanges routes but does not provide encryption.
VPN encryption protects the tunnel, not necessarily all traffic after it enters Azure.
Azure Firewall and NSGs can restrict traffic over a VPN connection.
Avoid overlapping address spaces.
Use redundant tunnels and gateways for critical connections.
Monitor authentication, tunnel health, routing, firewall activity, and configuration changes.