OpenVPN-2.4.0 integration into IPFire

Help on building IPFire & Feature Requests
ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN-2.4.0 integration into IPFire

Post by ummeegge » February 8th, 2017, 10:46 am

Have found the reason of this error
cibgiu wrote: Make the first connect but hang, on opnevon log: 'VERIFY ERROR: depth=0, error=CRL has expired'
Little googling and find the solution https://forums.openvpn.net/viewtopic.php?t=23166
The OpenVPN-2.4.0 developers integrated an "Refactor CRL handling" --> https://community.openvpn.net/openvpn/c ... e07016a336 which means "extra checks will be performed on the CRL, such as checking it validBefore and validAfter fields" . It might makes sense to adjust the "default_crl_days" to the CAs "default_days" which works currently with OpenSSLs maximum of "999999".
cibgiu wrote:in /var/ipfire/ovpn/openssl/ovpn.cnf default_crl_days from 30 to 3650
this value might also be OK even after 10 years the same question arises again (i know what you are thinking "what might be in 10 Years " :D ).
Nevertheless i adjust it now to the CA default_days and have tested if some already revoke certificates are still revoked.


EDIT: Deleted instructions to change CRL default days see below:
The following commands renews your CRL:

Code: Select all

openssl ca -config /var/ipfire/ovpn/openssl/ovpn.cnf -gencrl -out /var/ipfire/ovpn/crls/cacrl.pem
which should solve the described problem in my opinion.


So i think no problem to go this way... Won´t touch this Param cause this should be solved via renewing the CRL and should normally work via system

A bug report on Debian reflects this problem too --> https://bugs.debian.org/cgi-bin/bugrepo ... bug=849909 .
EDIT: After a deeper look i changed this in the installer script (it won´t touch the openssl config) cause i can´t confirm to leave the same days for the crl default days as it is for the days of the CA.

If i have more time i will integrate it in the installer, until then you might need to make this by your own.
DONE with in- uninstaller script
unDONE again

May someone have better ideas for that ?
An idea can be to bring on a button to renew the CRL ?! So if a machine hasn´t been touched for a long time, it might be possible to renew the CRL ???

Thanks again Giuseppe good that you found that.

Greetings,

UE

EDIT: Have added the CRL fix in the in- uninstaller script, uninstallation removes the changes in ovpn.cnf again to bring back the old state.
Changed it back to default behavior and the script won´t touch the openssl config.
Default value for "default_crl_days" findable under /var/ipfire/ovpn/openssl/ovpn.cnf is

Code: Select all

default_crl_days                = 30
Image
Image
Image

fkienker
Posts: 72
Joined: March 3rd, 2011, 4:59 pm

Re: OpenVPN-2.4.0 integration into IPFire

Post by fkienker » February 9th, 2017, 6:11 pm

FYI re wireguard - it is still relatively experimental and AFAIK Linux only. No Windows road warrior means it is pointless for most of us.

Thanks csmall for the useful information. I will look out for this. My intention is to put this on a x64 system and test it shortly. Is there any reason x64 testing would not apply to x32?

The change from the old 999 day maximum certificate expiration is really useful. Just yesterday a site got "bitten" by this limit. 10 years sounds like a lot but it really isn't.

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN-2.4.0 integration into IPFire

Post by ummeegge » February 19th, 2017, 8:52 am

Hi,
fkienker wrote: The change from the old 999 day maximum certificate expiration is really useful. Just yesterday a site got "bitten" by this limit. 10 years sounds like a lot but it really isn't.
just to make it a little clearer (needed also to have a deeper look into it), the "VERIFY ERROR: depth=0, error=CRL has expired" error depends on the 'default_crl_days' not on the "default_days" for the CA validity .

The CA validity:
is on IPFire per default set to '999999' days which is the OpenSSL maximum and is about 2737 years, 10 months and 30 days if i count it correctly. So a today created CA looks like this:

Code: Select all

        Validity
            Not Before: Feb 19 06:36:59 2017 GMT
            Not After : Jan 16 06:36:59 4755 GM
(checkable over the information button via WUI).

The CRL default days:
The CRL expires after 30 days and should be updated over the system in my opinion. So i think this param is there to set the value for the date of the next update --> https://books.google.de/books?id=IIqwAy ... ys&f=false , a discussion causing this topic --> http://openssl.6102.n7.nabble.com/CRL-a ... 49987.html might be interessting too .
The malfunctioning in case of cibgiu might be cause his system was a longer time off... ?! Haven´t had such problems here either...

Have changed the script back so the ovpn.cnf won´t be touched, have edited also this post --> https://forum.ipfire.org/viewtopic.php? ... 7&start=15 .

In case i´m wrong, just say something ;) .

UE
Image
Image
Image

mariad
Posts: 4
Joined: February 22nd, 2017, 9:43 am

Re: OpenVPN-2.4.0 integration into IPFire

Post by mariad » February 22nd, 2017, 10:03 am

@ummeegge
Great Job i must say
Well done

doc
Posts: 121
Joined: June 5th, 2014, 12:33 pm
Location: Hannover

Re: OpenVPN-2.4.0 integration into IPFire

Post by doc » April 7th, 2017, 9:08 am

I really hoped it would make its way in core 110...

What's the actual status/plan?
Image

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN-2.4.1 integration into IPFire

Post by ummeegge » April 7th, 2017, 5:09 pm

Thank you both for your replays,
doc wrote:I really hoped it would make its way in core 110...
i can understand that, have also hoped for more testings and feedback in here.

As i said before, this changes (also in the minimum version) are really not only an beside update, this one is a bigger one and i would really love/need to have more testing people to go a step further for a merge request.
A good thing is, the first update of a big version jump (*.0) can include sometimes bigger bugs (also if i haven´t had/find some bigger ones in 2.4.0) so it can be wise to wait for the next version which fixes them mostly but could bring on also some extensions... So now here we are OpenVPN-2.4.1 is out --> https://community.openvpn.net/openvpn/w ... nOpenvpn24 , lz4 is meanwhile also with version 1.7.5 out --> https://github.com/lz4/lz4/releases/tag/v1.7.5 .
doc wrote:What's the actual status
My status is currently:
- Testing the new OpenVPN-2.4.1 and LZ4-1.7.5 versions .
- Give the different key length of the PKI a good testing round.
--> my N2N works currently nice with a ROOT key length of 12288 bit, HOST key length with 8192 bit RSA and a 4096 bit DH-parameter. The tls-crypt function works as a good beside one with AEAD (AES-256-CTR) but also GCM AES-256-GCM makes a very good impression same with the elyptic-curve crypto for the DHE exchange for the control channel (noticeable faster).

Connection log for N2N 32 Bit and new OpenVPN-2.4.1 on one side:

Code: Select all

