Topics

Networking failing using openvpn

Klaus Rung
 

I have a deb 7 jessie node that has the openvpn installed. The openvpn work fine when booted and gets the 44. ip and works normally for a day or so. When the provider releases the wan ip it appears that the node cannot reconnect to get the 44 ip and the message in the log is

Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.

The resolv.conf is set up to use 1.1.1.1, the same is set up in the networking file.

Once you reboot the pc all is good again. Is there anything I should check or is there a solution to this. It only happens when using the vpn.

Klaus
ve3kr
node 7371

k9dc
 

This is probably because your DNS 1.1.1.1 is not accessible after the tunnel drops. With DNS dead, your node will not be able to lookup vpn01.irlp.net. I would suggest using your local router for DNS (not 1.1.1.1 or other outside nameserver). The reason is that your local router will always work regardless of the VPN being there or not.

I would also recommend upgrading to Debian 9 Stretch. The version of OpenVPN that comes with 9, is much more robust than Debian 7.

-k9dc

On Jun 10, 2020, at 10:14, Klaus Rung via groups.io <k_rung=yahoo.com@groups.io> wrote:

I have a deb 7 jessie node that has the openvpn installed. The openvpn work fine when booted and gets the 44. ip and works normally for a day or so. When the provider releases the wan ip it appears that the node cannot reconnect to get the 44 ip and the message in the log is

Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.

The resolv.conf is set up to use 1.1.1.1, the same is set up in the networking file.

Once you reboot the pc all is good again. Is there anything I should check or is there a solution to this. It only happens when using the vpn.

Klaus
ve3kr
node 7371

David Cameron - IRLP
 

A big problem is that the server you are showing doesn't exist any more (142.103.194.4). We need to figure out why that is also. Somewhere,  that ip is hard coded.

Sounds like openvpn is losing the gateway, and not able to recover. 

Dave Cameron 



-------- Original message --------
From: k9dc <Dave@...>
Date: 6/10/20 7:27 AM (GMT-08:00)
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] Networking failing using openvpn


This is probably because your DNS 1.1.1.1 is not accessible after the tunnel drops. With DNS dead, your node will not be able to lookup vpn01.irlp.net.  I would suggest using your local router for DNS (not 1.1.1.1 or other outside nameserver).  The reason is that your local router will always work regardless of the VPN being there or not.

I would also recommend upgrading to Debian 9 Stretch.  The version of OpenVPN that comes with 9, is much more robust than Debian 7.

-k9dc

> On Jun 10, 2020, at 10:14, Klaus Rung via groups.io <k_rung@...> wrote:
>
> I have a deb 7 jessie node that has the openvpn installed. The openvpn work fine when booted and gets the 44. ip and works normally for a day or so. When the provider releases the wan ip it appears that the node cannot reconnect to get the 44 ip and the message in the log is
>
> Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
> Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
>
> The resolv.conf is set up to use 1.1.1.1, the same is set up in the networking file.
>
> Once you reboot the pc all is good again. Is there anything I should check or is there a solution to this. It only happens when using the vpn.
>
> Klaus
> ve3kr
> node 7371






Ramon Gandia
 

On my node 3288, that IP address is hard coded into
~/scripts/ipupdate
~/scripts/bind_best_server

It seems that if there is poor connectivity, it defaults
to that IP address. With good connectivity, its not an
issue.

Was one of the reason I wanted to lengthen the timeout
value in an earlier post. However, doing so, just
covers up the problem.

--
Ramon AL7X 3288 3289 7254

On 6/10/20 6:52 AM, David Cameron - IRLP wrote:
A big problem is that the server you are showing doesn't exist any more
(142.103.194.4). We need to figure out why that is also. Somewhere,
that ip is hard coded.

Sounds like openvpn is losing the gateway, and not able to recover.

Dave Cameron



-------- Original message --------
From: k9dc <Dave@...>
Date: 6/10/20 7:27 AM (GMT-08:00)
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] Networking failing using openvpn


This is probably because your DNS 1.1.1.1 is not accessible after the
tunnel drops. With DNS dead, your node will not be able to lookup
vpn01.irlp.net.  I would suggest using your local router for DNS (not
1.1.1.1 or other outside nameserver).  The reason is that your local
router will always work regardless of the VPN being there or not.

I would also recommend upgrading to Debian 9 Stretch.  The version of
OpenVPN that comes with 9, is much more robust than Debian 7.

-k9dc

> On Jun 10, 2020, at 10:14, Klaus Rung via groups.io
<k_rung=yahoo.com@groups.io> wrote:
>
> I have a deb 7 jessie node that has the openvpn installed. The
openvpn work fine when booted and gets the 44. ip and works normally for
a day or so. When the provider releases the wan ip it appears that the
node cannot reconnect to get the 44 ip and the message in the log is
>
> Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
> Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
>
> The resolv.conf is set up to use 1.1.1.1, the same is set up in the
networking file.
>
> Once you reboot the pc all is good again. Is there anything I should
check or is there a solution to this. It only happens when using the vpn.
>
> Klaus
> ve3kr
> node 7371






David Cameron - IRLP
 

Its in a comment in ipupdate, and I recently fixed the script for the find_best_server. It will be in the next update.

I also updated the web DYNDNS timeout to 5 seconds. It is not a time critical piece, but adds delay into anything calling ipupdate if there is a DNS problem.

Those errors will still exist, but it will show a different IP (which is valid).

When the node has no internet, it will keep trying to connect, and throw errors when it doesn't connect.

David Cameron

