[plug] Working from home - VPN routers

Sat Apr 11 13:18:29 AWST 2020

I was assuming that sudo would run openvpn with adequate permissions

Running from a root login results in the same output (specific details x'd
out):

# openvpn --config /etc/openvpn/client.ovpn
Sat Apr 11 12:57:44 2020 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)]
[LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Sat Apr 11 12:57:44 2020 library versions: OpenSSL 1.1.1  11 Sep 2018, LZO
2.08
Enter Auth Username: xxxxxx
Enter Auth Password: ********
Sat Apr 11 12:57:54 2020 TCP/UDP: Preserving recently used remote address:
[AF_INET]xxx.xxx.xxx.xxx:1194
Sat Apr 11 12:57:54 2020 UDP link local: (not bound)
Sat Apr 11 12:57:54 2020 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Sat Apr 11 12:57:54 2020 WARNING: this configuration may cache passwords in
memory -- use the auth-nocache option to prevent this
Sat Apr 11 12:57:54 2020 [DSL-AC68U] Peer Connection Initiated with
[AF_INET]xxx.xxx.xxx.xxx:1194
Sat Apr 11 12:57:55 2020 TUN/TAP device tap0 opened
Sat Apr 11 12:57:55 2020 Initialization Sequence Completed
Sat Apr 11 12:58:56 2020 [DSL-AC68U] Inactivity timeout (--ping-restart),
restarting
Sat Apr 11 12:58:56 2020 SIGUSR1[soft,ping-restart] received, process
restarting
Sat Apr 11 12:58:56 2020 SIGUSR1[soft,ping-restart] received, process
restarting
Sat Apr 11 12:59:01 2020 TCP/UDP: Preserving recently used remote address:
[AF_INET]xxx.xxx.xxx.xxx:1194
Sat Apr 11 12:59:01 2020 UDP link local: (not bound)
Sat Apr 11 12:59:01 2020 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Sat Apr 11 12:59:01 2020 WARNING: 'link-mtu' is used inconsistently,
local='link-mtu 1582', remote='link-mtu 1602'
Sat Apr 11 12:59:01 2020 WARNING: 'cipher' is used inconsistently,
local='cipher AES-256-GCM', remote='cipher AES-256-CBC'
Sat Apr 11 12:59:01 2020 WARNING: 'auth' is used inconsistently,
local='auth [null-digest]', remote='auth SHA256'
Sat Apr 11 12:59:01 2020 [DSL-AC68U] Peer Connection Initiated with
[AF_INET]xxx.xxx.xxx.xxx:1194
Sat Apr 11 12:59:02 2020 TUN/TAP device tap0 opened
Sat Apr 11 12:59:02 2020 Initialization Sequence Completed
Sat Apr 11 13:00:02 2020 [DSL-AC68U] Inactivity timeout (--ping-restart),
restarting

No sign of tap0 using ifconfig.

Interesting that using the config file made by the router raises three
warnings.  In trying to start the vpn through the network manager I have
addresses these but am left with the autonegotiation problem.

K.

On Sat, 11 Apr 2020 at 12:16, Ian Kent <raven at themaw.net> wrote:

> On Sat, 2020-04-11 at 09:58 +0800, Kevin Shackleton wrote:
> > Hi All,
> >
> > We managed to set up an openvpn solution, using an ASUS DSL-AC68U
> > router.  This runs what looks like a slightly customised DD-WRT
> > firmware.
> >
> > Setting up openvpn on the router and setting up openvpn client on
> > Windows hosts are straightforward tasks.
> >
> > I'm having trouble getting openvpn to work in Ubuntu 18.04.  To set
> > up a client using the Network Manager dialogs I could not simply
> > refer to the config file that the router generated, but had to write
> > out the ca cert, the user cert and the user private key as separate
> > files.  Regardless of if I use Network Manager or the command line
> >
> >    sudo openvpn --config /etc/openvpn/client.ovpn
> >
> > I'm running into this error in syslog:
> >
> >    link_config: autonegotiation is unset or enabled, the speed and
> > duplex are not writable.
>
> Permission vs. ownership perhaps?
>
> >
> > According to the syslog, the openvpn command line actually uses
> > NetworkManager, so it's not surprising they both fail.
>
> That doesn't sound right but I haven't looked myself, when I was
> trying to get a VPN going under Ubuntu just recently I used the
> NetworkManager interface ... it was a matter of translating ovpn
> to the NM dialog settings, not really that straight forward ...
> but it did work for me.
>
> >
> > Any ideas about autonegotiation not being writable?  I'm thinking
> > that perhaps a scratch folder has not been created?
>
> Does the same thing happen when using NetworkManager?
> sudo might not be the right thing to use for this.
>
> I'd try su'ing to root proper and see if that helps.
>
> Ian
> >
> > Thanks,
> >
> > Kevin.
> >
> > On Sat, 28 Mar 2020 at 18:58, Kevin Shackleton <
> > krshackleton at gmail.com> wrote:
> > > Hi All,
> > >
> > > We are, like many businesses, working from home as much as possible
> > > - I have not been in-office for the last fortnight.
> > >
> > > Up to this time we have not bothered with an office router that
> > > "does a VPN".  Now a need has arisen and the business owner bought
> > > a D-Link DIR-895L/R, connected to our NBN modem.  This device
> > > offers "QuickVPN", using a pre-shared key.  As a router it's
> > > working fine (though it lacks SIP, we will add on a Cisco ATA)
> > >
> > > So far we have not been able to make the VPN gateway work, from
> > > Windows or Linux clients.  We're getting authentication failures,
> > > though we have tried all sorts of combinations of protocols.
> > >
> > > I'm interested in ideas and words of experience on the subject:
> > >  - any chance the modem is affecting the VPN?
> > >  - comments on the selected device (is anyone using "QuickVPN"?)
> > > and recommended alternative devices
> > >  - comments on re-flashing the device to DD-WRT which D-Links says
> > > is supported.  My main concern with a re-flashing is that the wi-fi
> > > may lose some of its capabilities - not really a big worry.
> > >  - thoughts about if a VPN using a PSK is really adequate these
> > > days, or if we should not re-flash and start using openVPN with
> > > large certificates
> > >
> > > Regards,
> > > Kevin.
> > >
> >
> > _______________________________________________
> > PLUG discussion list: plug at plug.org.au
> > http://lists.plug.org.au/mailman/listinfo/plug
> > Committee e-mail: committee at plug.org.au
> > PLUG Membership: http://www.plug.org.au/membership
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20200411/ea49e7c2/attachment.html>