Apr  7 16:59:58 ipfire-32bit UE2n2n[1530]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Apr  7 16:59:58 ipfire-32bit UE2n2n[1530]: OpenVPN 2.4.1 i586-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr  5 2017
Apr  7 16:59:58 ipfire-32bit UE2n2n[1530]: library versions: OpenSSL 1.0.2j  26 Sep 2016, LZO 2.09
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:12324
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: ROUTE_GATEWAY 192.168.221.1/255.255.255.0 IFACE=red0 HWADDR=00:d0:08:67:dd:ec
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: TUN/TAP device tun1 opened
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: TUN/TAP TX queue length set to 100
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: /sbin/ip link set dev tun1 up mtu 1500
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: /sbin/ip addr add dev tun1 local 10.5.6.2 peer 10.5.6.1
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: /sbin/ip route add 192.168.6.0/24 via 10.5.6.1
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: /sbin/ip route add 192.168.7.0/24 via 10.5.6.1
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: TCP/UDP: Preserving recently used remote address: [AF_INET]91.192.xxx.xxx:12324
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: Socket Buffers: R=[180224->180224] S=[180224->180224]
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: UDP link local (bound): [AF_INET]192.168.221.2:12324
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: UDP link remote: [AF_INET]91.192.xxx.xxx:12324
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: GID set to nobody
Apr  7 16:59:58 ipfire-32bit UE2n2n[1531]: UID set to nobody
Apr  7 17:00:01 ipfire-32bit UE2n2n[1531]: TLS: Initial packet from [AF_INET]91.192.xxx.xxx:61000, sid=d26e2374 13d02b37
Apr  7 17:00:01 ipfire-32bit UE2n2n[1531]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:12324
Apr  7 17:00:01 ipfire-32bit UE2n2n[1531]: MANAGEMENT: CMD 'state'
Apr  7 17:00:01 ipfire-32bit UE2n2n[1531]: MANAGEMENT: Client disconnected
Apr  7 17:00:01 ipfire-32bit UE2n2n[1531]: VERIFY OK: depth=1, C=DE, ST=HH, L=Hamburg, O=xxxx, OU=xxxx, CN=xxxx CA, emailAddress=xxxx@web.de
Apr  7 17:00:01 ipfire-32bit UE2n2n[1531]: VERIFY OK: nsCertType=SERVER
Apr  7 17:00:01 ipfire-32bit UE2n2n[1531]: VERIFY OK: depth=0, C=DE, ST=HH, O=xxxx, OU=xxxx, CN=xxx.xxx-gateway.de
Apr  7 17:00:04 ipfire-32bit UE2n2n[1531]: Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr  7 17:00:04 ipfire-32bit UE2n2n[1531]: Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr  7 17:00:04 ipfire-32bit UE2n2n[1531]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 8192 bit RSA
Apr  7 17:00:04 ipfire-32bit UE2n2n[1531]: [xxx.xxx-gateway.de] Peer Connection Initiated with [AF_INET]91.192.xxx.xxx:61000
Apr  7 17:00:05 ipfire-32bit UE2n2n[1531]: Initialization Sequence Completed
The other side 64 bit machine with OpenVPN 2.4.0:

Code: Select all

Apr  7 16:59:52 ipfire-64bit UE2n2n[2140]: TLS: Initial packet from [AF_INET]79.238.xxx.xxx:12324, sid=a6439375 87a441f2
Apr  7 16:59:55 ipfire-64bit UE2n2n[2140]: VERIFY OK: depth=1, C=DE, ST=HH, L=Hamburg, O=xxxx, OU=xxxx, CN=xxxx CA, emailAddress=xxxx@web.de
Apr  7 16:59:55 ipfire-64bit UE2n2n[2140]: VERIFY OK: depth=0, C=DE, ST=HH, O=xxxx, OU=FZeit, CN=UE2
Apr  7 16:59:56 ipfire-64bit UE2n2n[2140]: Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr  7 16:59:56 ipfire-64bit UE2n2n[2140]: Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr  7 16:59:56 ipfire-64bit UE2n2n[2140]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 8192 bit RSA
Apr  7 16:59:56 ipfire-64bit UE2n2n[2140]: [UE2] Peer Connection Initiated with [AF_INET]76.248.xxx.xxx:12324
Apr  7 16:59:57 ipfire-64bit UE2n2n[2140]: Initialization Sequence Completed
doc wrote:plan?
OpenVPN changes a lot of directives which might be sooner or later a kind of stress.
- "WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead."
EDIT: Needs a bigger think about, quote from OpenVPNs EasyRSA3 howto --> https://community.openvpn.net/openvpn/w ... nVPN-Howto:
Easy-RSA and MITM protection with OpenVPN

Important note: some OpenVPN configs rely on the deprecated "Netscape" cert attribute called nsCertType. This is deprecated behavior, and Easy-RSA 3 does not enable this by default like v2 did. Please use the --remote-cert-tls directive in your OpenVPN config files for MITM protection.

