Problem with host certificate / destroyed OpenVPN

tobias · 6 April 2020 16:01

Dear all,

I was wondering if you could help me with a problem I’m having with OpenVPN in combination with IPFire 2.25 (i586) - Core Update 142.

The other day I ran into the problem (german):

Das Host Zertifikat ist nicht RFC3280 Regelkonform.
Bitte IPFire auf die letzte Version updaten und generieren sie ein neues Root und Host Zertifikat so bald wie möglich.

I updated IPFire (from 138) and since then the OpenVPN service could not be started anymore. I replaced the /var/ipfire/ovpn/server.conf file according to this thread in the old forum:
https://forum.ipfire.org/viewtopic.php?f=16&t=21330

This didn’t help either.

I deleted the x509 certificate and set it up as new (2048 bit) but I’m still unable to get this thing to work. I am unable to start the OpenVPN service, even rebooting didn’t bring it back up.

It was still working last week (RoadWarrior configuration), so I’m wondering what went wrong anyone able to help me with this? I’d be glad to answer your questions, I know I might probably not have covered everything in my explanation.

Thanks for your help in advance!
Best regards
Tobias

ummeegge · 6 April 2020 16:14

Hi tobias,
if the OpenVPN server do not starts there should be something findable under /var/log/httpd/error_log, if something hangs with the configuration you should also be able to find something with a
grep openvpn /var/log/openvpn
. As a beside one, the mentioned topic from the old forum is about the appropriate entries in /var/ipfire/ovpn/openssl/ovpn.cnf which is responsible for the ‘Extended Key Usage’ .

Best,

Erik

tobias · 6 April 2020 16:47

Dear Erik,

thanks for your quick comment.

The forum entry I was referring to had the same original error described, that’s why I was trying to work this case. Anyway as this did not help let me quickly sum up the latest findings.

Output of /var/log/httpd/error_log:

> [Mon Apr 06 13:44:40.429375 2020] [cgid:error] [pid 2593:tid 3082691392] AH01239: cgid daemon process died, restarting
> [Mon Apr 06 13:44:40.914425 2020] [mpm_event:notice] [pid 2593:tid 3082691392] AH00491: caught SIGTERM, shutting down
> [Mon Apr 06 13:46:37.517940 2020] [mpm_event:notice] [pid 2642:tid 3082785600] AH00489: Apache/2.4.41 (Unix) OpenSSL/1.1.1d configured -- resuming normal operations
> [Mon Apr 06 13:46:37.540998 2020] [core:notice] [pid 2642:tid 3082785600] AH00094: Command line: '/usr/sbin/httpd'
> Can't load /var/ipfire/ovpn/ca/.rnd into RNG
> 3080959744:error:2406F079:random number generator:RAND_load_file:Cannot open file:crypto/rand/randfile.c:98:Filename=/var/ipfire/ovpn/ca/.rnd
> Generating a RSA private key
> ............................................................................++++
> ..........................................++++
> writing new private key to '/var/ipfire/ovpn/ca/cakey.pem'
> -----
> You are about to be asked to enter information that will be incorporated
> into your certificate request.
> What you are about to enter is what is called a Distinguished Name or a DN.
> There are quite a few fields but you can leave some blank
> For some fields there will be a default value,
> If you enter '.', the field will be left blank.
> -----
> Country Name (2 letter code) [GB]:State or Province Name (full name) []:Locality Name (eg, city) []:Organization Name (eg, company) [My Company Ltd]:Organizational Unit Name (eg, section) []:Common Name (eg, your name or your server's hostname) []:Email Address []:Cannot write random bytes:
> 3080959744:error:24070079:random number generator:RAND_write_file:Cannot open file:crypto/rand/randfile.c:233:Filename=/var/ipfire/ovpn/ca/.rnd
> Can't load /var/ipfire/ovpn/ca/.rnd into RNG
> 3080292096:error:2406F079:random number generator:RAND_load_file:Cannot open file:crypto/rand/randfile.c:98:Filename=/var/ipfire/ovpn/ca/.rnd
> Generating a RSA private key
> .......................................................................+++++
> .+++++
> writing new private key to '/var/ipfire/ovpn/certs/serverkey.pem'
> -----
> You are about to be asked to enter information that will be incorporated
> into your certificate request.
> What you are about to enter is what is called a Distinguished Name or a DN.
> There are quite a few fields but you can leave some blank
> For some fields there will be a default value,
> If you enter '.', the field will be left blank.
> -----
> Country Name (2 letter code) [GB]:State or Province Name (full name) []:Locality Name (eg, city) []:Organization Name (eg, company) [My Company Ltd]:Organizational Unit Name (eg, section) [/var/log/httpd/error_log

Output of grep openvpn /var/log/openvpn:

grep: /var/log/openvpn: Is a directory

This directory contains no file, it’s empty.

Since probably one hour I cannot ping the IPfire’s full name anymore, only IP address still works.
It was “BZRFire.VERWALTUNG” which did work (still have the CMD window open with successful ping commands) but now it quit working and can’t resolve the hostname (IP address still works!)

Is there anything else I can check? I’m not an expert, I’m sorry. I was lucky it has been working for years now but since last weekend it came to this sudden halt and I would sincerely like to know the cause of this …

Thanks!
Tobias

tobias · 6 April 2020 16:55

This is what the OpenVPN page states:

Now I can’t press the button on the bottom right because I again deleted the x509 certificate. But even when it’s (re)generated I can press the button, then the page reloads but it remains halted and the service won’t come up

FRITZ!Box still has the port forwarding in place, IP address on red interface hasn’t changed, it looks good – according to my understanding.

ummeegge · 6 April 2020 17:50

Hi tobias,
this message →

points it pretty much out, you have an old ovpn.cnf on your system, this patch →
git.ipfire.org Git - ipfire-2.x.git/commitdiff is meanwhile some time ago and am not sure why you do not have the actual one which you can get here → https://git.ipfire.org/?p=ipfire-2.x.git;a=blob_plain;f=config/ovpn/openssl/ovpn.cnf;hb=HEAD . May a good way is to load it via curl or wget (to prevent wrong line breaks), rename it and give it the right permissions.
-rw-r--r-- 1 nobody nobody 2726 Feb 1 2019 /var/ipfire/ovpn/openssl/ovpn.cnf

If this is done, you will need to recreate the X509.

Best,

Erik

tobias · 6 April 2020 21:24

Dear Erik,

thank you for your input. Unfortunately I still have not been successful.

I used WinSCP to copy over the file and made sure the file is in place with the correct permissions:

Then I tried to re-create the x509 certificate thingy, but with no change.
The error_log file does not incorporate ongoing timestamp information so I can only barely guess what has been written since the last update of that file.

This is what’s in there at the bottom:

Generating a RSA private key
...........................+++++
.................+++++
writing new private key to '/var/ipfire/ovpn/certs/serverkey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:State or Province Name (full name) []:Locality Name (eg, city) []:Organization Name (eg, company) [My Company Ltd]:Organizational Unit Name (eg, section) []:Common Name (eg, your name or your server's hostname) []:Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:An optional company name []:Using configuration from /var/ipfire/ovpn/openssl/ovpn.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'DE'
organizationName      :PRINTABLE:'COMPANY'
commonName            :PRINTABLE:'COMPANY.WORKGROUP'
Certificate is to be certified until Mar  3 21:04:11 4758 GMT (999999 days)

Write out database with 1 new entries
Data Base Updated
Using configuration from /var/ipfire/ovpn/openssl/ovpn.cnf
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
.................................................................................................+.........................................................+..........................................................................................................................................................................+........................................................................................................................................................+.....................................................+......................................................+.....................................................................................+....................................................................................................................................................................................................................................................................+.................................+...+..................+.....................................................+...............................................................+..+........+..........................................................................+....................................................................+.............................................................................................................................+............................................................................................................................+...........................................................................................+..............+............................+........................................................................................+...................................................................+......................................................................................................................+............................+..........................................................................................................................................................................................................+................................................................................................................+.................................................................................++*++*++*++*

It remains the same.
Whenever I push the button to start the OpenVPN server, nothing happens except a page refresh.

Sorry for being a pain
Is there something else you can think of I could check? I’m pretty puzzled …

Thanks
Tobias

xperimental · 7 April 2020 02:30

Reboot tut immer gut.

Maybe some proccess is still running and didn’t load the new file. Also clean up the log file / delete all content and create the certificate again to see actual information.

ummeegge · 7 April 2020 09:06

Hi all,
your ‘error_log’ looks now good and theX509 creation should be finished. The last line (with all the dots) is the Diffie-Hellman parameter which ends regular with ‘…++++++++’ . How does the ’ Certificate Authorities and -Keys’ section looks like now ?

You also can click the ‘save’ button and then the start button. If the server do not starts, check the logs again with a

cat /var/log/httpd/error_log

and a

grep openvpn /var/log/messages

Best,

Erik

tobias · 8 April 2020 09:09

Dear all,

thank you for your help so far. It cost my half my night, but eventually I got this to work again. How? Not really sure … too many things I tried working on.

What I did was to use an internal backup that I restored.
With that backup in place the VPN functionality was brought back to life – for whatever reason – but still not really working and still showing the original error with the missing conformity of RFC3280 etc.

I then deleted the x509 settings completely and re-generated everything according to my best knowledge. I then set up a new RoadWarrior account, did a test and voilà - it acceppted my connection. With one amendment: I had to remove the “auth” entry from the .ovpn file first.

There is one thing that does not work anymore and I can’t get behind it …
Earlier, the IPFire installation was named “BZRFire.VERWALTUNG”. And I could put that in the browser and connected to it just fine. But this doesn’t work anymore. Only the IP address still works … something with the DNS settings are seemingly wrong, but as mentioned, I don’t know why

If someone comes up with a plan to let me know where I might look into it I’d be very happy.

Oh and one other thing:
The welcome page says that /dev/sda1 only has 9 % disk space left. What can be deleted safely without destroying the service again?

Thanks to you guys, you’ve been a great help so far!
Best regards
Tobias

tobias · 8 April 2020 09:23

Today is my lucky day I guess

I just wanted to check the settings and tried connecting to it and it wouldn’t let me … what the heck is wrong?

> Wed Apr 08 11:15:37 2020 OpenVPN 2.4.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 31 2019
> Wed Apr 08 11:15:37 2020 Windows version 6.1 (Windows 7) 64bit
> Wed Apr 08 11:15:37 2020 library versions: OpenSSL 1.1.0l  10 Sep 2019, LZO 2.10
> Enter Management Password:
> Wed Apr 08 11:15:37 2020 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
> Wed Apr 08 11:15:37 2020 Need hold release from management interface, waiting...
> Wed Apr 08 11:15:37 2020 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
> Wed Apr 08 11:15:37 2020 MANAGEMENT: CMD 'state on'
> Wed Apr 08 11:15:37 2020 MANAGEMENT: CMD 'log all on'
> Wed Apr 08 11:15:37 2020 MANAGEMENT: CMD 'echo all on'
> Wed Apr 08 11:15:37 2020 MANAGEMENT: CMD 'bytecount 5'
> Wed Apr 08 11:15:37 2020 MANAGEMENT: CMD 'hold off'
> Wed Apr 08 11:15:37 2020 MANAGEMENT: CMD 'hold release'
> Wed Apr 08 11:15:39 2020 MANAGEMENT: CMD 'password [...]'
> Wed Apr 08 11:15:39 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
> Wed Apr 08 11:15:39 2020 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
> Wed Apr 08 11:15:39 2020 MANAGEMENT: >STATE:1586337339,RESOLVE,,,,,,
> Wed Apr 08 11:15:39 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]84.147.32.45:1194
> Wed Apr 08 11:15:39 2020 Socket Buffers: R=[8192->8192] S=[8192->8192]
> Wed Apr 08 11:15:39 2020 UDP link local: (not bound)
> Wed Apr 08 11:15:39 2020 UDP link remote: [AF_INET]84.147.32.45:1194
> Wed Apr 08 11:15:39 2020 MANAGEMENT: >STATE:1586337339,WAIT,,,,,,
> Wed Apr 08 11:16:39 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
> Wed Apr 08 11:16:39 2020 TLS Error: TLS handshake failed
> Wed Apr 08 11:16:39 2020 SIGUSR1[soft,tls-error] received, process restarting
> Wed Apr 08 11:16:39 2020 MANAGEMENT: >STATE:1586337399,RECONNECTING,tls-error,,,,,
> Wed Apr 08 11:16:39 2020 Restart pause, 5 second(s)
> Wed Apr 08 11:16:44 2020 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
> Wed Apr 08 11:16:44 2020 MANAGEMENT: >STATE:1586337404,RESOLVE,,,,,,
> Wed Apr 08 11:16:44 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]84.147.32.45:1194
> Wed Apr 08 11:16:44 2020 Socket Buffers: R=[8192->8192] S=[8192->8192]
> Wed Apr 08 11:16:44 2020 UDP link local: (not bound)
> Wed Apr 08 11:16:44 2020 UDP link remote: [AF_INET]84.147.32.45:1194
> Wed Apr 08 11:16:44 2020 MANAGEMENT: >STATE:1586337404,WAIT,,,,,,
> Wed Apr 08 11:17:44 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
> Wed Apr 08 11:17:44 2020 TLS Error: TLS handshake failed
> Wed Apr 08 11:17:44 2020 SIGUSR1[soft,tls-error] received, process restarting
> Wed Apr 08 11:17:44 2020 MANAGEMENT: >STATE:1586337464,RECONNECTING,tls-error,,,,,
> Wed Apr 08 11:17:44 2020 Restart pause, 5 second(s)
> Wed Apr 08 11:17:49 2020 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
> Wed Apr 08 11:17:49 2020 MANAGEMENT: >STATE:1586337469,RESOLVE,,,,,,
> Wed Apr 08 11:17:49 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]84.147.32.45:1194
> Wed Apr 08 11:17:49 2020 Socket Buffers: R=[8192->8192] S=[8192->8192]
> Wed Apr 08 11:17:49 2020 UDP link local: (not bound)
> Wed Apr 08 11:17:49 2020 UDP link remote: [AF_INET]84.147.32.45:1194
> Wed Apr 08 11:17:49 2020 MANAGEMENT: >STATE:1586337469,WAIT,,,,,,
> Wed Apr 08 11:18:20 2020 SIGTERM[hard,] received, process exiting
> Wed Apr 08 11:18:20 2020 MANAGEMENT: >STATE:1586337500,EXITING,SIGTERM,,,,,

