Re: [Openvpn-users] OpenVPN issues with Windows NLA

[David Sommerseth]

On 03/07/2020 09:46, Marc SCHAEFER wrote:
> On Fri, Jul 03, 2020 at 01:20:09AM +0100, tincanteksup wrote:
>> DNSSec would put an end to this sort of snooping .. lol
> 
> As Gert said, no, it won't.
> 
> What you may want is DNS over HTTPS or over TLS. However, in that case, it's
> the DNS provider that can snoop on you, but no longer your ISP. If your ISP
> does not spy on you, the mixing with all of its customers and the caching it
> offers are valuable.
> 
> Google and CloudFare offer DNS over HTTPS, bypassing your local DNS,
> the latter seem to less spy on its users.
> 
>https://en.wikipedia.org/wiki/DNS_over_HTTPS

For a more in-depth walk-through about the issues around DNS over HTTPS (DoH),
please see this:    Paul Vixie is
one of the biggest names in the DNS scope, and this guy knows what DNS is all
about.

DoH is really not a good solution for very many use cases.  And it is a move
in the opposite direction of the benefit of a proper DNS protocol,
decentralizing requests.  And DoH needs to implement additional complexity on
the server side if you want to consider regional based DNS lookups (like using
a local CDN) ... and this is not even touching the privacy/tracking issues in 
DoH.

What is often ignored by many of the DoH promoters, DNS over TLS (DoT) exists
and provides the same level of features as unencrypted DNS lookups - without
all the issues DoH adds.  The biggest challenge of DoT is that many DNS
servers have not been upgraded to a reasonable solution with this support, and
many who has done that has not configured DoT yet.


-- 
kind regards,

David Sommerseth




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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[tincanteksup]

Thanks .. this appears clarify my mis-understanding.

On 03/07/2020 08:46, Marc SCHAEFER wrote:

On Fri, Jul 03, 2020 at 01:20:09AM +0100, tincanteksup wrote:

DNSSec would put an end to this sort of snooping .. lol


As Gert said, no, it won't.

What you may want is DNS over HTTPS or over TLS. However, in that case, it's
the DNS provider that can snoop on you, but no longer your ISP. If your ISP
does not spy on you, the mixing with all of its customers and the caching it
offers are valuable.

Google and CloudFare offer DNS over HTTPS, bypassing your local DNS,
the latter seem to less spy on its users.

https://en.wikipedia.org/wiki/DNS_over_HTTPS


___
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] OpenVPN issues with Windows NLA

[tincanteksup]

Thanks .. it would seem that I have been mis-informed about this for 
quite some time ..


Today I learnt something !

On 03/07/2020 07:13, Gert Doering wrote:

Hi,

On Fri, Jul 03, 2020 at 01:20:09AM +0100, tincanteksup wrote:

DNSSec would put an end to this sort of snooping .. lol


Actually, it won't.  DNSSec guarantees authencity, but does not encrypt.

gert




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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Marc SCHAEFER]

On Fri, Jul 03, 2020 at 01:20:09AM +0100, tincanteksup wrote:
> DNSSec would put an end to this sort of snooping .. lol

As Gert said, no, it won't.

What you may want is DNS over HTTPS or over TLS. However, in that case, it's
the DNS provider that can snoop on you, but no longer your ISP. If your ISP
does not spy on you, the mixing with all of its customers and the caching it
offers are valuable.

Google and CloudFare offer DNS over HTTPS, bypassing your local DNS,
the latter seem to less spy on its users.

   https://en.wikipedia.org/wiki/DNS_over_HTTPS


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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Gert Doering]

Hi,

On Fri, Jul 03, 2020 at 01:20:09AM +0100, tincanteksup wrote:
> DNSSec would put an end to this sort of snooping .. lol

Actually, it won't.  DNSSec guarantees authencity, but does not encrypt.

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] OpenVPN issues with Windows NLA

[tincanteksup]

On 03/07/2020 00:12, Marco De Vitis wrote:

Il 02/07/20 19:54, Selva Nair ha scritto:


 1. The DNS of my LAN (i.e. my home router's IP) has been set as
    default gateway for the OpenVPN interface. But I'll need to
    remember changing it if I connect from elsewhere.

That looks like a strange setting but probably doesn't hurt.


I'm not sure I understand myself how this setting is involved, but it is 
actually required: if I remove it I'm back at the starting point with 
the failed NCSI check.


I also captured network traffic to investigate, and with the gateway 
setup I can see a successful DNS query to the VPN DNS (not my gateway) 
for dns.msftncsi.com, while without it I see no trace of this query.




DNSSec would put an end to this sort of snooping .. lol



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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Marco De Vitis]

