I recently upgraded to release 187 and initially all seemed good.
I needed to edit one OpenVPN client route settings .to add a new client side subnet
I added the route / mask and saved the change.
for good measure I stopped and restarted the OpenVPN service
on first inspection everything seemed OK . green [RUNNING] icon as usual but the [Stop OpenVPN server] button still said [Start OpenVPN server]
I refreshed the page to find that OpenVPN was now showing [STOPPED]
so I clicked the button to start the server …
and nothing happened! Once stopped in this condition I can no longer restart it from the GUI
I rebooted IPFire and the OpenVPN service started and all the clients came up
I stopped the OpenVPN server and restarted the service a further time- exactly the same thing happened and the server would not activate.
A further reboot and the service was back
I edited the client and removed the new route (there is no conflict as the subnet is not used anywhere else) saved the changes and
stopped / started OpenVPN
OpenVPN would not start . I rebooted the firewall and the service comes up and all clients connect as normal .
I just tried to duplicate your steps and OpenVPN started and ran just fine.
I added 192.168.75.0/24 which is not clashing with anything on my system and after reboot the additional route was added to the server.conf file and OpenVPN started and stayed running with no issues.
When you removed the route and then rebooted, did the server still not start properly.
The symptom of OpenVPN trying to start and then stopping is usually an indication of an error of some sort in the config file.
Create the route again, reboot the machine and then stop and restart the server.
Then go to the WUI page Logs - System Logs. Then select OpenVPN in the drop down box labelled Section:
Then press the export button and it will update the logs and then provide them as a text output on your browser tab. You can then copy and paste them into the forum page editing any private bits, such as your public IP and domain name etc.
Whatever is happening is not as simple as an incorrect route as if the subnet is missed out or an incorrect octet is used then the checks within the openvpn cgi page flag up that the route definition is invalid.
So your log page will be important to see what messages it comes up with when it fails to start the server.
Maybe also worthwhile to show the contents of the
/var/ipfire/ovpn/server.conf
file to see if the contents give any clue as to what is causing the issue.
Very frustrating, but I had to power cycle IPFire for operational reasons (equipment moves) earlier this morning and since that reboot the GUI behaves as expected. both with and without the additional route to the one client.
I can no longer reproduce the issue seen yesterday. But thank you for your support.
I have tested every client and all but the one with the additional subnet works exactly as expected .
That particular client is odd, in that every time the VPN client re-establishes the connection, it drops the route to green on the client side, the client can still be accessed from blue but not green. if I go to the client device and manually add the green route it works, but the next time the connection drops, green no longer becomes available.
I checked the WUI under advanced server options and the route to green is not there , thinking that was the problem, i manually added it , only to be told that green route is always there by an error message.
there is no issue with any of the other clients who can all get to green so I am presuming this issue is the client end which has recently undergone a firmware upgrade.
Problems that just go away can be very frustrating but at least it is working again. Fingers crossed that it doesn’t come back, at least for a long while, but if it does have a look in the system log to see.
You could still look in the system logs for OpenVPN, choosing a day when you know you had the problem and see if you can find anything that might suggest what problem it was having.