@bonnietwin , i think i found the problem according to @tphz expiring date catch from above. The investigation of the certificate for the expiring date includes only *.pem files but an N2N client import includes only a *.p12 file and no *.pem . The OpenSSL command uses the x509 flag so it covers no PKCS#12 files but even if, the PKCS#12 container does not contain ‘Validity’ information.
Potential solution: ovpnconfig´s index contains “IPFire n2n Client” as a potential search string to investigate the connection name(s) which needs to be extracted into PEM format to read out the “Not After” line for calculation.
May someone can confirm ?
Best,
Erik
@tphz
if you want to check a potential solution for your problem above, does this →
for i in $(awk -F',' '/IPFire n2n Client/ { print $3 }' /var/ipfire/ovpn/ovpnconfig); do
openssl pkcs12 -in /var/ipfire/ovpn/certs/${i}.p12 -out /var/ipfire/ovpn/certs/${i}cert.pem -nodes -password pass:''
chown nobody:nobody /var/ipfire/ovpn/certs/${i}cert.pem
done
fix the “Client Status and -Control” overview of the N2N client ?
Does CU174 break existing OpenVPN c2n profiles that still rely on an old host certificate w/o key usage extention? I think I read somewhere that OpenVPN server 2.6.x will do so?
Or is it still safe for me to update w/o the need to re-create all client profiles?
The last openvpn server version change was to 2.5.8 in CU172.
What is being mentioned in the posts above is related to a commit to the perl code for the OpenVPN WUI page that will flag up how much time is left on client connection certificates.
The key usage extension was updated around 2019, maybe earlier. I have references to CU145 but also some back to CU115.
If it doesn’t get updated then eventually something will break. I don’t know if that will occur with version 2.6.0 or not.
Im asking since there are some removed/changed features in the changelog of 2.6.0 regarding cipher and certificate handling: openvpn/Changes.rst at master · OpenVPN/openvpn · GitHub
AFAIS one needs to set --compat-mode to be able to use old configurations and I don’t see any checkbox for that in IPFIre’s OpenVPN WUI. I can add that to the “server.conf.local”, of course.
Anyway, I’ll do some tests with a clone of my productive setup the next days to see if --compat-mode really helps. If not, we should add a warning to the release notes.
version 2.6.0 has some major changes and is therefore not being put into place yet.
Some significant changes are needed to the WUI due to trying to maintain older connection setups of users so that we try and avoid breaking existing setups.
If you have connection setups with older ciphers then when we have a modified WUI code it would be good if you will be able to test out the changes, as all of my setups have systems that I am unable to test old ciphers on.
If CU173 is working for you without --compat-mode then CU174 will also work.
I believe that will only be needed when version 2.6.0 is released in IPFire and that won’t happen till the WUI changes mentioned above have been worked out and tested.
which won´t need additional *.pem files in /certs are not a good solution since the information button for N2N clients is then useless.
The bash snipped or something with the same affect from above might be something for update.sh and all already existing N2N client connections but changes needs to be done in ovpnmain.cgi for every new N2N client import may somewhere around here ?
I would expect that it will apply in either case. It is only a flagging of the status. It doesn’t change anything in the certificate.
My understanding from @ummeegge in an earlier post is that the code is looking for .pem files but the N2N only uses .p12 files and the check process for the date in the certificate is probably getting an error message which is being translated as that the certificate has expired. (I have not looked through the code so this is a presumption on my behalf).
@tphz
I am glad you found and reported this bug. I am following the topic.
We did well to hope for help from other users.
I thank you for encouraging me in the previous post to help you.
Although I figured out how to configure n2n in IPFire, I couldn’t help you in any way because I don’t have “another n2n server to hook into,” so I can’t do any testing.
Unity is strength. This is the strength of the IPFire community!!!
I try to describe a scenario, just encountered for CU173 stable. I do not know if it is normal and I do not know if it also occurs for CU174 test.
I set up 2 rules in the firewall:
The first one performs a port forward to local port 68nn for external IP 176.n.n.n avoiding creating the LOG.
The second performs a port forward to local port 68nn for all Italian external IPs, creating the LOG.
Despite these 2 rules, it seems from the LOGs that there are (from time to time) DROP_INPUT conditions for IP 176.n.n.n
Is this normal?
The firewall rules shown have a destination of 172.16.3.1 while the drop log message is for a destination of 192.168.111 4 and therefore does not match your rules. So the drop message is normal.
You are absolutely right. I got confused with the RED, since my router forwards to 192.168… In fact, I tried disabling the first rule. all OK!!! I thank you and apologize for not checking properly before .
It would appear that some packets (which the router forwards to 192.168.111.4) are not being forwarded over to orange. Since this is a condition that does not comply with the rules I have set, it logically gets blocked .
.
someone is needed to report a bug !
.