On 2020-06-10 8:57 a.m., Ramon Gandia wrote:
On my node 3288, that IP address is hard coded into
~/scripts/ipupdate
~/scripts/bind_best_server
It seems that if there is poor connectivity, it defaults
to that IP address.  With good connectivity, its not an
issue.
Was one of the reason I wanted to lengthen the timeout
value in an earlier post.  However, doing so, just
covers up the problem.
--
Ramon AL7X 3288 3289 7254
On 6/10/20 6:52 AM, David Cameron - IRLP wrote:
A big problem is that the server you are showing doesn't exist any more
(142.103.194.4). We need to figure out why that is also. Somewhere,
that ip is hard coded.

Sounds like openvpn is losing the gateway, and not able to recover.

Dave Cameron



-------- Original message --------
From: k9dc <Dave@...>
Date: 6/10/20 7:27 AM (GMT-08:00)
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] Networking failing using openvpn


This is probably because your DNS 1.1.1.1 is not accessible after the
tunnel drops. With DNS dead, your node will not be able to lookup
vpn01.irlp.net.  I would suggest using your local router for DNS (not
1.1.1.1 or other outside nameserver).  The reason is that your local
router will always work regardless of the VPN being there or not.

I would also recommend upgrading to Debian 9 Stretch.  The version of
OpenVPN that comes with 9, is much more robust than Debian 7.

-k9dc

 > On Jun 10, 2020, at 10:14, Klaus Rung via groups.io
<k_rung=yahoo.com@groups.io> wrote:
 >
 > I have a deb 7 jessie node that has the openvpn installed. The
openvpn work fine when booted and gets the 44. ip and works normally for
a day or so. When the provider releases the wan ip it appears that the
node cannot reconnect to get the 44 ip and the message in the log is
 >
 > Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
 > Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
 > Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
 > Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
 > Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
 >
 > The resolv.conf is set up to use 1.1.1.1, the same is set up in the
networking file.
 >
 > Once you reboot the pc all is good again. Is there anything I should
check or is there a solution to this. It only happens when using the vpn.
 >
 > Klaus
 > ve3kr
 > node 7371






Klaus Rung
 

Ok thanks for the dns info to use the router dns and see if that fixes the problem.

Klaus


On Wednesday, June 10, 2020, 10:27:41 a.m. EDT, k9dc <dave@...> wrote:



This is probably because your DNS 1.1.1.1 is not accessible after the tunnel drops. With DNS dead, your node will not be able to lookup vpn01.irlp.net.  I would suggest using your local router for DNS (not 1.1.1.1 or other outside nameserver).  The reason is that your local router will always work regardless of the VPN being there or not.

I would also recommend upgrading to Debian 9 Stretch.  The version of OpenVPN that comes with 9, is much more robust than Debian 7.

-k9dc

> On Jun 10, 2020, at 10:14, Klaus Rung via groups.io <k_rung=yahoo.com@groups.io> wrote:
>
> I have a deb 7 jessie node that has the openvpn installed. The openvpn work fine when booted and gets the 44. ip and works normally for a day or so. When the provider releases the wan ip it appears that the node cannot reconnect to get the 44 ip and the message in the log is
>
> Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
> Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to server 142.103.194.4. Cant obtain current IP.
>
> The resolv.conf is set up to use 1.1.1.1, the same is set up in the networking file.
>
> Once you reboot the pc all is good again. Is there anything I should check or is there a solution to this. It only happens when using the vpn.
>
> Klaus
> ve3kr
> node 7371







Klaus Rung
 

So are you saying I should wait until the update to see if things stay working?



On Wednesday, June 10, 2020, 12:53:38 p.m. EDT, David Cameron - IRLP <dcameron@...> wrote:


Its in a comment in ipupdate, and I recently fixed the script for the
find_best_server. It will be in the next update.

I also updated the web DYNDNS timeout to 5 seconds. It is not a time
critical piece, but adds delay into anything calling ipupdate if there
is a DNS problem.

Those errors will still exist, but it will show a different IP (which is
valid).

When the node has no internet, it will keep trying to connect, and throw
errors when it doesn't connect.

David Cameron

On 2020-06-10 8:57 a.m., Ramon Gandia wrote:
> On my node 3288, that IP address is hard coded into
> ~/scripts/ipupdate
> ~/scripts/bind_best_server
>
> It seems that if there is poor connectivity, it defaults
> to that IP address.  With good connectivity, its not an
> issue.
>
> Was one of the reason I wanted to lengthen the timeout
> value in an earlier post.  However, doing so, just
> covers up the problem.
>
> --
> Ramon AL7X 3288 3289 7254
>
> On 6/10/20 6:52 AM, David Cameron - IRLP wrote:
>> A big problem is that the server you are showing doesn't exist any more
>> (142.103.194.4). We need to figure out why that is also. Somewhere,
>> that ip is hard coded.
>>
>> Sounds like openvpn is losing the gateway, and not able to recover.
>>
>> Dave Cameron
>>
>>
>>
>> -------- Original message --------
>> From: k9dc <Dave@...>
>> Date: 6/10/20 7:27 AM (GMT-08:00)
>> To: IRLP@irlp.groups.io
>> Subject: Re: [IRLP] Networking failing using openvpn
>>
>>
>> This is probably because your DNS 1.1.1.1 is not accessible after the
>> tunnel drops. With DNS dead, your node will not be able to lookup
>> vpn01.irlp.net.  I would suggest using your local router for DNS (not
>> 1.1.1.1 or other outside nameserver).  The reason is that your local
>> router will always work regardless of the VPN being there or not.
>>
>> I would also recommend upgrading to Debian 9 Stretch.  The version of
>> OpenVPN that comes with 9, is much more robust than Debian 7.
>>
>> -k9dc
>>
>>  > On Jun 10, 2020, at 10:14, Klaus Rung via groups.io
>> <k_rung=yahoo.com@groups.io> wrote:
>>  >
>>  > I have a deb 7 jessie node that has the openvpn installed. The
>> openvpn work fine when booted and gets the 44. ip and works normally for
>> a day or so. When the provider releases the wan ip it appears that the
>> node cannot reconnect to get the 44 ip and the message in the log is
>>  >
>>  > Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to server
>> 142.103.194.4. Cant obtain current IP.
>>  > Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to server
>> 142.103.194.4. Cant obtain current IP.
>>  > Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to server
>> 142.103.194.4. Cant obtain current IP.
>>  > Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
>>  > Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to server
>> 142.103.194.4. Cant obtain current IP.
>>  >
>>  > The resolv.conf is set up to use 1.1.1.1, the same is set up in the
>> networking file.
>>  >
>>  > Once you reboot the pc all is good again. Is there anything I should
>> check or is there a solution to this. It only happens when using the vpn.
>>  >
>>  > Klaus
>>  > ve3kr
>>  > node 7371
>>
>>
>>
>>
>>
>>
>>
>
>
>


