Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

Hi,

On 02/10/2022 11:14, David W Graham wrote:

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?


Thank you for the suggestion. I've had weird routing and dns issues in 
the past on Windows because of IPv6 - so now I disable it everywhere. So 
the answer is yes, on the client side ipv6 is disabled both on the 
ethernet interface and openvpn. On the server it isn't disabled. If I 
remember correctly it would need a server reboot to do this, so I have 
to catch a window of opportunity when I can restart the server and then 
test things again and post here





On Fri, 30 Sept 2022 at 20:32, Sebastian Arcus  wrote:



On 28/09/2022 18:37, Selva Nair wrote:

Hello,

On Wed, Sep 28, 2022 at 1:10 PM Sebastian Arcus 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



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[David W Graham]

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  wrote:
>
>
> On 28/09/2022 18:37, Selva Nair wrote:
> > Hello,
> >
> > On Wed, Sep 28, 2022 at 1:10 PM Sebastian Arcus  > > 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

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

On 28/09/2022 18:37, Selva Nair wrote:

Hello,

On Wed, Sep 28, 2022 at 1:10 PM Sebastian Arcus > 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

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Jan Just Keijser]

On 29/09/22 01:19, André via Openvpn-users wrote:

Hi,

Could it have something to do with SMB Multichannel...?


interesting suggestion and definitelty worth exploring.

We are missing info however (which Selva's questions should partially 
answer.
One of the things I am still unclear about is what route the VPN traffic 
takes when the client is on the LAN as the server - where are the 
(sanitized) routes to the VPN/adsl gateway ?


What happens if the client configuration uses
  server 192.168.112.1
instead of a DNS name?

JJK




--- Original Message ---
On Wednesday, September 28th, 2022 at 19:37, Selva Nair 
 wrote:



Hello,

On Wed, Sep 28, 2022 at 1:10 PM Sebastian Arcus > 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?), probably there is some third party port 
forwarding running on the client? 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?


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..


Selva






___
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

Re: [Openvpn-users] Correct way to handle routing when on home network?

[André via Openvpn-users]

Hi,

Could it have something to do with SMB Multichannel...?

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Wednesday, September 28th, 2022 at 19:37, Selva Nair  
wrote:

> Hello,
>
> On Wed, Sep 28, 2022 at 1:10 PM Sebastian Arcus  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?), probably there is some 
> third party port forwarding running on the client? 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?
>
> 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..
>
> Selva___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Selva Nair]

Hello,

On Wed, Sep 28, 2022 at 1:10 PM Sebastian Arcus 
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?), probably
there is some third party port forwarding running on the client? 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?

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..

Selva
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

On 27/09/2022 20:47, Jan Just Keijser wrote:

Hi,

On 27/09/22 15:29, Sebastian Arcus wrote:


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 tried reproducing this today on a Win 10 PC but to no avail:  as long 
as the LAN-route has a lower metric than the VPN-route then a net 
share/smb command always goes over the LAN route.


While reproducing , I did see something odd WRT "on-link" routes versus 
routes that have a gateway.

You posted a while back your IPv4 routing table


IPv4 Route Table
===
Active Routes:
Network Destination    Netmask  Gateway Interface Metric
   0.0.0.0  0.0.0.0    192.168.112.1 192.168.112.236   25
     127.0.0.0    255.0.0.0 On-link 127.0.0.1    331
     127.0.0.1  255.255.255.255 On-link 127.0.0.1    331
   127.255.255.255  255.255.255.255 On-link 127.0.0.1    331
     192.168.112.0    255.255.255.0 On-link 192.168.112.236    281
     192.168.112.0    255.255.255.0    192.168.114.5 192.168.114.6 500



what happens if you add a route *after* the VPN comes up :

   route add 192.168.112.0 mask 255.255.255.0 192.168.112.1

then re-test your performance?


I've just tried this and it doesn't appear to make any difference - smb 
traffic is still routed through the tunnel




___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

On 27/09/2022 21:09, tincantech wrote:

Hi,




Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, September 22nd, 2022 at 19:25, tincantech 
 wrote:




--- Original Message ---
On Thursday, September 22nd, 2022 at 15:06, Sebastian Arcus 
s.ar...@open-t.co.uk wrote:





Server: openvpn 2.5.7, Linux Slackware
Client: openvpn 2.5.7, Windows 10
OpenVPN server lan subnet: 192.168.112.0/24
OpenVPN subnet: 192.168.114.0/24

server.conf

proto udp
port 1194
dev tun
server 192.168.114.0 255.255.255.0
push "route 192.168.112.0 255.255.255.0"
push "dhcp-option DNS 192.168.112.1"
push "dhcp-option WINS 192.168.112.1"
push "route-metric 500"
ca "ca.crt"
cert "server.crt"
key "server.key"
tls-auth "ta.key" 0
dh "dh.pem"



It is also worth mentioning that --topology net30 is deprecated.

https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Changedefault--topologynet30tosubnet

That may help routing.


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



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

On 27/09/2022 21:09, tincantech wrote:

Hi,




Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, September 22nd, 2022 at 19:25, tincantech 
 wrote:




--- Original Message ---
On Thursday, September 22nd, 2022 at 15:06, Sebastian Arcus 
s.ar...@open-t.co.uk wrote:





Server: openvpn 2.5.7, Linux Slackware
Client: openvpn 2.5.7, Windows 10
OpenVPN server lan subnet: 192.168.112.0/24
OpenVPN subnet: 192.168.114.0/24

server.conf

proto udp
port 1194
dev tun
server 192.168.114.0 255.255.255.0
push "route 192.168.112.0 255.255.255.0"
push "dhcp-option DNS 192.168.112.1"
push "dhcp-option WINS 192.168.112.1"
push "route-metric 500"
ca "ca.crt"
cert "server.crt"
key "server.key"
tls-auth "ta.key" 0
dh "dh.pem"



It is also worth mentioning that --topology net30 is deprecated.

https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Changedefault--topologynet30tosubnet

That may help routing.


I've seen in the past the mention of change to --topology subnet, but 
until now I didn't quite get what the change means. I've just re-read 
again the docs and I thing I understand now. I will try the change in 
the next few days and see if it makes a difference with this issue. It 
looks like a good idea to move all my OpenVPN setups to the new topology 
anyway. Thank you for the suggestion.



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

On 27/09/2022 20:47, Jan Just Keijser wrote:

Hi,

On 27/09/22 15:29, Sebastian Arcus wrote:


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 tried reproducing this today on a Win 10 PC but to no avail:  as long 
as the LAN-route has a lower metric than the VPN-route then a net 
share/smb command always goes over the LAN route.


One other thing to keep in mind is that 2 weeks ago this server was 
upgraded from OpenVPN 2.4.4 to the current 2.5.7. As soon as the upgrade 
happened, uses started to complain bitterly that access to shared files 
on the server was extremely slow - and that's when I started to 
investigate. I can't be absolutely sure of the situation before the 
upgrade, but it appears that this issue only cropped up after the 
upgrade to OpenVPN 2.5.7 on the server




While reproducing , I did see something odd WRT "on-link" routes versus 
routes that have a gateway.

You posted a while back your IPv4 routing table


IPv4 Route Table
===
Active Routes:
Network Destination    Netmask  Gateway Interface Metric
   0.0.0.0  0.0.0.0    192.168.112.1 192.168.112.236   25
     127.0.0.0    255.0.0.0 On-link 127.0.0.1    331
     127.0.0.1  255.255.255.255 On-link 127.0.0.1    331
   127.255.255.255  255.255.255.255 On-link 127.0.0.1    331
     192.168.112.0    255.255.255.0 On-link 192.168.112.236    281
     192.168.112.0    255.255.255.0    192.168.114.5 192.168.114.6 500



what happens if you add a route *after* the VPN comes up :

   route add 192.168.112.0 mask 255.255.255.0 192.168.112.1

then re-test your performance?


I will try that in the next few days and post here


It looks like the Windows client decides to use the wintun adapter 
*first* to talk to the server, and hence it initiates a .114 connection 
and your performance is crap - but *WHY* ?


also, does the same problem occur if you disable the
   windows-driver wintun
line and revert back to tap-win ?


I've tried both WinTUN and TAP -and the results are the same - routing 
of smb traffic goes through the tunnel



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[tincantech via Openvpn-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,




Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, September 22nd, 2022 at 19:25, tincantech 
 wrote:



> --- Original Message ---
> On Thursday, September 22nd, 2022 at 15:06, Sebastian Arcus 
> s.ar...@open-t.co.uk wrote:



> > Server: openvpn 2.5.7, Linux Slackware
> > Client: openvpn 2.5.7, Windows 10
> > OpenVPN server lan subnet: 192.168.112.0/24
> > OpenVPN subnet: 192.168.114.0/24
> > 
> > server.conf
> > 
> > proto udp
> > port 1194
> > dev tun
> > server 192.168.114.0 255.255.255.0
> > push "route 192.168.112.0 255.255.255.0"
> > push "dhcp-option DNS 192.168.112.1"
> > push "dhcp-option WINS 192.168.112.1"
> > push "route-metric 500"
> > ca "ca.crt"
> > cert "server.crt"
> > key "server.key"
> > tls-auth "ta.key" 0
> > dh "dh.pem"
> > 

It is also worth mentioning that --topology net30 is deprecated.

https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Changedefault--topologynet30tosubnet

That may help routing.


-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJjM1hqACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ1u2wf/SS5+Hq+IpOnaVdC4RhmHSyA0BThafEwiPNl5Fu8Bq1SuMBGb
2UWwfDVmc8PcIpkRmpHykFfBNdEQT3WeZeo+Cqxy1PbbbPEKO33QUO26jZTb
ZwTlmTBPvxzolhj+74gHqhk8DCAX4Z2g0aBBG/ttyrIjzgdLHMI6DpgptR20
4Udq2rRMUDxfJvHvsT3SlVtQxxeWrrJP0dvCkVY29qkL9Lqqbt6iyRmTMsac
yNSOonWUSDQ0JtNaYYBw9WVADYr9RE0IkVPutWrYt9e2ksqpSGYBVD1CQJq7
XmiQf4iYIMdeMjrLH0dybm5SUgdz6cSgt+Pe3wlOHE3ew20v3CDkMg==
=GmJ2
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Jan Just Keijser]

