On 28/09/2022 18:37, Selva Nair wrote:
Hello,
On Wed, Sep 28, 2022 at 1:10 PM Sebastian Arcus <s.ar...@open-t.co.uk
<mailto:s.ar...@open-t.co.uk>> wrote:
On 27/09/2022 21:09, tincantech wrote:
Some updates from today's testing:
Test case 1
Topology: subnet
Adapter: WinTUN
Netbios over TCP/IP: disabled or enabled
Result: 300kbs (for both states of NetBIOS over TCP/IP)
Test case 2
Topology: subnet
Adapter: TAP
Netbios over TCP/IP: disabled or enabled
Result: 900Mbs (for both states of Netbios over TCP/IP)
Essentially using "topology subnet" seems to work fine with the TAP
adapter, but routes all smb traffic through the tunnel with the WinTUN
adapter, even when Netbios over TCP/IP is disabled.
I'm not sure if this actually clarifies things or makes it worse. I
re-run the tests several times, and rebooted the machine after changing
the settings on the adapters and before running the tests
This is getting more and more mysterious. Somehow SMB traffic is using
the VPN IP and hence getting routed through the tunnel. DNS/netbios
would have been the obvious culprit, but that doesn't seem to be the
case... As Windows has no built-in policy routing facilities (does it?),
Windows 10 has the NRPT table - which is policy based routing. I don't
know if it is similar to what is available on other OS's though. I have
already thought about it, as I had some dealings with it in the past. I
checked the settings on the machine and the table is empty.
probably there is some third party port forwarding running on the
client?
Seems unlikely - they are just bog standard office machines, and the
users have no admin access to install software. But I guess anything is
possible. Also the issue is present on both machines which have OpenVPN
installed
However, that should have affected both wintun and tap-windows
tunnels. Can you mount a shared folder using the LAN IP of the server
like \\192.168.112.xx and see whether that makes a difference?
I can certainly try that, but I wonder if it would yield any useful
information, since netstat shows during the file transfer that the
client is definitely accessing Samba on the server at 192.168.112.1 and
Samba on the server is configured to listen only to the loopback
interface and 192.168.112.1, so any attempt to talk to it at
192.168.114.1 (the vpn interface) would be rejected
But if you think the above would still be useful, I can certainly try it
tcpdump could also help figure out why there are two smb streams one
using LAN IP and other using the VPN, which is carrying what traffic,
which one gets established first etc..
I could do that. I'm not overly familiar with tcpdump. Would a command
like below capture what is needed on the server side (assuming the vpn
client is on 192.168.14.53 and 192.168.112.10)?
tcpdump -n -w dump.file host 192.168.114.53 or 192.168.112.10 and tcp
port 445
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
