Hi Sebastian,
On 22/09/22 17:49, Sebastian Arcus wrote:
On 22/09/2022 16:09, Jan Just Keijser wrote:
Hi,
On 22/09/22 16:06, Sebastian Arcus wrote:
I use openvpn on laptops to access the vpn server and the network
behind it. When the laptops are connected directly to the vpn server
home network, to stop traffic going through the vpn, for years I've
used successfully the route metric directive:
push "route-metric 500"
The 500 metric is supposed to be higher than wired connections, so
the wired connection was preferred when connected to the openvpn
server home lan, instead of the vpn connection.
This doesn't seem to work properly with Windows 10 any more.
Although the route metric does get set correctly on Windows 10, it
seems to just ignore it and route all traffic
sounds like Windows 10 is finally getting routing right , or more
likely, that something changed in your LAN routes that you weren't
aware of ;)
normal routing means that a more *specific* route wins over the
*metric* of a route, e.g.
- a route to 192.168.112.0/24 with metric 500 is more specific than
a route to 192.168.0.0/16 with metric 50, so this would get routed
over the tunnel.
It will be interesting to see the routing table after the VPN client
has connected - that will most likely tell us what is happening here.
Thank you for getting back to me. I think the route specificity
shouldn't come into play here - as seen from the routing table below,
there are two entries for 192.168.112.0/24 network - one through the
vpn and one through the wired connection. They are both equally
specific - so the route metric, if Windows 10 behaved as expected,
should determine which one is chosen - unless I'm missing something?
Sorry for the line wrapping pushing the route metric value to the next
line
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.112.1 192.168.112.236 25
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
192.168.112.0 255.255.255.0 On-link 192.168.112.236 281
192.168.112.0 255.255.255.0 192.168.114.5 192.168.114.6 500
192.168.112.236 255.255.255.255 On-link 192.168.112.236 281
192.168.112.255 255.255.255.255 On-link 192.168.112.236 281
192.168.114.1 255.255.255.255 192.168.114.5 192.168.114.6 500
192.168.114.4 255.255.255.252 On-link 192.168.114.6 259
192.168.114.6 255.255.255.255 On-link 192.168.114.6 259
192.168.114.7 255.255.255.255 On-link 192.168.114.6 259
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.112.236 281
224.0.0.0 240.0.0.0 On-link 192.168.114.6 259
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.112.236 281
255.255.255.255 255.255.255.255 On-link 192.168.114.6 259
===========================================================================
the routing table looks OK to me, though I find the route
192.168.112.236 255.255.255.255 On-link 192.168.112.236 281
a little odd - it suggests a /32 route pointing to itself.
Can you confirm that a
tracert -d 192.168.112.1
indeed enters the tunnel first?
JJK
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
