OpenVPN not setting Default Gateway for connection

[marcexeu]

Hi guys, can you please help me with this, no default gateway for my OpenVPN connection:



After connection on Windows
Unknown adapter OpenVPN Data Channel Offload:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::e818:b9c1422f%48
IPv4 Address. . . . . . . . . . . : 10.8.0.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :


OpenVPN Server Config
port 443
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "redirect-gateway def1 bypass-dhcp"
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key
crl-verify crl.pem
ca ca.crt
cert server_H58ShHhi1u1KPFs7.crt
key server_H58ShHhi1u1KPFs7.key
auth SHA512
cipher AES-256-GCM
ncp-ciphers AES-256-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 3


OpenVPN Client OVPN file

client
proto udp
explicit-exit-notify
remote MYADDRESS.ddns.net 443
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_H58ShHhi1u1KPFs7 name
auth SHA512
auth-nocache
cipher AES-256-GCM
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
ignore-unknown-option block-outside-dns
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3



OpenVPN Client log:

Sun Jan 15 20:42:51 2023 OpenVPN 2.6_rc1 [git:v2.6_rc1/84e70c479e81eebe] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Dec 28 2022
Sun Jan 15 20:42:51 2023 Windows version 10.0 (Windows 10 or greater), amd64 executable
Sun Jan 15 20:42:51 2023 library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10
Sun Jan 15 20:42:51 2023 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun Jan 15 20:42:51 2023 Need hold release from management interface, waiting...
Sun Jan 15 20:42:51 2023 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:61916
Sun Jan 15 20:42:51 2023 MANAGEMENT: CMD 'state on'
Sun Jan 15 20:42:51 2023 MANAGEMENT: CMD 'log on all'
Sun Jan 15 20:42:51 2023 MANAGEMENT: CMD 'echo on all'
Sun Jan 15 20:42:51 2023 MANAGEMENT: CMD 'bytecount 5'
Sun Jan 15 20:42:51 2023 MANAGEMENT: CMD 'state'
Sun Jan 15 20:42:51 2023 MANAGEMENT: CMD 'hold off'
Sun Jan 15 20:42:51 2023 MANAGEMENT: CMD 'hold release'
Sun Jan 15 20:42:51 2023 MANAGEMENT: CMD 'password [...]'
Sun Jan 15 20:42:51 2023 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sun Jan 15 20:42:51 2023 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Jan 15 20:42:51 2023 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sun Jan 15 20:42:51 2023 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Jan 15 20:42:51 2023 MANAGEMENT: >STATE:1673811771,RESOLVE,,,,,,
Sun Jan 15 20:42:51 2023 TCP/UDP: Preserving recently used remote address: [AF_INET]80.183.119.164:443
Sun Jan 15 20:42:51 2023 ovpn-dco device [OpenVPN Data Channel Offload] opened
Sun Jan 15 20:42:51 2023 UDP link local: (not bound)
Sun Jan 15 20:42:51 2023 UDP link remote: [AF_INET]80.183.119.164:443
Sun Jan 15 20:42:51 2023 MANAGEMENT: >STATE:1673811771,WAIT,,,,,,
Sun Jan 15 20:42:51 2023 MANAGEMENT: >STATE:1673811771,AUTH,,,,,,
Sun Jan 15 20:42:51 2023 TLS: Initial packet from [AF_INET]80.183.119.164:443, sid=326fa072 97315f82
Sun Jan 15 20:42:51 2023 VERIFY OK: depth=1, CN=cn_Fgo3j0rHv7f7Vzlz
Sun Jan 15 20:42:51 2023 VERIFY KU OK
Sun Jan 15 20:42:51 2023 Validating certificate extended key usage
Sun Jan 15 20:42:51 2023 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun Jan 15 20:42:51 2023 VERIFY EKU OK
Sun Jan 15 20:42:51 2023 VERIFY X509NAME OK: CN=server_H58ShHhi1u1KPFs7
Sun Jan 15 20:42:51 2023 VERIFY OK: depth=0, CN=server_H58ShHhi1u1KPFs7
Sun Jan 15 20:42:51 2023 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 256 bit EC, curve prime256v1, signature: ecdsa-with-SHA256
Sun Jan 15 20:42:51 2023 [server_H58ShHhi1u1KPFs7] Peer Connection Initiated with [AF_INET]80.183.119.164:443
Sun Jan 15 20:42:51 2023 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
Sun Jan 15 20:42:51 2023 TLS: tls_multi_process: initial untrusted session promoted to trusted
Sun Jan 15 20:42:51 2023 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,redirect-gateway def1 bypass-dhcp,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0,peer-id 1,cipher AES-256-GCM'
Sun Jan 15 20:42:51 2023 OPTIONS IMPORT: timers and/or timeouts modified
Sun Jan 15 20:42:51 2023 OPTIONS IMPORT: --ifconfig/up options modified
Sun Jan 15 20:42:51 2023 OPTIONS IMPORT: route options modified
Sun Jan 15 20:42:51 2023 OPTIONS IMPORT: route-related options modified
Sun Jan 15 20:42:51 2023 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Jan 15 20:42:51 2023 OPTIONS IMPORT: peer-id set
Sun Jan 15 20:42:51 2023 OPTIONS IMPORT: data channel crypto options modified
Sun Jan 15 20:42:51 2023 interactive service msg_channel=644
Sun Jan 15 20:42:51 2023 MANAGEMENT: >STATE:1673811771,ASSIGN_IP,,10.8.0.2,,,,
Sun Jan 15 20:42:51 2023 INET address service: add 10.8.0.2/24
Sun Jan 15 20:42:52 2023 IPv4 dns servers set using service
Sun Jan 15 20:42:52 2023 IPv4 MTU set to 1500 on interface 48 using service
Sun Jan 15 20:42:52 2023 Blocking outside dns using service succeeded.
Sun Jan 15 20:42:52 2023 C:\WINDOWS\system32\route.exe ADD 80.183.119.164 MASK 255.255.255.255 192.168.205.49
Sun Jan 15 20:42:52 2023 Route addition via service succeeded
Sun Jan 15 20:42:52 2023 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1
Sun Jan 15 20:42:52 2023 Route addition via service succeeded
Sun Jan 15 20:42:52 2023 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.1
Sun Jan 15 20:42:52 2023 Route addition via service succeeded
Sun Jan 15 20:42:52 2023 Initialization Sequence Completed
Sun Jan 15 20:42:52 2023 MANAGEMENT: >STATE:1673811772,CONNECTED,SUCCESS,10.8.0.2,80.183.119.164,443,,

