On 22/09/22 20:00, Sebastian Arcus wrote:
[...]
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.
I just checked another Windows 10 machine, and it has the same type of
route - I am guessing it is some sort of weird Windows 10 thing?
Probably, I'd need to check a Windows 10 box myself which I don't have
access to at the moment...
Can you confirm that a
tracert -d 192.168.112.1
indeed enters the tunnel first?
Things are potentially getting more interesting. tracert claims a
single hop - which would suggest that the traffic is going straight to
the internet server, and not entering the vpn tunnel. However, copying
a file from a smb file share on the server shows speeds of 700 kbits -
corresponding with the uplink of our ADSL internet connection.
Shutting down openvpn on the server automatically pushes the file
transfer speed to 1000mbs (well, almost) - which is the speed of our
internal network. Somehow the smb protocol is using different routing
rules then the tracert command?
next thing to try is to install "iperf" on both a VPN client and
*another* machine on the LAN (not the VPN server!) and then do a simple
iperf test: this will show which IP the client is connecting from.
So install iperf, then the "another" machine, do
iperf -s
and on the VPN client do
iperf -c 192.168.112.XX
(the VPN server itself is a special case here, as all VPN clients
will/should set up a bypass route to it )
Plus, like Gert said, if 192.168.113.0 is free, then modifying your VPN
set up to do
push "route 192.168.113.0 255.255.254.0"
should definitely ensure that the LAN route takes precedence over the
VPN route, regardless of the metric.
HTH,
JJK
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