Il 02/07/20 19:54, Selva Nair ha scritto:


 1. The DNS of my LAN (i.e. my home router's IP) has been set as
default gateway for the OpenVPN interface. But I'll need to
remember changing it if I connect from elsewhere.

That looks like a strange setting but probably doesn't hurt.


I'm not sure I understand myself how this setting is involved, but it is 
actually required: if I remove it I'm back at the starting point with 
the failed NCSI check.


I also captured network traffic to investigate, and with the gateway 
setup I can see a successful DNS query to the VPN DNS (not my gateway) 
for dns.msftncsi.com, while without it I see no trace of this query.


Such weakening of the server-side firewall shouldn't be required as 
you are not sending any traffic to those IPs via the VPN.  When you 
use block-outside DNS, the DNS server pushed must be ready to do all 
name resolutions for you. If it's doing that, and in particular 
resolving those dns.msftncsi.com  etc 
involved in ncsi, you should be good.


Probably Windows is doing something weird behind our backs. Have you 
tried setting a direct route via your router to those two IPs on your 
machine (instead of on the server-side firewall)? "route add 
131.107.255.255 mask 255.255.255.255 192.168.1.1" etc.


Indeed this is weird.
I tried adding the routes (and deleted the equivalent ones to the other 
gateway, pushed by the server), but it didn't work.


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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Selva Nair]

Hi

On Thu, Jul 2, 2020 at 1:08 PM Marco De Vitis  wrote:

> Il 01/07/20 21:18, Selva Nair ha scritto:
>
> fwiw, try removing the pushed block-outside-dns by adding this to the
> client config:
>
> pull-filter ignore block-outside-dns
>
>
> Hi,
> I tried this and indeed it fixes the issue, Windows detects internet
> connectivity.
>
> But it introduces a different issue related to my company setup: we have
> internal servers which we need to reach by internal hostname (e.g.
> myhost.companyname) when using the VPN. But when I do not use
> block-outside-dns Windows tries to resolve them using external DNS servers,
> and this will fail.
>

Yes, removing block-outside-dns is not a real solution and could break
resolution of internal names as you see. Though I have setups where it
works fine with resolution via both interfaces and connection-specific
suffix set on the TAP interface.


>
> I tried setting the interface metrics to give a higher priority to the
> OpenVPN interface - and so hopefully to its DNS, but the behaviour did not
> change.
>
> At the moment it all seems to be working with the original VPN config
> (block-outside-dns) plus the following two additions by the network guys,
> but it's far from ideal:
>
>1. The DNS of my LAN (i.e. my home router's IP) has been set as
>default gateway for the OpenVPN interface. But I'll need to remember
>changing it if I connect from elsewhere.
>
> That looks like a strange setting but probably doesn't hurt.

>
>1. The company firewall has been configured to allow traffic from the
>VPN client range to Microsoft connectivity check IPs 131.107.255.255 and
>13.107.4.52. But what if they change? (The firewall is usually configured
>to block any traffic from VPN to external IPs, because the configured
>routes should let this happen through the standard ethernet/wifi interface)
>
> Such weakening of the server-side firewall shouldn't be required as you
are not sending any traffic to those IPs via the VPN.  When you use
block-outside DNS, the DNS server pushed must be ready to do all name
resolutions for you. If it's doing that, and in particular resolving those
dns.msftncsi.com etc involved in ncsi, you should be good.

Probably Windows is doing something weird behind our backs. Have you tried
setting a direct route via your router to those two IPs on your machine
(instead of on the server-side firewall)? "route add 131.107.255.255 mask
255.255.255.255 192.168.1.1" etc.

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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Marco De Vitis]

Il 01/07/20 21:18, Selva Nair ha scritto:

fwiw, try removing the pushed block-outside-dns by adding this to the
client config:

pull-filter ignore block-outside-dns


Hi,
I tried this and indeed it fixes the issue, Windows detects internet 
connectivity.


But it introduces a different issue related to my company setup: we have 
internal servers which we need to reach by internal hostname (e.g. 
myhost.companyname) when using the VPN. But when I do not use 
block-outside-dns Windows tries to resolve them using external DNS 
servers, and this will fail.


I tried setting the interface metrics to give a higher priority to the 
OpenVPN interface - and so hopefully to its DNS, but the behaviour did 
not change.


At the moment it all seems to be working with the original VPN config 
(block-outside-dns) plus the following two additions by the network 
guys, but it's far from ideal:


1. The DNS of my LAN (i.e. my home router's IP) has been set as default
   gateway for the OpenVPN interface. But I'll need to remember
   changing it if I connect from elsewhere.
2. The company firewall has been configured to allow traffic from the
   VPN client range to Microsoft connectivity check IPs 131.107.255.255
   and 13.107.4.52. But what if they change? (The firewall is usually
   configured to block any traffic from VPN to external IPs, because
   the configured routes should let this happen through the standard
   ethernet/wifi interface)

Any other clues?
Thanks again.
Marco
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Marco De Vitis]

