Openvpn4UCS not showing up in the menu after reinstall

I’m running UCS4 (up to date) and installed OpenVPN4UCS 1.1.3
I found out it still has the bug not displaying users with the table error.
So I removed it via the appcenter, see if a reinstall would fix it.
Did a reboot
and installed it again via the appcenter
The app apears to be installed alright when I look at the appcenter, the icon is there.
but I can not configure it’s settings, there is no longer an entry OpenVPN4UCS under the menu Computers.
Under the menu Users there is also no way to activate OpenVPN.

Any ideas what could be the reason for this strange behaviour?
Help would be appreciated!

Hello Thorsten Kaufmann,

thanks for your post. We could reproduce the symptoms you are describing here and it looks like you came across two issues, we could solve today. A new bugfix release 1.1.4 will be made available shortly.

Here is how you can help yourself in OpenVPN4UCS 1.1.3:

  1. Issue - no configuration options

Solution: Open the UMC and go to ‘Domain Join’. In here you should find the scripts ‘94univention-openvpn-master’, ‘-server’ and ‘-site2site’. Most likely at least one of them with the status ‘pending’. Please mark those pending scripts and click ‘Execute’. Once done you may have to reload the UMC and you should find all the options back in place.

Cause: UCS tracks the successful join states in ‘/var/univention-join/status’. As you have installed the package once, the success was tracked here. Our de-installation routine should have removed the corresponding entry, which unfortunately it didn’t due to a version no. conflict. Since the entry still existed, the join-scripts have not been executed properly during the re-installation of the exact same software version. You would have not encountered this by installing a different (newer, if existed) version.

  1. Issue - display_users error

Solution: Once you have re-enabled the settings (above), please restart your apache2 webserver via console:

/etc/init.d/apache2 restart

Cause: The apache2 webserver is going to restart during the installation process. Unfortunately this happens a little early, so the webserver does not recognize the deployed configuration in time, resulting in apache2 not knowing that it is responsible for redirecting access on ‘…/display_users/cmd/’.

Please confirm or deny if the described solutions above helped to solve the issues. If you still encounter the issues, please leave a comment and/or get in touch with us via bytemine.net.

Greetings from Oldenburg,

Ingo von Thielau

First of all thanks for the quick reply!

  1. The scripts are marked successful, in the logs it says:

[quote]RUNNING 94univention-openvpn-master.inst
EXITCODE=already_executed
RUNNING 94univention-openvpn-server.inst
EXITCODE=already_executed
RUNNING 94univention-openvpn-sitetosite.inst
EXITCODE=already_executed[/quote]

I did a force execute, and the menu is back :slight_smile:

I tried to connect through VPN, but it didn’t work.
So I checked the System Services to see if it was running, but there was no mention of OpenVPN in there.
Next thing I tried was to restart the OpenVPN service via init.d but it failed.
The daemon.log said:

[quote]Nov 4 11:33:26 server2 ovpn-server[7210]: Options error: You must define certificate file (–cert) or PKCS#12 file (–pkcs12)
Nov 4 11:33:26 server2 ovpn-server[7210]: Use --help for more information.[/quote]

Hello Thorsten Kaufmann,

looking at the log snippet you posted it looks like the required server configuration file ‘/etc/openvpn/server.conf’ exists, but is missing essential information inside it. If you open the file it is most likely that you won’t find a line starting with ‘cert’. This is very unexpected. Is there any content at all?

I do assume you have activated the service (OpenVPN server) via the UMC and did the initial configuration once. The configuration file and it’s contents are initially generated / deployed during the first activation of the service via the UMC. Furthermore the referred part in the configuration is static and not touched again in any way - even if you do changes on your configuration via the UMC. Therefore I have no clue at the moment why the content is missing.

One option you have is to post the content of the config file here. Please feel free to edit IPs or anything you don’t want to show of here in public.

The other / the ‘easy’ way to get a working config file again would be to delete the ‘server.conf’ (and if existing ‘server.conf-disabled’). Next step would be to go to the ‘OpenVPN4UCS’ tab in the extended options of the computer object in the UMC. Deactivate the OpenVPN server and save the change. Re-enable and save again afterwards. This should regenerate the config according to the settings provided.

