<div dir="ltr"><div>I was assuming that sudo would run openvpn with adequate permissions</div><div><br></div><div>Running from a root login results in the same output (specific details x'd out):</div><div><br></div><div># openvpn --config /etc/openvpn/client.ovpn<br>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<br>Sat Apr 11 12:57:44 2020 library versions: OpenSSL 1.1.1  11 Sep 2018, LZO 2.08<br>Enter Auth Username: xxxxxx<br>Enter Auth Password: ********<br>Sat Apr 11 12:57:54 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194<br>Sat Apr 11 12:57:54 2020 UDP link local: (not bound)<br>Sat Apr 11 12:57:54 2020 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1194<br>Sat Apr 11 12:57:54 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this<br>Sat Apr 11 12:57:54 2020 [DSL-AC68U] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1194<br>Sat Apr 11 12:57:55 2020 TUN/TAP device tap0 opened<br>Sat Apr 11 12:57:55 2020 Initialization Sequence Completed<br>Sat Apr 11 12:58:56 2020 [DSL-AC68U] Inactivity timeout (--ping-restart), restarting<br>Sat Apr 11 12:58:56 2020 SIGUSR1[soft,ping-restart] received, process restarting<br>Sat Apr 11 12:58:56 2020 SIGUSR1[soft,ping-restart] received, process restarting<br>Sat Apr 11 12:59:01 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194<br>Sat Apr 11 12:59:01 2020 UDP link local: (not bound)<br>Sat Apr 11 12:59:01 2020 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1194<br>Sat Apr 11 12:59:01 2020 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1582', remote='link-mtu 1602'<br>Sat Apr 11 12:59:01 2020 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-GCM', remote='cipher AES-256-CBC'<br>Sat Apr 11 12:59:01 2020 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'<br>Sat Apr 11 12:59:01 2020 [DSL-AC68U] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1194<br>Sat Apr 11 12:59:02 2020 TUN/TAP device tap0 opened<br>Sat Apr 11 12:59:02 2020 Initialization Sequence Completed<br>Sat Apr 11 13:00:02 2020 [DSL-AC68U] Inactivity timeout (--ping-restart), restarting<br></div><div><br></div><div><br></div><div>No sign of tap0 using ifconfig.</div><div><br></div><div>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.<br></div><div><br></div><div>K.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 11 Apr 2020 at 12:16, Ian Kent <<a href="mailto:raven@themaw.net">raven@themaw.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 2020-04-11 at 09:58 +0800, Kevin Shackleton wrote:<br>
> Hi All,<br>
> <br>
> We managed to set up an openvpn solution, using an ASUS DSL-AC68U<br>
> router.  This runs what looks like a slightly customised DD-WRT<br>
> firmware.<br>
> <br>
> Setting up openvpn on the router and setting up openvpn client on<br>
> Windows hosts are straightforward tasks.<br>
> <br>
> I'm having trouble getting openvpn to work in Ubuntu 18.04.  To set<br>
> up a client using the Network Manager dialogs I could not simply<br>
> refer to the config file that the router generated, but had to write<br>
> out the ca cert, the user cert and the user private key as separate<br>
> files.  Regardless of if I use Network Manager or the command line<br>
> <br>
>    sudo openvpn --config /etc/openvpn/client.ovpn<br>
> <br>
> I'm running into this error in syslog:<br>
> <br>
>    link_config: autonegotiation is unset or enabled, the speed and<br>
> duplex are not writable.<br>
<br>
Permission vs. ownership perhaps?<br>
<br>
> <br>
> According to the syslog, the openvpn command line actually uses<br>
> NetworkManager, so it's not surprising they both fail.<br>
<br>
That doesn't sound right but I haven't looked myself, when I was<br>
trying to get a VPN going under Ubuntu just recently I used the<br>
NetworkManager interface ... it was a matter of translating ovpn<br>
to the NM dialog settings, not really that straight forward ...<br>
but it did work for me.<br>
<br>
> <br>
> Any ideas about autonegotiation not being writable?  I'm thinking<br>
> that perhaps a scratch folder has not been created?<br>
<br>
Does the same thing happen when using NetworkManager?<br>
sudo might not be the right thing to use for this.<br>
<br>
I'd try su'ing to root proper and see if that helps.<br>
<br>
Ian<br>
> <br>
> Thanks,<br>
> <br>
> Kevin.<br>
> <br>
> On Sat, 28 Mar 2020 at 18:58, Kevin Shackleton <<br>
> <a href="mailto:krshackleton@gmail.com" target="_blank">krshackleton@gmail.com</a>> wrote:<br>
> > Hi All,<br>
> > <br>
> > We are, like many businesses, working from home as much as possible<br>
> > - I have not been in-office for the last fortnight.<br>
> > <br>
> > Up to this time we have not bothered with an office router that<br>
> > "does a VPN".  Now a need has arisen and the business owner bought<br>
> > a D-Link DIR-895L/R, connected to our NBN modem.  This device<br>
> > offers "QuickVPN", using a pre-shared key.  As a router it's<br>
> > working fine (though it lacks SIP, we will add on a Cisco ATA)<br>
> > <br>
> > So far we have not been able to make the VPN gateway work, from<br>
> > Windows or Linux clients.  We're getting authentication failures,<br>
> > though we have tried all sorts of combinations of protocols.<br>
> > <br>
> > I'm interested in ideas and words of experience on the subject:<br>
> >  - any chance the modem is affecting the VPN?<br>
> >  - comments on the selected device (is anyone using "QuickVPN"?)<br>
> > and recommended alternative devices<br>
> >  - comments on re-flashing the device to DD-WRT which D-Links says<br>
> > is supported.  My main concern with a re-flashing is that the wi-fi <br>
> > may lose some of its capabilities - not really a big worry.<br>
> >  - thoughts about if a VPN using a PSK is really adequate these<br>
> > days, or if we should not re-flash and start using openVPN with<br>
> > large certificates<br>
> > <br>
> > Regards,<br>
> > Kevin.<br>
> > <br>
> <br>
> _______________________________________________<br>
> PLUG discussion list: <a href="mailto:plug@plug.org.au" target="_blank">plug@plug.org.au</a><br>
> <a href="http://lists.plug.org.au/mailman/listinfo/plug" rel="noreferrer" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
> Committee e-mail: <a href="mailto:committee@plug.org.au" target="_blank">committee@plug.org.au</a><br>
> PLUG Membership: <a href="http://www.plug.org.au/membership" rel="noreferrer" target="_blank">http://www.plug.org.au/membership</a><br>
<br>
</blockquote></div>