On 22/09/2022 20:56, Jan Just Keijser wrote:
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 )
Hi and thank you again to both of you for the suggestions.
1. Running iperf3 as per instructions above to another machine on the
network, both in client and server mode, produces (nearly) gigabit
speeds - so the traffic is going directly through the lan and bypassing
the tunnel
2. However, trying to upload or download a large file to a Samba share
on the vpn server results in speeds of 300-700kbs - which equate to our
ADSL uplink
3. Also, watching the vpn traffic with iptraf on the server tun0
interface confirms that the smb traffic is all being redirected through
the tunnel
4. Shutting down openvpn on the server restores internal smb traffic
through the lan
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.
5. Regarding Gert's suggestion, 192.168.113.0 is not available - but
even if it were, I'm not sure I'm following the mechanics behind the
suggestion. Why would we be trying to push a route to 192.168.113.0/25
through the tunnel, when the server I am trying to access is on
192.168.112.0? I think I'm missing the point somehow
Back to the bigger picture, I am puzzled as to how OpenVPN on the
Windows 10 client somehow interferes with routing of smb traffic, but
not other types of traffic such as the iperf speed tests. I've had this
issue start to crop up on several sites in the last few months, so I a
keen to get to the bottom of it and try to understand what is going on
if possible.
Thank you again
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
