The problem manifests when a Windows 10 client successfully establishes an OpenVPN connection to a Windows Server 2012 host, but fails to route any network traffic through the tunnel. While DNS resolution works (confirmed by successful domain name resolution), all subsequent network operations time out, including ping attempts to the VPN gateway (10.8.0.1).

Mon Jan 16 13:45:16 2017 TEST ROUTES: 3/3 succeeded len=2 ret=1 a=0 u/d=up
Mon Jan 16 13:45:16 2017 Route addition via service succeeded
Mon Jan 16 13:45:16 2017 MANAGEMENT: >STATE:1484574316,CONNECTED,SUCCESS,10.8.0.6,xxx.xxx.xxx.xxx,1194,,

The log shows routes being successfully added, yet connectivity fails. This suggests either:
1. A Windows firewall blocking traffic
2. Incorrect network interface metric values
3. Missing NAT/masquerade rules on the server

The server config pushes three crucial directives:

push "route 192.168.0.0 255.255.255.0"
push "redirect-gateway local def1"
push "dhcp-option DNS 8.8.8.8"

Solution 1: Interface Metric Adjustment
Run these commands in PowerShell as Administrator:

Get-NetAdapter | Where-Object {$_.InterfaceDescription -match "TAP-Windows"} | 
Set-NetIPInterface -InterfaceMetric 1

Solution 2: Firewall Rules
Create an inbound rule for OpenVPN:

netsh advfirewall firewall add rule name="OpenVPN" dir=in action=allow program="C:\Program Files\OpenVPN\bin\openvpn.exe" enable=yes

On your Windows Server 2012, confirm IP forwarding is enabled:

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v IPEnableRouter /t REG_DWORD /d 1 /f

Then restart the RemoteAccess service:

net stop RemoteAccess & net start RemoteAccess

Modify your client.ovpn with these additional directives:

route-method exe
route-delay 2
dhcp-option DNS 8.8.8.8
register-dns
block-outside-dns

After connecting, run these diagnostic commands:

route print
netsh interface ipv4 show interfaces
netsh interface ipv4 show subinterfaces

Compare the metrics of your physical adapter versus the TAP adapter. The TAP adapter should have the lowest metric.

Add these scripts to your OpenVPN config directory:

up.bat:

@echo off
for /F "tokens=3" %%A in ('route print ^| find "0.0.0.0" ^| find "10.8.0.5"') do set METRIC=%%A
route change 0.0.0.0 mask 0.0.0.0 10.8.0.5 metric %METRIC% if %1

down.bat:

@echo off
route delete 0.0.0.0 mask 0.0.0.0 10.8.0.5

Then reference them in your client config:

script-security 2
up "up.bat"
down "down.bat"

---

When examining the server configuration and client logs, we can observe several critical points:

# Server config highlights
push "route 192.168.0.0 255.255.255.0"
push "redirect-gateway local def1"
push "dhcp-option DNS 8.8.8.8"

The configuration appears correct at first glance, but Windows networking stack behaves differently than iOS when handling VPN routes.

First, verify the routing table after connection:

route print

You should see entries like:

Network Destination        Netmask          Gateway       Interface
0.0.0.0                  128.0.0.0       10.8.0.5       10.8.0.6
128.0.0.0                128.0.0.0       10.8.0.5       10.8.0.6
192.168.0.0              255.255.255.0   10.8.0.5       10.8.0.6

Add these directives to your client configuration:

# Enhanced client config for Windows
script-security 2
route-method exe
route-delay 2
register-dns
block-outside-dns

Windows Firewall often blocks TAP adapter traffic. Create an inbound rule for the OpenVPN TAP interface:

netsh advfirewall firewall add rule name="OpenVPN TAP" dir=in action=allow interface="Ethernet 4"

For comprehensive testing, use this PowerShell script:

# Test-VPN.ps1
Test-Connection 10.8.0.1 -Count 1
Test-Connection 8.8.8.8 -Count 1
Test-Connection google.com -Count 1
Get-NetRoute -InterfaceAlias "Ethernet 4"
Resolve-DnsName google.com -Server 8.8.8.8

Add this to both server and client configs to address the SWEET32 warning:

cipher AES-256-CBC
auth SHA256
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384

After applying all fixes, your connection log should show:

Initialization Sequence Completed
TEST ROUTES: 3/3 succeeded
DHCP option string: DNS 8.8.8.8
Register-dns admin operation succeeded

Remember to test both local network resources and internet connectivity after each configuration change.