NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

OpenVPN not working out of the box on 9068 with 2014.1

Hello,

I'm running 2014.1 on my cRIO 9068 device, and Id like to get OpenVPN up and running.  I have a known good .opvn, .key, and .p12 files (tested on Windows machine), and the server is configured and running correctly (multiple machines have been able to connect).

I believe the issue is not my configuration, but the default install of 2014.1 missing a binary file.  My output:

<code>

<REDACTED>@<REDACTED>4:/etc/openvpn/<REDACTED># openvpn --config <REDACTED>.ovpn

Mon Feb 16 05:12:57 2015 OpenVPN 2.3.2 arm-nilrt-linux-gnueabi [SSL (OpenSSL)] [LZO] [EPOLL] [eurephia] [MH] [IPv6] built on Oct  2 2014

Enter Auth Username:tstar

Enter Auth Password:

Mon Feb 16 05:13:10 2015 WARNING: file '<REDACTED>.p12' is group or others accessible

Mon Feb 16 05:13:10 2015 WARNING: file '<REDACTED>-tls.key' is group or others accessible

Mon Feb 16 05:13:10 2015 Control Channel Authentication: using '<REDACTED>-tls.key' as a OpenVPN static key file

Mon Feb 16 05:13:10 2015 UDPv4 link local (bound): [undef]

Mon Feb 16 05:13:10 2015 UDPv4 link remote: [AF_INET]<REDACTED_IP_ADDRESS>

Mon Feb 16 05:13:10 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

Mon Feb 16 05:13:12 2015 [VPN Dev Server Cert] Peer Connection Initiated with [AF_INET]<REDACTED_IP_ADDRESS>

Mon Feb 16 05:13:14 2015 TUN/TAP device tun0 opened

Mon Feb 16 05:13:14 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0

Mon Feb 16 05:13:14 2015 /sbin/ip link set dev tun0 up mtu 1500

Mon Feb 16 05:13:14 2015 Linux ip link set failed: could not execute external program

Mon Feb 16 05:13:14 2015 Exiting due to fatal error

</code>

The binary file /sbin/ip is missing from the install.

What opkg package do I need to install to get this working?  And, additionally, if NI is officially recommending openvpn as the VPN solution (which by default comes installed on the Linux install), why doesn't it work out of the box?

Thanks,

-TD

0 Kudos
Message 1 of 14
(8,125 Views)

Answering my own question:

It appears that the route2 package installed by NI installs the ip binary to /sbin/ip.route2 rather than /sbin/ip.  Creating a symbolic link did the trick:

    # cd /sbin

    # ln -s ip.route2 ip

This isn't the first time that missing sym links, or "incorrectly" named files have burned me on the real-time linux install.  Is there a document somewhere that explains the rational for not using traditional names for things, and/or the look up table to what other linux distrobutions call files compared to what NI is calling them?

Thanks,

-TD

0 Kudos
Message 2 of 14
(4,606 Views)

Many linux distributions will have more than one provider of a particular utility, and they are not always 100% compatible. This is where the name_of_utility<dot>name_of_package naming scheme came into play, and there is a notion of selecting the default implementation to use (which will create the symlink to the name_of_utility filename).

Now, a quick check of a 2014 install seems to indicated that the issue is the default-selection mechanism simply creates the symlink in a different location on $PATH, namely /bin/ip. This change happens in the OpenEmbedded build component, specifically with this change. So, in 2014, we see this change land and the location of the alternative link change.

0 Kudos
Message 3 of 14
(4,606 Views)

Thanks for doing the research there Brad, I appreaciate it.  I do agree with everything you wrote, however I'm still confused as to why the sym-link wasn't shipped with 2014.1?  If the openvpn software was shipped with 2014.1, I would expect it to work without creating symlinks thats all.

Thanks again for the clarification.

-TD

0 Kudos
Message 4 of 14
(4,606 Views)

tduffy,

That's a fine question that I don't have the answer to.

0 Kudos
Message 5 of 14
(4,606 Views)

tduffy wrote:

# openvpn --config

Believe it or not, this is the problem: the system is not configured for openvpn to be run "bare" like this from the command line. Instead, use the /usr/sbin/vpnctl shell script as, e.g., `vpnctl start`.