Il 01/07/20 18:36, Selva Nair ha scritto:


This is surprising as the routing table shows you are not using
redirect-gateway and, except for some server side internal networks
and one or two external addresses, all targets are routed in clear via
the LAN gateway.
Indeed, this is how my company VPN is configured on purpose, to avoid 
routing all external traffic through the company network when we are 
smart working from home.

some domains. In particular, see whether "nslookup dns.msftncsi.com
172.28.254.1" resolves to 131.107.255.255 although that may not be
conclusive.
At the moment it resolves successfully. I'm trying it in a loop to see 
if it fails anytime.
Thanks for the pointer and for the confirmation of routing 
configuration, maybe this can be helpful for asking to the network team.


Regards,
Marco.


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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Selva Nair]

On Wed, Jul 1, 2020 at 3:18 PM Selva Nair  wrote:
>
> Hi,
>
> On Wed, Jul 1, 2020 at 3:09 PM Marco De Vitis  wrote:

..

> > But why should this make NLA fail? DNS resolution using the VPN DNS
> > server appears to work fine for every address, including the one which
> > Microsoft uses for the connection check. But the failure is systematic
> > instead.
>
> If the pushed DNS server works for all domains, I'm out of ideas. But
> fwiw, try removing the pushed block-outside-dns by adding this to the
> client config:
>
> pull-filter ignore block-outside-dns
>
> and check the logs to ensure it's ignored. This shouldn't be required,
> and is not ideal, but worth a test.

In case it was not obvious, for this test you also have to remove any
block-outside-dns in the client config.

Selva


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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Selva Nair]

Hi,

On Wed, Jul 1, 2020 at 3:09 PM Marco De Vitis  wrote:
>
> Il 01/07/20 20:21, tincanteksup ha scritto:
> > The post you made on the forum suggests that you have set a default
> > gateway on the TAP adapter ..
> > Do not do that.
> Well yes, it's an attempt I made because I saw everyone in that thread
> telling that this fixed the issue. But it didn't for me (and I did not
> expect it, actually), so I rolled back to the original configuration.
> > We do not have your client config or logs so this is just a guess but
> > do not use --block-outside-dns (if you are).
> At this point, this is most probably the reason: the block-outside-dns
> option is in use. Even if I remove it from the client config, it's
> pushed from the server.
>
> But why should this make NLA fail? DNS resolution using the VPN DNS
> server appears to work fine for every address, including the one which
> Microsoft uses for the connection check. But the failure is systematic
> instead.

If the pushed DNS server works for all domains, I'm out of ideas. But
fwiw, try removing the pushed block-outside-dns by adding this to the
client config:

pull-filter ignore block-outside-dns

and check the logs to ensure it's ignored. This shouldn't be required,
and is not ideal, but worth a test.

Selva


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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Marco De Vitis]

Il 01/07/20 20:21, tincanteksup ha scritto:
The post you made on the forum suggests that you have set a default 
gateway on the TAP adapter ..

Do not do that.
Well yes, it's an attempt I made because I saw everyone in that thread 
telling that this fixed the issue. But it didn't for me (and I did not 
expect it, actually), so I rolled back to the original configuration.
We do not have your client config or logs so this is just a guess but 
do not use --block-outside-dns (if you are).
At this point, this is most probably the reason: the block-outside-dns 
option is in use. Even if I remove it from the client config, it's 
pushed from the server.


But why should this make NLA fail? DNS resolution using the VPN DNS 
server appears to work fine for every address, including the one which 
Microsoft uses for the connection check. But the failure is systematic 
instead.


Indeed, I just discovered there is a NCSI log in the Event Viewer and 
when NLA fails I see in there an ActiveHttpProbeFailed event, followed 
by a SuspectDnsProbeFailed event.


Sorry for not posting logs and config but I did not want to overwhelm 
the list, the terminal output was already long enough.


Here is the config:


dev tun
persist-tun
persist-key
cipher AES-128-CBC
ncp-ciphers AES-256-GCM:AES-128-GCM
auth SHA1
tls-client
client
resolv-retry infinite
remote x.x.x.x 443 tcp-client
setenv opt block-outside-dns
verify-x509-name " OpenVPN" name
auth-user-pass
pkcs12 .p12
tls-auth .key 1
remote-cert-tls server
passtos


And the connection log:

