VPN service

2.1 Frontend

2.2 Backend

2.3 Legacy (Cisco ASA/AnyConnect)

3.1 Access

• all staff and student accounts are automatically granted the permission to use VPN.

• 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.

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.

• in general 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.

• 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

• users can send all traffic through the tunnel if they choose to.

3.5 Client configuration

• only openvpn3 clients are supported.

• the setup URL is https://vpn.bfh.science

• 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 account and password as present in LDAP (with or without @bfh.ch suffix).

• 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)

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

• Cisco ASA Abschaltung Ende 2025

• Redirect vpn.bfh.ch zu vpn.bfh.science

Setup

• FSS: documentation for end-users

• MWS: client deployment for end-users

• gbs4: discontinue vpn formular fuer ext accounts

• shs1: block BFH user on the firewall, remove nft rules from proxy

• shs1: redesign of VPN subnets for better firewall deployment

• TODO: enduser seite und links auf vpn.bfh.science

• TODO: Entra oAuth2 Passwort durch Zertifikat ersetzen

• TODO: aggregate logs on vpn.bfh.science

• TODO: exception list for book/magazine publishers

• TODO: vpn desaster recovery documentation/exercise

• krj2: unblock script for ratelmited IPs

• TODO: lo interface binding to ::1 instead of 127.0.0.1

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.