David Cameron - IRLP
 

To me it is a bit of a "hang"... The VPN drops, but the gateway is not returned to the local LAN. It gets stuck on the VPN, but can not reconnect.

I think the only solution is to have an external script that tries to ping the private IP of the VPN server you are connected to, and if fails a few times in a row, then restart the VPN.

It appears to be a bug in the older openvpn, as it does not seem to recover from certain situations. You should be able to adjust some of the keepalive parameters, etc.

Dave Cameron

On 2020-06-10 9:53 a.m., Klaus Rung via groups.io wrote:
Ok thanks for the dns info to use the router dns and see if that fixes the problem.
Klaus
On Wednesday, June 10, 2020, 10:27:41 a.m. EDT, k9dc <dave@...> wrote:
This is probably because your DNS 1.1.1.1 is not accessible after the tunnel drops. With DNS dead, your node will not be able to lookup vpn01.irlp.net.  I would suggest using your local router for DNS (not 1.1.1.1 or other outside nameserver).  The reason is that your local router will always work regardless of the VPN being there or not.
I would also recommend upgrading to Debian 9 Stretch.  The version of OpenVPN that comes with 9, is much more robust than Debian 7.
-k9dc

> On Jun 10, 2020, at 10:14, Klaus Rung via groups.io
<k_rung=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:
>
> I have a deb 7 jessie node that has the openvpn installed. The
openvpn work fine when booted and gets the 44. ip and works normally for a day or so. When the provider releases the wan ip it appears that the node cannot reconnect to get the 44 ip and the message in the log is
>
> Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
> Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
> Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to server
142.103.194.4. Cant obtain current IP.
>
> The resolv.conf is set up to use 1.1.1.1, the same is set up in the
networking file.
>
> Once you reboot the pc all is good again. Is there anything I should
check or is there a solution to this. It only happens when using the vpn.
>
> Klaus
> ve3kr
> node 7371

David Cameron - IRLP
 

No, the update will have no effect on your problem. All it will do is change the IP address reported in your error.

You should update these nodes to Debian 9 at least, and then try it with the update openvpn.

Updating a Debian node in place is not overly complicated. Debian 7 is no longer supported though, so the first step is not simple. There are lots of sites online that describe the update process. Just google "update debian 7 to 9" (or 7 to 8, then 8 to 9 etc.)

David Cameron

On 2020-06-10 9:56 a.m., Klaus Rung via groups.io wrote:
So are you saying I should wait until the update to see if things stay working?
On Wednesday, June 10, 2020, 12:53:38 p.m. EDT, David Cameron - IRLP <dcameron@...> wrote:
Its in a comment in ipupdate, and I recently fixed the script for the
find_best_server. It will be in the next update.
I also updated the web DYNDNS timeout to 5 seconds. It is not a time
critical piece, but adds delay into anything calling ipupdate if there
is a DNS problem.
Those errors will still exist, but it will show a different IP (which is
valid).
When the node has no internet, it will keep trying to connect, and throw
errors when it doesn't connect.
David Cameron
On 2020-06-10 8:57 a.m., Ramon Gandia wrote:
> On my node 3288, that IP address is hard coded into
> ~/scripts/ipupdate
> ~/scripts/bind_best_server
>
> It seems that if there is poor connectivity, it defaults
> to that IP address.  With good connectivity, its not an
> issue.
>
> Was one of the reason I wanted to lengthen the timeout
> value in an earlier post.  However, doing so, just
> covers up the problem.
>
> --
> Ramon AL7X 3288 3289 7254
>
> On 6/10/20 6:52 AM, David Cameron - IRLP wrote:
>> A big problem is that the server you are showing doesn't exist any more
>> (142.103.194.4). We need to figure out why that is also. Somewhere,
>> that ip is hard coded.
>>
>> Sounds like openvpn is losing the gateway, and not able to recover.
>>
>> Dave Cameron
>>
>>
>>
>> -------- Original message --------
>> From: k9dc <Dave@... <mailto:Dave@...>>
>> Date: 6/10/20 7:27 AM (GMT-08:00)
>> To: IRLP@irlp.groups.io <mailto:IRLP@irlp.groups.io>
>> Subject: Re: [IRLP] Networking failing using openvpn
>>
>>
>> This is probably because your DNS 1.1.1.1 is not accessible after the
>> tunnel drops. With DNS dead, your node will not be able to lookup
>> vpn01.irlp.net.  I would suggest using your local router for DNS (not
>> 1.1.1.1 or other outside nameserver).  The reason is that your local
>> router will always work regardless of the VPN being there or not.
>>
>> I would also recommend upgrading to Debian 9 Stretch.  The version of
>> OpenVPN that comes with 9, is much more robust than Debian 7.
>>
>> -k9dc
>>
>>  > On Jun 10, 2020, at 10:14, Klaus Rung via groups.io
>> <k_rung=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:
>>  >
>>  > I have a deb 7 jessie node that has the openvpn installed. The
>> openvpn work fine when booted and gets the 44. ip and works normally for
>> a day or so. When the provider releases the wan ip it appears that the
>> node cannot reconnect to get the 44 ip and the message in the log is
>>  >
>>  > Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to server
>> 142.103.194.4. Cant obtain current IP.
>>  > Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to server
>> 142.103.194.4. Cant obtain current IP.
>>  > Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to server
>> 142.103.194.4. Cant obtain current IP.
>>  > Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
>>  > Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to server
>> 142.103.194.4. Cant obtain current IP.
>>  >
>>  > The resolv.conf is set up to use 1.1.1.1, the same is set up in the
>> networking file.
>>  >
>>  > Once you reboot the pc all is good again. Is there anything I should
>> check or is there a solution to this. It only happens when using the
vpn.
>>  >
>>  > Klaus
>>  > ve3kr
>>  > node 7371
>>
>>
>>
>>
>>
>>
>>
>
>
>

