OpenVPN-2.4.x integration into IPFire

Help on building IPFire & Feature Requests
ummeegge
Community Developer
Community Developer
Posts: 4216
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: 76
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: 4216
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: 4216
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: 4216
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: 76
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: 4216
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

Hellfire
Posts: 306
Joined: November 8th, 2015, 8:54 am

Re: OpenVPN-2.4.0 integration into IPFire

Post by Hellfire » August 21st, 2017, 7:21 pm

Hi,

I would like to try out the latest OpenVPN pakage. Is there already a complete installer available that contains all fixes or better that is "feature" complete?
Does the installer itself or more generally spoken the new OpenVPN implementation, support Core 112, x64?

Out of interest: I've recently changed my IPFire installation from a VM to a "real" hardware, a APU2B4 board. Since then I noticed that connecting from my Android Smartphone, using OpenVPN for Android, to IPFire does now stop at the time of authentication and tries to resume again and again in an endless loop until I stop this process. Any chance that this is caused by the recent "hardware" change?

greets,
Michael
Image

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

Re: OpenVPN-2.4.0 integration into IPFire

Post by ummeegge » August 27th, 2017, 8:49 am

Hi Michael,
the last update for OpenVPN has been made for Core 112 --> http://people.ipfire.org/~ummeegge/OpenVPN-2.4/ but i have currently only testing results from myself, nevertheless only the language files has been changed. In Core 111 some more testings has been done, that´s why there is currently only a README in there available how to install this on your own.
64 bit has beneath 32 bit always been supported in this topic.

Installer: I left the installer out since there has been not that much interest and testings, feedback and requests therefor it made not much sense for me to make more work as a minimum requires, may this can be changed but only if there is more interest for this otherwise my time is better elsewhere invested...

There has been made also some other work (Bugfixes and features) also for the current official IPFire version which are not included in this topic but i think about to integrate them in here too. May i will leave the "minimal version" out for comming updates then and provide only the extended version with fixes for:
- https://bugzilla.ipfire.org/show_bug.cgi?id=11364
- https://bugzilla.ipfire.org/show_bug.cgi?id=11307
- https://bugzilla.ipfire.org/show_bug.cgi?id=10482
- https://bugzilla.ipfire.org/show_bug.cgi?id=11424 <-- which i did not tested until now but i looks good for me.
- https://forum.ipfire.org/viewtopic.php?f=50&t=18852 <-- which is part of #11364 .

EDIT: Some deprecations --> https://community.openvpn.net/openvpn/w ... tedOptions needs to be better overviewed and also tested.
Hellfire wrote:
August 21st, 2017, 7:21 pm
Out of interest: I've recently changed my IPFire installation from a VM to a "real" hardware, a APU2B4 board. Since then I noticed that connecting from my Android Smartphone, using OpenVPN for Android, to IPFire does now stop at the time of authentication and tries to resume again and again in an endless loop until I stop this process. Any chance that this is caused by the recent "hardware" change?
When i read Android and authentication problems also without seeing the error log messages, i do have currently a suspicion which can be read in the above mentioned last link --> https://forum.ipfire.org/viewtopic.php?f=50&t=18852 . If you can find the in there described log error messages too, you can try then also the provided solution in there.

Am currently on vacation but if i am back home again i can go for another version with the above mentioned new points and may also a new in- uninstaller if enough interest is there to test all that and to bring on also some feedback which is important for further steps or a merge request.

Greetings,

UE
Image
Image
Image

Hellfire
Posts: 306
Joined: November 8th, 2015, 8:54 am

Re: OpenVPN-2.4.0 integration into IPFire

Post by Hellfire » August 28th, 2017, 9:40 am

So have nice vacations and give some signal if you are at home again ;D

cu
Michael
Image

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

Re: OpenVPN-2.4.x integration into IPFire

Post by ummeegge » September 5th, 2017, 8:11 am

Hi all,
updated version has been uploaded. Version includes now:

- All in here mentioned features/updates.
- Sources (OpenVPN-2.4.3 and lz4-1.8.0) has been compiled with Core 113 (new toolchains) and for Core 113 (language files).
- There are no 'minimal' or 'extended' versions anymore but all changes has been merged together (all packages are now 'extended' so to call).
- Packages are as before available for 32 and 64 bit versions which are marked in the package with _32_ or _64_ there is no ARM package currently available.
- Bugfixes has been integrated for:
- https://bugzilla.ipfire.org/show_bug.cgi?id=11364
- https://bugzilla.ipfire.org/show_bug.cgi?id=11307
- https://bugzilla.ipfire.org/show_bug.cgi?id=10482
- https://forum.ipfire.org/viewtopic.php?f=50&t=18852 <-- which is part of #11364 .
- Code has been reduced in N2N plausicheck section.
- No installer but a README with a howto install it can be found in here --> http://people.ipfire.org/~ummeegge/OpenVPN-2.4/ .
- The new packages can be found also in here --> http://people.ipfire.org/~ummeegge/OpenVPN-2.4/ <-- use the highest core number.
- Start topic has been updated --> https://forum.ipfire.org/viewtopic.php?f=50&t=18067 to the actual state.
- All changes can be overviewed and compared with the current actual IPFire Core 113 version in here --> https://github.com/ummeegge/OpenVPN_30. ... pnmain.cgi .

As before, testings, feedback and/or extensions are welcome and important.

So far from here. Greetings,

UE
Image
Image
Image

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

Re: OpenVPN-2.4.x integration into IPFire

Post by ummeegge » October 9th, 2017, 2:13 pm

Image
Image
Image

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

Re: OpenVPN-2.4.x integration into IPFire

Post by fkienker » October 9th, 2017, 4:15 pm

Will the Core 113 work with Core 114 or will you need to update your packages to support Core 114?

Best regards,
Fred

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest