Helo,
… only one short question:
since 17.07.24 it is not possible to get connection over Openvpn.
We checked IPFire - no updates or changes at 17.07.24
We checked LANCOM router on red - firmware up-to-date, no changes to see.
If we are testing connection on UDP 1194: sudo nmap -p 1194 -sU 80.153.xxx.yyy Starting Nmap 7.80 ( https://nmap.org ) at 2024-07-20 11:36 CEST Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.06 seconds
10 tests … 2 times connection for some seconds sudo nmap -p 1194 -sU 80.153.xxx.yyy Starting Nmap 7.80 ( https://nmap.org ) at 2024-07-20 11:31 CEST Nmap scan report for pxxxxxx.dip0.t-ipconnect.de (80.153.xxx.yyy) Host is up (0.040s latency). PORT STATE SERVICE 1194/udp open|filtered openvpn
Someone knows the reason? Is it CROWDSTRIKE affaire ?
Thanks and sorry,
… we use IPFire 2.29 (x86_64) - Core-Update 186 since a while without problems:
oVPN log from 10…20.07.2024:
Verbindungs-Name
Verbunden
Getrennt
Dauer
Empfangen
Gesendet
support
2024-07-12 10:23:07
2024-07-12 10:35:59
12m 52s
3.17 MB
27.64 MB
support
2024-07-13 12:32:34
2024-07-13 12:41:49
9m 15s
1.39 MB
12.90 MB
support
2024-07-16 07:49:11
2024-07-16 08:05:17
16m 6s
946.70 KB
6.33 MB
support
2024-07-17 07:59:12
2024-07-17 08:22:18
23m 6s
4.56 MB
36.28 MB
support
2024-07-17 09:32:23
2024-07-17 09:36:31
4m 8s
582.30 KB
3.90 MB
support
2024-07-17 11:23:23
2024-07-17 11:25:57
2m 34s
18.99 KB
14.44 KB
What logfile you mean ? Is it to find on web interface or only via SSH ?
P.S. : I found the string “VERIFY ERROR: depth=0, error=CRL has expired” in /var/log/messages via ssh.
But I don’t understand the workaround … What should I edit ?
That could be the case. As mentioned in that thread, the bug is related to when the CRL expires. The CRL typically has a validity time of 1 month so if when you updated to CU186 there was three weeks to go then there would be no problem until the three weeks was up and the CRL expired. The bug is related to the automatic updating of the CRL.
Yes. On the WUI menu there is an entry at the most right hand end of the menu entries labelled Logs. In the Logs list at the bottom there is an entry labelled System Logs. select that.
In the drop down box labelled Section: you will find an entry labelled OpenVPN. Select that and then press the Update button. You will then see the logs for the OpenVPN server. Search in there for any CRL messages that include VERIFY ERROR.
To make it simpler you can choose All for the Date entry (it is at the top of the date list, just before 1 ) and then press the update button and then after the logs are updated press the Export button. The whole logs for the chosen time period will be provided in a web page and you can then use the search function of the browser to search for VERIFY ERROR in that page.
That command will update the CRL using the new updated location for the ovpn.cnf file.
It will not fix the bug but it will renew the CRL for another month and by then Core Update 187 should be released, it is already out in Testing phase and would be expected to be released fully by end of July. That update has the bug fix in it and will ensure that the automatic update of the CRL occurs again.
You shouldn’t have needed to reboot only stop and restart the OpenVPN server on the WUI. However reboot should have done the same thing.
Do you still see the CRL Verify Error message in the OpenVPN log for times after when you ran the command.
When you ran the command did it give any error messages or no message at all. The latter together with no CRL Verify Error in the log would say that the CRL bug issue has been resolved so there must be some other issue.
To track that new issue down the best approach is to look at the OpenVPN Server log on IPFire and at the OpenVPN Client’s log on whatever device you are trying to do the roadwarrior connection with.
The logs are your friend. In the vast majority of cases the cause of the problem being experienced can be identified from the logs.
I just had the same problem today, yesterday everything was fine.
So, I updated the CRL manually like mentioned above. But it did not work without a reboot, sorry.
When executing the openssl command, I discovered a mismatch, at least I think it’s a mismatch. The pathname in the command says /var/ipfire/ovpn/crls/…, while in /usr/share/openvpn/ovpn.cnf (line 12 here) the path resolves to /var/ipfire/ovpn/crl.
Note, there is no s at the end.
You are right that is a mismatch to my mind also. However that has been like that for a long time. At least since CU100 8 years ago.
I suspect that the openvpn-crl-updater script and any other code working on the CRL is not using that variable from the ovpn.cnf
At least that is the only reason I can think of.
I will check through the code and see if it is used anywhere.
I will also do an update to correct it so that if it is used in the future that it will not then cause a problem.
EDIT:-
I have looked through the openvpn-crl-updater and the ovpnmain.cgi for the crl directory.
In the updater script it creates a variable at the beginning of the script that specifies /crls/ and that variable is used in the openssl commands used in the updater.
In the cgi script all the openssl commands have the out option specified with a path that explicitly specifies /crls/
In neither case is the crl directory taken from the ovpn.cnf file
The question might even be if we need all of that specified or not, but at least while the crl dir is pecified in there it will be corrected to /crls/
Thanks for flagging it up.
EDIT2:-
Looking vat the man page for the openssl crl command, -config does not look to be an available option. Therefore it might be that nothing will ever be taken from the ovpn.cnf for the crl command.
The -config option is an available option for the openssl req or the openssl ca commands.
Helo,
today we were in the office - the Firewall-PC hanged loading BIOS.
Repetition of reboot - no problems - and openVPN is OK again …
Greetings and thank you for the help !
CRL has expired issue mentioned above was this fixed in build 187.?
I just lost connectivity with two firewalls on same site ( internet reported as working fine ) both were updated a few days ago to build 187 and have been rebooted post install ?
The file openvpn-crl-updater has the correct openssl.cnf location and it is working for me.
My CRL was updated 10 days ago and that was 10 days after I upgraded to CU187. So the updater worked for me automatically with Core Update 187.