OpenVPN Client setup on TrueNAS Core 12

[Baal]

Hi there, I've checked around and it seems like a few people have had this issue in the past with little to no resolution.. just random success here and there with no documentation...
I have OpenVPN server running on my OPNsense firewall. My phone, laptop and desktop are all capable of connecting to the VPN successfully.
However, I cannot connect the TrueNAS box to the VPN using the OpenVPN client under services.
I've setup the CA and Certs as documented by a few others on this forum with no success.
I do have the OPNsense set to local directory username / password authentication. I assume when it succesfully connects to the VPN I'll get to enter those credentials...

On a side note, are my settings 'Secure enough' or should I up them to AES-256-CBC, SHA512 etc? I've heard that leaving the default port 1194 isn't entirely wise, so I'll change that when or if I get this figured out.

Show : Here is the config for the OpenVPN

cipher AES-128-CBC
auth SHA256
client
resolv-retry infinite
remote someobscured.domainontheinternet.com 1194 udp
lport 0
verify-x509-name " ------------ , CN=OpenVPN-Cert" subject
remote-cert-tls server
auth-user-pass

Show : Here is a screenshot of the CA

I inserted what was inside the <ca> </ca>

Show : Here is a screenshot of the Cert

I inserted what was inside the <cert> </cert> and <key> </key>

Show : Here is a screenshot of the Client Config with the errors I receive

 

[pete.magnusson]

Following, have the same question and setup :)

 

[jgreco]

Ah. Your spoiler tags were spoiled because it doesn't like spaces around the = sign.

For OpenVPN, the use of port 1194 advertises what you are running on the port.

The paranoid among us (hi!) who run OpenVPN at scale for multiple purposes including inter-network WAN links, we tend to use the tls-crypt feature of OpenVPN, which protects the TLS negotiation behind a separate static key, giving you something sorta like two-factor authentication would be for your login accounts. No one can sit there and attack the TLS interface unless they know the static key, which means that you can not have to worry as much that 1194 advertises your use of OpenVPN. Of course you can also just pick a random port AND tls-crypt and then it just looks like random crap going back and forth.

 

[Baal]

Anyone able to provide insight?
It seems to be very common for this issue to be ignored on these forms

 

[jgreco]

Anyone able to provide insight?
It seems to be very common for this issue to be ignored on these forms

I can guess why, it's going to have to do with twitchy complicated networking stuff; if it was possible to make it work easily out of the box, it would be. However, OpenVPN in a TUN configuration (the more common) "requires" the OpenVPN daemon to be allocated a private subnet, and for that space to be routed at the host sponsoring the OpenVPN daemon, by your router, or else your OpenVPN will not have full connectivity to the network you're attaching it to, which is probably not what you expect.

So as someone who implements OpenVPN at scale and has deployed a dozen OpenVPN systems in the last few days alone, both TUN and TAP, I can tell you that the usual problem is that most people don't have a particularly good grasp of IP networking and how routing works. That's a poor predictor of success. And the problem is I don't really have the time to drag everyone through all the IP networking fundamentals.

OpenVPN's own page on the "basics" is several screens long

Some Basic Networking Concepts Simplified | OpenVPN

Although our users may already have a background in networking, nobody can be expected to know it all. Here are some basic concepts simplified.

openvpn.net

and I think it's about 30% crap, and still about 30% missing useful stuff.

Basically, the best hint I can give you is that if you haven't logged in on your gateway router and pointed 10.8.0.0/24 (or whatever range OpenVPN TUN is using) at your TrueNAS OpenVPN host, not only is it not LIKELY to work, but it isn't EXPECTED to either. This is the thing that is a common thread in about 80% of OpenVPN TUN configuration misadventures.

But even with that said, that's usually not the exclusive thing that needs to be fixed, and figuring out what the next thing is, via proxy, from someone who doesn't understand IP networking, is frustrating and often unsuccessful.

That said, if you avail yourself of resources that are available and you still have a specific question, I may be willing or able to help. I've been using OpenVPN at scale in multiple roles since almost day 1.

 

[simonj]

I can guess why, it's going to have to do with twitchy complicated networking stuff; if it was possible to make it work easily out of the box, it would be. However, OpenVPN in a TUN configuration (the more common) "requires" the OpenVPN daemon to be allocated a private subnet, and for that space to be routed at the host sponsoring the OpenVPN daemon, by your router, or else your OpenVPN will not have full connectivity to the network you're attaching it to, which is probably not what you expect.

So as someone who implements OpenVPN at scale and has deployed a dozen OpenVPN systems in the last few days alone, both TUN and TAP, I can tell you that the usual problem is that most people don't have a particularly good grasp of IP networking and how routing works. That's a poor predictor of success. And the problem is I don't really have the time to drag everyone through all the IP networking fundamentals.

OpenVPN's own page on the "basics" is several screens long

Some Basic Networking Concepts Simplified | OpenVPN

Although our users may already have a background in networking, nobody can be expected to know it all. Here are some basic concepts simplified.

openvpn.net

and I think it's about 30% crap, and still about 30% missing useful stuff.

Basically, the best hint I can give you is that if you haven't logged in on your gateway router and pointed 10.8.0.0/24 (or whatever range OpenVPN TUN is using) at your TrueNAS OpenVPN host, not only is it not LIKELY to work, but it isn't EXPECTED to either. This is the thing that is a common thread in about 80% of OpenVPN TUN configuration misadventures.

But even with that said, that's usually not the exclusive thing that needs to be fixed, and figuring out what the next thing is, via proxy, from someone who doesn't understand IP networking, is frustrating and often unsuccessful.

That said, if you avail yourself of resources that are available and you still have a specific question, I may be willing or able to help. I've been using OpenVPN at scale in multiple roles since almost day 1.