[openvpn_inc]

Hello marcexeu,

That is normal. Normally your computer should have only one default gateway. That's why it's called the default. Meaning one. And that will be on the network interface that provides you with Internet access. There are very rare cases where you would want a default gateway on the VPN interface but in almost all cases you really do not want that. So what you are seeing is expected.

To redirect Internet traffic through the VPN tunnel you implement routes like you have already;
Sun Jan 15 20:42:52 2023 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1
Sun Jan 15 20:42:52 2023 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.1

Those 2 routes should route all ipv4 Internet traffic through the VPN tunnel just fine. You can verify with traceroute/tracert to see which hop packets will go through first. It should be the internal VPN IP of the OpenVPN server. In this case apparently 10.8.0.1.

Kind regards,
Johan

[RemoteOne]

@openvpn_inc It probably depends on your use case as to whether you want the default gateway to be on the VPN or not. We use openVPN as the client for remote access to our network. We want all traffic to pass through the company gateway except for designated external links pushed by routes from the server (MS Teams/Office for example we configure to bypass the VPN so we do not slow the connections to them)

@marceaxu The issue usually happens when Windows assigns a metric to the new connection that is higher than one of your existing ones - so Windows keeps using the existing one as it's default.

If you open a CMD prompt and run the command

Code: Select all

NETSH INTERFACE IPV4 SHOW INTERFACES

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
 25          55        1500  disconnected  WiFi
 27           5        1500  disconnected  Local Area Connection
  9          65        1500  disconnected  Bluetooth Network Connection
  7          25        1500  disconnected  Local Area Connection 2
 12          25        1500  connected     Ethernet 2
  2           4        1500  disconnected  OpenVPN Data Channel Offload
  8          25        1500  disconnected  Local Area Connection* 1
 24          25        1500  disconnected  Local Area Connection* 3
 28          15        1500  connected     vEthernet (Default Switch)

If you use IPv6 also then also run

NETSH INTERFACE IPV6 SHOW INTERFACES

you can see the Metric (Met column) assigned to each of the adapters in your system. The one with the lowest metric will be the one whose default gateway is used.

You need to make sure "OpenVPN Data Channel Offload" adapter has the lowest number. Mine was assigned 25 by Windows on installation, so the VPN-assigned Default Gateway never took effect. This metric also affects the DNS in the same way. If you use split-DNS you will find that an external resolver is handling your queries instead of the internal (on-VPN) one. You can see that I set my adapter to Metric 4 to make it the lowest Metric number in the system.

Note the lowest current Metric on your system, and pick a number lower than that.

On Windows 11, click Search and type "Manage network adapter" and Enter to bring up the "Advanced Network Settings" page. Scroll down and click on "More network adapter options" to bring up the old Windows 10 style adapter page.

Double-click on the "OpenVPN Data Channel Offload" adapter to bring up it's property page.
Double-click on "Internet Protocol Version 4 (TCP/IPv4)" to bring up the properties page
Click the Advanced... button
In the "IP Settings" on the bottom of the page you can see that "Automatic metric" is selected
Un-check the box, and enter your chosen Metric

If you also use IPv6, repeat the change for "Internet Protocol Version 6 (TCP/IPv6)"

Save and exit

Your VPN-assigned Gateway/DNS should now work as expected.

[marcexeu]

Thank you, but it does not work, i still do not have a default gateway assigned to the connection, so i cannot use internet when connected to my VPN

[RemoteOne]

Have you pushed the default-gateway option from the server, or set it in the client file?

I push the DNS (internal first, then external), WINS, DOMAIN, and Default Gateway options to the client

push "dhcp-option DNS <VPN-DNS-IP1>"
push "dhcp-option DNS <VPN-DNS-IP2>"
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option WINS <VPN-WINS-IP1>"
push "dhcp-option DOMAIN <vpn.domain>"
push "redirect-gateway def1 bypass-dhcp"

[RemoteOne]

The other issue you might have is that the machine that is your server (say 192.168.100.200) will have a lan connection with a default gateway (say 192.168.100.1). All traffic that gets onto that network will go out through that gateway. However, when that gateway gets response packets for your VPN client (10.8.0.nnn) it will not know what to do with it. That gateway will only be aware of the 192.168.100.nnn network. It will not understand that it needs to send VPN traffic back to the VPN server to be routed back to the correct VPN client.

Your lan gateway (192.168.200.1) needs a static route to deliver all traffic for 10.8.0.0/24 through the lan address of the VPN server (192.168.100.200)