Hi,

On 27/09/22 15:29, Sebastian Arcus wrote:


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 tried reproducing this today on a Win 10 PC but to no avail:  as long 
as the LAN-route has a lower metric than the VPN-route then a net 
share/smb command always goes over the LAN route.


While reproducing , I did see something odd WRT "on-link" routes versus 
routes that have a gateway.

You posted a while back your IPv4 routing table


IPv4 Route Table
===
Active Routes:
Network Destination    Netmask  Gateway Interface Metric
  0.0.0.0  0.0.0.0    192.168.112.1 192.168.112.236   25
    127.0.0.0    255.0.0.0 On-link 127.0.0.1    331
    127.0.0.1  255.255.255.255 On-link 127.0.0.1    331
  127.255.255.255  255.255.255.255 On-link 127.0.0.1    331
    192.168.112.0    255.255.255.0 On-link 192.168.112.236    281
    192.168.112.0    255.255.255.0    192.168.114.5 192.168.114.6 500



what happens if you add a route *after* the VPN comes up :

  route add 192.168.112.0 mask 255.255.255.0 192.168.112.1

then re-test your performance?

It looks like the Windows client decides to use the wintun adapter 
*first* to talk to the server, and hence it initiates a .114 connection 
and your performance is crap - but *WHY* ?


also, does the same problem occur if you disable the
  windows-driver wintun
line and revert back to tap-win ?

HTH,

JJK



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

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

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Jan Just Keijser]

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.



HTH,

JJK



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

On 26/09/2022 07:53, Jan Just Keijser wrote:

On 23/09/22 23:22, Sebastian Arcus wrote:

On 23/09/2022 22:16, Sebastian Arcus wrote:

[...]
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




ah, that makes sense, that removing it on one side breaks the tunnel. 
Things to try next:


- increase verbosity on the samba server and check the logs when the 
client connects; not sure if the IP address will be logged, but it might 
give you a hint


- on the windows client, how are accessing the drive ?  using IP? using 
DNS name? using Netbios name?


- also, things you can test on the Windows 10 client in a 
Command/Console window:


   nbtstat -c
   nbtstat -n
   nbtstat -A 192.168.112.1   ## the samba server IP
   nbtstat -a  Sambaserver    ## the samba server Name

both with the VPN up and down - if the Sambaserver names resolves to a 
.114 address when the VPN is up, then you've found your problem.


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 AddressLife [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 AddressLife [sec]

STAPELY-SERVER <20>  UNIQUE  192.168.112.1   446
__SAMBA__  <20>  UNIQUE  192.168.112.1   446


# nbtstat -n

OpenVPN Wintun:
Node IpAddress: [192.168.114.10] Scope Id: []

NetBIOS Local Name Table

   Name   Type Status
-
WKS-03-STAPELY <00>  UNIQUE  Registered
STAPELYCARE<00>  GROUP   Registered
WKS-03-STAPELY <20>  UNIQUE  Registered

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 Local Name Table

   Name   Type Status
-
WKS-03-STAPELY <00>  UNIQUE  Registered
STAPELYCARE<00>  GROUP   Registered
WKS-03-STAPELY <20>  UNIQUE  Registered


# nbtstat -A 192.168.112.1

OpenVPN Wintun:
Node IpAddress: [192.168.114.10] Scope Id: []

   NetBIOS Remote Machine Name Table

   Name   Type Status
-
STAPELY-SERVER <00>  UNIQUE  Registered
STAPELY-SERVER <03>  UNIQUE  Registered
STAPELY-SERVER <20>  UNIQUE  Registered
STAPELYCARE<1B>  UNIQUE  Registered
STAPELYCARE<1C>  GROUP   Registered
STAPELYCARE<00>  GROUP   Registered
__SAMBA__  <00>  GROUP   Registered
__SAMBA__  

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

On 23/09/2022 22:16, Selva Nair wrote:



On Fri, Sep 23, 2022 at 5:07 PM Sebastian Arcus > 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

 >     > .
 >
 >
 > 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   00  192.168.112.1:445   0.0.0.0:* LISTEN
tcp   00  127.0.0.1:445   0.0.0.0:* LISTEN
tcp6  00  ::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:58466ESTABLISHED
tcp   0 194020 192.168.112.1:445  192.168.114.10:61152ESTABLISHED
tcp   0  0192.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

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Jan Just Keijser]

On 23/09/22 23:22, Sebastian Arcus wrote:

On 23/09/2022 22:16, Sebastian Arcus wrote:

[...]
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




ah, that makes sense, that removing it on one side breaks the tunnel. 
Things to try next:


- increase verbosity on the samba server and check the logs when the 
client connects; not sure if the IP address will be logged, but it might 
give you a hint


- on the windows client, how are accessing the drive ?  using IP? using 
DNS name? using Netbios name?


- also, things you can test on the Windows 10 client in a 
Command/Console window:


  nbtstat -c
  nbtstat -n
  nbtstat -A 192.168.112.1   ## the samba server IP
  nbtstat -a  Sambaserver    ## the samba server Name