Thanks. This piece of advice actually solved it for me. Was following the YouTube tutorial on trueNas openvpn setup and could never connect to anything other than the openVPN host on the remote network. Adding a static route for all traffic to 10.20.0.0 (vpn client subnet) over the trueNas host as gateway on my internet router solved it.

 

[jgreco]

Thanks. This piece of advice actually solved it for me.

No problem. Probably solves it for you and about half of everyone else with OpenVPN "issues"; the problem is the routing environment needs to be coherent, and most folks have never run into the need to DESIGN a segmented network so that every node can reach every other node. Modern networks, someone else has usually solved this problem for them, often implicitly. OpenVPN represents their first experience off-roading.

Hope you didn't suffer too many bruises along the way.

 

[simonj]

I can now successfully reach all servers on the remote network through the OpenVPN app on my mac.

However, I also have a small Truenas box here that I want to connect to the remote location through VPN for replication. In general the connection seemed to work out following this advice https://www.truenas.com/community/threads/openvpn-client.99422/ and just uploading the same .opvn config file (which works on the mac) on the trueNAS box.
But I cannot reach any host from the TrueNAS client. I can ping 10.20.0.2 but nothing else.
The remote LAN runs on 192.168.178.0/24 The OpenVPN TrueNAS server on 192.168.178.81

here's the syslog output when connecting. With my limited knowledge it looks like routing should be setup properly:

Code:

Jan 31 09:05:07 truenas openvpn[1773174]: PUSH: Received control message: 'PUSH_REPLY,route 192.168.178.0 255.255.255.0,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,dhcp-option DNS 1.1.1.1,dhcp-option DNS 192.168.178.1,route-gateway 10.20.0.1,topology subnet,ifconfig 10.20.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Jan 31 09:05:07 truenas openvpn[1773174]: OPTIONS IMPORT: --ifconfig/up options modified
Jan 31 09:05:07 truenas openvpn[1773174]: OPTIONS IMPORT: route options modified
Jan 31 09:05:07 truenas openvpn[1773174]: OPTIONS IMPORT: route-related options modified
Jan 31 09:05:07 truenas openvpn[1773174]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Jan 31 09:05:07 truenas openvpn[1773174]: OPTIONS IMPORT: peer-id set
Jan 31 09:05:07 truenas openvpn[1773174]: OPTIONS IMPORT: adjusting link_mtu to 1624
Jan 31 09:05:07 truenas openvpn[1773174]: OPTIONS IMPORT: data channel crypto options modified
Jan 31 09:05:07 truenas openvpn[1773174]: Data Channel: using negotiated cipher 'AES-256-GCM'
Jan 31 09:05:07 truenas openvpn[1773174]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 31 09:05:07 truenas openvpn[1773174]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 31 09:05:07 truenas openvpn[1773174]: net_route_v4_best_gw query: dst 0.0.0.0
Jan 31 09:05:07 truenas openvpn[1773174]: net_route_v4_best_gw result: via 0.0.0.0 dev lo
Jan 31 09:05:07 truenas openvpn[1773174]: ROUTE_GATEWAY ON_LINK IFACE=lo HWADDR=00:00:00:00:00:00
Jan 31 09:05:07 truenas openvpn[1773174]: TUN/TAP device tun0 opened
Jan 31 09:05:07 truenas openvpn[1773174]: net_iface_mtu_set: mtu 1500 for tun0
Jan 31 09:05:07 truenas openvpn[1773174]: net_iface_up: set tun0 up
Jan 31 09:05:07 truenas openvpn[1773174]: net_addr_v4_add: 10.20.0.2/24 dev tun0
Jan 31 09:05:07 truenas openvpn[1773174]: net_route_v4_add: 85.195.242.34/32 via 0.0.0.0 dev lo table 0 metric -1
Jan 31 09:05:07 truenas openvpn[1773174]: net_route_v4_add: 0.0.0.0/1 via 10.20.0.1 dev [NULL] table 0 metric -1
Jan 31 09:05:07 truenas openvpn[1773174]: net_route_v4_add: 128.0.0.0/1 via 10.20.0.1 dev [NULL] table 0 metric -1
Jan 31 09:05:07 truenas openvpn[1773174]: net_route_v4_add: 192.168.178.0/24 via 10.20.0.1 dev [NULL] table 0 metric -1
Jan 31 09:05:07 truenas openvpn[1773174]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Jan 31 09:05:07 truenas openvpn[1773174]: Initialization Sequence Completed
Jan 31 09:05:07 truenas systemd-udevd[1773359]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jan 31 09:05:09 truenas ntpd[2880]: Listen normally on 25 tun0 10.20.0.2:123
Jan 31 09:05:09 truenas ntpd[2880]: Listen normally on 26 tun0 [fe80::b452:a480:a999:d3f9%13]:123

Do I have to setup a static route on the TrueNAS box? @jgreco maybe you can advise me on this as well?

 

[Whattteva]

I can now successfully reach all servers on the remote network through the OpenVPN app on my mac.

However, I also have a small Truenas box here that I want to connect to the remote location through VPN for replication. In general the connection seemed to work out following this advice https://www.truenas.com/community/threads/openvpn-client.99422/ and just uploading the same .opvn config file (which works on the mac) on the trueNAS box.
But I cannot reach any host from the TrueNAS client. I can ping 10.20.0.2 but nothing else.
The remote LAN runs on 192.168.178.0/24 The OpenVPN TrueNAS server on 192.168.178.81

I think I can guess what's wrong. Your traffic to the host is probably fine, but the RETURN traffic may not be getting routed.
Login to your OPNsense box and print out the routing table with netstat -r.

What's the subnet of your client LAN (where your MAC resides)?