On 27/09/2022 20:47, Jan Just Keijser wrote:
Hi,
On 27/09/22 15:29, Sebastian Arcus wrote:
On 26/09/2022 13:53, Jan Just Keijser wrote:
Hi,
On 26/09/22 13:49, Sebastian Arcus wrote:
[...]
Thank you for the extra suggestions. Please find below the output of
the nbtstat commands, with the vpn up and a large slow file transfer
in progress, just to be sure the fault was still present at the
time. As far as I can tell from the output, the server name always
resolves to the correct IP.
I am accessing the share through a mapped drive, which uses the
server name. Also, as per my other email this morning, the output of
netstat during a slow file transfer confirms that the vpn/samba
server is being accessed by its internal IP address - so it doesn't
seem to be a name resolution issue.
# nbtstat -c
OpenVPN Wintun:
Node IpAddress: [192.168.114.10] Scope Id: []
NetBIOS Remote Cache Name Table
Name Type Host Address Life [sec]
------------------------------------------------------------
STAPELY-SERVER <00> UNIQUE 192.168.112.1 484
OpenVPN TAP-Windows6:
Node IpAddress: [0.0.0.0] Scope Id: []
No names in cache
Ethernet:
Node IpAddress: [192.168.112.53] Scope Id: []
NetBIOS Remote Cache Name Table
Name Type Host Address Life [sec]
------------------------------------------------------------
STAPELY-SERVER <20> UNIQUE 192.168.112.1 446
__SAMBA__ <20> UNIQUE 192.168.112.1 446
now this output is quite interesting: with the VPN up, the Netbios
name of the client resolves first to 192.168.114.10 (and later to
122.53); so it could very well be that the Windows 10 smb client
picks that address to connect with - which would explain the VPN route.
The thing is, why does Windows do that and how can we influence it?
I did notice that you are pushing a WINS server to your clients.
Just to test, can you disable NetBios-over-TCPIP for the wintun
adapter? that should be under Network properties.
Hi and thank you for the further suggestions. Please see below updates:
1. Removing 'push "dhcp-option WINS 192.168.112.1"' from the server
config file doesn't seem to make any difference - the problem is still
there
2. Disabling Netbios over DNS on both ethernet and WinTUN adapters on
the client fixes the issues
3. Enabling Netbios over DNS on either ethernet OR WinTUN breaks
things again, and the transfers are very slow
I tried reproducing this today on a Win 10 PC but to no avail: as long
as the LAN-route has a lower metric than the VPN-route then a net
share/smb command always goes over the LAN route.
While reproducing , I did see something odd WRT "on-link" routes versus
routes that have a gateway.
You posted a while back your IPv4 routing table
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
what happens if you add a route *after* the VPN comes up :
route add 192.168.112.0 mask 255.255.255.0 192.168.112.1
then re-test your performance?
I've just tried this and it doesn't appear to make any difference - smb
traffic is still routed through the tunnel
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