Wed Jul 01 20:41:47 2020 OpenVPN 2.4.9 x86_64-w64-mingw32 [SSL 
(OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 16 2020

Wed Jul 01 20:41:47 2020 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Jul 01 20:41:47 2020 library versions: OpenSSL 1.1.1f  31 Mar 
2020, LZO 2.10
Wed Jul 01 20:41:50 2020 TCP/UDP: Preserving recently used remote 
address: [AF_INET]x.x.x.x:443
Wed Jul 01 20:41:50 2020 Attempting to establish TCP connection with 
[AF_INET]x.x.x.x:443 [nonblock]
Wed Jul 01 20:41:51 2020 TCP connection established with 
[AF_INET]x.x.x.x:443

Wed Jul 01 20:41:51 2020 TCP_CLIENT link local: (not bound)
Wed Jul 01 20:41:51 2020 TCP_CLIENT link remote: [AF_INET]x.x.x.x:443
Wed Jul 01 20:41:51 2020 WARNING: this configuration may cache 
passwords in memory -- use the auth-nocache option to prevent this
Wed Jul 01 20:41:51 2020 [ OpenVPN] Peer Connection Initiated with 
[AF_INET]x.x.x.x:443

Wed Jul 01 20:41:52 2020 open_tun
Wed Jul 01 20:41:52 2020 TAP-WIN32 device [OpenVPN] opened: 
\\.\Global\{9872CE0F-C4BA-42E5-8CB3-18E05AE0C387}.tap
Wed Jul 01 20:41:52 2020 Set TAP-Windows TUN subnet mode 
network/local/netmask = 172.28.254.0/172.28.254.241/255.255.255.0 
[SUCCEEDED]
Wed Jul 01 20:41:52 2020 Notified TAP-Windows driver to set a DHCP 
IP/netmask of 172.28.254.241/255.255.255.0 on interface 
{9872CE0F-C4BA-42E5-8CB3-18E05AE0C387} [DHCP-serv: 172.28.254.254, 
lease-time: 31536000]
Wed Jul 01 20:41:52 2020 Successful ARP Flush on interface [20] 
{9872CE0F-C4BA-42E5-8CB3-18E05AE0C387}

Wed Jul 01 20:41:52 2020 Blocking outside dns using service succeeded.
Wed Jul 01 20:41:57 2020 ROUTE: route addition failed using service: 
L'oggetto esiste già.   [status=5010 if_index=20]
Wed Jul 01 20:41:57 2020 ROUTE: route addition failed using service: 
L'oggetto esiste già.   [status=5010 if_index=20]

Wed Jul 01 20:41:57 2020 Initialization Sequence Completed
Wed Jul 01 20:41:57 2020 Register_dns request sent to the service


Thanks.
Marco


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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Marco De Vitis]

Il 01/07/20 18:43, tincanteksup ha scritto:

This is the reason as explained by Micro

https://forums.openvpn.net/viewtopic.php?f=1&t=27321
Thanks, I already found many descriptions of the reason for this issue, 
it really looks the same issue I'm experiencing, but the strange thing 
is that my configuration should already be ok and no workaround seems to 
be useful in my case.
This is why I'm asking here, and I also added a post myself today in the 
link you mention.


Regards,
Marco.


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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[tincanteksup]

Hi,

On 01/07/2020 19:03, Marco De Vitis wrote:

Il 01/07/20 18:43, tincanteksup ha scritto:

This is the reason as explained by Micro

https://forums.openvpn.net/viewtopic.php?f=1&t=27321
Thanks, I already found many descriptions of the reason for this issue, 
it really looks the same issue I'm experiencing, but the strange thing 
is that my configuration should already be ok and no workaround seems to 
be useful in my case.
This is why I'm asking here, and I also added a post myself today in the 
link you mention.




The post you made on the forum suggests that you have set a default 
gateway on the TAP adapter ..

Do not do that.

According to the routing you posted here on the mailing list, you are 
not redirecting your gateway

and so you should not mess about with default gateway.

As Selva pointed out, this sounds more like a DNS issue ..

We do not have your client config or logs so this is just a guess but do 
not use --block-outside-dns (if you are).


The way to get the best help is to follow the instructions here:
https://forums.openvpn.net/viewtopic.php?f=30&t=22603#p68963


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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Marco De Vitis]

Il 01/07/20 18:43, Jan Just Keijser ha scritto:

what happens if you add to your config

  route 0.0.0.0 0.0.0.0 vpn_gateway 
Thanks, I just tried it, I saw the route added in "route print", but the 
result was the same.

I would say that NLA usually breaks 2-3 minutes after connecting to the VPN.

Regards,
Marco.


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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Selva Nair]

Hi