The biggest reason why we have it structured this way (including why iproute2 is installed the way it is) is that vpnctl implements unprivileged execution of the openvpn daemon: it runs as the "openvpn" user, not admin. This is a small but significant improvement in system security, and is a supported OpenVPN configuration, but it's not easy to get right out of the box, so vpnctl takes care of most of the details.

In particular, iproute2 needs to be run directly by (unprivilged) OpenVPN, and the way that we have accomplished this is by creating a copy of iproute2 (/usr/lib/iproute2-openvpn/ip), making it only executable by the openvpn account, then making it setuid.

You can continue to run OpenVPN in the way you have configured it, but there are other good reasons, besides privilege restriction, why you ought to get it working through vpnctl instead:

  • vpnctl is run on startup, cf. /etc/rcS.d/S42vpn. So once `vpnctl start` works, you get automated startup for free, you don't need to worry about .pid file management, start-stop-services, etc.
  • All of that is also implemented in safe mode. That is, vpnctl is the only way to get OpenVPN working in safemode.
  • System formatting and imaging are aware of the configuration file paths vpnctl expects, such that they will honor preservation/application/reset of network settings. Here's a fun and TOTALLY UNSUPPORTED AND WILL PROBABLY NOT WORK AND DO NOT RELY ON THIS FOR PRODUCTION SYSTEMS WITHOUT TALKING TO US parlor trick you can try when you get vpnctl working: Hardcode lladdr in your client.conf. Reformat while preserving all network settings. Hey, look at that! The target's still on the VPN after the reformat!

And, additionally, if NI is officially recommending openvpn as the VPN solution

NI does not recommend or support any VPN solution on NI Linux RT targets. While OpenVPN happens to be the only VPN solution present, I would characterize our level of support of it as being slightly above "you break it, you buy it". We do try to make sure it works once every release though.

You have probably guessed this already, but we (NI) are desperately trying to have our cake and eat it too. Do you recall where you heard openvpn as being officially recommended?

Message 6 of 14
(4,606 Views)

Richard,

These are the kinds of forum posts I love the most .

It looks to me, after some digging, that the openvpn configuration file needs to be called client.conf, and exist within the /etc/natinst/share/openvpn directory (which does not exist on a fresh install).  The config file, as well as any additional files, must be owned by the openvpn.openvpn user ( thank you VERY much for the verbose debug output! ).

    # mkdir /etc/natinst/share/openvpn

    # cd /etc/natinst/share

    # chown openvpn:openvpn ./openvpn

    <copy all your files into /etc/natinst/share/openvpn>

    # chown openvpn:openvpn ./*

So after doing the above, i get some wonky errors that I did not get when just calling my configuration file from the CLI command, specificly:

Feb 16 11:47:10 <REDACTED> openvpn[737]: WARNING: 'dev-type' is used inconsistently, local='dev-type tap', remote='dev-type tun'

Feb 16 11:47:10 <REDACTED> openvpn[737]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1590', remote='link-mtu 1558'

Feb 16 11:47:10 <REDACTED> openvpn[737]: WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'

Feb 16 11:47:10 <REDACTED> openvpn[737]: [VPN Dev Server Cert] Peer Connection Initiated with [AF_INET]<REDACTED_IP_ADDRESS>:<REDACTED_PORT_NUMBER>

Feb 16 11:47:12 <REDACTED> openvpn[737]: WARNING: Since you are using --dev tap, the second argument to --ifconfig must be a netmask, for example something like 255.255.255.0. (silence this warning with --ifconfig-nowarn)

Feb 16 11:47:12 <REDACTED> openvpn[737]: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options

Feb 16 11:47:12 <REDACTED> openvpn[737]: OpenVPN ROUTE: failed to parse/resolve route for host/network: <REDACTED_IP_ADDRESS>

Feb 16 11:47:12 <REDACTED> openvpn[737]: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options

Feb 16 11:47:12 <REDACTED> openvpn[737]: OpenVPN ROUTE: failed to parse/resolve route for host/network: <REDACTED_IP_ADDRESS>

