Hi - I have finally been able to get my client to connect to OpenVPN on IPfire, but once connected I cannot do anything. There is no DNS available. I tried configuring DNS in the server AND the client certificates, but it doesn’t work. I am a newbie with IPFire and I have to admit being a bit frustrated at getting this to work. My IPFire is behind a Synology router (trying to use IPFire to protect my small business network) but my daily driver is on the Synology, not IPFire, because I just want to VPN to the business network (hosting webservers).
I should add:
My router has port forwarding rules to 192.168.40.199 on 80 and 443 to expose the webserver (and I will configure IPFire to port forward to 10.0.0.2 once I’m ready). Right now, the port forwarding rules are turned off while I figure out how to get everything working.
I want to be able to VPN into GREEN on IPFIre from my daily driver to perform maintenance on the web server and to update/maintain IPFire.
Hi there! Thanks for that - I’d actually seen that during my research (I always go to the forums as a last resort…) and I actually attempted to use that config (secure client package). I could NEVER connect. It was only by switching to the insecure download that I could get the VPN to connect at all. My daily driver is an Intel Nuc running Ubuntu 22.10. Ubuntu is…consistently unreliable when you monkey with the network settings. I nearly have to reboot every time I change something because it starts acting weird. I’m NOT using a separate client in Ubuntu - I’m using the OpenVPN package installed into network settings.
I need to be able to use DNS for websites (WAN) but also the DNS server on my router for local sites (because this is a test environment). Maybe all that layered DNS is the problem - dunno. But I read somewhere that WAN–>Router–>IPFire is actually the notional use case, so I can’t be doing anything that crazy.
I assume you did not give a password to the certificate when you set it up, as this is necessary for the insecure package to be created. The fact that this works and the secure one does not, clearly tells us that your problem is restricted to the delivery of all the 5 pieces of information necessary for a successful connection of OpenVPN connect client to the server (likely, at least one of the certificates and the OpenVPN connect logs should tell you which one). I would proceed the troubleshooting based on this premise.
The standard situation should be that you only ever get shown the insecure connection option if you left the PKCS12 password blank and you only ever get shown the secure connection option if you filled in a PKCS12 password,
There is a bug in the cgi code for the OpenVPN WUI page that allows both the secure and the insecure connection options to be shown at the same time under certain circumstances.
If you filled out the PKCS12 password then only use the secure connection option and if you left it blank then only use the insecure connection option.
You cannot use the secure and the insecure connection options at the same time. One of them will not work correctly.
If you fill in a password for the PKCS12 password fields then you client will need to ask for the password or you will need to use the client keyring or key store to apply the password for you.
Thank you for the feedback, and for letting me know about the bug!
Actually, when I first set up OpenVPN, I used the secure package (supplied a password). NEVER could get the client to connect. When I deleted the VPN server and did the process again, without supplying a password and using the unsecure package, it connected right up. I will go back and try the secure process again to see if I can get it to work. Then I’ll see if my DNS issue is resolved and loop back here. If the secure package doesn’t work, I’ll dive into the logs (may need some help deciphering them).
I really appreciate all of you helping me out. IPFire seems to be exactly the solution I need, but I don’t think I’m smart enough (yet!) on how it works to use it appropriately. And networking is mostly voodoo anyway…
Ok - so I tore down the VPN and set it back up. I added a client with a password, exported the package to the client and installed it…no joy on the connection. Logs don’t indicate anything…
So I tried to connect to OpenVPN from the CLI on my client, and got the following:
2022-12-29 16:12:58 DEPRECATED OPTION: --cipher set to ‘AES-256-CBC’ but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
2022-12-29 16:12:58 Note: Kernel support for ovpn-dco missing, disabling data channel offload.
2022-12-29 16:12:58 OpenVPN 2.6_git x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
2022-12-29 16:12:58 library versions: OpenSSL 3.0.5 5 Jul 2022, LZO 2.10 Enter Private Key Password: *************
2022-12-29 16:13:07 OpenSSL: error:11800071:PKCS12 routines::mac verify failure
2022-12-29 16:13:07 OpenSSL: error:0308010C:digital envelope routines::unsupported
2022-12-29 16:13:07 Decoding PKCS12 failed. Probably wrong password or unsupported/legacy encryption
2022-12-29 16:13:07 SIGUSR1[soft,private-key-password-failure] received, process restarting
2022-12-29 16:13:07 Restart pause, 5 second(s)
I changed the cert encryption to AES-256-GCM and the first error went away, but I still got the “Decoding PKCS12 failed” error. I realize this is an IPFire forum, not an Ubuntu forum, but I’m not sure which side I’m doing something wrong on…
Okay, I think I know what is happening now. Thanks for the log info that helped.
This line indicates that your client is using Openssl-3 whereas IPFire is still on Openssl-1.1.1 and there is a mismatch between these two in terms of the CA/Host certificate for OpenVPN in IPFire.
The solution is defined near the end of that thread from post 18 and involves adding a Legacy entry into the openssl.cnf file on your client. That post gives more details and I can confirm that it worked for me.
Openssl-3 is planned to be introduced for IPFire but recently there were several releases in a row with various security issues which required fixes or reversions so the core devs decided to wait for a while until Openssl-3 looked to be more stable from a security point of view.
The Openssl-1.1.1 series is still supported and gets any required security and bug fixes and was not affected by the issues that occurred on Openssl-3.
Hopefully the above fixes the issues you have been having with the secure version. Let us know either way.
Enter Private Key Password: *************