On Wed, Jul 1, 2020 at 12:45 PM Jan Just Keijser  wrote:
>
> Hi,
>
> On 01/07/20 14:51, Marco De Vitis wrote:
>
> Hi,
> I use OpenVPN client 2.4.9 on Windows 10 (v2004), and I have issues with the 
> Network Location Awareness (NLA) Windows service.
>
> The issue is essentially described here, even though it dates back to Windows 
> 7: 
> https://docs.microsoft.com/it-it/archive/blogs/the_microsoft_excel_support_team_blog/office-2013-reports-no-internet-connectivity-with-vpn-connection
>
> My symptoms are the same: when I connect to my company VPN using OpenVPN, 
> soon or later (maybe after minutes, maybe hours) the NLA service decides that 
> no internet access is available, I get the "no internet access" tray icon, 
> and some applications do not work as they should, notably Spotify and Office 
> 365 in my case. Nevertheless, all other applications work fine and I can 
> successfully access the web and my company LAN. But those apps refusing to 
> connect are very annoying.
>
> When this happens, this script actually finds no failed checks:
> https://community.spiceworks.com/scripts/show/4340-network-connection-status-indicator-ncsi-test
>
>
> what happens if you add to your config
>
>   route 0.0.0.0 0.0.0.0 vpn_gateway 
>
> (or push "route 0.0.0.0 0.0.0.0 vpn_gateway " from the server) ?
>
> that sometimes helps Windows NLA to allow traffic over the VPN.

In this case not all traffic is being sent via the VPN and there is no
redirect-gateway def1 in use. Almost all traffic continues to go via
the LAN and the default gateway is maintained on that interface. So
all those links about broken ncsi don't apply. I suspect DNS through
VPN is broken.

Selva


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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Jan Just Keijser]

Hi,

On 01/07/20 14:51, Marco De Vitis wrote:

Hi,
I use OpenVPN client 2.4.9 on Windows 10 (v2004), and I have issues 
with the Network Location Awareness (NLA) Windows service.


The issue is essentially described here, even though it dates back to 
Windows 7: 
https://docs.microsoft.com/it-it/archive/blogs/the_microsoft_excel_support_team_blog/office-2013-reports-no-internet-connectivity-with-vpn-connection


My symptoms are the same: when I connect to my company VPN using 
OpenVPN, soon or later (maybe after minutes, maybe hours) the NLA 
service decides that no internet access is available, I get the "no 
internet access" tray icon, and some applications do not work as they 
should, notably Spotify and Office 365 in my case. Nevertheless, all 
other applications work fine and I can successfully access the web and 
my company LAN. But those apps refusing to connect are very annoying.


When this happens, this script actually finds no failed checks:
https://community.spiceworks.com/scripts/show/4340-network-connection-status-indicator-ncsi-test



what happens if you add to your config

  route 0.0.0.0 0.0.0.0 vpn_gateway 

(or push "route 0.0.0.0 0.0.0.0 vpn_gateway " from the server) ?

that sometimes helps Windows NLA to allow traffic over the VPN.

HTH,

JJK

I tried every workaround I could find on the web: remove antivirus, 
disable windows firewall, set NLA delayed startup, set default gateway 
in TAP NIC properties, set registry keys like in 
https://support.microsoft.com/en-us/help/4550028/firewall-profile-does-not-switch-to-domain-when-using-third-party-vpn 
or 
https://social.technet.microsoft.com/Forums/en-US/e3e75a8f-27f7-479b-b573-3d012a69b45f/network-location-awareness-doesnt-detect-connectivity?forum=win10itpronetworking

Nothing fixed the issue.

I'm getting crazy, can anyone help, please?

Thanks.

This is the "ipconfig /all" output when connected to the VPN:

Configurazione IP di Windows

   Nome host . . . . . . . . . . . . . . : 
   Suffisso DNS primario . . . . . . . . : .local
   Tipo nodo . . . . . . . . . . . . . . : Ibrido
   Routing IP abilitato. . . . . . . . . : No
   Proxy WINS abilitato . . . . . . . .  : No
   Elenco di ricerca suffissi DNS. . . . : 

Scheda Ethernet Ethernet:

   Stato supporto. . . . . . . . . . . . : Supporto disconnesso
   Suffisso DNS specifico per connessione:
   Descrizione . . . . . . . . . . . . . : Realtek PCIe GbE Family 
Controller

   Indirizzo fisico. . . . . . . . . . . : 3C-2C-30-E6-30-91
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì

Scheda sconosciuta OpenVPN:

   Suffisso DNS specifico per connessione: 
   Descrizione . . . . . . . . . . . . . : TAP-Windows Adapter V9
   Indirizzo fisico. . . . . . . . . . . : 00-FF-98-72-CE-0F
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì
   Indirizzo IPv6 locale rispetto al collegamento . : 
