In order to access to IBR internal services, IBR employees and students doing work at IBR can use OpenVPN. Note that version 2.6 or newer is required. Unlike PPTP and IPsec, OpenVPN combines great flexibility, relatively simple configuration, and availability for all major platforms. As of now, we have no plans to support WireGuard.
Routed tunnels are provided for both IPv4 and IPv6; bridging is not offered. Clients receive private IPv4 addresses, for which the IBR router uses NAT to allow external communication. IPv6 is supported through a public subnet.
The provided information and profiles have been tested with Mac OS "Tunnelblick" and the OpenVPN iOS app.
This service is not meant to be used for anonymizing access to any peers or for accessing geo-blocked commercial services.
As a service that will end soon in April or May 2026, we provide the following profiles for user-based authentication (non 2FA) of IBR users. The provided profiles differ in the range of the tunneled address spaces.
Note that the support of these profiles will end, once our new VPN configuration and authentication system is mandatory. See the next section.
In times of more and more content distribution networks with rapidly changing setups, we see longer a value in trying to add a few target addresses to be routed through IBR VPN tunnels supposed to reach IEEExplore, Statista, or Elsevier. If you want to access such remote service from outside the TU network, please consider using the "ibr-all" setup above.
We have plans to re-work the VPN setup with the target to enhance security. For now, we keep the service as it is and do some additional testing on additional UDP ports 1196 and 1197. You can try the new approaches, if you like. Feedback is welcome.
Users (members of groups mitarb and ibrusers) are able to manage their own private client configurations and derived profiles. Such a configuation consists of a key/certificate-pair managed on the server, a requestable .ovpn profile that embeds these credentials, and optionally some server-side settings that will be pushed to the client upon connection. As a user, you just have to know about the ibr-vpn tool to manage your client configuration(s) and you have to handle your downloaded .ovpn profile(s) with severe care and use them solely for your personal client(s).
steinb@x1 $ ibr-vpn create phone --tu
steinb@x1 $ ibr-vpn create notebook --all
steinb@x1 $ ibr-vpn list
steinb-phone
steinb-notebook
steinb@x1 $ ibr-vpn profile phone # to print a download URL and QR-code
steinb@x1 $ ( umask 0077 && ibr-vpn profile --stdout notebook > notebook.ovpn )
Note that such a named .ovpn profile contains all the required credentials to establish your VPN connection. Never let anyone else get access to such a file. However, other username or password information is not required to establish a VPN connection, when you use this approach.
As a special use case, staff members may use the --user y0000009 option to create configurations for y-Users that are not allowed to create configurations themselves. This might be useful for some courses. In this case, the creating staff member's email address becomes part of the certificate's Subject DN which denotes the responsibility to revoke the configration when it is no longer required.
Staff creating config:
steinb@x1 $ ibr-vpn create --user y0000009 pac-2026
Y-user requesting/downloading the config:
y0000009@x1 $ ibr-vpn profile pac-2026
Staff revoking config when the course is finished:
steinb@x1 $ ibr-vpn revoke y0000009-pac-2026
Another approach besides certificate based access is based on username/password authentication which is handled internally via Keycloak. Once, when we make 2FA in Keycloak mandatory (or for now if you actively enabled 2FA on your Keycloak account profile), your authentication data should in fact be, for example:
username: steinb
password: Password123456
with 123456 being the current TOTP code.
Since this makes things more complicated and requires handling the sensible main password on each connection attempt, we strongly suggest to use the certificate based authentication presented above.
If you want to use this approach, you can get an according client configuration by the ibr-vpn profile without a name:
steinb@x1 $ ibr-vpn profile --stdout > keycloak-auth.ovpn
or to get a download URL:
steinb@x1 $ ibr-vpn profile
We will soon ban y-accounts from free access to our IBR VPN service and limit it to use the staff managed access described above. Students are free to use the GITZ VPN service, of course. IBR students usually have IBR accounts that can be used with the authentication schemes described above.
Setting up on Linux using the linked profiles above is very straightforward. First, the package openvpn must be installed. Then the VPN connection can be started with the command sudo openvpn IBR-TUonly.ovpn (or with another profile).
Integrating OpenVPN into Gnome via network settings is quite challenging but works after a few adjustments through the NetworkManager CLI's import function.
Required Packages:
networkmanager openvpn networkmanager-openvpnnetwork-manager network-manager-gnome network-manager-openvpn network-manager-openvpn-gnomeAdjust Configuration:
<connection> tags of the remaining connectionImporting the Profile:
nmcli connection import type openvpn file <profile.ovpn>Setting the Username:
nmcli connection edit <configname>
set vpn.user-name <username>
save
quit
Done. To debug, you can view the output of OpenVPN with sudo journalctl -f.
It is also possible to provide customized OpenVPN tunnel configurations for employees and projects that allow certificate-based authentication, static client addresses, explicit routing, and other specific adjustments. (@Admin: see openvpn:/etc/openvpn/README.IBR)
Employees can check the current status of active tunnels using ibr-vpn status.