both with the VPN up and down - if the Sambaserver names resolves to a 
.114 address when the VPN is up, then you've found your problem.


HTH,

JJK



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

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
     .

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

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Selva Nair]

On Fri, Sep 23, 2022 at 5:07 PM Sebastian Arcus 
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.236281
> > 192.168.112.255  255.255.255.255 On-link
> > 192.168.112.236281
> >
> > 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
> >  .
> >
> >
> > 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.

Selva
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

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
 . 



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?



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

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
 . 



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.





___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

On 23/09/2022 12:07, Jan Just Keijser wrote:

Hi Sebastian,

On 23/09/22 12:01, Sebastian Arcus wrote:


[...]



Hi and thank you again to both of you for the suggestions.

1. Running iperf3 as per instructions above to another machine on the 
network, both in client and server mode, produces (nearly) gigabit 
speeds - so the traffic is going directly through the lan and 
bypassing the tunnel


2. However, trying to upload or download a large file to a Samba share 
on the vpn server results in speeds of 300-700kbs - which equate to 
our ADSL uplink


3. Also, watching the vpn traffic with iptraf on the server tun0 
interface confirms that the smb traffic is all being redirected 
through the tunnel


4. Shutting down openvpn on the server restores internal smb traffic 
through the lan



[...]


Back to the bigger picture, I am puzzled as to how OpenVPN on the 
Windows 10 client somehow interferes with routing of smb traffic, but 
not other types of traffic such as the iperf speed tests. I've had 
this issue start to crop up on several sites in the last few months, 
so I a keen to get to the bottom of it and try to understand what is 
going on if possible.




you have to keep in mind that traffic to and from the VPN server itself 
is treated differently than traffic to all other hosts in the 
server-side LAN.  Traffic to the VPN server itself should never flow 
through the tunnel, as otherwise the encrypted OpenVPN traffic itself 
would also be routed through the tunnel, resulting in the infamous 
"biting your own tail" problem.
Normally, the OpenVPN client will add a /32 route directly to the 
OpenVPN server that bypasses the tunnel.


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 . The 
*broadcast* address for this network  by definition is 192.168.112.255, 
which would mean that your VPN server is occupying the same address as 
the broadcast address - if true, then I am not surprised that this is 
causing issues. Actually, I am surprised that things are working at all!


Please post the LAN IP address of the VPN server.


The lan IP of the openvpn server is 192.168.112.1. Wouldn't the .255 be 
just a route for the broadcast address?





___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Jan Just Keijser]

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
 . 



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 ...)


cheers,

JJK

___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Selva Nair]

>
> 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.236281
>192.168.112.255  255.255.255.255 On-link 192.168.112.236281
>
> 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 .


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.

Selva
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Gert Doering]

Hi,

On Fri, Sep 23, 2022 at 11:01:49AM +0100, Sebastian Arcus wrote:
> > Plus, like Gert said, if 192.168.113.0 is free, then modifying your VPN 
> > set up to do
> >    push "route 192.168.113.0 255.255.254.0"
> > should definitely ensure that the LAN route takes precedence over the 
> > VPN route, regardless of the metric.
> 
> 5. Regarding Gert's suggestion, 192.168.113.0 is not available - but 
> even if it were, I'm not sure I'm following the mechanics behind the 
> suggestion. Why would we be trying to push a route to 192.168.113.0/25 
> through the tunnel, when the server I am trying to access is on 
> 192.168.112.0? I think I'm missing the point somehow

/23, not /25 - so a supernet, including .112 and .113

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Jan Just Keijser]

Hi Sebastian,

On 23/09/22 12:01, Sebastian Arcus wrote:


[...]



Hi and thank you again to both of you for the suggestions.

1. Running iperf3 as per instructions above to another machine on the 
network, both in client and server mode, produces (nearly) gigabit 
speeds - so the traffic is going directly through the lan and 
bypassing the tunnel


2. However, trying to upload or download a large file to a Samba share 
on the vpn server results in speeds of 300-700kbs - which equate to 
our ADSL uplink


3. Also, watching the vpn traffic with iptraf on the server tun0 
interface confirms that the smb traffic is all being redirected 
through the tunnel


4. Shutting down openvpn on the server restores internal smb traffic 
through the lan



[...]


Back to the bigger picture, I am puzzled as to how OpenVPN on the 
Windows 10 client somehow interferes with routing of smb traffic, but 
not other types of traffic such as the iperf speed tests. I've had 
this issue start to crop up on several sites in the last few months, 
so I a keen to get to the bottom of it and try to understand what is 
going on if possible.




you have to keep in mind that traffic to and from the VPN server itself 
is treated differently than traffic to all other hosts in the 
server-side LAN.  Traffic to the VPN server itself should never flow 
through the tunnel, as otherwise the encrypted OpenVPN traffic itself 
would also be routed through the tunnel, resulting in the infamous 
"biting your own tail" problem.
Normally, the OpenVPN client will add a /32 route directly to the 
OpenVPN server that bypasses the tunnel.


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 . The 
*broadcast* address for this network  by definition is 192.168.112.255, 
which would mean that your VPN server is occupying the same address as 
the broadcast address - if true, then I am not surprised that this is 
causing issues. Actually, I am surprised that things are working at all!


