VPN service

2.1 Frontend

2.2 Backend

3.1 Access

• all staff and student accounts are automatically granted the permission to use VPN, unless they are member of the IDM.perm.infrastructure.vpn.no-access group in LDAP.

• all other accounts can be manually granted permission if needed (such as guest and ext accounts) by making them a member of the IDM.perm.infrastructure.vpn.access group in LDAP.

• cliens use TLS-CRYPT certificate as shared secret

3.2 Sessions

• there is no session limit, multiple devices can be connect with one account at the same time.

• there is session timeout of 3d after which clients are automatically disconnected.

• there is no bandwith limit, however individual client connections currently top-out at around 1GB/s.

• VPN connections from BFH internal network are blocked.

3.3 Client addresses

• each client recieves both a public IPv4 (147.87.80.0/20) and a public IPv6 address (2a07:6b44:209::/48) managed by the VPN server (not via DHCP), detailed subnet to node mappings are listed in the subnet list.

• there is no subnet propagation, the VPN service is for connecting single clients to the BFH network, not entire subnets (site-to-site).

• there is no client isolation, VPN clients are part of fabric-clients and can reach each other as well as any network addresses just as LAN and WLAN clients.

• there is no DDNS for clients conntected to VPN.

3.4 Client routing

• VPN is a Layer 3 Tunnel (tun) via UDP on the default port 1194 with fallback on TCP port 443.

• General connection preference is: udp6 → udp4 → tcp6 → tcp4

• failover indiscriminatly, regardless of connectivity or daemon load.

• with the default profile (vpn.bfh.science), only BFH IPv6 subnets and IPv4 subnets go through VPN, everything else goes through the local internet uplink.

• exceptions are maintained for e.g. book publishers that have allowed BFH subnets for their services, these are also going through VPN.

• with the all profile (all.vpn.bfh.science), all traffic goes through the tunnel.

• DNS queries for bfh.ch are tunneled through VPN when using a windows client, all other DNS queries do not go through the tunnel but the to the local resolver, → see client matrix.

3.5 Client configuration

• only openvpn3 clients are supported.

• the setup URLs are:

  • either https://vpn.bfh.science (with split tunneling, recommended)

  • or https://all.vpn.bfh.science (without split tunneling)

• the connection host is connect.vpn.bfh.science

• the configuration is only downloaded once during the setup of the client, there is no automatic configuration update (needs to be triggered manually on the client by re-running the setup).

• users authenticate with their BFH UPN and password as present in LDAP (e.g. foo1@bfh.ch).

• client uses nobind to have the tun interface move on top the active interface (LAN vs. WLAN)

• client verifies endpoint client certificate (with embedded root ca certificate)

• client uses decreased poll timeout to 5s

• data cipher is CHACHA20-POLY1305

3.6 Server load-balancing

• 2 nodes with nft as loadbalancer (active/passive)

• nft loadbalancer does round-robin on both backends and instances

• traffic to the loadbalancers (/29) are excluded from the tunnel

3.7 Server connections

• each backend has multiple daemons to handle many sessions in parallel for maximizing bandwith

• each daemon has its own subnet (openvpn is setup in subnet topology)

• management port per daemon on socket (/run/openvpn/management_$id.socket)

3.8 Split tunneling

• we recommend using split tunneling, i.e. only traffic to the BFH network is routed through the VPN tunnel.

• we maintain a list of exceptions that are also routed through the tunnel, such as library resources and scientific publishes where BFH has a IP-restriction based subscription. new exceptions can be requested via servicedesk

• we don’t recommend choosing to route all traffic trought the the VPN tunnel, i.e. disabling split tunneling, in order to avoid local network problems, issues with cloud services, and for performance reasons.

4.1 Client

• Download Client:

  • Linux: sudo apt install openvpn3-client

  • macOS & Windows: https://openvpn.net/client/

• On managed BFH Clients (macOS and Windows):

  • Team MWS provides regularly on their on schedule new versions of the openvpn client.

  • Generally always the newest client can and should be used.

  • If we are aware of important security fixes, we proactively ask Team MWS to deploy updates.

• On unmanaged Clients:

  • Users have to update the package on their own. On Linux, we recommend to use automatic updates (of all packages, not just openvpn).

4.2 Client features

4.3 VPN throughput

4.4 Server recovery

• On base[5-8] and base10 start all vpn.bfh.science containers

• Check if all vpn workers (daemon*.node*.vpn.bfh.science) are running (# sudo systemctl status openvpn-server@* | grep "^Active"). There should be 16 running daemons listed for each node.

• Check if oAuth2 proxy (node*.proxy.oauth2.vpn.bfh.science) is running by checking if https://oauth2.vpn.bfh.science/101/ready. This should return “OK”. Please iterate “101” from 101 to 116, 201 to 216, 301 to 316 and 401 to 416.

• Check if the loadbalancer (node*.proxy.vpn.bfh.science) is running by checking if nftables is populated on the node (# nft list ruleset should have chains like TO_NODE*, loadbalancing, ratelimiting …). Pinging (v4 and v6) to connect.vpn.bfh.science should be successful.

• Check if there are already users (# ssh node*.vpn.bfh.science sudo /srv/node*.vpn.bfh.science/openvpn/bin/get_all_loggedin_clients).

• Check if rate limiter has been hit (# ssh connect.vpn.bfh.science sudo nft list sets). IP addresses which are in the set “BAN_V*” cannot establish new connections.

Legacy

• Switch off Cisco ASA (VPN-ext) on 4.5.2026

Setup

• shs1: redesign of VPN subnets for better firewall deployment

• krj2: unblock script for ratelmited IPs

• krj2: script usual operations like killing sessions of a user etc.

• krj2: Entra oAuth2 Passwort in Azure Appreg durch Zertifikat ersetzen (#857)

• bad9: tidy apache config to allow allowed users only (i.e. no ext on main, no main on ext)

• TODO: aggregate logs on vpn.bfh.science

• TODO: vpn desaster recovery documentation/exercise

Features

• try Data Channel Offload (DCO) with Linux >= 6.16

• try DDNS via client-connect/client-disconnect hooks auf openvpn-server

• authentication with certificates

• replace nft loadbalancer with udp aware proxy

Known issues

• configuration inconsistency: OpenVPN Client bug on IPv6-only systems (#351)

• android: “always on” vpn warnings

• openvpn3-client doesn’t support connection profiles (#15)

• there’s no possibility to push config changes or an updated config to the client

• openvpn-auth-ldap doesn’t support defered authentication (#66, #67)

• OpenVPN3 connect client (version >= 3.8.0) hangs trying to connect. Cause: if any modifications (username or password entry) are done after the import of the profile. Workaround: Purge profile, fetch profile with the correct username, do not modify the config (no password save).

• iPerf3 and iPerf3-darwin on MacOS and iOS does not send packages through VPN. Ping and traceroute on the other hand do.