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 hope the above helps a bit
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
