I've only been following this loosely, and may have missed the clear statement. I apologise for that.
Windows 10 is inherently IPV6, and IPV4 is only bolted on. That has occasional odd effects with routing (and with network timeouts and discovery and other stuff), where the IPV4 follows an IPV6 state instead of the expected result. Have you tried all this with all IPV6 turned off at both ends? On Fri, 30 Sept 2022 at 20:32, Sebastian Arcus <s.ar...@open-t.co.uk> wrote: > > > 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 _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