TLS handshake fails … why would that be when it worked just fine again yesterday? I tested it with five different accounts.

I don’t like bugging you guys, I’m really sorry. Yet I am clueless without your help.
Thank you for your time so far!
Tobias

ummeegge · 8 April 2020 09:42

Hi Tobias,
you can find a FAQ (checklist) for this specific message ‘TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)’ on OpenVPN --> https://openvpn.net/faq/tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity/ .

Did you press the ‘save’ button at the web user interface one time ? This one is important since only then changes will be written to your server.conf, this is also the case for the ‘’–auth’’ directive.

What i can say, in fact one important point was the actualization of the ovpn.cnf .

Best,

Erik

tobias · 8 April 2020 10:00

Hi Erik,

Thanks for pointing me to the FAQ document.
I have checked the parameters accordingly (fixed IP address on RED, FRITZ!Box Port Forwarding over UDP port 1194), Dynamic DNS works fine, IPFire is connected etc.

Yesterday I have been able to test 5 connections simultaneously (and successfully). Therefore I am sure I hit the ‘Save’ button when I was finished with the configuration.

If the problem persists I think I will have to re-install the whole thing. Don’t know why after years of service all comes down so rapidly. Maybe there is a defect somewhere and I haven’t figured this out yet.

Thanks
Tobias