Please post the LAN IP address of the VPN server.

cheers,

JJK




___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

On 22/09/2022 20:56, Jan Just Keijser wrote:

On 22/09/22 20:00, Sebastian Arcus wrote:

[...]



the routing table looks OK to me, though I find the route
     192.168.112.236  255.255.255.255 On-link 
192.168.112.236    281

a little odd - it suggests a /32 route pointing to itself.


I just checked another Windows 10 machine, and it has the same type of 
route - I am guessing it is some sort of weird Windows 10 thing?


Probably, I'd need to check a Windows 10 box myself which I don't have 
access to at the moment...




Can you confirm that a
   tracert -d 192.168.112.1
indeed enters the tunnel first?


Things are potentially getting more interesting. tracert claims a 
single hop - which would suggest that the traffic is going straight to 
the internet server, and not entering the vpn tunnel. However, copying 
a file from a smb file share on the server shows speeds of 700 kbits - 
corresponding with the uplink of our ADSL internet connection. 
Shutting down openvpn on the server automatically pushes the file 
transfer speed to 1000mbs (well, almost) - which is the speed of our 
internal network. Somehow the smb protocol is using different routing 
rules then the tracert command?


next thing to try is to install "iperf" on both a VPN client and 
*another* machine on the LAN (not the VPN server!) and then do a simple 
iperf test: this will show which IP the client is connecting from.


So install iperf, then the "another" machine, do
   iperf -s

and on the VPN client do
   iperf -c 192.168.112.XX

(the VPN server itself is a special case here, as all VPN clients 
will/should set up a bypass route to it )


Hi and thank you again to both of you for the suggestions.

1. Running iperf3 as per instructions above to another machine on the 
network, both in client and server mode, produces (nearly) gigabit 
speeds - so the traffic is going directly through the lan and bypassing 
the tunnel


2. However, trying to upload or download a large file to a Samba share 
on the vpn server results in speeds of 300-700kbs - which equate to our 
ADSL uplink


3. Also, watching the vpn traffic with iptraf on the server tun0 
interface confirms that the smb traffic is all being redirected through 
the tunnel


4. Shutting down openvpn on the server restores internal smb traffic 
through the lan





Plus, like Gert said, if 192.168.113.0 is free, then modifying your VPN 
set up to do

   push "route 192.168.113.0 255.255.254.0"
should definitely ensure that the LAN route takes precedence over the 
VPN route, regardless of the metric.


5. Regarding Gert's suggestion, 192.168.113.0 is not available - but 
even if it were, I'm not sure I'm following the mechanics behind the 
suggestion. Why would we be trying to push a route to 192.168.113.0/25 
through the tunnel, when the server I am trying to access is on 
192.168.112.0? I think I'm missing the point somehow


Back to the bigger picture, I am puzzled as to how OpenVPN on the 
Windows 10 client somehow interferes with routing of smb traffic, but 
not other types of traffic such as the iperf speed tests. I've had this 
issue start to crop up on several sites in the last few months, so I a 
keen to get to the bottom of it and try to understand what is going on 
if possible.


Thank you again


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Jan Just Keijser]

On 22/09/22 20:00, Sebastian Arcus wrote:

[...]



the routing table looks OK to me, though I find the route
     192.168.112.236  255.255.255.255 On-link 
192.168.112.236    281

a little odd - it suggests a /32 route pointing to itself.


I just checked another Windows 10 machine, and it has the same type of 
route - I am guessing it is some sort of weird Windows 10 thing?


Probably, I'd need to check a Windows 10 box myself which I don't have 
access to at the moment...




Can you confirm that a
   tracert -d 192.168.112.1
indeed enters the tunnel first?


Things are potentially getting more interesting. tracert claims a 
single hop - which would suggest that the traffic is going straight to 
the internet server, and not entering the vpn tunnel. However, copying 
a file from a smb file share on the server shows speeds of 700 kbits - 
corresponding with the uplink of our ADSL internet connection. 
Shutting down openvpn on the server automatically pushes the file 
transfer speed to 1000mbs (well, almost) - which is the speed of our 
internal network. Somehow the smb protocol is using different routing 
rules then the tracert command?


next thing to try is to install "iperf" on both a VPN client and 
*another* machine on the LAN (not the VPN server!) and then do a simple 
iperf test: this will show which IP the client is connecting from.


So install iperf, then the "another" machine, do
  iperf -s

and on the VPN client do
  iperf -c 192.168.112.XX

(the VPN server itself is a special case here, as all VPN clients 
will/should set up a bypass route to it )



Plus, like Gert said, if 192.168.113.0 is free, then modifying your VPN 
set up to do

  push "route 192.168.113.0 255.255.254.0"
should definitely ensure that the LAN route takes precedence over the 
VPN route, regardless of the metric.


HTH,

JJK



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

On 22/09/2022 19:25, tincantech wrote:

Hi,

Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, September 22nd, 2022 at 15:06, Sebastian Arcus 
 wrote:



I use openvpn on laptops to access the vpn server and the network behind
it. When the laptops are connected directly to the vpn server home
network, to stop traffic going through the vpn, for years I've used
successfully the route metric directive:



push "route-metric 500"



The 500 metric is supposed to be higher than wired connections, so the
wired connection was preferred when connected to the openvpn server home
lan, instead of the vpn connection.



This doesn't seem to work properly with Windows 10 any more. Although
the route metric does get set correctly on Windows 10, it seems to just
ignore it and route all traffic



"route all traffic" is obviously used out of context here, see below:


Does anyone know if Windows 10 now behaves differently with regards to
route metric? Is there a new recommended way to deal with this issue?
More details below of my setup:



Server: openvpn 2.5.7, Linux Slackware
Client: openvpn 2.5.7, Windows 10
OpenVPN server lan subnet: 192.168.112.0/24
OpenVPN subnet: 192.168.114.0/24




server.conf



proto udp
port 1194
dev tun
server 192.168.114.0 255.255.255.0
push "route 192.168.112.0 255.255.255.0"
push "dhcp-option DNS 192.168.112.1"
push "dhcp-option WINS 192.168.112.1"
push "route-metric 500"
ca "ca.crt"
cert "server.crt"
key "server.key"
tls-auth "ta.key" 0
dh "dh.pem"





client.conf



client
windows-driver wintun
proto udp
remote vpn.remote.address
port 1194
resolv-retry infinite
ping-restart 10
persist-key
persist-tun
key-direction 1
remote-cert-tls server
ca "ca.crt"
cert "client.crt"
key "client.key"
tls-auth "ta.key" 1
remote-cert-tls server





No where is "route all traffic" set by either side.

For clarity.


Yes, you are right, sorry. I should have said that the traffic aimed at 
the openvpn lan ip address ends up being routed through the vpn tunnel, 
instead of directly through the lan. Thank you for pointing it out.



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[tincantech via Openvpn-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, September 22nd, 2022 at 15:06, Sebastian Arcus 
 wrote:


> I use openvpn on laptops to access the vpn server and the network behind
> it. When the laptops are connected directly to the vpn server home
> network, to stop traffic going through the vpn, for years I've used
> successfully the route metric directive:
> 
> push "route-metric 500"
> 
> The 500 metric is supposed to be higher than wired connections, so the
> wired connection was preferred when connected to the openvpn server home
> lan, instead of the vpn connection.
> 
> This doesn't seem to work properly with Windows 10 any more. Although
> the route metric does get set correctly on Windows 10, it seems to just
> ignore it and route all traffic
> 

"route all traffic" is obviously used out of context here, see below:

> Does anyone know if Windows 10 now behaves differently with regards to
> route metric? Is there a new recommended way to deal with this issue?
> More details below of my setup:
> 
> Server: openvpn 2.5.7, Linux Slackware
> Client: openvpn 2.5.7, Windows 10
> OpenVPN server lan subnet: 192.168.112.0/24
> OpenVPN subnet: 192.168.114.0/24
> 
> 
> server.conf
> 
> proto udp
> port 1194
> dev tun
> server 192.168.114.0 255.255.255.0
> push "route 192.168.112.0 255.255.255.0"
> push "dhcp-option DNS 192.168.112.1"
> push "dhcp-option WINS 192.168.112.1"
> push "route-metric 500"
> ca "ca.crt"
> cert "server.crt"
> key "server.key"
> tls-auth "ta.key" 0
> dh "dh.pem"
> 
> 
> 
> client.conf
> 
> client
> windows-driver wintun
> proto udp
> remote vpn.remote.address
> port 1194
> resolv-retry infinite
> ping-restart 10
> persist-key
> persist-tun
> key-direction 1
> remote-cert-tls server
> ca "ca.crt"
> cert "client.crt"
> key "client.key"
> tls-auth "ta.key" 1
> remote-cert-tls server
> 
> 
> 

No where is "route all traffic" set by either side.

For clarity.

> 
> 
> ___
> Openvpn-users mailing list
> Openvpn-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJjLKiCACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ0L7ggAqSZPe0r+Px/Rngvixgx2L82qqb4csJzGhH2Je/xZvkQODIwJ
vVDytYSJrozR/FkLtuAB4wkWzZumhkm0vvjbJ+RqZHsQAV/AZ1BcTh0qiJEX
cHc6I6ajaB8k8rsmhSKM1fbHzpX1urOSDIW5lQ1a9ePJv3oxMqmjV2sU8C/F
Ywa0i2kyIw4//2W7cJSvwjlyhuPzQ1cfxND78czbejegx7cjRe4LaQA6Dq+k
rb065mvt8Mjzj9+16APGuEebwjvDT2W9dvVa5QEg5P8vdzFv8tH6GXJo6ZhK
bEJwZ+TWLuGYVXn0W5d9nb8Z0W3nwsVt3kLsgxv33fV7sLag5urFhA==
=lkIC
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Sebastian Arcus]

On 22/09/2022 17:12, Jan Just Keijser wrote:

Hi Sebastian,

On 22/09/22 17:49, Sebastian Arcus wrote:

On 22/09/2022 16:09, Jan Just Keijser wrote:

Hi,

On 22/09/22 16:06, Sebastian Arcus wrote:
I use openvpn on laptops to access the vpn server and the network 
behind it. When the laptops are connected directly to the vpn server 
home network, to stop traffic going through the vpn, for years I've 
used successfully the route metric directive:


push "route-metric 500"

The 500 metric is supposed to be higher than wired connections, so 
the wired connection was preferred when connected to the openvpn 
server home lan, instead of the vpn connection.


This doesn't seem to work properly with Windows 10 any more. 
Although the route metric does get set correctly on Windows 10, it 
seems to just ignore it and route all traffic


sounds like Windows 10 is finally getting routing right , or more 
likely, that something changed in your LAN routes that you weren't 
aware of ;)
normal routing means that a more *specific* route wins over the 
*metric* of a route, e.g.


- a route to 192.168.112.0/24 with metric 500  is more specific than 
a route to 192.168.0.0/16 with metric 50, so this would get routed 
over the tunnel.


It will be interesting to see the routing table after the VPN client 
has connected - that will most likely tell us what is happening here.


Thank you for getting back to me. I think the route specificity 
shouldn't come into play here - as seen from the routing table below, 
there are two entries for 192.168.112.0/24 network - one through the 
vpn and one through the wired connection. They are both equally 
specific - so the route metric, if Windows 10 behaved as expected, 
should determine which one is chosen - unless I'm missing something? 
Sorry for the line wrapping pushing the route metric value to the next 
line



IPv4 Route Table
=== 


Active Routes:
Network Destination    Netmask  Gateway Interface  Metric
  0.0.0.0  0.0.0.0    192.168.112.1 192.168.112.236   25
    127.0.0.0    255.0.0.0 On-link 127.0.0.1    331
    127.0.0.1  255.255.255.255 On-link 127.0.0.1    331
  127.255.255.255  255.255.255.255 On-link 127.0.0.1    331
    192.168.112.0    255.255.255.0 On-link 192.168.112.236    281
    192.168.112.0    255.255.255.0    192.168.114.5 192.168.114.6    500
  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
    192.168.114.1  255.255.255.255    192.168.114.5 192.168.114.6    500
    192.168.114.4  255.255.255.252 On-link 192.168.114.6    259
    192.168.114.6  255.255.255.255 On-link 192.168.114.6    259
    192.168.114.7  255.255.255.255 On-link 192.168.114.6    259
    224.0.0.0    240.0.0.0 On-link 127.0.0.1    331
    224.0.0.0    240.0.0.0 On-link 192.168.112.236    281
    224.0.0.0    240.0.0.0 On-link 192.168.114.6    259
  255.255.255.255  255.255.255.255 On-link 127.0.0.1    331
  255.255.255.255  255.255.255.255 On-link 192.168.112.236    281
  255.255.255.255  255.255.255.255 On-link 192.168.114.6    259
=== 





the routing table looks OK to me, though I find the route
     192.168.112.236  255.255.255.255 On-link 192.168.112.236
281

a little odd - it suggests a /32 route pointing to itself.


I just checked another Windows 10 machine, and it has the same type of 
route - I am guessing it is some sort of weird Windows 10 thing?




Can you confirm that a
   tracert -d 192.168.112.1
indeed enters the tunnel first?


Things are potentially getting more interesting. tracert claims a single 
hop - which would suggest that the traffic is going straight to the 
internet server, and not entering the vpn tunnel. However, copying a 
file from a smb file share on the server shows speeds of 700 kbits - 
corresponding with the uplink of our ADSL internet connection. Shutting 
down openvpn on the server automatically pushes the file transfer speed 
to 1000mbs (well, almost) - which is the speed of our internal network. 
Somehow the smb protocol is using different routing rules then the 
tracert command?



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Gert Doering]

Hi,

On Thu, Sep 22, 2022 at 04:49:36PM +0100, Sebastian Arcus wrote:
> Thank you for getting back to me. I think the route specificity 
> shouldn't come into play here - as seen from the routing table below, 
> there are two entries for 192.168.112.0/24 network - one through the vpn 
> and one through the wired connection. They are both equally specific - 
> so the route metric, if Windows 10 behaved as expected, should determine 
> which one is chosen - unless I'm missing something? Sorry for the line 
> wrapping pushing the route metric value to the next line

This actually gives you a nice opportunity - if the .113.0/24 is free,
you could try pushing a route to 192.168.112.0/23 (note "/23") - normal
routing rules would prefer /24 vs. /23, so "LAN = 24" would always
win before "VPN /23".

Metric is helpful for "/24 vs /24", but if that can be avoided by going
for more-specific-wins, better.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Jan Just Keijser]

Hi Sebastian,

On 22/09/22 17:49, Sebastian Arcus wrote:

On 22/09/2022 16:09, Jan Just Keijser wrote:

Hi,

On 22/09/22 16:06, Sebastian Arcus wrote:
I use openvpn on laptops to access the vpn server and the network 
behind it. When the laptops are connected directly to the vpn server 
home network, to stop traffic going through the vpn, for years I've 
used successfully the route metric directive:


push "route-metric 500"

The 500 metric is supposed to be higher than wired connections, so 
the wired connection was preferred when connected to the openvpn 
server home lan, instead of the vpn connection.


This doesn't seem to work properly with Windows 10 any more. 
Although the route metric does get set correctly on Windows 10, it 
seems to just ignore it and route all traffic


sounds like Windows 10 is finally getting routing right , or more 
likely, that something changed in your LAN routes that you weren't 
aware of ;)
normal routing means that a more *specific* route wins over the 
*metric* of a route, e.g.


- a route to 192.168.112.0/24 with metric 500  is more specific than 
a route to 192.168.0.0/16 with metric 50, so this would get routed 
over the tunnel.


It will be interesting to see the routing table after the VPN client 
has connected - that will most likely tell us what is happening here.


Thank you for getting back to me. I think the route specificity 
shouldn't come into play here - as seen from the routing table below, 
there are two entries for 192.168.112.0/24 network - one through the 
vpn and one through the wired connection. They are both equally 
specific - so the route metric, if Windows 10 behaved as expected, 
should determine which one is chosen - unless I'm missing something? 
Sorry for the line wrapping pushing the route metric value to the next 
line



IPv4 Route Table
=== 


Active Routes:
Network Destination    Netmask  Gateway Interface  Metric
  0.0.0.0  0.0.0.0    192.168.112.1 192.168.112.236   25
    127.0.0.0    255.0.0.0 On-link 127.0.0.1    331
    127.0.0.1  255.255.255.255 On-link 127.0.0.1    331
  127.255.255.255  255.255.255.255 On-link 127.0.0.1    331
    192.168.112.0    255.255.255.0 On-link 192.168.112.236    281
    192.168.112.0    255.255.255.0    192.168.114.5 192.168.114.6    500
  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
    192.168.114.1  255.255.255.255    192.168.114.5 192.168.114.6    500
    192.168.114.4  255.255.255.252 On-link 192.168.114.6    259
    192.168.114.6  255.255.255.255 On-link 192.168.114.6    259
    192.168.114.7  255.255.255.255 On-link 192.168.114.6    259
    224.0.0.0    240.0.0.0 On-link 127.0.0.1    331
    224.0.0.0    240.0.0.0 On-link 192.168.112.236    281
    224.0.0.0    240.0.0.0 On-link 192.168.114.6    259
  255.255.255.255  255.255.255.255 On-link 127.0.0.1    331
  255.255.255.255  255.255.255.255 On-link 192.168.112.236    281
  255.255.255.255  255.255.255.255 On-link 192.168.114.6    259
=== 





the routing table looks OK to me, though I find the route
    192.168.112.236  255.255.255.255 On-link 192.168.112.236    281
a little odd - it suggests a /32 route pointing to itself.

Can you confirm that a
  tracert -d 192.168.112.1
indeed enters the tunnel first?

JJK



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Correct way to handle routing when on home network?

[Jan Just Keijser]

Hi,

On 22/09/22 16:06, Sebastian Arcus wrote:
I use openvpn on laptops to access the vpn server and the network 
behind it. When the laptops are connected directly to the vpn server 
home network, to stop traffic going through the vpn, for years I've 
used successfully the route metric directive:


push "route-metric 500"

The 500 metric is supposed to be higher than wired connections, so the 
wired connection was preferred when connected to the openvpn server 
home lan, instead of the vpn connection.


This doesn't seem to work properly with Windows 10 any more. Although 
the route metric does get set correctly on Windows 10, it seems to 
just ignore it and route all traffic


sounds like Windows 10 is finally getting routing right , or more 
likely, that something changed in your LAN routes that you weren't aware 
of ;)
normal routing means that a more *specific* route wins over the *metric* 
of a route, e.g.


- a route to 192.168.112.0/24 with metric 500  is more specific than a 
route to 192.168.0.0/16 with metric 50, so this would get routed over 
the tunnel.


It will be interesting to see the routing table after the VPN client has 
connected - that will most likely tell us what is happening here.


HTH,

JJK



Does anyone know if Windows 10 now behaves differently with regards to 
route metric? Is there a new recommended way to deal with this issue? 
More details below of my setup:


Server: openvpn 2.5.7, Linux Slackware
Client: openvpn 2.5.7, Windows 10
OpenVPN server lan subnet: 192.168.112.0/24
OpenVPN subnet: 192.168.114.0/24


server.conf

proto udp
port 1194
dev tun
server 192.168.114.0 255.255.255.0
push "route 192.168.112.0 255.255.255.0"
push "dhcp-option DNS 192.168.112.1"
push "dhcp-option WINS 192.168.112.1"
push "route-metric 500"
ca "ca.crt"
cert "server.crt"
key "server.key"
tls-auth "ta.key" 0
dh "dh.pem"



client.conf

client
windows-driver wintun
proto udp
remote vpn.remote.address
port 1194
resolv-retry infinite
ping-restart 10
persist-key
persist-tun
key-direction 1
remote-cert-tls server
ca "ca.crt"
cert "client.crt"
key "client.key"
tls-auth "ta.key" 1
remote-cert-tls server






___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users