Klaus Rung
 

Ok thanks for the info below. I will experiment for now and see if I can get it to stop failing and if not will have to go the route you suggest.


On Wednesday, June 10, 2020, 1:01:33 p.m. EDT, David Cameron - IRLP <dcameron@...> wrote:


To me it is a bit of a "hang"... The VPN drops, but the gateway is not
returned to the local LAN. It gets stuck on the VPN, but can not reconnect.

I think the only solution is to have an external script that tries to
ping the private IP of the VPN server you are connected to, and if fails
a few times in a row, then restart the VPN.

It appears to be a bug in the older openvpn, as it does not seem to
recover from certain situations. You should be able to adjust some of
the keepalive parameters, etc.

Dave Cameron

On 2020-06-10 9:53 a.m., Klaus Rung via groups.io wrote:
> Ok thanks for the dns info to use the router dns and see if that fixes
> the problem.
>
> Klaus
>
>
> On Wednesday, June 10, 2020, 10:27:41 a.m. EDT, k9dc <dave@...> wrote:
>
>
>
> This is probably because your DNS 1.1.1.1 is not accessible after the
> tunnel drops. With DNS dead, your node will not be able to lookup
> vpn01.irlp.net.  I would suggest using your local router for DNS (not
> 1.1.1.1 or other outside nameserver).  The reason is that your local
> router will always work regardless of the VPN being there or not.
>
> I would also recommend upgrading to Debian 9 Stretch.  The version of
> OpenVPN that comes with 9, is much more robust than Debian 7.
>
> -k9dc
>
>  > On Jun 10, 2020, at 10:14, Klaus Rung via groups.io
> <k_rung=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:
>  >
>  > I have a deb 7 jessie node that has the openvpn installed. The
> openvpn work fine when booted and gets the 44. ip and works normally for
> a day or so. When the provider releases the wan ip it appears that the
> node cannot reconnect to get the 44 ip and the message in the log is
>  >
>  > Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to server
> 142.103.194.4. Cant obtain current IP.
>  > Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to server
> 142.103.194.4. Cant obtain current IP.
>  > Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to server
> 142.103.194.4. Cant obtain current IP.
>  > Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
>  > Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to server
> 142.103.194.4. Cant obtain current IP.
>  >
>  > The resolv.conf is set up to use 1.1.1.1, the same is set up in the
> networking file.
>  >
>  > Once you reboot the pc all is good again. Is there anything I should
> check or is there a solution to this. It only happens when using the vpn.
>  >
>  > Klaus
>  > ve3kr
>  > node 7371
>
>
>
>
>
>
>
>


Klaus Rung
 

If I update to the deb 9 will the audio announcements stop working on echolink and the other old scripts that are in the node like time etc? I would hate to break things worse than they are now. The reason for using the vpn service on these nodes is because of their internet connection being non routable.

On Wednesday, June 10, 2020, 1:04:26 p.m. EDT, David Cameron - IRLP <dcameron@...> wrote:


No, the update will have no effect on your problem. All it will do is
change the IP address reported in your error.

You should update these nodes to Debian 9 at least, and then try it with
the update openvpn.

Updating a Debian node in place is not overly complicated. Debian 7 is
no longer supported though, so the first step is not simple. There are
lots of sites online that describe the update process. Just google
"update debian 7 to 9" (or 7 to 8, then 8 to 9 etc.)

David Cameron

