On 23/09/2022 22:16, Sebastian Arcus wrote:
On 23/09/2022 15:00, Jan Just Keijser wrote:
Hi Selva,
On 23/09/22 15: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> .
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.
The bypass route is not relevant here: OpenVPN adds a bypass route
only if redirect-gateway
is in use. Which is not the case here. Also the relevant IP of the
server for bypass depends
on how is remote specified in the config -- remote could be made to
resolve
always to the public IP (via NAT) or to the LAN IP while on LAN.
However, in both cases a bypass
route is not required in this particular setup.
ah good catch, I did not know that about the /32 route to the
broadcast address (but **why** ?!?!?!?)
At any rate , it is a very good idea to post the name and IP address
of the SMB "server" - you could very well be right in that the SMB
server resolves to an IP in the VPN IP range (note that he is using
WINS as well - lord knows what `lmhosts` returns ...)
I an update on progress, but to be honest I can't really make sense of
what it means. Both the server and the client had 'fragment 1300' in the
configs - which I didn't include in my post as I assumed the problem
can't have anything to do with MTU's - since traffic through the vpn
tunnel was working. Through trial and error I discovered that commenting
out 'fragment 1300' on the client, all of a sudden all the smb traffic
starts flowing through the lan. I tested several times, enabled and
disabled 'fragment 1300', and restarted the computer to be sure - and so
far it really seems like it was the culprit. But frankly that doesn't
make any sort of sense to me. I'm going back at the end of next week to
this site to re-run the tests again and again to be sure - because I
can't make sense of why 'fragment 1300' would have been causing smb
traffic to be routed through the tunnel. If anyone has any ideas, they
are very welcome?
Actually, testing things remotely again, I can answer this particular
question myself. Having 'fragment 1300' only on the server effectively
breaks the tunnel - which I didn't realise when I was on site. That is
why it seemed to fix things - as with a disconnected tunnel, it forced
traffic through the lan. I will have to go back there next week and look
again at things using netstat, as per Selva's suggestion
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