fe80::94e8:b4ce:f66f:19ab%20(Preferenziale)

   Indirizzo IPv4. . . . . . . . . . . . : 172.28.254.241(Preferenziale)
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Lease ottenuto. . . . . . . . . . . . : mercoledì 1 luglio 2020 
13:07:27

   Scadenza lease . . . . . . . . . . .  : giovedì 1 luglio 2021 13:07:26
   Gateway predefinito . . . . . . . . . :
   Server DHCP . . . . . . . . . . . . . : 172.28.254.254
   IAID DHCPv6 . . . . . . . . . . . : 268500888
   DUID Client DHCPv6. . . . . . . . : 
00-01-00-01-24-FE-F3-1A-3C-2C-30-E6-30-91

   Server DNS . . . . . . . . . . . . .  : 172.28.254.1
   NetBIOS su TCP/IP . . . . . . . . . . : Attivato

Scheda LAN wireless Connessione alla rete locale (LAN)* 1:

   Stato supporto. . . . . . . . . . . . : Supporto disconnesso
   Suffisso DNS specifico per connessione:
   Descrizione . . . . . . . . . . . . . : Microsoft Wi-Fi Direct 
Virtual Adapter

   Indirizzo fisico. . . . . . . . . . . : 4A-5F-99-1A-44-C7
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì

Scheda LAN wireless Connessione alla rete locale (LAN)* 2:

   Stato supporto. . . . . . . . . . . . : Supporto disconnesso
   Suffisso DNS specifico per connessione:
   Descrizione . . . . . . . . . . . . . : Microsoft Wi-Fi Direct 
Virtual Adapter #2

   Indirizzo fisico. . . . . . . . . . . : 5A-5F-99-1A-44-C7
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì

Scheda LAN wireless Wi-Fi:

   Suffisso DNS specifico per connessione: home-life.hub
   Descrizione . . . . . . . . . . . . . : Qualcomm QCA9377 802.11ac 
Wireless Adapter

   Indirizzo fisico. . . . . . . . . . . : 48-5F-99-1A-44-C7
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì
   Indirizzo IPv6 locale rispetto al collegamento . : 
fe80::4d05:e505:5528:dfb1%17(Preferenziale)

   Indirizzo IPv4. . . . . . . . . . . . : 192.168.1.27(Preferenziale)
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Lease otten

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[tincanteksup]

This is the reason as explained by Micro

https://forums.openvpn.net/viewtopic.php?f=1&t=27321



On 01/07/2020 17:36, Selva Nair wrote:

Hi

On Wed, Jul 1, 2020 at 11:21 AM Marco De Vitis  wrote:


Hi,
I use OpenVPN client 2.4.9 on Windows 10 (v2004), and I have issues with the 
Network Location Awareness (NLA) Windows service.

The issue is essentially described here, even though it dates back to Windows 
7: 
https://docs.microsoft.com/it-it/archive/blogs/the_microsoft_excel_support_team_blog/office-2013-reports-no-internet-connectivity-with-vpn-connection




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

Re: [Openvpn-users] OpenVPN issues with Windows NLA

[Selva Nair]

Hi

On Wed, Jul 1, 2020 at 11:21 AM Marco De Vitis  wrote:
>
> Hi,
> I use OpenVPN client 2.4.9 on Windows 10 (v2004), and I have issues with the 
> Network Location Awareness (NLA) Windows service.
>
> The issue is essentially described here, even though it dates back to Windows 
> 7: 
> https://docs.microsoft.com/it-it/archive/blogs/the_microsoft_excel_support_team_blog/office-2013-reports-no-internet-connectivity-with-vpn-connection
>
> My symptoms are the same: when I connect to my company VPN using OpenVPN, 
> soon or later (maybe after minutes, maybe hours) the NLA service decides that 
> no internet access is available, I get the "no internet access" tray icon, 
> and some applications do not work as they should, notably Spotify and Office 
> 365 in my case. Nevertheless, all other applications work fine and I can 
> successfully access the web and my company LAN. But those apps refusing to 
> connect are very annoying.

This is surprising as the routing table shows you are not using
redirect-gateway and, except for some server side internal networks
and one or two external addresses, all targets are routed in clear via
the LAN gateway.