On 2020-06-10 9:56 a.m., Klaus Rung via groups.io wrote:
> So are you saying I should wait until the update to see if things stay
> working?
>
>
>
> On Wednesday, June 10, 2020, 12:53:38 p.m. EDT, David Cameron - IRLP
> <dcameron@...> wrote:
>
>
> Its in a comment in ipupdate, and I recently fixed the script for the
> find_best_server. It will be in the next update.
>
> I also updated the web DYNDNS timeout to 5 seconds. It is not a time
> critical piece, but adds delay into anything calling ipupdate if there
> is a DNS problem.
>
> Those errors will still exist, but it will show a different IP (which is
> valid).
>
> When the node has no internet, it will keep trying to connect, and throw
> errors when it doesn't connect.
>
> David Cameron
>
> On 2020-06-10 8:57 a.m., Ramon Gandia wrote:
>  > On my node 3288, that IP address is hard coded into
>  > ~/scripts/ipupdate
>  > ~/scripts/bind_best_server
>  >
>  > It seems that if there is poor connectivity, it defaults
>  > to that IP address.  With good connectivity, its not an
>  > issue.
>  >
>  > Was one of the reason I wanted to lengthen the timeout
>  > value in an earlier post.  However, doing so, just
>  > covers up the problem.
>  >
>  > --
>  > Ramon AL7X 3288 3289 7254
>  >
>  > On 6/10/20 6:52 AM, David Cameron - IRLP wrote:
>  >> A big problem is that the server you are showing doesn't exist any more
>  >> (142.103.194.4). We need to figure out why that is also. Somewhere,
>  >> that ip is hard coded.
>  >>
>  >> Sounds like openvpn is losing the gateway, and not able to recover.
>  >>
>  >> Dave Cameron
>  >>
>  >>
>  >>
>  >> -------- Original message --------
>  >> From: k9dc <Dave@... <mailto:Dave@...>>
>  >> Date: 6/10/20 7:27 AM (GMT-08:00)
>  >> To: IRLP@irlp.groups.io <mailto:IRLP@irlp.groups.io>
>  >> Subject: Re: [IRLP] Networking failing using openvpn
>  >>
>  >>
>  >> This is probably because your DNS 1.1.1.1 is not accessible after the
>  >> tunnel drops. With DNS dead, your node will not be able to lookup
>  >> vpn01.irlp.net.  I would suggest using your local router for DNS (not
>  >> 1.1.1.1 or other outside nameserver).  The reason is that your local
>  >> router will always work regardless of the VPN being there or not.
>  >>
>  >> I would also recommend upgrading to Debian 9 Stretch.  The version of
>  >> OpenVPN that comes with 9, is much more robust than Debian 7.
>  >>
>  >> -k9dc
>  >>
>  >>  > On Jun 10, 2020, at 10:14, Klaus Rung via groups.io
>  >> <k_rung=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:
>  >>  >
>  >>  > I have a deb 7 jessie node that has the openvpn installed. The
>  >> openvpn work fine when booted and gets the 44. ip and works normally for
>  >> a day or so. When the provider releases the wan ip it appears that the
>  >> node cannot reconnect to get the 44 ip and the message in the log is
>  >>  >
>  >>  > Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to server
>  >> 142.103.194.4. Cant obtain current IP.
>  >>  > Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to server
>  >> 142.103.194.4. Cant obtain current IP.
>  >>  > Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to server
>  >> 142.103.194.4. Cant obtain current IP.
>  >>  > Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
>  >>  > Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to server
>  >> 142.103.194.4. Cant obtain current IP.
>  >>  >
>  >>  > The resolv.conf is set up to use 1.1.1.1, the same is set up in the
>  >> networking file.
>  >>  >
>  >>  > Once you reboot the pc all is good again. Is there anything I should
>  >> check or is there a solution to this. It only happens when using the
> vpn.
>  >>  >
>  >>  > Klaus
>  >>  > ve3kr
>  >>  > node 7371
>  >>
>  >>
>  >>
>  >>
>  >>
>  >>
>  >>
>  >
>  >
>  >
>
>
>


wa1nvc
 

I had the same problem. Change the DNS server (resolv.conf) to be your router so the VPN client can find the VPN server when the network bounces.

I had the problem intermittently; I think the problem was whether the cache was stale. Setting resolv.conf to 192.168.1.1 (your router/gateway) fixed the problem.

BTW, Debian 9 so far appears to be more stable with the VPN client than Debian 7.

Roger
WA1NVC

--
Sent from my MS Surface

Klaus Rung
 

Ok thanks for that. I will give that a try as the node has been loosing connectivity daily sometimes and then it will go for a couple of days no problem.

Klaus
ve3kr

On Wednesday, June 10, 2020, 1:25:08 p.m. EDT, wa1nvc <wa1nvc@...> wrote:


I had the same problem.  Change the DNS server (resolv.conf) to be your
router so the VPN client can find the VPN server when the network bounces.

I had the problem intermittently; I think the problem was whether the
cache was stale.  Setting resolv.conf to 192.168.1.1 (your
router/gateway) fixed the problem.

BTW, Debian 9 so far appears to be more stable with the VPN client than
Debian 7.

Roger
WA1NVC

--
Sent from my MS Surface



k9dc
 

On Jun 10, 2020, at 13:25, wa1nvc <wa1nvc@...> wrote:
BTW, Debian 9 so far appears to be more stable with the VPN client than Debian 7.
Roger
WA1NVC
That is correct. I actually would have preferred to make IRLP VPN only work only with the newer versions BECAUSE they are more reliable. But all of the Nanonodes in the network are running Debian 7, and since Micronode International is now out of business, it is unlikely they will ever be upgraded. Probably a third of the VPNs assigned are on Nanonodes.

-k9dc

David Cameron - IRLP
 

Klaus,

Someone needs to fix the EchoIRLP scripts in the download repository and/or update the install script. I spent a lot of time to fix the broken scripts and it went nowhere. You will see my comments in the scripts.

The problem is the use of SoX (command is sox) and how it handles arguments. IRLP fixed this in 2015. There are also reasons to use aoss and aplay versus other programs and play in many cases. It happens in 5 scripts in the EchoIRLP/scripts directory:

