Topics

Networking failing using openvpn


David Cameron - IRLP
 

Caution with a blanket statement to use the router as the DNS. Not ALL routers have DNS forwarders, and they might not be active.

You can set multiple DNS servers in the /etc/resolv.conf file. I suggest using your router and one of 1.1.1.1, 1.0.0.1, 4.4.2.2, 8.8.8.8. Each one on a new line

nameserver 192.168.1.1
nameserver 1.0.0.1
nameserver 4.4.2.2

I know that some "paygates" on wifi hotspots used to use 1.1.1.1 as a local address. It causes a number of problems.

Dave Cameron

On 2020-06-10 1:48 p.m., k9dc 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


David McAnally
 

These changes are now applied to my github repository <https://github.com/wd5m/echoirlp> for new installs. Thank you Dave Cameron! I should have done this long ago.

David M.
WD5M


On Wed, Jun 10, 2020 at 1:07 PM 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
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >
>  >  >
>  >  >
>  >
>  >
>  >
>
>
>




 

On 11/06/20 03:01, David Cameron - IRLP 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.
Yes, older versions of OpenVPN do seem to get into a state where the
tunnel appears to be "up", but it can't pass traffic.  I have an old
OpenVPN router here, and I manage this with a cron job that runs ever
minute.  First it checks for connectivity using ping.  If connectivity
fails, then it kills the active OpenVPN process, waits 30 seconds and
restarts OpenVPN.  As a result, I've had a reliable tunnel for years.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


 

On 11/06/20 04:07, David Cameron - IRLP 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:
Thanks Dave, I've got a copy, will have a look.  There's a couple of us
talking about some updates.  I'm not yet in a position to take this on,
but I will take a look.   First step might be making a GitHub repository
(if there isn't already one) then learning how to use it. :)

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


 

On 11/06/20 07:58, David McAnally wrote:
These changes are now applied to my github repository <https://github.com/wd5m/echoirlp> for new installs. Thank you Dave Cameron! I should have done this long ago.
Thanks David.    I thought there was a GitHub out there somewhere, saves me creating one. :)


-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com