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.

• client uses TLS-CRYPT 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 is 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 defined 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.

• no DDNS for clients for the moment

3.4 Client routing

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

• Fallback is TCP port 443.

• General connection preference is: udp6 -> udp4 -> tcp6 -> tcp4

• failover indiscriminatly, regardless of connectivity or daemon load.

• 75% of the backend daemons listen on UDP, 25% on TCP.

• in general only BFH IPv6 subnets and IPv4 subnets go through VPN, everything else goes through the local internet uplink.

• exceptions are maintained (TODO bad9) 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.info

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

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

• client notifies server on exit

• data cipher is CHACHA20-POLY1305

• TODO bad9: remaining ciphers

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 features

• TODO bad9: add row for openvpn linux client

Legacy

• Cisco ASA Abschaltung Ende 2025

• Redirect vpn.bfh.ch zu vpn.bfh.info

Setup

• TODO juli: client update empfehlung (MWS)

• TODO juli: documentation for end-users (FSS)

• TODO juli: client deployment for end-users (MWS)

• TODO juli: enduseranleitung und links auf vpn.bfh.info

• graphivz im servicebeschrieb

• TODO juli/august: upgrade to trixie

• TODO juli/august: replace nft loadbalancer with udp aware proxy

• TODO juli/august: rate-limiting auf proxy

• TODO august: vpn desastery recovery documentation/exercise

Features

• MFA

• Data Channel Offload (DCO) with Linux >= 6.14

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

• Authentication with certificates

Known issues

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

• configuration inconsistency: OpenVPN Server ‘proto: udp6’ is needed to have udp4 too (dualstack)

• 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