echo_common
echo_on
echo_wavgen
echo_wavplay
wavprep

I have put a copy of all of these scripts here:

ftp://ftp.irlp.net/pub/bugfixes/Deb_EchoIRLP_scriptfix.tgz

On your node, change to the EchoIRLP scripts directory, and run:

wget ftp://ftp.irlp.net/pub/bugfixes/Deb_EchoIRLP_scriptfix.tgz
tar -zxvf Deb_EchoIRLP_scriptfix.tgz
chown repeater.repeater *
chmod 750 *

I can not help you fix it if it breaks anything.

We can not choose to run outdated software to keep hold of things that are not maintained. The solution is simple. Someone near and dear to EchoIRLP needs to take this on and fix the scripts that the installs use.

Dave Cameron
VE7LTD

On 2020-06-10 10:08 a.m., Klaus Rung via groups.io wrote:
If I update to the deb 9 will the audio announcements stop working on echolink and the other old scripts that are in the node like time etc? I would hate to break things worse than they are now. The reason for using the vpn service on these nodes is because of their internet connection being non routable.
On Wednesday, June 10, 2020, 1:04:26 p.m. EDT, David Cameron - IRLP <dcameron@...> wrote:
No, the update will have no effect on your problem. All it will do is
change the IP address reported in your error.
You should update these nodes to Debian 9 at least, and then try it with
the update openvpn.
Updating a Debian node in place is not overly complicated. Debian 7 is
no longer supported though, so the first step is not simple. There are
lots of sites online that describe the update process. Just google
"update debian 7 to 9" (or 7 to 8, then 8 to 9 etc.)
David Cameron
On 2020-06-10 9:56 a.m., Klaus Rung via groups.io wrote:
> So are you saying I should wait until the update to see if things stay
> working?
>
>
>
> On Wednesday, June 10, 2020, 12:53:38 p.m. EDT, David Cameron - IRLP
> <dcameron@... <mailto:dcameron@...>> wrote:
>
>
> Its in a comment in ipupdate, and I recently fixed the script for the
> find_best_server. It will be in the next update.
>
> I also updated the web DYNDNS timeout to 5 seconds. It is not a time
> critical piece, but adds delay into anything calling ipupdate if there
> is a DNS problem.
>
> Those errors will still exist, but it will show a different IP (which is
> valid).
>
> When the node has no internet, it will keep trying to connect, and throw
> errors when it doesn't connect.
>
> David Cameron
>
> On 2020-06-10 8:57 a.m., Ramon Gandia wrote:
>  > On my node 3288, that IP address is hard coded into
>  > ~/scripts/ipupdate
>  > ~/scripts/bind_best_server
>  >
>  > It seems that if there is poor connectivity, it defaults
>  > to that IP address.  With good connectivity, its not an
>  > issue.
>  >
>  > Was one of the reason I wanted to lengthen the timeout
>  > value in an earlier post.  However, doing so, just
>  > covers up the problem.
>  >
>  > --
>  > Ramon AL7X 3288 3289 7254
>  >
>  > On 6/10/20 6:52 AM, David Cameron - IRLP wrote:
>  >> A big problem is that the server you are showing doesn't exist
any more
>  >> (142.103.194.4). We need to figure out why that is also. Somewhere,
>  >> that ip is hard coded.
>  >>
>  >> Sounds like openvpn is losing the gateway, and not able to recover.
>  >>
>  >> Dave Cameron
>  >>
>  >>
>  >>
>  >> -------- Original message --------
>  >> From: k9dc <Dave@... <mailto:Dave@...> <mailto:Dave@...
<mailto:Dave@...>>>
>  >> Date: 6/10/20 7:27 AM (GMT-08:00)
>  >> To: IRLP@irlp.groups.io <mailto:IRLP@irlp.groups.io>
<mailto:IRLP@irlp.groups.io <mailto:IRLP@irlp.groups.io>>
>  >> Subject: Re: [IRLP] Networking failing using openvpn
>  >>
>  >>
>  >> This is probably because your DNS 1.1.1.1 is not accessible after the
>  >> tunnel drops. With DNS dead, your node will not be able to lookup
>  >> vpn01.irlp.net.  I would suggest using your local router for DNS (not
>  >> 1.1.1.1 or other outside nameserver).  The reason is that your local
>  >> router will always work regardless of the VPN being there or not.
>  >>
>  >> I would also recommend upgrading to Debian 9 Stretch.  The version of
>  >> OpenVPN that comes with 9, is much more robust than Debian 7.
>  >>
>  >> -k9dc
>  >>
>  >>  > On Jun 10, 2020, at 10:14, Klaus Rung via groups.io
>  >> <k_rung=yahoo.com@groups.io <mailto:yahoo.com@groups.io>
<mailto:yahoo.com@groups.io <mailto:yahoo.com@groups.io>>> wrote:
>  >>  >
>  >>  > I have a deb 7 jessie node that has the openvpn installed. The
>  >> openvpn work fine when booted and gets the 44. ip and works
normally for
>  >> a day or so. When the provider releases the wan ip it appears
that the
>  >> node cannot reconnect to get the 44 ip and the message in the log is
>  >>  >
>  >>  > Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to
server
>  >> 142.103.194.4. Cant obtain current IP.
>  >>  > Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to
server
>  >> 142.103.194.4. Cant obtain current IP.
>  >>  > Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to
server
>  >> 142.103.194.4. Cant obtain current IP.
>  >>  > Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
>  >>  > Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to
server
>  >> 142.103.194.4. Cant obtain current IP.
>  >>  >
>  >>  > The resolv.conf is set up to use 1.1.1.1, the same is set up
in the
>  >> networking file.
>  >>  >
>  >>  > Once you reboot the pc all is good again. Is there anything I
should
>  >> check or is there a solution to this. It only happens when using the
> vpn.
>  >>  >
>  >>  > Klaus
>  >>  > ve3kr
>  >>  > node 7371
>  >>
>  >>
>  >>
>  >>
>  >>
>  >>
>  >>
>  >
>  >
>  >
>
>
>

