How to install OpenVPN inside a jail in FreeNAS 9.2.1.6+ with access to remote hosts via NAT

[ram]

Both TCP and UDP is also possible (if it hasn't been mentioned before)

/usr/local/etc/ipfw.rules

Code:

#!/bin/sh


EPAIR=$(/sbin/ifconfig -l | tr " " "\n" | /usr/bin/grep epair)

ipfw -q -f flush

ipfw -q nat 1 config if ${EPAIR}

ipfw -q add nat 1 all from 10.8.0.0/24 to any out via ${EPAIR}

ipfw -q add nat 1 all from 10.9.0.0/24 to any out via ${EPAIR}

ipfw -q add nat 1 all from any to any in via ${EPAIR}


TUN0=$(/sbin/ifconfig -l | tr " " "\n" | /usr/bin/grep tun -m1)

ifconfig ${TUN0} name tun0


TUN1=$(/sbin/ifconfig -l | tr " " "\n" | /usr/bin/egrep tun[^0])

ifconfig ${TUN1} name tun1

in jail rc.conf

Code:

openvpnudp_enable="YES"
openvpnudp_if="tun"
openvpnudp_configfile="/mnt/openvpn/openvpn.conf"
openvpnudp_dir="/mnt/openvpn"

openvpntcp_enable="YES"
openvpntcp_if="tun"
openvpntcp_configfile="/mnt/openvpn/openvpn-tcp.conf"
openvpntcp_dir="/mnt/openvpn"

cloned_interfaces="tun tun"

gateway_enable="YES"
firewall_enable="YES"
firewall_script="/usr/local/etc/ipfw.rules"

openvpn-tcp.conf

Code:

port 10011

proto tcp

dev tun1

ca /mnt/openvpn/keys/ca.crt

cert /mnt/openvpn/keys/issued/openvpn-server.crt #Server key created previously

key /mnt/openvpn/keys/private/openvpn-server.key

dh /mnt/openvpn/keys/dh.pem #Diffie-Hellman parameters are now 2048 bits long

server 10.9.0.0 255.255.255.0 #Purple network

ifconfig-pool-persist ipp.txt

push "route 192.168.178.0 255.255.255.0" #Yellow network

route 192.168.178.4 255.255.255.0 10.9.0.1 #Routes traffic from the Yellow network side (10.0.0.0/24)

									  #to the Purple network side (10.8.0.0/24)


push "dhcp-option DNS 192.168.178.1"

#push "redirect-gateway def1"

push "redirect-gateway def1 bypass-dhcp"


tls-auth /mnt/openvpn/keys/auth.key 0

# REVOCATION LIST:

#crl-verify /mnt/openvpn/keys/crl.pem

keepalive 10 120

group nobody

user nobody

comp-lzo

persist-key

persist-tun

verb 3


duplicate-cn

openvpn.conf

Code:

port 10011

proto udp

dev tun0

ca /mnt/openvpn/keys/ca.crt

cert /mnt/openvpn/keys/issued/openvpn-server.crt #Server key created previously

key /mnt/openvpn/keys/private/openvpn-server.key

dh /mnt/openvpn/keys/dh.pem #Diffie-Hellman parameters are now 2048 bits long

server 10.8.0.0 255.255.255.0 #Purple network

ifconfig-pool-persist ipp.txt

push "route 192.168.178.0 255.255.255.0" #Yellow network

route 192.168.178.4 255.255.255.0 10.8.0.1 #Routes traffic from the Yellow network side (10.0.0.0/24)

									  #to the Purple network side (10.8.0.0/24)


push "dhcp-option DNS 192.168.178.1"

#push "redirect-gateway def1"

push "redirect-gateway def1 bypass-dhcp"


tls-auth /mnt/openvpn/keys/auth.key 0

# REVOCATION LIST:

#crl-verify /mnt/openvpn/keys/crl.pem

keepalive 10 120

group nobody

user nobody

comp-lzo

persist-key

persist-tun

verb 3


duplicate-cn

 

[zoomzoom]

@ram Exactly what is your post supposed to be about, as there's no discernable purpose one can garnish from your post.

• If you were posting in reference to @kpeng, they need to post their log files for troubleshooting... simply posting config files for someone with issues does nothing, as it doesn't demonstrate where the issue is. The only way to discern what the exact issue is, log files must be queried.

While TCP can be used for OpenVPN, there's only two use cases for it:

1. Troubleshooting
2. High packet loss when utilizing UDP

Outside of those two use cases, TCP should not be utilized, as TCP cannot efficiently encapsulate itself.

 

[EvanVanVan]

And yes, once you've completed the prerequisite edits, move to the commands. Also, in each step, there is a file path in burnt orange in the upper right hand corner of the prerequisites - this specifies what file is being edited, or from what directory the commands are being executed from.

Servers and clients line numbers is telling the user where to look in the openssl.cnf for the servers and clients SAN profiles for the CA. It will be easier for you to understand the openssl.cnf if you download notepad++ in Windows, then download the language profile for it from my GitHub. The directions on that page link also tell you how to import that language file into Notepad++. Once you do so, open the openssl.cnf in Notepad++ and select the Language drop down menu, and finally select "config" at the very bottom of that menu.

Hey, I've got a couple questions if you wouldn't mind answering them. Going through with the prequiste edits, should I make making the changes as specified for OpenWRT even though I'm not actually going to use it (i.e. alt_ca_main to alt_ca_openwrt)? And should I be commenting out most of the lines?

Show : For Example...

Code:

# Main #
  [ alt_ca_openwrt ]
  DNS.1  = nas_ca
  IP.1	 = 127.0.0.1

# Router 2 #		# I see that this gets modified in the ICA prerequisites section next
#  [ alt_ica_router2 ]
#  DNS.1   = Router.2
#  IP.1	   = 127.0.0.1

# Router 3 #
#  [ alt_ica_router3 ]
#  DNS.1  = Router.3
#  IP.1	  = 127.0.0.1

# Router 4 #
#  [ alt_ica_router4 ]
#  DNS.1  = Router.4
#  IP.1	  = 127.0.0.1


#--------------------------------------------------------------------
		##----- Certificate Authority Clients -----##
#--------------------------------------------------------------------

# Main #

  # Servers #
#  [ alt_sophos ]
#  IP.1	 = 192.168.2.1
#  IP.2	 = 127.0.0.1
#  DNS.1 = SophosUTM
#  DNS.2 = your.ddns.com

# [ alt_freenas ]	   # Not sure if I shoujld do anything with this section, athough I am hoping it can be used to sign the https:// webgui page?
# IP.1	= 192.168.2.13
# IP.2	= 192.168.2.130	   #Also no sure why there are 2 IPs?
# IP.3	= 127.0.0.1
# DNS.1  = Free.NAS
# DNS.2  = FreeNAS.igb0
# DNS.3  = FreeNAS.igb1

# [ alt_owncloud ]
# IP.1   = 192.168.2.150
# IP.2   = 127.0.0.1
# DNS.1 = OwnCloud.FreeNAS

[ alt_vpn_server1 ]
IP.1	= 10.0.0.1
DNS.1  = your.ddns.com

# Clients #
[ alt_vpn1_user1 ]			   #edit the name?  it appears to be an extension name
email.1 = admin@email.com
DNS.1  = VPN1-Client1-Device-Hostname1	   # Do I change/comment out these?
DNS.2  = VPN1-Client1-Device-Hostname2	   # Do I change/comment out these?

Making the CA prerequisite edits (but specified towards openwrt), and running the first commands (from /etc/ssl) I get the following error. I see the unknown extension name, but it's been changed and I'm not sure what's happening. I'm trying to run it in the openvpn jail in /etc/ssl.

Code:

[root@openvpn /etc/ssl]# openssl req -x509 -new -sha512 -days 3650 -newkey rsa:4096 -keyout ca/OpenWrt-CA.key.pem -out ca/OpenWrt-CA.crt.pem -config ./openssl.cnf -extensions v3_ca_openwrt
Error Loading extension section v3_ca_openwrt
34379279064:error:22097082:X509 V3 routines:DO_EXT_NCONF:unknown extension name:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509v3/v3_conf.c:125:
34379279064:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509v3/v3_conf.c:95:name=basicconstraints, value=ca:true

Thank you

 

[EvanVanVan]

Hey, I've got a couple questions if you wouldn't mind answering them. Going through with the prequiste edits, should I make making the changes as specified for OpenWRT even though I'm not actually going to use it (i.e. alt_ca_main to alt_ca_openwrt)? And should I be commenting out most of the lines?

Making the CA prerequisite edits (but specified towards openwrt), and running the first commands (from /etc/ssl) I get the following error. I see the unknown extension name, but it's been changed and I'm not sure what's happening. I'm trying to run it in the openvpn jail in /etc/ssl.

Thank you

Aright, I got that stuff figured out, I had better luck after not wget-ing the raw file from github, but instead selecting it all and just copy/pasting it into a new openssl.cnf. I also had misunderstood the tips for bsd users at the top and used a script to make everything lower case, as well as remove crlf returns. Manually setting the few variables to lowercase (technically making one variable all uppercase worked as well) myself as well as finding and fixing the only two lines with incorrect returns in them (example commands near the bottom) allowed the command to execute properly.

On to the second command I now get this error though (FYI I ended up using the generic commands and not changing them to WRT specific ones):

Code:

root@openvpn:/etc/ssl # openssl ca -gencrl -keyfile ca.key.pem -cert ca.crt.pem -out ca.crl.pem -config ./openssl.cnf
Using configuration from ./openssl.cnf
Enter pass phrase for ca.key.pem:
wrong number of fields on line 1 (looking for field 6, got 1, '' left)

Edit: A quick google shows it could be a whitespace vs tab issue, but I'll have to look into it more tonight.

 

[zoomzoom]

@EvanVanVan Don't comment anything out, unless you've used an openssl.cnf before and know what must not be commented out.

• Provided you utilize the commands included at the bottom of the config, there's no need to comment anything out.
• Your errors in your first post are either due to the EOLs and formatting differences needed to switch it to a linux/bsd config, or a result of commenting out critical information for the config to function, and/or modifying the certificate v3 options (which I stated in the config should not be modified unless one knows what they're doing).

An openssl.cnf is not like a normal config file, where everything uncommented is used.

• I left the 3 ICAs as an example, where if one needs multiple ICAs, they can simply copy & paste information into them as needed, which avoids the user having to understand how the config must be set up.

• For example, I have a master CA that I use for my Sophos UTM router, then ICAs for every other router/physical server I have, of which the master CA signs.
  • This provides security, as well as user convenience, by preventing all other ICAs from being compromised if the key to any one of them is compromised.
    • This allows for only that ICA and all it's certs to be trashed, a new ICA created, and new certs issued.
  • If an individual is going to be issuing more than a handful of certs (10+), the user may wish to incorporate additional ICAs the device ICA would then sign. For example, if one has a VPN server that's used by more than just a few people, it's better to create an additional ICA for the VPN server, which the device ICA signs. This would prevent the device's ICA, as well as everything else it's signed, from having to be trashed if the VPN Server's ICA's key is ever compromised
  • VPN with separate VPN Server ICA:
    • Master CA (Sophos) signs Router 1 ICA >> Router 1 ICA signs VPN Server ICA >> VPN Server ICA issues and signs VPN Server cert & VPN Client certs
      • VPN Server ICA, and all certificates signed by it, would have to be recreated if it's compromised as the VPN Server certificate authority

  • VPN without separate VPN Server ICA:

  • Master CA (Sophos) signs Router 1 ICA >> Router 1 ICA issues and signs VPN Server cert & VPN Client certs
    • Router 1 ICA, and all certificates signed by it, would have to be recreated if it's compromised as the VPN Server certificate authority

  • Any ICA one wishes to have sign additional CAs or ICAs must have a pathleen value greater than 0 under it's V3 profile
    • The pathleen value stipulates how many, if any, CAs or ICAs a CA or ICA can sign
• I have yet to use the openssl.cnf on a BSD OS... did it not function with the variables under [ CA_default ] as uppercase?
  • If not, I'll change that

• The only variables that matter are those under [ CA_default ]; all other variables are user preference if they choose to modify & then use them within their openssl commands.
  • I'll add this info to the top of the config as well, as I realize now that's not clear from the config

• After re-reading, I've pasted your error output below
  
  Code:

  root@openvpn:/etc/ssl # openssl ca -gencrl -keyfile ca.key.pem -cert ca.crt.pem -out ca.crl.pem -config ./openssl.cnf
  Using configuration from ./openssl.cnf
  Enter pass phrase for ca.key.pem:
  wrong number of fields on line 1 (looking for field 6, got 1, '' left

  • The issue is with the passphrase step for the CA signing key, and in order to figure out if it's the config or the script, you'll need to manually run that crl creation command by itself in a terminal.
    • If it errors out, it'll tell you what caused the error, but if it doesn't [error], it's the script.
  • EDIT:
    • I was totally off about the passphrase step in the process. After doing some lengthy research online this morning., I believe openssl expects the CRL to be created only when needing to revoke a certificate, something I didn't realize until you brought the error to my attention. This would explain why it's looking for all 6 sections in the index file, as unless a certificate has been revoked, the revocation section is left out of the file.
      • I've never experienced the CRL error as I always create my CRL immediately after creating a CA/ICA (if a master CA, it would be the second command; an ICA, the fourth).
      • The CRL command expects an either/or scenario for the index file:
        • EITHER: a zero length file (Linux/BSD: touch ./index Windows: echo > .\index)
        • OR: a certificate entry with the revoked section, revoking the specified cert

 

[EvanVanVan]

• Provided you utilize the commands included at the bottom of the config, there's no need to comment anything out.
• Your errors in your first post are either due to the EOLs and formatting differences needed to switch it to a linux/bsd config, or a result of commenting out critical information for the config to function, and/or modifying the certificate v3 options (which I stated in the config should not be modified unless one knows what they're doing).

Yes, thank you. I realized (after a while...) you never said to comment anything out so I decided to start from scratch and give it a shot. And what do you know, it worked lol. I actually had meant to ask in my first post what Intermediate Certificate Authorities were, but decided to wait until I did some searching myself. I had the general idea, but the purpose of them makes a lot more sense now...

• I have yet to use the openssl.cnf on a BSD OS... did it not function with the variables under [ CA_default ] as uppercase?
• The only variables that matter are those under [ CA_default ]; all other variables are user preference if they choose to modify & then use them within their openssl commands.

The only error the first command produces on fresh openssl.cnf was in line 68, but it's actually the lowercase "crldir" in line 67. After changing that to CRLDIR, the first command executed with no problems.

Lol it took me longer than it should have but I did finally figure that out after re-reading everything for the thousandth time.

After re-reading, I've pasted your error output below

• The issue is with the passphrase step for the CA signing key, and in order to figure out if it's the config or the script, you'll need to manually run that crl creation command by itself in a terminal.
  • If it errors out, it'll tell you what caused the error, but if it doesn't [error], it's the script.

I ran this openssl ca -gencrl -config ./openssl-mod.cnf (which I think is what you meant) and got two errors. The one I listed second actually occurred first...

• I think the main error was in lines 72 and 73, it didn't like the single quotes surrounding 'DIR/ca/ca.crt/key.pem'
• Secondarily, I had to fix the capitalization and move the ca.crt.pem and ca.key.pem files into the ca/ dir (after relying on the CA_defaults).

After that the command executed fine but I still got the same error once I put the passphrase in.. I'll keep trying things and reply if/when I figure anything out.


Thank you for the help

Not using your opsnssl.cnf I get the following error. I'll see what happens after I provide a key.pem and crt.pem

Code:

[root@freenas] /etc/ssl# openssl ca -gencrl
Using configuration from /etc/ssl/openssl.cnf   #####this is not your openssl.cnf#####
Error opening CA private key ./demoCA/private/cakey.pem
34379265480:error:02001002:system library:fopen:No such file or directory:/freenas-9.10-releng/_BE/os/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:398:fopen('./demoCA/private/cakey.pem','r')
34379265480:error:20074002:BIO routines:FILE_CTRL:system lib:/freenas-9.10-releng/_BE/os/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:400: unable to load CA private key

 

[zoomzoom]

After checking out my openssl.cnf, I realized I left out an option on the generalized one I created for GitHub... sorry about that.

1. openssl ca -gencrl -cert ./ca.crt.pem -keyfile ./ca.key.pem -out ./ca.crl.pem -extensions crl_ext -config ./openssl.cnf
   • -extensions crl_ext was missing
2. openssl crl -inform PEM -in ./ca.crl.pem -outform DER -out ./ca.crl

I actually had meant to ask in my first post what Intermediate Certificate Authorities were, but decided to wait until I did some searching myself. I had the general idea, but the purpose of them makes a lot more sense now...

A CA is a certificate authority which is not signed by another CA, while an ICA is a certificate authority which has been signed by another CA or ICA, of which makes it the intermediate authority. I prefer using ICAs rather than a bunch of CAs as there's a Chain of Trust with ICAs since they've been signed by a trusted CA, of which can either be a Public Authority [VeriSign, Comodo, etc.] or Self Signed.

I ran this openssl ca -gencrl -config ./openssl-mod.cnf (which I think is what you meant) and got two errors. The one I listed second actually occurred first...

• I think the main error was in lines 72 and 73, it didn't like the single quotes surrounding 'DIR/ca/ca.crt/key.pem'.
• Secondarily, I had to fix the capitalization and move the ca.crt.pem and ca.key.pem files into the ca/ dir after relying on the CA_default.

After that the command executed fine but I still got the same error once I put the passphrase in.. I'll keep trying things and reply if/when I figure anything out.

I'll fix the crldir, and I'll also add the directory structure that needs to be created to the Prerequisites section (starting line #506).

While everything could be in one folder, if one is issuing more than a couple of certs, it gets cluttered quite fast. Additionally, the CA folder should be utilized, as once one is done with issuing & signing certs, that folder should be encrypted via GnuPG [Linux/BSD] or Gpg4Win [Windows], otherwise there's no way to guarantee the security of the CA/ICAs. The same should also be done for the certificate keys, and is why I recommend also exporting each cert to a PKCS12, which would contain the cert, it's key, and the CA/concatenated ICA-CA cert

• What I recommend is creating a copy of the CA cert (not key), placing it in the root of the folder with the openssl.cnf (same for any ICA certs).
  • This allows for convenience when the CA/ICAs need to be installed onto systems to prevent the certificate errors that will occur with web servers (FreeNAS GUI page for instance).
  • I realize I never included the above information and will add it to the annotations at the top of the config when I make the other referenced additions

• I also recommend for two versions of ICA certs to be kept, a copy of the ICA.crt.pem, as well as a concatenated ICA-CA.crt.pem.
  • Windows does not recognize concatenated ICA-CA certs and will only recognize the first listed (the ICA cert) if imported into Certificate Manager.

• If using Windows, I highly recommend also downloading the PEM Association registry key on my GitHub and importing it into the registry, as it allows Windows to recognize the *.pem extension as a valid certificate.
  • The benefit is twofold: convenience in not having to rename certs if crossing between Linux/BSD (such as using VMs within Windows), as well as adding the certificate options to the context menu of a pem cert (install for instance)

And........I realized you probably wanted it without the -config option.... I get this error:

Code:

[root@freenas] /etc/ssl# openssl ca -gencrl
Using configuration from /etc/ssl/openssl.cnf   #####this is not your openssl.cnf#####
Error opening CA private key ./demoCA/private/cakey.pem
34379265480:error:02001002:system library:fopen:No such file or directory:/freenas-9.10-releng/_BE/os/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:398:fopen('./demoCA/private/cakey.pem','r')
34379265480:error:20074002:BIO routines:FILE_CTRL:system lib:/freenas-9.10-releng/_BE/os/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:400: unable to load CA private key

I'll see what happens after I provide a key.pem and crt.pem

The config always needs to be referenced, otherwise it will attempt to use /etc/ssl/openssl.cnf [even on Windows], which is an issue since the default openssl.cnf will not contain the correct information in relation to the custom openssl.cnf. I never recommend replacing the system default openssl.cnf as it's a good reference since it contains an insane amount of comments by default.

• Once you strip the comments away, you end up with a config like the one on my GitHub, of which I've attempted to keep the commenting to a minimum above the information section at the bottom of the config.
  • Due to the comments in the default openssl.cnf, and the amount of fat it adds to the config, more often than not the default config overwhelms users.

 

[zoomzoom]

I forgot to mention... I recommend keeping your working directory somewhere other than within your jail filesystem. I recommend creating at least two copies of your working directory, encrypting both folders (everything in them) with a 2048bit or 4096bit PGP key, and keeping at least one copy somewhere other than on your FreeNAS server.

• This assumes you create a secure password of at least 20 characters that protects the PGP signing key and follows the guidelines set forth here.
  • It's the WiFi Security Password section for OpenWrt, but what I wrote there holds true here as well

While the encryption is only needed for the keys, this guarantees all certs, keys, and files are kept together in an encrypted tar container and cannot be removed from the container without first decrypting.

 

[EvanVanVan]

• After re-reading, I've pasted your error output below
  
  Code:

  root@openvpn:/etc/ssl # openssl ca -gencrl -keyfile ca.key.pem -cert ca.crt.pem -out ca.crl.pem -config ./openssl.cnf
  Using configuration from ./openssl.cnf
  Enter pass phrase for ca.key.pem:
  wrong number of fields on line 1 (looking for field 6, got 1, '' left

  • The issue is with the passphrase step for the CA signing key, and in order to figure out if it's the config or the script, you'll need to manually run that crl creation command by itself in a terminal.
    • If it errors out, it'll tell you what caused the error, but if it doesn't [error], it's the script.

Finally fixed that error! Googling showed that it had to do with the index file. I had not realized that in between the first and second commands was when I had to add my cert entry into the index file. I had seen that I would need to manually add them but following the order of the commands I didn't think I had to do it at the point... My bad.

Once I did that (and used tabs instead of spaces between entries, I think because of the missing 3rd revocation-date-entry) the second command executed cleanly...

After checking out my openssl.cnf, I realized I left out an option on the generalized one I created for GitHub... sorry about that.

1. openssl ca -gencrl -cert ./ca.crt.pem -keyfile ./ca.key.pem -out ./ca.crl.pem -extensions crl_ext -config ./openssl.cnf
   • -extensions crl_ext was missing
2. openssl crl -inform PEM -in ./ca.crl.pem -outform DER -out ./ca.crl -config ./openssl.cnf
   • -config ./openssl.cnf was missing

Ok, I'm not sure if this stuff still applies, but fyi openssl crl informed me that -config was not a valid arg for crl

 

[zoomzoom]

Finally fixed that error! Googling showed that it had to do with the index file. I had not realized that in between the first and second commands was when I had to add my cert entry into the index file. I had seen that I would need to manually add them but following the order of the commands I didn't think I had to do it at the point... My bad.

Once I did that (and used tabs instead of spaces between entries, I think because of the missing 3rd revocation-date-entry) the second command executed cleanly...

Yeah, I was totally off about the passphrase step in the process. After doing some lengthy research online this morning., I believe openssl expects the CRL to be created only when needing to revoke a certificate, something I didn't realize until you brought the error to my attention. This would explain why it's looking for all 6 sections in the index file, as unless a certificate has been revoked, the revocation section is left out of the file.

• I've never experienced the CRL error as I always create my CRL immediately after creating a CA/ICA (if a master CA, it would be the second command; an ICA, the fourth).
• The CRL command expects an either/or scenario for the index file:
  • EITHER: a zero length file (Linux/BSD: touch ./index Windows: echo > .\index)
  • OR: a certificate entry with the revoked section, revoking the specified cert

You would add a cert entry for the CA/ICA only after creating a CRL

• The reason I set the steps in that order [CA/ICA creation >> CRL creation >> Certificate creation] is around 2 years ago when I taught myself how to use an openssl.cnf, I had enormous difficulty finding out how to create a CRL, both in regards to the command structure, as well as the openssl.cnf section for it. I figured it would be easier for users to just get it out of the way at the start, rather than wait until they need to revoke a cert and have no idea how to create a CRL.

Generally what I do for the index file is create all certs, including CA/ICAs, at once, then add them to the index file as the last step (it ends up being faster since you're not repeatedly starting & stopping).

Ok, I'm not sure if this stuff still applies, but fyi openssl crl informed me that -config was not a valid arg for crl

You're spot on... I clearly didn't pay enough attention to what I posted there =]

 

[EvanVanVan]

Yeah, I was totally off about the passphrase step in the process. After doing some lengthy research online this morning., I believe openssl expects the CRL to be created only when needing to revoke a certificate, something I didn't realize until you brought the error to my attention. This would explain why it's looking for all 6 sections in the index file, as unless a certificate has been revoked, the revocation section is left out of the file.

• I've never experienced the CRL error as I always create my CRL immediately after creating a CA/ICA (if a master CA, it would be the second command; an ICA, the fourth).
• The CRL command expects an either/or scenario for the index file:
  • EITHER: a zero length file (Linux/BSD: touch ./index Windows: echo > .\index)
  • OR: a certificate entry with the revoked section, revoking the specified cert

You would add a cert entry for the CA/ICA only after creating a CRL

• The reason I set the steps in that order [CA/ICA creation >> CRL creation >> Certificate creation] is around 2 years ago when I taught myself how to use an openssl.cnf, I had enormous difficulty finding out how to create a CRL, both in regards to the command structure, as well as the openssl.cnf section for it. I figured it would be easier for users to just get it out of the way at the start, rather than wait until they need to revoke a cert and have no idea how to create a CRL.

Generally what I do for the index file is create all certs, including CA/ICAs, at once, then add them to the index file as the last step (it ends up being faster since you're not repeatedly starting & stopping).

Haha hold up, I see the problem now... I don't know linux!

The generalize version of the command to create the index file is echo > index. Which I now realize must not create a zero length file. I just tried touch index and the crl command executes no problem. I had actually used touch index when following the OpenWRT wiki, before starting from scratch when trying to get the first command to work...whoops, my apologies.

And the order of creating the crl while doing everything else makes sense. Just to clarify, the -gencrl command worked when leaving the revocation date blank as long as I put "[tab][tab]" between the expiration date (2) and the serial number (4). Idk, if it would cause problems later but i had read it's typically left blank when the index file is created? (Until like you said a certificate needs to be revoked...)

Thank you

 

[zoomzoom]

Just to clarify, the -gencrl command worked when leaving the revocation date blank as long as I put "[tab][tab]" between the expiration date (2) and the serial number (4). Idk, if it would cause problems later but i had read it's typically left blank when the index file is created? (Until like you said a certificate needs to be revoked...)

I didn't know that two tab spaces between the exp. date and serial would solve the issue... I'll also be adding that to the openssl.cnf on GitHub when I make the other edits (should have time tomorrow) Thanks! =]

 

[EvanVanVan]

@zoomzoom Lol it's going so much easier now... On the OpenWRT Wiki in the Clients Certs section, is that a typo that the client cert is signed by the OpenWRT-CA.crt/key instead of the OpenVPN-ICA.crt/key?

Edit: nm, I see the generalize version is signed the same way. Not sure why.
Edit2: Looks like the -CAkey OpenWRT-CA.key in that command is missing a .pem though. (and the req is missing a -. I guess it is a wiki I could just edit it, but I've never done that before lol.)

 

[zoomzoom]

@zoomzoom Lol it's going so much easier now... On the OpenWRT Wiki in the Clients Certs section, is that a typo that the client cert is signed by the OpenWRT-CA.crt/key instead of the OpenVPN-ICA.crt/key?

Edit: nm, I see the generalize version is signed the same way. Not sure why.
Edit2: Looks like the -CAkey OpenWRT-CA.key in that command is missing a .pem though. (and the req is missing a -. I guess it is a wiki I could just edit it, but I've never done that before lol.)

The certificate names in those commands are arbitrary, as they depend on what the end user chooses to name their CA or ICA as. Those commands on that wiki should not be entered as is, as they need to be copied and pasted, then edited to replace names with the names the user chooses to utilize.

 

[EvanVanVan]

The certificate names in those commands are arbitrary, as they depend on what the end user chooses to name their CA or ICA as. Those commands on that wiki should not be entered as is, as they need to be copied and pasted, then edited to replace names with the names the user chooses to utilize.

I understand that (maybe lol) but I still think there's an issue. When creating the VPN user certificates under the Clients Certs section, the 2nd step Sign Cert with CA says:

openssl x509 req -sha512 -days 3650 -in ca/csr/vpn-client1.csr -CA ca/OpenWrt-CA.crt.pem -CAkey ca/OpenWrt-CA.key -CAserial ./serial -out openvpn/clients/vpn-client1-<username>-<hostname>.crt.pem -extfile ./openssl.cnf -extensions v3_openvpn_<username>

Shouldn't that be signed with the ICA instead of the Master CA? i.e. Following the example names used in the wiki: -CA ca/OpenVPN-ICA.crt.pem -CAkey ca/OpenVPN-ICA.key. I understand it's still an arbitrary name, but if it is recommended to be signed with the ICA instead it's seems misleading to use the master CA's name.

Couple other questions/comments:
1. In that same command openssl x509 -req is missing the it's hyphen.
2. Again in that same command the wiki has <hostname> (in bold like that). I understand that it's part of an arbitrary name that can/should be changed, but is it just used in addition to <username> as way of better organizing/keeping track of your users? What would an example <hostname> be?

Thank you

 

[zoomzoom]

It should... I'll get both fixed today. (I completely missed the point you were initially trying to make lol)

In regards to the host name, that's simply how I name my certs, as I create specific certs for specific devices (i.e. same user, but one each for PC, phone, and any other devices the VPN will be accessed from)

• PC: VPN Name - Client 1 - username - PC
  • WRTserver-Client1-foobar-AW18
• Phone: VPN Name - Client 1 - username - Phone
  • WRTserver-Client1-foobar-NX6P

This matters more so when having multiple routers and multiple VPNs for each router... without a naming structure of some kind, it's far too easy to lose track of which certs apply to which VPNs.

• This would also apply to a single router scenario, as OpenWrt can run multiple VPN servers from the same /etc/config/openvpn config file

You could also use a single user certificate across all devices, it's simply user preference and what works best for each user.

If the VPN is for accessing a LAN from WAN, I also highly recommend enabling CCD.

• If one does so, the Common Name must be the name of the individual file with the Client Configuration Directory.
  • For example, I generally set the common name to the user's first & last name, with the device name in parenthesis
    • CN: John Doe (AW18)
  • This would require either naming the file with the proper break format, or with the name in double quotes
    • Either: mkdir -p /etc/openvpn/clients && touch /etc/openvpn/clients/John\ Doe\ (AW18)
    • Or: mkdir -p /etc/openvpn/clients && touch "/etc/openvpn/clients/John Doe (AW18)"
  • CCD files are treated as shell scripts (no need for a shebang, just commands)
    • If you configure the VPN client to have a static IP, this is where you would put the ifconfig command
      • echo 'ifconfig-push 10.0.0.2 255.255.255.248' > /etc/openvpn/clients/John\ Doe\ (AW18)

 

[EvanVanVan]

@zoomzoom Very, very cool (lol seriously). Thanks for walking me through all of that the past couple of days. All of your tips+tricks are most definitely overkill for my security needs (at least I naively assume they are), but in the future I want to go back and implement the ones that I feasibly can... Lucky I have < 5 users so reissuing certs won't be overly difficult.

For my uses Easy-RSA would have probably been sufficient, but now I have a better understanding of how it works. Yeah it was a pain just trying to get the commands to execute and like you said the openssl.cnf was confusing at first, but once I got past that stuff it seems as simple as Easy-RSA (which I had initially used following robles' guide). And I got 4096bit encrypted master key and 3072bit DH key out of it, so at least I have the perception of high security for my peace of mind. (Which of course means nothing if I don't create, secure and store (edit: and -destroy-) them properly lol.)

@robles Hey, thank you for your guide as well... I would not have gotten the VPN server setup without it. Sorry for kind of hijacking the thread the past few days, hopefully others find the security information and tips useful. Thank you again!

 

[zoomzoom]

@zoomzoom Very, very cool (lol seriously). Thanks for walking me through all of that the past couple of days. All of your tips+tricks are most definitely overkill for my security needs (at least I naively assume they are), but in the future I want to go back and implement the ones that I feasibly can... Lucky I have < 5 users so reissuing certs won't be overly difficult.

For my uses Easy-RSA would have probably been sufficient, but now I have a better understanding of how it works. Yeah it was a pain just trying to get the commands to execute and like you said the openssl.cnf was confusing at first, but once I got past that stuff it seems as simple as Easy-RSA (which I had initially used following robles' guide). And I got 4096bit encrypted master key and 3072bit DH key out of it, so at least I have the perception of high security for my peace of mind. (Which of course means nothing if I don't create, secure and store (edit: and -destroy-) them properly lol.)

No problem at all. =]

A few points:

• Easy-RSA does not create proper VPN certs.
  • It is the quick and dirty way of doing certs, and should be avoided at all costs.
    • I compare it to using UPnP on routers.... sure it's convenient, and doesn't require the 30 seconds to manually forward the ports, but it also isn't secure.
      • It's a one size fits all approach... like Henry Ford said, "You can have your car in any color you want, as long as it's black".
  • It uses an openssl.cnf to create certs, but severely cripples what the user can/cannot do.
    1. It is not capable of creating certs with EKUs (serverAuth, clientAuth)
    2. It does not allow customization using SANs, therefore certs from Easy-RSA must use a single common name.
    3. It does not allow setting pathleen values, of which determines how many, if any, CAs/ICAs a CA/ICA can sign.
    4. It does not allow assigning certain values as a critical.
    5. The CA it creates is not a secure CA, as it does not match the accepted standard for the specific restrictions a CA/ICA should have
    6. It will create problems with certain routers/router OSes (such as Sophos), which requires the router's CA to have the loopback IP specified in the SAN profile.

• DH cert should not exceed 2048bit, unless you're using EC [Elliptic-Curve], of which OpenVPN will not support until version 2.4 is released
  • No idea when 2.4 will be released, as we've been on 2.3 for quite a few years, but whenever it is, it will include EC support, enabling the use of ECDH and ECDHE.
  • When EC is supported, all DH certs, keys, and hashes must exceed the value of the encryption one desires.
    • I thought I updated the config with this information, however it is possible I made a note to do so, but didn't actually make the change.
  • It is recommended to add TLS Ciphers and TLS options to your OpenVPN server config (see my OpenVPN config on my GitHub: JW0914.GitHub.io)

• It's not about high security, but simply security and privacy in general
  • If one is creating a VPN, then the individual obviously has security and privacy concerns, otherwise there'd be no need for the VPN.
    • 2048bit/AES256 are both currently uncrackable and will remain so until at least 2030, or a major breakthrough in quantum computing.
  • Anything over 2048bit is overkill, but would be necessary depending on the information being protected (corporate business, governmental classifications, citizens of oppressive governments, etc.)
  • Hashes should be at least SHA256, and if using 64 bit architecture, SHA512 (x64 processes SHA512 faster than SHA256 & SHA384)

 

[robles]

@ram Exactly what is your post supposed to be about, as there's no discernable purpose one can garnish from your post.

• If you were posting in reference to @kpeng, they need to post their log files for troubleshooting... simply posting config files for someone with issues does nothing, as it doesn't demonstrate where the issue is. The only way to discern what the exact issue is, log files must be queried.

While TCP can be used for OpenVPN, there's only two use cases for it:

1. Troubleshooting
2. High packet loss when utilizing UDP

Outside of those two use cases, TCP should not be utilized, as TCP cannot efficiently encapsulate itself.

I have an OpenVPN server using TCP over 443 to bypass strict firewall rules, so there are definitely cases you can use it. It's not recommended though, as it might yield high latencies.

I also thank you for helping people with their setups, but will politely ask the conversation be about this tutorial. If you'd like you can open another thread regarding your OpenWRT-Wiki instructions as @Suprazz did with his VPN tutorial. This is for organizational purposes, as people looking for answers on this tutorial will have to circle through the noise.

To everyone else, thanks for your support. This guide was made with the community in mind, and will always try to give something back for all of your help.

 

[zoomzoom]

I have an OpenVPN server using TCP over 443 to bypass strict firewall rules, so there are definitely cases you can use it. It's not recommended though, as it might yield high latencies.

This would fall into the only other use case besides troubleshooting, high packet loss using UDP, as TCP literally cannot efficiently encapsulate itself.

• I'd be curious to know if anyone has tried udp over port 80 to bypass strict firewalls, as that would be far more ideal.

I also thank you for helping people with their setups, but will politely ask the conversation be about this tutorial. If you'd like you can open another thread regarding your OpenWRT-Wiki instructions as @Suprazz did with his VPN tutorial. This is for organizational purposes, as people looking for answers on this tutorial will have to circle through the noise.

The conversation has been about this tutorial and using an openssl.cnf in lieu of Easy-RSA to generate certs...

• Please re-read the posts, looking past arbitrary certificate name references, referenced so because they're generic names within the openssl.cnf linked in my signature.
  • While I do believe @EvanVanVan referenced my OpenWrt OpenVPN wiki once or twice, the posts were always in regards to utilizing an openssl.cnf to generate certs in lieu of Easy-RSA in respect to this thread's tutorial

With that being said, this is your thread about your tutorial. If you believe the posts distract from the purpose of this thread, I'm more than happy to move them to their own separate thread.