How to Set Up VPN Site-to-Site with Windows RRAS on Windows Server 2025
A site-to-site VPN connects two physically separate networks — typically two branch offices or a headquarters and a data center — through an encrypted tunnel over the public internet, making both networks appear as a single unified network to devices on either end. Windows Server 2025 includes the Routing and Remote Access Service (RRAS), a full-featured software router and VPN gateway that supports site-to-site tunnels using industry-standard protocols including IKEv2 and L2TP/IPsec. Unlike client-to-site VPNs where individual users dial in, a site-to-site VPN requires no client software — the tunnel is established between two RRAS servers and remains permanently up, routing traffic between the two subnets transparently. This guide covers the complete end-to-end configuration of an IKEv2 site-to-site VPN between two Windows Server 2025 RRAS servers, including static routing, testing, and inspecting IPsec security associations.
Prerequisites
- Two Windows Server 2025 machines — one at each site (referred to as Site A Server and Site B Server)
- Each server has a public IP address or is reachable from the internet (or a WAN simulation for lab use)
- Each server has a second NIC connected to its respective internal LAN
- Firewall rules allowing UDP 500, UDP 4500, and IP protocol 50 (ESP) between both public IPs
- Administrative access to both servers
- A pre-shared key or machine certificates for IKEv2 authentication
Step 1: Install Remote Access Role on Both Servers
Install the Remote Access role with the RRAS and Routing sub-features on both RRAS servers. This must be done on each server independently.
# Run on BOTH servers (Site A and Site B)
Install-WindowsFeature -Name RemoteAccess -IncludeManagementTools
Install-WindowsFeature -Name RRAS -IncludeManagementTools
Install-WindowsFeature -Name Routing -IncludeManagementTools
# Verify the features are installed
Get-WindowsFeature -Name RemoteAccess, RRAS, Routing |
Select-Object DisplayName, Installed | Format-Table -AutoSize
# A reboot may be required
# Restart-Computer -Force
Step 2: Configure RRAS for Site-to-Site VPN
Use the Install-RemoteAccess cmdlet to configure RRAS specifically for site-to-site VPN. This sets up the VPN gateway without enabling client (dial-in) VPN access, which is a cleaner configuration for a dedicated site-to-site gateway.
# Run on SITE A SERVER
Install-RemoteAccess -VpnType VpnS2S
# Verify RRAS is running
Get-Service -Name RemoteAccess | Select-Object Name, Status, StartType
# Start RRAS if not already running
Start-Service -Name RemoteAccess
Set-Service -Name RemoteAccess -StartupType Automatic
# Confirm VPN type is set correctly
Get-RemoteAccess | Select-Object VpnS2SStatus, RoutingStatus
# Run on SITE B SERVER (same commands)
Install-RemoteAccess -VpnType VpnS2S
Start-Service -Name RemoteAccess
Set-Service -Name RemoteAccess -StartupType Automatic
Step 3: Create the Site-to-Site VPN Interface on Site A
Each RRAS server needs a “demand-dial” interface that represents the tunnel to the remote site. On Site A, this interface points to Site B’s public IP, and vice versa. The interface definition includes the authentication method, protocol, and subnet routing information.
# On SITE A SERVER
# Define variables for clarity
$SiteAPublicIP = "203.0.113.10" # Site A's public IP
$SiteBPublicIP = "203.0.113.20" # Site B's public IP
$SiteALanSubnet = "10.1.0.0/24" # Site A internal LAN
$SiteBLanSubnet = "10.2.0.0/24" # Site B internal LAN
$SharedSecret = "SiteVPN@Shared!Key2025"
$InterfaceName = "SiteB-VPN"
# Add the S2S VPN interface using IKEv2 with pre-shared key authentication
Add-VpnS2SInterface `
-Name $InterfaceName `
-Destination $SiteBPublicIP `
-Protocol IKEv2 `
-AuthenticationMethod PSKOnly `
-SharedSecret $SharedSecret `
-IPv4Subnet "$SiteBLanSubnet`:10" `
-PassThru
# Verify the interface was created
Get-VpnS2SInterface -Name $InterfaceName |
Select-Object Name, Destination, Protocol, ConnectionState, IPv4Subnet |
Format-List
# The metric (`:10` at the end of IPv4Subnet) is the route metric for this VPN path
# Lower metric = preferred route when multiple paths exist
Step 4: Create the Site-to-Site VPN Interface on Site B
Perform the mirror image configuration on Site B, pointing back to Site A’s public IP and advertising Site A’s LAN subnet through the tunnel.
# On SITE B SERVER
$SiteAPublicIP = "203.0.113.10"
$SiteBPublicIP = "203.0.113.20"
$SiteALanSubnet = "10.1.0.0/24"
$SiteBLanSubnet = "10.2.0.0/24"
$SharedSecret = "SiteVPN@Shared!Key2025"
$InterfaceName = "SiteA-VPN"
Add-VpnS2SInterface `
-Name $InterfaceName `
-Destination $SiteAPublicIP `
-Protocol IKEv2 `
-AuthenticationMethod PSKOnly `
-SharedSecret $SharedSecret `
-IPv4Subnet "$SiteALanSubnet`:10" `
-PassThru
Get-VpnS2SInterface -Name $InterfaceName |
Select-Object Name, Destination, Protocol, ConnectionState, IPv4Subnet |
Format-List
Step 5: Bring Up the VPN Tunnel
Once both sides are configured, establish the tunnel by enabling the interface on one side. IKEv2 will negotiate the security association, and both servers will authenticate using the pre-shared key.
# On SITE A SERVER — initiate the connection
Enable-VpnS2SInterface -Name "SiteB-VPN"
# Check the connection state (may take 15-30 seconds to establish)
Get-VpnS2SInterface -Name "SiteB-VPN" |
Select-Object Name, ConnectionState, LastError, IPv4Subnet | Format-List
# Expected: ConnectionState = Connected
# If the tunnel does not connect, check the last error:
Get-VpnS2SInterface -Name "SiteB-VPN" | Select-Object Name, LastError
# Common errors:
# 13868 - IKE authentication credentials are unacceptable (PSK mismatch)
# 13801 - IKE authentication credentials are unacceptable (certificate issue)
# 809 - Network connection not established (firewall blocking UDP 500/4500)
# On SITE B — verify the tunnel came up from Site B's perspective
Get-VpnS2SInterface -Name "SiteA-VPN" | Select-Object Name, ConnectionState
Step 6: Configure Static Routing
RRAS must know how to route traffic destined for the remote subnet through the VPN tunnel interface. The Add-VpnS2SInterface command with -IPv4Subnet usually adds the route automatically, but verify and add routes manually if needed.
# On SITE A SERVER — verify the route to Site B's LAN via the VPN interface exists
Get-NetRoute | Where-Object { $_.DestinationPrefix -like "10.2.*" } |
Select-Object DestinationPrefix, NextHop, InterfaceAlias, RouteMetric | Format-Table -AutoSize
# If the route is missing, add it manually
# First, get the interface index of the VPN tunnel
$vpnIf = (Get-NetAdapter | Where-Object { $_.InterfaceDescription -like "*WAN Miniport*IKEv2*" }).ifIndex
Add-NetRoute -DestinationPrefix "10.2.0.0/24" `
-InterfaceIndex $vpnIf `
-RouteMetric 10 `
-PolicyStore ActiveStore
# Also add persistent route so it survives reboots
Add-NetRoute -DestinationPrefix "10.2.0.0/24" `
-InterfaceIndex $vpnIf `
-RouteMetric 10 `
-PolicyStore PersistentStore
# On SITE B SERVER — add route back to Site A's LAN
$vpnIfB = (Get-NetAdapter | Where-Object { $_.InterfaceDescription -like "*WAN Miniport*IKEv2*" }).ifIndex
Add-NetRoute -DestinationPrefix "10.1.0.0/24" `
-InterfaceIndex $vpnIfB `
-RouteMetric 10 `
-PolicyStore PersistentStore
# Verify routing on both servers
Get-NetRoute -DestinationPrefix "10.1.0.0/24"
Get-NetRoute -DestinationPrefix "10.2.0.0/24"
Step 7: Test Connectivity Through the Tunnel
With the tunnel up and routes configured, test end-to-end connectivity between the two sites.
# From Site A RRAS server, ping a host on Site B's LAN
ping 10.2.0.1 -n 4
# Using PowerShell Test-NetConnection for richer output
Test-NetConnection -ComputerName 10.2.0.1 -InformationLevel Detailed
# Test a specific port (e.g., RDP on a server at Site B)
Test-NetConnection -ComputerName 10.2.0.10 -Port 3389 -InformationLevel Detailed
# Trace the route to confirm traffic goes through the VPN (not the internet directly)
tracert 10.2.0.1
# From a workstation on Site A's LAN (not the RRAS server),
# test connectivity to Site B (ensure the workstation's default gateway is the RRAS LAN IP)
# The workstation should be able to reach 10.2.0.x addresses transparently
# Test DNS resolution of Site B hostnames (if DNS is configured cross-site)
Resolve-DnsName "server02.corp.contoso.com" -Server 10.2.0.5
Step 8: Inspect IPsec Security Associations
For troubleshooting and security auditing, inspect the active IPsec Main Mode and Quick Mode security associations to confirm the correct encryption and authentication algorithms are in use.
# View IPsec Main Mode Security Associations (IKE phase 1)
netsh ipsec dynamic show mmsa all
# View IPsec Quick Mode Security Associations (IKE phase 2 — the actual data encryption)
netsh ipsec dynamic show qmsa all
# Using PowerShell to inspect IKEv2 SA details
Get-NetIPsecMainModeSA | Select-Object LocalAddress, RemoteAddress, AuthenticationMethod, `
CipherAlgorithm, HashAlgorithm, DhGroup, Lifetime | Format-List
Get-NetIPsecQuickModeSA | Select-Object LocalAddress, RemoteAddress, `
CipherAlgorithm, AuthenticationMethod, PfsGroup, Lifetime | Format-List
# Verify that IKEv2 is using AES-256 and SHA-256 (Windows Server 2025 defaults)
# If you need custom algorithms, configure IPsec policies
New-NetIPsecPhase1AuthSet -DisplayName "SiteVPN-Auth" `
-Proposal (New-NetIPsecAuthProposal -Machine -MachineCert -Authority "CN=Corp-CA")
# For the Quick Mode (data encryption) proposal
New-NetIPsecPhase2AuthSet -DisplayName "SiteVPN-Phase2" `
-Proposal (New-NetIPsecAuthProposal -Machine)
Step 9: Configure RRAS to Reconnect Automatically
# Ensure the VPN interface is set to connect on demand and persist
Set-VpnS2SInterface -Name "SiteB-VPN" `
-InitiateConfigPayload $true `
-PassThru
# Set idle disconnect timeout (0 = never disconnect)
Set-VpnS2SInterface -Name "SiteB-VPN" -IdleDisconnectSeconds 0 -PassThru
# Configure RRAS to re-establish the tunnel automatically after disconnect
# RRAS handles this natively — verify the service is set to automatic restart
$svc = Get-WmiObject Win32_Service -Filter "Name='RemoteAccess'"
sc.exe failure RemoteAccess reset= 86400 actions= restart/5000/restart/10000/restart/30000
# Verify auto-reconnect by monitoring VPN interface state
while ($true) {
$state = (Get-VpnS2SInterface -Name "SiteB-VPN").ConnectionState
Write-Host "$(Get-Date -Format HH:mm:ss) — VPN State: $state" -ForegroundColor $(
if ($state -eq "Connected") { "Green" } else { "Red" }
)
if ($state -ne "Connected") {
Write-Warning "Tunnel down — attempting reconnect"
Enable-VpnS2SInterface -Name "SiteB-VPN"
}
Start-Sleep -Seconds 30
}
Step 10: Using Certificate Authentication Instead of PSK
# For higher security, replace PSK with machine certificates from an Enterprise CA
# Both RRAS servers must have a machine certificate from a mutually trusted CA
# Request a machine certificate on both servers (if using AD CS)
Get-Certificate -Template "Machine" -CertStoreLocation Cert:LocalMachineMy
# Recreate the VPN interface using certificate authentication
Remove-VpnS2SInterface -Name "SiteB-VPN" -Force
Add-VpnS2SInterface `
-Name "SiteB-VPN" `
-Destination "203.0.113.20" `
-Protocol IKEv2 `
-AuthenticationMethod MachineCertificates `
-Certificate (Get-ChildItem Cert:LocalMachineMy | Where-Object { $_.Subject -like "*SiteA*" }) `
-IPv4Subnet "10.2.0.0/24:10" `
-PassThru
Enable-VpnS2SInterface -Name "SiteB-VPN"
Get-VpnS2SInterface -Name "SiteB-VPN" | Select-Object Name, ConnectionState, AuthenticationMethod
A site-to-site VPN using Windows RRAS on Windows Server 2025 provides a cost-effective, fully supported, and highly configurable WAN connectivity solution for organizations that cannot justify dedicated SD-WAN appliances or third-party VPN hardware. IKEv2 offers fast reconnection after network interruptions, strong encryption, and broad compatibility. By combining RRAS with IPsec certificate authentication, static routing, and automatic reconnection, you can build a resilient inter-site VPN that routes traffic transparently between subnets. The IPsec SA inspection commands in Step 8 give you the visibility needed to audit the security of your tunnel, while the monitoring loop in Step 9 ensures that your operations team is notified immediately if the tunnel drops. For multi-site deployments, repeat this procedure for each site pair, or consider deploying Windows Server 2025 in a hub-and-spoke RRAS topology where a central hub server maintains tunnels to all remote spokes.