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.
HTH,
JJK
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
