First of all, thank you to the team for such a major update going so smoothly! I love the OpenVPN Connection Statistics page. Is that new or have I just never noticed it?
I did notice that when I navigate to the Advanced page, that some of my previous settings are changed. For example, MTU is set to 1440 instead of my custom 1472. And it looks like the Hash is set to SHA2 256bit when I had it set to SHA2 512bit previously. So it looks like I will have to change and re-save those settings. No big deal, but I wanted to provide that feedback in case it is unintended.
I checked the backup and the settings match up right with current settings. So my memory must have failed me. I have a screenshot of my configuration settings from a year ago and they match up with my memory. But apparently I changed those settings sometime in the past year and forgot about it. I apologize for the false alarm.
I installed the new update today, and now Iâm having issues when the OTP option is enabled. When connecting, it still asks for the OpenVPN userâs password, but it no longer prompts for the OTP password afterward.
That is because the openvpnctrl code was changed with CU197.
The two options now are rw for roadwarrior and n2n for net-to-net.
It would also be good to see what the CU197 log file
/var/log/pakfire/update-core-upgrade-197.log
shows near the end as the update shuts down the OpenVPNH server, does the required file changes and then starts the service back up with the new initscripts and with the new daemons. If the startup of the new system did not work there should be some message for why not.
I think all my testing was with updates and not a fresh install.
The log file name was changed in the update process. Not sure why it would not work correctly in a fresh install. It was also added into the backup restore process and that was something I tested out and it worked at that time.
I also see from your image that you have ended up with ncp-disable in the server.conf.
There were explicit commits to ensure that both from an update and from a restore that ncp-disable was not inserted as that is no longer a valid option in openvpn-2.6.x
That entry in the server.conf will stop the server starting as the option is unrecognised.
I will try and find some time tomorrow to do a fresh install of CU197 and see if I confirm what you found both directly after the install and then after doing a restore from a backup from CU196 with the old system.
Unfortunately we had little feedback on CU197 Testing other than our own testing of multiple different conditions and prior settings. I will try and figure out what is going wrong here and see what needs to be modified to fix it for a fresh install.
I managed to make some time available now so I just did a fresh install of CU197 and after the install there was /var/run/openvpn-rw.log
and in /var/ipfire/ovpn/collectd.vpn
there was /var/run/openvpn-rw.log
There was no /var/run/ovpnserver.log file.
So different from what you experienced.
I then did a restore of an old pre CU197 backup with the old names and without cipher negotiation. The backup contained ncp-disable in the server.conf file but after restore this was no longer in the server.conf file.
After restore my openvpn RW server was running with no problems. The correct log file names were present as after the fresh install.
So I have not been able to reproduce what you showed.
Can you confirm that the sha256sum hash of your CU197 iso was c7141cf5a2dbf262d7c6c040c485bdc96f2a9ea556879299876755e5120803cf
which is the value I got on my version and is the same as the sha256sum value on the download website.
EDIT1:
I just saw that your install was a rpi4 so your sha256sum hash will not match mine but it should match the value in the download page for the aarch64 image file.
EDIT2:
I copied the aarch64 image file to a usb stick. Then I mounted that stick and I checked out some of the files.
The collectd.vpn file had openvpn-rw.log in it.
The backup.pl file had the correct section in it for restoring old openvpn settings and updating them to the correct Openvpn-2.6.x versions.
I canât test out actually running the aarch64 image as I donât have any arm system available to do that with. Both of the RPiâs I have are used for other applications in my network.
If the sha256sum for the aarch64 image file that you used is 23d143390d1013b1d15e2785dba0e6381b0e397031268a3332bcc825e9fa1e63
then it matches the one on the download page and that matches what I copied to my usb stick.
In that case I would suggest doing a fresh copy of the image to your RPi sdcard and repeat the network install again and backup restore and see how it goes for a second time. Do you end up duplicating the same problem or does it work after the repeat install.
If it duplicates, it would be good to know if the incorrect file names were already present directly after the install was completed and before doing a backup restore, or only after the backup restore.
Please keep in mind, I took my backup from core 195 as mentioned.
There was an remark within announcement some weeks ago, which led me to prefer a fresh install: Only a fresh install should make the new kernel available or something like that.
The backup structure was the same for CU195 and CU196. To confirm I installed CU197 fresh again on a vm system. It had the right logfile name in collectd.vpn again and after restoring from a CU195 backup OpenVPN was running correctly and I could successfully access via my mobile roadwarrior connection.
Your checksum for the image file you used shows it was not corrupted somehow during the download.
The only way for you to end up with ncp-disable still in your server.conf file would be if the restore function restored the files but then missed out the command to run the openvpn.cgi page.
Just to confirm, for the restore of your backup you are using the restore function from the backup WUI page and not manually restoring the files from the .ipf file?
Check in you messages log for when the restore has completed. There should be the line
This is the line from the backup.pl process that is run after the restore has been completed.
If that line did not get executed properly for some reason then the server.conf file from the backup would not be updated to use negotiation and to have the ncp-disable line and others removed.
Do you see any error messages in the lines after the above entry in your logs?
on this production system ipfire runs from stick on my rpi 4.
I do not use iso but flash image.
Thats why I have got core 195 running and another stick with failed core 197 on it.
If you tell me what you need, youâll get it.
I restored in WUI and rebooted.. No addons.
No DHCP in use.
Be careful reading the logs. Iâm not sure, which part of the logs has been changed by restoring.
Here is /var/log/messages out of my failed 197 installation for you. I wonder to see n2nNIBE described as âfailedâ. This connection worked with core 197. Maybe it took some time to come up.
Okay so the restore script called the ovpnmain.cgi code to run as it should.
This should have updated the openvpn server.conf file contents to remove ncp-disable etc
The next command in the restore code carries out a sed command on the file /var/ipfire/ovpn/collectd.vpn
to replace /var/run/ovpnserver.log in that file to /var/run/openserver-rw.log
Can you check the contents of /var/ipfire/ovpn/collectd.vpn
to see which of the lines above it has. There should also be a line for any n2n connections that you had in your backup.
Could you also show the contents of the /var/run/ovpn/server.conf file, redacting any sensitive info like your public IP.
Itâs the first hint of trouble, because there is another n2n connection called ân2nBeNiâ in /var/ipfire/ovpn/n2nconf.
This n2n connection was not active / not in use. Only the above mentioned n2nNIBE is in use and was working with core 195 and 197.
II.
/var/run/ovpn/server.conf does not exist.
A file named server.conf is located in /var/ipfire/ovpn and contains:
â#OpenVPN Server conf
daemon openvpnserver
writepid /var/run/openvpn.pid
#DAN prepare OpenVPN for listening on blue and orange
\# hint by author: I do not use orange, but red, green and blue. Routes are set correctly. roadwarrior worked with Core 195
;local (deleted by author)
dev tun
proto udp
port 1024
script-security 3
ifconfig-pool-persist /var/ipfire/ovpn/ovpn-leases.db 3600
client-config-dir /var/ipfire/ovpn/ccd
tls-server
ca /var/ipfire/ovpn/ca/cacert.pem
cert /var/ipfire/ovpn/certs/servercert.pem
key /var/ipfire/ovpn/certs/serverkey.pem
dh /etc/ssl/ffdhe4096.pem
server (deleted by author)
tun-mtu 1360
push â(deleted by author)â
push â(deleted by author)â
route (deleted by author)
client-to-client
mssfix 0
keepalive 10 60
status-version 1
status /var/run/ovpnserver.log 30
ncp-disable
cipher AES-256-GCM
auth SHA512
tls-version-min 1.2
tls-auth /var/ipfire/ovpn/certs/ta.key
push âdhcp-option DOMAIN âŚâ
push âdhcp-option DNS 192.168.10.1â
max-clients 100
tls-verify /usr/lib/openvpn/verify
crl-verify /var/ipfire/ovpn/crls/cacrl.pem
auth-user-pass-optional
reneg-sec 86400
user nobody
group nobody
persist-key
persist-tun
verb 3
# Log clients connecting/disconnecting
client-connect â/usr/sbin/openvpn-metrics client-connectâ
client-disconnect â/usr/sbin/openvpn-metrics client-disconnectâ
# Enable Management Socket
management /var/run/openvpn.sock unix
management-client-authâ
That is not a problem. Only enabled n2n client connections are listed in collectd.vpn.
If that other n2n connection was enabled then it would be automatically added to collectd.vpn
Also it has openvpn-rw.log in it.
This means that the sed command after the running of ovpnmain.cgi waqs carried out successfully. That also mean that the ovpnmain.cgi will have run but from your server.conf it is clear that nothing got changed in it.
Sorry, typo from me.
The server.conf file has not been updated but it is not clear why not.
It still has the lines
The status line should have been updated, the ncp-disable removed and the cipher AES-256-GCM line changed to data-ciphers-fallback AES-256-GCM
There should also have been added the line data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
plus a line topology subnet
None of that happened.
The .ipf backup file is basically just a tar archive. Can you view inside it and look at the /var/ipfire/ovpn/settings file and see if it has a line ENABLED=
or ENABLED=on
All of my restore testing was with a backup of an enabled openvpn setup. Maybe that is a difference.
âThe status line should have been updated, the ncp-disable removed and the cipher AES-256-GCM line changed to data-ciphers-fallback AES-256-GCM
There should also have been added the line data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
plus a line topology subnet"
Can I change these lines within my stick and boot after that or should I boot Core 197 and change these lines via cli?
Is your line âtopology subnetâ complete? Or do I need something like âgreen0â ?
Here is /var/ipfire/ovpn/settings out of my backup Core 195:
VPN_IP=(deleted by author)
ADDITIONAL_CONFIGS=
DDEST_PORT=1024
DCIPHER=AES-256-GCM
DMTU=1360
ROOTCERT_ORGANIZATION=(deleted by author)
DOVPN_SUBNET=(deleted by author)
TLSAUTH=on
ROOTCERT_HOSTNAME=(deleted by author)
DAUTH=SHA512
KEEPALIVE_2=60
MAX_CLIENTS=100
ROOTCERT_OU=(deleted by author)
DHCP_DOMAIN=(deleted by author)
LOG_VERB=3
CLIENT2CLIENT=on
DCOMPLZO=off
ENABLED_BLUE=on
ROOTCERT_COUNTRY=(deleted by author)
ENABLED_ORANGE=off
DPROTOCOL=udp
DHCP_WINS=
ROOTCERT_CITY=(deleted by author)
ENABLED=on
ROUTES_PUSH=
ROOTCERT_STATE=(deleted by author)
REDIRECT_GW_DEF1=
KEEPALIVE_1=10
DHCP_DNS=(deleted by author)
Those are lines that should be different but there may be addi9tional differences.
It might be worth to press the Save button on the main OpenVPN WUI page. That might correct the issues in the server.conf by forcing the ovpnmain.cgi code to run as it appears to have not run correctly from the restore process.
If that does not work then I would suggest doing a fresh write of the CU197 .img file to your USB memory stick and then doing a restore of the backup again.
If the same happens again then it suggests some sort of systematic issue but someone that has an arm based system to test it out on will need to look at it.
If a new fresh install and restore works then it indicates some hiccup in the original install or restore.