If you really need the old, deprecated behavior, enable the Netscape extensions by reading vars.example before signing certs with your CA. This will allow you to use --ns-cert-type with OpenVPN.
this might be not that funny, sounds a little bit like the known "--tls-remote" scenario but i think it is more worse since the certificates needs to be signed with the CA in that way. So an easy switch with the directives from "--ns-cert-type" to "--remote-cert-tls" is not possible in my opinon cause the old certificates won´t work anymore and needs to be generated again with the new directive...
--> needs to be changed with 2.5.x ...
- "--comp-lzo [mode] " is deprecated and will be substitued with "--compress [algorithm]" , haven´t find the exact time when this will happened. This might be not that huge problem cause OpenVPN-2.4.x can push this directive to the clients even this is not possible with N2N but the mostly larger scale of RW clients can go there an easier way.
--> Nevertheless, this should also soon be changed.
This announcements can be found in here --> https://community.openvpn.net/openvpn/w ... n24ManPage and here --> https://community.openvpn.net/openvpn/w ... nVPN-Howto.
For the home users and smaller cooperations this might be not that hard to manage but i haven´t found currently a proper way to go there an easy way for the users with 100 or more clients, there needs to be more testings in that specific manner may we can find a good way ?!
- Testings with longer RSA key lengths but also with EC-Crypto in general might be nice.
- Two factor authentication ẃill come in the next days for some testings in my environment.
....

In this topic may there will come:
- A new installer with the new versions and may a possibility for lz4 compression also for N2N connections (RW got it already).
Image

EDIT: Will release the new versions with Core 110. The old one is again/still available

There is more, but for the first some more feedback from the community in here might be a good/important thing even i can´t integrate this into my "plan" but surely into an "status"...

Let´s see.

Greetings,

UE
Image
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN-2.4.0 integration into IPFire

Post by ummeegge » May 15th, 2017, 8:24 pm

Hi all,
just für die Akten. OpenVPN-2.4.2 is out --> https://openvpn.net/index.php/open-sour ... loads.html and there has been some interesting news with this release.
OpenVPN found some resources --> https://www.privateinternetaccess.com/b ... ry-report/ which paid a security audit --> https://ostif.org/the-audit-of-openvpn-is-complete/ --> https://community.openvpn.net/openvpn/w ... neerAudits . The results are pretty interesting in my opinion and all in all i think the results are pretty OK even there are some criticals in there which are, as far as i can see, not exploitable on IPFires default configuration.

As promised, i made a new version for Core 110 which includes:
- Updated language files.
- The current new OpenVPN version 2.4.2 .
- New LZ4-1.7.5 version.
- Compression menu (choice between LZO, LZ4-v2 and none) also for N2N connections (as shown above). <-- By reading the security audit this might not be the securest feature...

I left the installer now out since there seems to be not much interest for testing and support with that. Nevertheless, since i used it for myself, in here --> http://people.ipfire.org/~ummeegge/OpenVPN-2.4/ the 32 and 64 bit versions for minimal and extended versions can be found.

Greetings,

UE
Image
Image
Image

fkienker
Posts: 72
Joined: March 3rd, 2011, 4:59 pm

Re: OpenVPN-2.4.0 integration into IPFire

Post by fkienker » May 19th, 2017, 5:11 pm

Thanks for the update. I am going to try to pull this to a test box this weekend, time permitting. Will attempt to give you some feedback after that.

Best regards,
Fred

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN-2.4.3 integration into IPFire

Post by ummeegge » June 27th, 2017, 4:05 pm

Since OpenVPN have had a second security audit made by Guido Vranken whereby some vulnerabilities has been found --> https://community.openvpn.net/openvpn/w ... OpenVPN243, OpenVPN released a version 2.4.3 --> https://openvpn.net/index.php/open-sour ... loads.html --> https://community.openvpn.net/openvpn/w ... nOpenvpn24 which fixes those problems.

Made therefor also a new version which also includes the new language files for Core 111 which can be found as before in here --> http://people.ipfire.org/~ummeegge/OpenVPN-2.4/ .
I do not made an installer for this cause there was no testing feedback for this, but a README can be found under the mentioned address.

Made also a possible fix for the in here --> https://forum.ipfire.org/viewtopic.php? ... 15#p106499 mentioned problem with
- "WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead."
which is, as already feared more work :( ... Fix can be found in here --> https://forum.ipfire.org/viewtopic.php?f=50&t=18852 which works good for me... --> If someone have better ideas your welcome to bring them on.

Greetings to all,

UE
Image
Image
Image

Post Reply

Who is online

Users browsing this forum: rodneyp, xPliZit_xs and 1 guest