>
> This is the "ipconfig /all" output when connected to the VPN:
>
> Configurazione IP di Windows
>
>Nome host . . . . . . . . . . . . . . : 
>Suffisso DNS primario . . . . . . . . : .local
>Tipo nodo . . . . . . . . . . . . . . : Ibrido
>Routing IP abilitato. . . . . . . . . : No
>Proxy WINS abilitato . . . . . . . .  : No
>Elenco di ricerca suffissi DNS. . . . : 
>
> Scheda Ethernet Ethernet:
>
>Stato supporto. . . . . . . . . . . . : Supporto disconnesso
>Suffisso DNS specifico per connessione:
>Descrizione . . . . . . . . . . . . . : Realtek PCIe GbE Family Controller
>Indirizzo fisico. . . . . . . . . . . : 3C-2C-30-E6-30-91
>DHCP abilitato. . . . . . . . . . . . : Sì
>Configurazione automatica abilitata   : Sì
>
> Scheda sconosciuta OpenVPN:
>
>Suffisso DNS specifico per connessione: 
>Descrizione . . . . . . . . . . . . . : TAP-Windows Adapter V9
>Indirizzo fisico. . . . . . . . . . . : 00-FF-98-72-CE-0F
>DHCP abilitato. . . . . . . . . . . . : Sì
>Configurazione automatica abilitata   : Sì
>Indirizzo IPv6 locale rispetto al collegamento . : 
> fe80::94e8:b4ce:f66f:19ab%20(Preferenziale)
>Indirizzo IPv4. . . . . . . . . . . . : 172.28.254.241(Preferenziale)
>Subnet mask . . . . . . . . . . . . . : 255.255.255.0
>Lease ottenuto. . . . . . . . . . . . : mercoledì 1 luglio 2020 13:07:27
>Scadenza lease . . . . . . . . . . .  : giovedì 1 luglio 2021 13:07:26
>Gateway predefinito . . . . . . . . . :
>Server DHCP . . . . . . . . . . . . . : 172.28.254.254
>IAID DHCPv6 . . . . . . . . . . . : 268500888
>DUID Client DHCPv6. . . . . . . . : 
> 00-01-00-01-24-FE-F3-1A-3C-2C-30-E6-30-91
>Server DNS . . . . . . . . . . . . .  : 172.28.254.1

That is the DNS server set on the TAP interface by the VPN.  Check
whether it's capable of resolving external addresses. Probably what
you see is due to inconsistent DNS resolution.

I can't say why it works for a while and only some services are
affected, but it could happen if 172.28.254.1 gives bogus results for
some domains. In particular, see whether "nslookup dns.msftncsi.com
172.28.254.1" resolves to 131.107.255.255 although that may not be
conclusive.

> And here it the output of "route print":
>
> ===
> Elenco interfacce
>  16...3c 2c 30 e6 30 91 ..Realtek PCIe GbE Family Controller
>  20...00 ff 98 72 ce 0f ..TAP-Windows Adapter V9
>   4...4a 5f 99 1a 44 c7 ..Microsoft Wi-Fi Direct Virtual Adapter
>  21...5a 5f 99 1a 44 c7 ..Microsoft Wi-Fi Direct Virtual Adapter #2
>  17...48 5f 99 1a 44 c7 ..Qualcomm QCA9377 802.11ac Wireless Adapter
>   1...Software Loopback Interface 1
>  61...00 15 5d 9c 2e 02 ..Hyper-V Virtual Ethernet Adapter
> ===
>
> IPv4 Tabella route
> ===
> Route attive:
>  Indirizzo rete Mask  Gateway Interfaccia Metrica
>   0.0.0.0  0.0.0.0  192.168.1.1 192.168.1.27 35
> 10.3.64.0255.255.192.0 172.28.254.1   172.28.254.241259
> 10.3.66.0255.255.255.0 172.28.254.1   172.28.254.241259
> 10.3.67.0255.255.255.0 172.28.254.1   172.28.254.241259
> 10.3.68.0255.255.252.0 172.28.254.1   172.28.254.241259
> 10.3.72.0  255.255.255.128 172.28.254.1   172.28.254.241259
>  90.84.191.96  255.255.255.255 172.28.254.1   172.28.254.241259
>
> 127.0.0.0255.0.0.0 On-link 127.0.0.1331
> 127.0.0.1  255.255.255.255 On-link 127.0.0.1331
>   12

[Openvpn-users] OpenVPN issues with Windows NLA

[Marco De Vitis]

Hi,
I use OpenVPN client 2.4.9 on Windows 10 (v2004), and I have issues with 
the Network Location Awareness (NLA) Windows service.


The issue is essentially described here, even though it dates back to 
Windows 7: 
https://docs.microsoft.com/it-it/archive/blogs/the_microsoft_excel_support_team_blog/office-2013-reports-no-internet-connectivity-with-vpn-connection


My symptoms are the same: when I connect to my company VPN using 
OpenVPN, soon or later (maybe after minutes, maybe hours) the NLA 
service decides that no internet access is available, I get the "no 
internet access" tray icon, and some applications do not work as they 
should, notably Spotify and Office 365 in my case. Nevertheless, all 
other applications work fine and I can successfully access the web and 
my company LAN. But those apps refusing to connect are very annoying.