Regards,

Ingo von Thielau

Contents of /etc/openvpn/server.conf

[quote]### Constant values

dh /etc/openvpn/dh2048.pem
ca /etc/univention/ssl/ucsCA/CAcert.pem
crl-verify /etc/openvpn/crl.pem
ifconfig-pool-persist ipp.txt
push “route 192.168.3.0 255.255.255.0”
push “dhcp-option DNS 192.168.3.25”
push “dhcp-option DOMAIN mycompany.local”
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 1
mute 5
status /var/log/openvpn/openvpn-status.log
management /var/run/management-udp unix
dev tun
topology subnet

Values which can be changed through UDM

port 1194
server 10.173.175.0 255.255.255.0
proto udp
push “redirect-gateway”
plugin /usr/lib/openvpn/openvpn-auth-pam.so /etc/pam.d/vpncheckpass
[/quote]

As you can see the initial configuration was done.
I check on the settings under Computers and “OpenVPN server active” is marked.

Contents of /etc/openvpn# ls -alF

[quote]total 56
drwxr-xr-x 3 root root 4096 Nov 4 11:30 ./
drwxr-xr-x 121 root root 12288 Nov 5 19:07 …/
-rw-r–r-- 1 root root 803 Oct 9 09:56 ca.crl
drwxr-xr-x 2 root nogroup 4096 Nov 2 19:57 ccd-1194/
-rw-r–r-- 1 root root 1137 Nov 5 18:58 crl.pem
-rw-r–r-- 1 root root 424 Nov 1 18:44 dh2048.pem
-rw------- 1 root root 0 Nov 2 19:58 ipp.txt
-rw-r–r-- 1 root nogroup 63 Nov 2 19:57 ips-1194
-rw-r–r-- 1 root nogroup 0 Nov 2 19:57 ipsv6-1194
-rw-r–r-- 1 root nogroup 626 Nov 4 11:30 server.conf
-rw-r–r-- 1 root nogroup 443 Nov 4 11:14 sitetosite.conf-disabled
-rw------- 1 root nogroup 635 Nov 4 11:14 sitetosite.key
-rw------- 1 root root 636 Nov 4 11:14 sitetosite.newkey
-rwxr-xr-x 1 root root 1357 Dec 2 2014 update-resolv-conf*
[/quote]

I will try the workaround and report the results here, thanks again for your help here.

I did the steps as proposed, new contents of /etc/openvpn/server.conf:

[quote]### Constant values

dh /etc/openvpn/dh2048.pem
ca /etc/univention/ssl/ucsCA/CAcert.pem
crl-verify /etc/openvpn/crl.pem
ifconfig-pool-persist ipp.txt
push “route 192.168.3.0 255.255.255.0”
push “dhcp-option DNS 192.168.3.25”
push “dhcp-option DOMAIN mycompany.local”
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 1
mute 5
status /var/log/openvpn/openvpn-status.log
management /var/run/management-udp unix
dev tun
topology subnet

Values which can be changed through UDM

port 1194
server 10.173.175.0 255.255.255.0
proto udp
push “redirect-gateway”
plugin /usr/lib/openvpn/openvpn-auth-pam.so /etc/pam.d/vpncheckpass
[/quote]
No change, but as you can see it was rewritten:

I tried some more to get this working.

I added these missing lines to /etc/openvpn/server.conf

[quote]cert /etc/univention/ssl/server.mycompany.local/cert.pem
key /etc/univention/ssl/server.mycompany.local/private.key[/quote]
And restart OpenVPN /etc/init.d/openvpn restart
From that moment on I could connect without problems, but I could only access the server itself.

In the logs I found a warning:

But the group DC Backup appears to be the cause of that, so that should not be a problem.

I also changed the firewall settings so I can access the other servers in the network.
In /etc/sysctl.conf remove # in front of the line #net.ipv4.ip_forward=1
To take effect immediately: echo 1 > /proc/sys/net/ipv4/ip_forward
Then in /etc/security/packetfilter.d/50_local.sh add:

[quote]iptables -A FORWARD -i eth0 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.173.175.0/24 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.173.175.0/24 -o eth0 -j MASQUERADE[/quote]
and restart the firewall: /etc/init.d/univention-firewall restart

Works like a charm :slight_smile:

Now there appears to be one last problem.
In server/download/ I get an authentication error when I try to log in.

The first one says:

I checked the Administrator is part of that group, so it should work.

The second one says:

[quote]Authorization Required
This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn’t understand how to supply the credentials required.
Apache/2.2.22 (Univention) Server at server.mycompany.local Port 443[/quote]

Some more background information:
UCS 4.0 Master (up to date) is installed as a VM on Proxmox 3.4 KVM/QEMU.
UCS modules for DHCP/DNS, email, fetchmail and fileshares are installed, OpenVPN4UCS is the only non UCS app installed.

I would love to know where the settings for server.conf are stored.
After deleting the file it got recreated with the same old settings.
I couldn’t find them in UCR nor any template file, but there must be one obviously.

Maybe it has something to do with the fact that I choose 1195 (as depicted in the manual) as the port the first time.
After rereadig, and realising that this is the site-to-site port, I changed the port to 1194
It sounds a bit far fetched, but could this have messed it all up?

Hello Thorsten Kaufmann,

good to see you made progress here. Let me comment on a few things:

  1. You are not missing any files in ‘/etc/openvpn/’. This is good.

  2. Yes, the two lines added to ‘/etc/openvpn/server.conf’ were the only ones missing. If they would have been inserted during the generation of the file, they would have pointed to '/etc/univention/ssl/<$HOSTNAME>/, which is in fact symlinked to ‘/etc/univention/ssl/<$FQDN>/’.

  3. For adding custom iptables ‘/etc/security/packetfilter.d/50_local.sh’ is the right place to go to. Although it is rarely needed, as the ‘redirect-gateway’ option (which you are already using according to your posts) is sufficient for / in most cases. You can refer to the official OpenVPN manual (community.openvpn.net/openvpn/w … n22ManPage) for further details and possible options – which you could add manually for testing if you want to.

  4. Restricting access to the OpenVPN user overview with the group ‘VPN Admins’ is intentional, as 1.) the overview lists everyone with access to the VPN, 2.) the overview site is capable of disconnecting users and 3.) a task like watching over the connections can be delegated to a user without providing full admin privileges. By default the regular ‘Administrator’ is part of that group.

  5. To download a ready2go package via the download page you have to edit the user objects advanced settings and grant access to OpenVPN first, which generates the package. Each user is only allowed to get to the users own package. Therefor the user is required to use the domain credentials to access the package.

  6. UCS stores a lot of information in LDAP and so does OpenVPN4UCS - at least for the options exposed by the UMC. The actual generation of the config is handled by python scripts. You may want to take a look at the github repository (github.com/bytemine/univention-openvpn), so you don’t need to track down the files from the packages on your system.

  7. You are free in choosing the port for the connection. As long you do not active ‘site2site’, port 1195 won’t show up. So no, no conflict is to expect here.

Furthermore I did some testing on the weekend (UCS 4.0-3 errata360 with OpenVPN4UCS 1.1.3), but I was unable to provoke / reproduce the exact same behavior you are experiencing with the configuration file. All tests checked out OK - the config was alright in every case.

So I think it’s fair to say that there must be ‘something special’ with your setup - but the app itself looks OK for now. And so far this is the only report off such behavior. If you want to track this down you can still get in touch with us for some remote support.

Regards,

Ingo von Thielau

1 up to 3: thanks for the confirmation!

4: I understand that I have to log in, but both the Administrator as well as the testuser that I created and added to the group can’t log in. The log in popup keeps comming back, telling me the user has to be part of the group VPN Admins.

5: The users have access to openVPN marked. Before I did a reinstall I managed to download the package for the testuser. The package for this user is working perfectly fine. Even the downloadpage itself shows up nicely ans I can enter the user name. It is just that the download is nolonger accessible due to authentication problems.

6: Thanks, I will have a look. Hope that 1.1.4 will pull it straight again.

7: Apart from this little mistake during installation I see no strange things in my setup. Good to know that this is not the reason for all the trouble.

Thank you for your efforts to reproduce it this weekend, it is much appreciated! With respect to "something special’ in my setup, I have no idea. It is a really basic small business server running fine for 2 month now.

Hello Thorsten Kaufmann,

OpenVPN4UCS 1.1.4 has been released. Please update your system to the new version.

Regarding 4./5.: These issues should not show up either. I’m sorry to see you struggling this hard by running from one issue into another. Please test this again after the update.

Regarding 7.: I do believe you. But this does not help you - unfortunately. So ‘something special’ is just a placeholder for ‘the reason’, which his quite hard to anticipate, if tests lead in the opposite direction.

Please test 1.1.4 and report back if and what did change your experience. You can also try the regeneration of the config file again if you want to.

Regards,

Ingo von Thielau

Sorry for the delay, it took some time (and help) to find out what was going on with the server.

I tested 1.1.4 but it didn’t change anything, the problems persisted.
Why the openvpn server.conf wasn’t generated with the two extra lines is still unclear.

We were able to get the download page working by changing the password (AuthLDAPBindPassword) in: /var/www/readytogo/USERNAME/.htaccess for all the users.

In order to get the display_users page working again we had to change the password for user ldapper-s-SERVERNAME.

I have no clue why these password problems popped up. If IIRC I did change the UCS root password via console and the Administrator password via the webGUI between the two installs. But that should not be a problem. Maybe this info helps Bytemine to locate the origins of this problem so it can be fixed. If you need any more info, just ask.

But apart from all the afore mentioned problems OpenVPN4UCS still is a nice product and works fine!

Hello Thorsten Kaufmann,

thanks for coming back with your success and your appreciation for the product. This is most welcome. :slight_smile:

We discussed the authentication problems you mentioned in your last post.

One guideline during development was not to delete anything without consent / knowledge of the ‘admin’. As a result everything configured is left in place, if the package is removed. So after a reinstallation everything is back, as it was configured. The idea is nearly (not exactly) similar to ‘deleting’ software packages instead of ‘purging’ them.

The problem is (up to version 1.1.4) - as you have experienced - that the installation process generates a lot of configuration and credential items you mentioned. But if the corresponding files exist, nothing is overwritten to keep the original state. Let’s face it: This has been a design flaw (although with good intentions), as the newly generated and needed credentials are not set to the current values.

So we are going to break with the ‘don’t touch the existing items’ philosophy for those particular needs. The changes to the code were implemented yesterday, so you can expect the changes in the upcoming next release.

Thanks for your patience and help to discover this.

Regards,

Ingo von Thielau

Hi Ingo

This seems to be still an issue. I have a freshly installed Univention (4.3-0 errata22) with Openvpn4UCS version 1.1.14 and those cert and key lines are missing. If I add them by hand everything works fine. After changing some parameters in the OpenVPN4UCS console and hitting save those lines gets removed every time.

Am I doing anything wrong?

Moin,

those lines are written unconditionally when the config is created and never touched afterwards. Furthermore, there is no code to remove those lines. What happens if you remove /etc/openvpn/server.conf, change some parameters and save?

Those lines are always missing. Even when I delete server.conf:

root@server1:~# cat /etc/openvpn/server.conf
### Constant values

dh /etc/openvpn/dh2048.pem
ca /etc/univention/ssl/ucsCA/CAcert.pem
crl-verify /etc/openvpn/crl.pem
cipher AES-256-CBC
ifconfig-pool-persist ipp.txt
push "route None None"
push "dhcp-option DNS 10.1.0.10"
push "dhcp-option DOMAIN xxxxxx"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 1
mute 5
status /var/log/openvpn/openvpn-status.log
management /var/run/management-udp unix
dev tun
topology subnet

### Values which can be changed through UDM

port xxxxx
server 10.2.0.0 255.255.255.0
proto udp
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so /etc/pam.d/vpncheckpass

Where shall I put those lines where they won’t get removed?

Since there is no code to delete those lines, the problem is located somewhere else. What is the md5sum of /usr/lib/univention-directory-listener/system/openvpn-server.py?

d97f6fbf739cdb317f155f53b778cef5  /usr/lib/univention-directory-listener/system/openvpn-server.py
Mastodon