Klaus Rung
 

Thanks for this help Dave with your fixes. I am sorry to see that nobody is taking up the upkeep of the EchoIRLP scripts as it was very handy to have both systems available on the same pc and the echolink side gets the reliability of irlp and the same standards the irlp side had. It is very handy to be able to call into the home repeater using the echolink app on your phone when you cannot use a radio but have internet like during a trip or no node available in the area.

On Wednesday, June 10, 2020, 2:08:10 p.m. EDT, David Cameron - IRLP <dcameron@...> wrote:


Klaus,

Someone needs to fix the EchoIRLP scripts in the download repository
and/or update the install script. I spent a lot of time to fix the
broken scripts and it went nowhere. You will see my comments in the scripts.

The problem is the use of SoX (command is sox) and how it handles
arguments. IRLP fixed this in 2015. There are also reasons to use aoss
and aplay versus other programs and play in many cases. It happens in 5
scripts in the EchoIRLP/scripts directory:

echo_common
echo_on
echo_wavgen
echo_wavplay
wavprep

I have put a copy of all of these scripts here:

ftp://ftp.irlp.net/pub/bugfixes/Deb_EchoIRLP_scriptfix.tgz

On your node, change to the EchoIRLP scripts directory, and run:

wget  ftp://ftp.irlp.net/pub/bugfixes/Deb_EchoIRLP_scriptfix.tgz
tar  -zxvf  Deb_EchoIRLP_scriptfix.tgz
chown  repeater.repeater  *
chmod  750  *

I can not help you fix it if it breaks anything.

We can not choose to run outdated software to keep hold of things that
are not maintained. The solution is simple. Someone near and dear to
EchoIRLP needs to take this on and fix the scripts that the installs use.

Dave Cameron
VE7LTD

On 2020-06-10 10:08 a.m., Klaus Rung via groups.io wrote:
> If I update to the deb 9 will the audio announcements stop working on
> echolink and the other old scripts that are in the node like time etc? I
> would hate to break things worse than they are now. The reason for using
> the vpn service on these nodes is because of their internet connection
> being non routable.
>
> On Wednesday, June 10, 2020, 1:04:26 p.m. EDT, David Cameron - IRLP
> <dcameron@...> wrote:
>
>
> No, the update will have no effect on your problem. All it will do is
> change the IP address reported in your error.
>
> You should update these nodes to Debian 9 at least, and then try it with
> the update openvpn.
>
> Updating a Debian node in place is not overly complicated. Debian 7 is
> no longer supported though, so the first step is not simple. There are
> lots of sites online that describe the update process. Just google
> "update debian 7 to 9" (or 7 to 8, then 8 to 9 etc.)
>
> David Cameron
>
> On 2020-06-10 9:56 a.m., Klaus Rung via groups.io wrote:
>  > So are you saying I should wait until the update to see if things stay
>  > working?
>  >
>  >
>  >
>  > On Wednesday, June 10, 2020, 12:53:38 p.m. EDT, David Cameron - IRLP
>  > <dcameron@... <mailto:dcameron@...>> wrote:
>  >
>  >
>  > Its in a comment in ipupdate, and I recently fixed the script for the
>  > find_best_server. It will be in the next update.
>  >
>  > I also updated the web DYNDNS timeout to 5 seconds. It is not a time
>  > critical piece, but adds delay into anything calling ipupdate if there
>  > is a DNS problem.
>  >
>  > Those errors will still exist, but it will show a different IP (which is
>  > valid).
>  >
>  > When the node has no internet, it will keep trying to connect, and throw
>  > errors when it doesn't connect.
>  >
>  > David Cameron
>  >
>  > On 2020-06-10 8:57 a.m., Ramon Gandia wrote:
>  >  > On my node 3288, that IP address is hard coded into
>  >  > ~/scripts/ipupdate
>  >  > ~/scripts/bind_best_server
>  >  >
>  >  > It seems that if there is poor connectivity, it defaults
>  >  > to that IP address.  With good connectivity, its not an
>  >  > issue.
>  >  >
>  >  > Was one of the reason I wanted to lengthen the timeout
>  >  > value in an earlier post.  However, doing so, just
>  >  > covers up the problem.
>  >  >
>  >  > --
>  >  > Ramon AL7X 3288 3289 7254
>  >  >
>  >  > On 6/10/20 6:52 AM, David Cameron - IRLP wrote:
>  >  >> A big problem is that the server you are showing doesn't exist
> any more
>  >  >> (142.103.194.4). We need to figure out why that is also. Somewhere,
>  >  >> that ip is hard coded.
>  >  >>
>  >  >> Sounds like openvpn is losing the gateway, and not able to recover.
>  >  >>
>  >  >> Dave Cameron
>  >  >>
>  >  >>
>  >  >>
>  >  >> -------- Original message --------
>  >  >> From: k9dc <Dave@... <mailto:Dave@...> <mailto:Dave@...
> <mailto:Dave@...>>>
>  >  >> Date: 6/10/20 7:27 AM (GMT-08:00)
>  >  >> To: IRLP@irlp.groups.io <mailto:IRLP@irlp.groups.io>
> <mailto:IRLP@irlp.groups.io <mailto:IRLP@irlp.groups.io>>
>  >  >> Subject: Re: [IRLP] Networking failing using openvpn
>  >  >>
>  >  >>
>  >  >> This is probably because your DNS 1.1.1.1 is not accessible after the
>  >  >> tunnel drops. With DNS dead, your node will not be able to lookup
>  >  >> vpn01.irlp.net.  I would suggest using your local router for DNS (not
>  >  >> 1.1.1.1 or other outside nameserver).  The reason is that your local
>  >  >> router will always work regardless of the VPN being there or not.
>  >  >>
>  >  >> I would also recommend upgrading to Debian 9 Stretch.  The version of
>  >  >> OpenVPN that comes with 9, is much more robust than Debian 7.
>  >  >>
>  >  >> -k9dc
>  >  >>
>  >  >>  > On Jun 10, 2020, at 10:14, Klaus Rung via groups.io
>  >  >> <k_rung=yahoo.com@groups.io <mailto:yahoo.com@groups.io>
> <mailto:yahoo.com@groups.io <mailto:yahoo.com@groups.io>>> wrote:
>  >  >>  >
>  >  >>  > I have a deb 7 jessie node that has the openvpn installed. The
>  >  >> openvpn work fine when booted and gets the 44. ip and works
> normally for
>  >  >> a day or so. When the provider releases the wan ip it appears
> that the
>  >  >> node cannot reconnect to get the 44 ip and the message in the log is
>  >  >>  >
>  >  >>  > Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  > Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  > Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  > Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
>  >  >>  > Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  >
>  >  >>  > The resolv.conf is set up to use 1.1.1.1, the same is set up
> in the
>  >  >> networking file.
>  >  >>  >
>  >  >>  > Once you reboot the pc all is good again. Is there anything I
> should
>  >  >> check or is there a solution to this. It only happens when using the
>  > vpn.
>  >  >>  >
>  >  >>  > Klaus
>  >  >>  > ve3kr
>  >  >>  > node 7371
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >
>  >  >
>  >  >
>  >
>  >
>  >
>
>
>