When this happens, this script actually finds no failed checks:
https://community.spiceworks.com/scripts/show/4340-network-connection-status-indicator-ncsi-test

I tried every workaround I could find on the web: remove antivirus, 
disable windows firewall, set NLA delayed startup, set default gateway 
in TAP NIC properties, set registry keys like in 
https://support.microsoft.com/en-us/help/4550028/firewall-profile-does-not-switch-to-domain-when-using-third-party-vpn 
or 
https://social.technet.microsoft.com/Forums/en-US/e3e75a8f-27f7-479b-b573-3d012a69b45f/network-location-awareness-doesnt-detect-connectivity?forum=win10itpronetworking

Nothing fixed the issue.

I'm getting crazy, can anyone help, please?

Thanks.

This is the "ipconfig /all" output when connected to the VPN:

Configurazione IP di Windows

   Nome host . . . . . . . . . . . . . . : 
   Suffisso DNS primario . . . . . . . . : .local
   Tipo nodo . . . . . . . . . . . . . . : Ibrido
   Routing IP abilitato. . . . . . . . . : No
   Proxy WINS abilitato . . . . . . . .  : No
   Elenco di ricerca suffissi DNS. . . . : 

Scheda Ethernet Ethernet:

   Stato supporto. . . . . . . . . . . . : Supporto disconnesso
   Suffisso DNS specifico per connessione:
   Descrizione . . . . . . . . . . . . . : Realtek PCIe GbE Family 
Controller

   Indirizzo fisico. . . . . . . . . . . : 3C-2C-30-E6-30-91
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì

Scheda sconosciuta OpenVPN:

   Suffisso DNS specifico per connessione: 
   Descrizione . . . . . . . . . . . . . : TAP-Windows Adapter V9
   Indirizzo fisico. . . . . . . . . . . : 00-FF-98-72-CE-0F
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì
   Indirizzo IPv6 locale rispetto al collegamento . : 
fe80::94e8:b4ce:f66f:19ab%20(Preferenziale)

   Indirizzo IPv4. . . . . . . . . . . . : 172.28.254.241(Preferenziale)
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Lease ottenuto. . . . . . . . . . . . : mercoledì 1 luglio 2020 13:07:27
   Scadenza lease . . . . . . . . . . .  : giovedì 1 luglio 2021 13:07:26
   Gateway predefinito . . . . . . . . . :
   Server DHCP . . . . . . . . . . . . . : 172.28.254.254
   IAID DHCPv6 . . . . . . . . . . . : 268500888
   DUID Client DHCPv6. . . . . . . . : 
00-01-00-01-24-FE-F3-1A-3C-2C-30-E6-30-91

   Server DNS . . . . . . . . . . . . .  : 172.28.254.1
   NetBIOS su TCP/IP . . . . . . . . . . : Attivato

Scheda LAN wireless Connessione alla rete locale (LAN)* 1:

   Stato supporto. . . . . . . . . . . . : Supporto disconnesso
   Suffisso DNS specifico per connessione:
   Descrizione . . . . . . . . . . . . . : Microsoft Wi-Fi Direct 
Virtual Adapter

   Indirizzo fisico. . . . . . . . . . . : 4A-5F-99-1A-44-C7
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì

Scheda LAN wireless Connessione alla rete locale (LAN)* 2:

   Stato supporto. . . . . . . . . . . . : Supporto disconnesso
   Suffisso DNS specifico per connessione:
   Descrizione . . . . . . . . . . . . . : Microsoft Wi-Fi Direct 
Virtual Adapter #2

   Indirizzo fisico. . . . . . . . . . . : 5A-5F-99-1A-44-C7
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì

Scheda LAN wireless Wi-Fi:

   Suffisso DNS specifico per connessione: home-life.hub
   Descrizione . . . . . . . . . . . . . : Qualcomm QCA9377 802.11ac 
Wireless Adapter

   Indirizzo fisico. . . . . . . . . . . : 48-5F-99-1A-44-C7
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì
   Indirizzo IPv6 locale rispetto al collegamento . : 
fe80::4d05:e505:5528:dfb1%17(Preferenziale)

   Indirizzo IPv4. . . . . . . . . . . . : 192.168.1.27(Preferenziale)
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Lease ottenuto. . . . . . . . . . . . : mercoledì 1 luglio 2020 10:33:11
   Scadenza lease . . . . . . . . . . .  : giovedì 2 luglio 2020 13:04:47
   Gateway predefinito . . . . . . . . . : 192.168.1.1
   Server DHCP . . . . . . . . . . . . . : 192.168.1.1
   IAID DHCPv6 . . . . . . . . .