ummeegge · 8 April 2020 11:57

Hi Tobias,
if your IP is correct (best is to mask it with a e.g. (84.147.xx.xx) then you are probably off. Tried to ping you

4 packets transmitted, 0 received, 100% packet loss, time 3039ms

did you checked that your Hostname/IP is really resolved ?

As another idea.

Best,

Erik

tobias · 8 April 2020 15:29

Hi Erik,

you are totally right

With all the changing back and forth I must have configured the Dynamic DNS service to use the IP address of the RED interface, which is an internal address (192.168.178.20) derived from the FRITZ!Box router, as IPFire does not do PPPoE here. After the obligatory 24 h disconnect the record could not have been updated accordingly.

So first of all I tested it with a manual update at no-ip.com and typed in the official FRITZ!Box WAN IP address. Then I changed it to “Guess the real public IP with help of an external server” (as circled) and suddenly the hostname entry turned green, which is as it was supposed to be I guess:

Now I have to declare myself a n00b I’m afraid.

> ifconfig -a
>     red0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
>               inet addr:192.168.178.20  Bcast:192.168.178.255  Mask:255.255.255.0
>               UP BROADCAST RUNNING  MTU:1500  Metric:1
>               [ ... ]

But why … why can’t I use the DNS name “IPFire.VERWALTUNG” anymore and have to use the IP address instead? It was working fine until recently

Thanks again for your help.
I wish I knew more about this topic!

Best regards
Tobias

ummeegge · 9 April 2020 05:21

Hi Tobias,
so your VPN works now “Problem with host certificate / destroyed OpenVPN” is solved ? If so, let us first finish the topic for a better overview.

Best,

Erik

tobias · 10 April 2020 11:58

Thank you, Erik!