Ramon Gandia
 

Some ISPS do not handle the 1.x.x.x DNS correctly. Historically,
AT&T used the 1.x.x.x network for themselves even if IANA had
not assigned it to them.

That was fixed not too long ago, but some ISPs have wrong routing
table.

The gooble DNS's 8.8.8.8 seem to always work. Try that, if the
problem goes away, then its a routing issue with the 1.x.x.x
network.

--
Ramon AL7X 3288 3289 7254

On 6/10/20 8:53 AM, Klaus Rung via groups.io wrote:
Ok thanks for the dns info to use the router dns and see if that fixes the problem.
Klaus

k9dc
 

Yes, it is a routing issue, in that 1.1.1.1 needs the VPN to work. But so does 8.8.8.8 or any other address not on your network. The local router will always be accessible, even if the VPN dies.

-k9dc

On Jun 10, 2020, at 15:41, Ramon Gandia <rfg8io@...> wrote:

Some ISPS do not handle the 1.x.x.x DNS correctly. Historically,
AT&T used the 1.x.x.x network for themselves even if IANA had
not assigned it to them.

That was fixed not too long ago, but some ISPs have wrong routing
table.

The gooble DNS's 8.8.8.8 seem to always work. Try that, if the
problem goes away, then its a routing issue with the 1.x.x.x
network.

--
Ramon AL7X 3288 3289 7254
On 6/10/20 8:53 AM, Klaus Rung via groups.io wrote:
Ok thanks for the dns info to use the router dns and see if that fixes the problem.
Klaus

Klaus Rung
 

Thanks for that hint, and another thing I can try.


On Wednesday, June 10, 2020, 3:42:20 p.m. EDT, Ramon Gandia <rfg8io@...> wrote:


Some ISPS do not handle the 1.x.x.x DNS correctly.  Historically,
AT&T used the 1.x.x.x network for themselves even if IANA had
not assigned it to them.

That was fixed not too long ago, but some ISPs have wrong routing
table.

The gooble DNS's 8.8.8.8 seem to always work.  Try that, if the
problem goes away, then its a routing issue with the 1.x.x.x
network.

--
Ramon AL7X 3288 3289 7254
On 6/10/20 8:53 AM, Klaus Rung via groups.io wrote:
> Ok thanks for the dns info to use the router dns and see if that fixes
> the problem.
>
> Klaus




Klaus Rung
 

I set it to use the local router and will watch it over the next few days..

On Wednesday, June 10, 2020, 4:49:10 p.m. EDT, k9dc <dave@...> wrote:



Yes, it is a routing issue, in that 1.1.1.1 needs the VPN to work. But so does 8.8.8.8 or any other address not on your network. The local router will always be accessible, even if the VPN dies.

-k9dc


> On Jun 10, 2020, at 15:41, Ramon Gandia <rfg8io@...> wrote:
>
> Some ISPS do not handle the 1.x.x.x DNS correctly.  Historically,
> AT&T used the 1.x.x.x network for themselves even if IANA had
> not assigned it to them.
>
> That was fixed not too long ago, but some ISPs have wrong routing
> table.
>
> The gooble DNS's 8.8.8.8 seem to always work.  Try that, if the
> problem goes away, then its a routing issue with the 1.x.x.x
> network.
>
> --
> Ramon AL7X 3288 3289 7254
> On 6/10/20 8:53 AM, Klaus Rung via groups.io wrote:
>> Ok thanks for the dns info to use the router dns and see if that fixes the problem.
>> Klaus