On 23/09/2022 22:16, Selva Nair wrote:
On Fri, Sep 23, 2022 at 5:07 PM Sebastian Arcus <s.ar...@open-t.co.uk
<mailto:s.ar...@open-t.co.uk>> wrote:
On 23/09/2022 14:48, Selva Nair wrote:
> Having said that, I took another look at the routing table on
the Win10
> client and noticed something odd. The only /32 routes I could
find are
> 192.168.112.236 255.255.255.255 On-link
> 192.168.112.236 281
> 192.168.112.255 255.255.255.255 On-link
> 192.168.112.236 281
>
> the .236 address is the client , so I presume that the .255
address is
> the VPN server IP ? If so, then you've got a very peculiar
network
> issue, as you say your network range is 192.168.112.0/24
<http://192.168.112.0/24>
> <http://192.168.112.0/24 <http://192.168.112.0/24>> .
>
>
> Windows always adds an onlink route to broadcast address ---
that's what
> you are
> seeing with the route to 192.168.112.255, not a route to the
"server".
> Nothing peculiar.
>
> One thing not clearly mentioned is whether the SMB "server" is on
the
> VPN "server".
> If so, smb mount may be using a hostname that resolves as the VPN
IP of
> the server.
> Or the VPN IP itself. Then SMB traffic will flow via the VPN.
A very good point to raise indeed. The Samba server is the same machine
as the vpn server. I already thought of that, and I checked on the
Windows 10 client that the host name used to access the share does
indeed resolve to the internal lan ip of the samba/vpn server -
192.168.112.1. Thank you for the suggestion though.
Are you sure? Check netstat to see established connections. SMB may not
be resolving IP the way you think it does. If this was a routing issue
with all traffic to the server going through the tunnel, the tunnel
itself would not work at all because of circular routing. There is no
way for SMB traffic to flow through the VPN tunnel other than the client
using the VPN IP of the server. Check again.
Following on from Selva's suggestions:
1. Check listening ports for Samba on the samba/vpn server (nothing on 139):
# netstat -ltn | grep 445
tcp 0 0 192.168.112.1:445 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN
tcp6 0 0 ::1:445 :::* LISTEN
So it looks like Samba is only listening on the internal lan interface
(192.168.112.1), not the vpn one (192.168.114.1)
2. Check on the server the traffic while there is a large smb file
transfer from the vpn client to the vps/samba server - while the client
is connected to vpn server's lan:
# netstat -tn | grep 445
tcp 0 0 192.168.112.1:445 192.168.112.53:58466 ESTABLISHED
tcp 0 194020 192.168.112.1:445 192.168.114.10:61152 ESTABLISHED
tcp 0 0 192.168.112.1:445 192.168.112.231:55564 ESTABLISHED
The client I am transferring the large file from is both the .112.53 and
.114.10. Somehow there are two parallel connections on the smb protocol,
both through the vpn tunnel and through the lan - but the bulk of the
traffic is going through the tunnel, not through the lan - as the speeds
are down to 200-400kbs on the transfer, and iptraf confirms this.
Also interesting is that the vpn client is clearly using the server's
internal lan ip when connecting to Samba (192.168.112.1) - even when the
connection goes through the tunnel. So name resolution is working as it
should. It really looks like Windows 10 is doing something weird to the
routing of smb traffic.
3. Samba is configured to only listen to the internal lan interface,
confirmed by netstat above, and the configuration in smb.conf below:
bind interfaces only = Yes
interfaces = lo eth2
The only solution I have found to stop all this is by adding a rule on
the firewall to block all traffic originating on the internal lan with
the destination the public IP address of the vpn server - thus stopping
vpn clients from being able to establish a tunnel when connected to the
vpn server's lan.
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