Feb 16 11:47:12 <REDACTED> openvpn[737]: ERROR: Cannot ioctl TUNSETIFF tapvpn0: Operation not permitted (errno=1)

Feb 16 11:47:12 <REDACTED> openvpn[737]: Exiting due to fatal error

After looking at the /usr/sbin/vpnctl script, it looks like the openvpn call is hard-coded to tap.  We are using tun ... so I had to remove that from the script (which makes me not feel so good, since I can only assume this file is overwritten on format ...).

Additionally, it looks like the ERROR above is a permissions thing?

Any chance you could shed some light on what I may be doing wrong?  My openvpn config below:

dev tap

persist-tun

persist-key

cipher AES-128-CBC

auth SHA1

tls-client

client

resolv-retry infinite

remote <REDACTED_IP_ADDRESS> <REDACTED_PORT_NUMBER> udp

lport 0

verify-x509-name "<REDACTED_CERT_NAME>" name

auth-user-pass

pkcs12 client.p12

tls-auth client-tls.key 1

ns-cert-type server

comp-lzo

Richard, thank you again for your reply.  Additionally, where is all of this documented for me to review?

Thanks,

-TD

0 Kudos
Message 7 of 14
(4,606 Views)

Ahh, and to answer your other question about OpenVPN, it was discussed openly at NI Week as the perfered vpn client for the cRIO-9068 in more than one talk.  It was also said to be included in the 2014.1 install because of this.

It is also referenced in this document: https://decibel.ni.com/content/docs/DOC-38615

I made the assumption after all of those things, that it was supported.

-TD

0 Kudos
Message 8 of 14
(4,606 Views)

After looking at the /usr/sbin/vpnctl script, it looks like the openvpn call is hard-coded to tap.  We are using tun ... so I had to remove that from the script (which makes me not feel so good, since I can only assume this file is overwritten on format ...).

Right, but more importantly, it will never work in safemode either, because vpnctl is extracted into a ramfs and so is regenerated on each safemode boot.

If existing infrastructure demands tun, you might want to consider setting up a separate server (on a separate port) for this target that is tap, bridging the appropriate interfaces together on the server.

Additionally, it looks like the ERROR above is a permissions thing?

I would more likely suspect it's related to the tun-specific options that the server is attempting to pass in. Try it again after equalizing the settings between client and server.

Any chance you could shed some light on what I may be doing wrong?  My openvpn config below:

dev tap

Note that this will only take effect if you delete the setting entirely from vpnctl, as opposed to simply changing it.

auth-user-pass

This won't work on system startup because the console input is unavailable to initscripts. One way you might be able to get interactive input, if that's what you need, is to set VPN_LOAD_ON_STARTUP=no in /etc/default/vpn and then set up your own mechanism for getting the username/password into a file, setting "auth-user-pass ", and running vpnctl yourself. You're probably not going to be able to avoid storing the credentials in a file, although you could be able to store them in tmpfs.

ns-cert-type server

This is overridden by vpnctl too.

The other settings seem ok.

Richard, thank you again for your reply.  Additionally, where is all of this documented for me to review?

Here. Sanjay's been asking me to document all of this for years; answering these questions is probably a good a method as any. I'll be mostly OOO over the next few weeks though. :F

That said, I have been hesitant to document it, in order to ensure the appropriate level of domain expertise. It's easy to *think* you've secured a system, and a lot of the security of the deployment is in proper system administration of the server, and its logs, etc.

0 Kudos
Message 9 of 14
(4,606 Views)

tduffy wrote:

Ahh, and to answer your other question about OpenVPN, it was discussed openly at NI Week as the perfered vpn client for the cRIO-9068 in more than one talk.  It was also said to be included in the 2014.1 install because of this.

It is also referenced in this document: https://decibel.ni.com/content/docs/DOC-38615

I made the assumption after all of those things, that it was supported.

In general, we support being able to run "a" VPN. Not necessarily yours. You already ran into that with the hardcoded TAP configuration.

This is actually not so different from the support that is provided for the opkg repos or for C++ development. The key difference is that those "just work" except for relatively few people, and the feature sets and behaviors are rather well-defined.

Thanks for the references, I'll bring it up with the appropriate channels.

0 Kudos
Message 10 of 14
(4,606 Views)