VPN service

1. About

TL;DR

A virtual private network (VPN) is a mechanism for creating a secure connection to extend access to a private network (one that disallows or restricts public access) to users who do not have direct access to it, such as an office network allowing secure access using an insecure communication medium such as the public Internet.

2. Systems

2.1 Frontend

FQDN IPv6 IPv4 Notes
connect.vpn.bfh.info High-available entry-point for all VPN connections
config.vpn.bfh.info Setup URL for VPN configuration

2.2 Backend

Warning
Always use the frontend DNS record

Never use the backend nodes directly:

  • backend may change without notice at any time (e.g. IP addresses, DNS records, configuration, etc.)
  • backend has no legacy support or grace periods, changes are implemented instantly
  • backend can be rebootet without notice at any time
  • backend access will soon be restricted

FQDN IPv6 IPv4
node1.vpn.bfh.info 2a07:6b44:115:11::21 10.4.123.21
node2.vpn.bfh.info 2a07:6b44:115:11::22 10.4.123.22
node3.vpn.bfh.info 2a07:6b44:115:11::23 10.4.123.23
node4.vpn.bfh.info 2a07:6b44:115:11::24 10.4.123.24
FQDN IPv6 IPv4
proxy.vpn.bfh.info 2a07:6b44:115:11::10 147.87.28.2
node1.proxy.vpn.bfh.info 2a07:6b44:115:11::11 147.87.28.3
node2.proxy.vpn.bfh.info 2a07:6b44:115:11::12 147.87.28.4
node3.proxy.vpn.bfh.info 2a07:6b44:115:11::13 147.87.28.5
node4.proxy.vpn.bfh.info 2a07:6b44:115:11::14 147.87.28.6
FQDN IPv6 IPv4
web.vpn.bfh.info 2a07:6b40::82 147.87.0.82

2.3 Legacy (Cisco ASA/AnyConnect)

FQDN BFH non-BFH IPv6 IPv4
vpn.bfh.ch
vpnext.bfh.ch
FQDN IPv6 IPv4
vc41.bfh.ch — 147.87.19.66
vc42.bfh.ch — 147.87.19.67
vc43.bfh.ch — 147.87.19.68
vc39.bfh.ch — 147.87.19.74

3. Features

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.infra.infrastructure.vpn.access group in LDAP.

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, no 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.

3.4 Client routing

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

  • Fallback is TCP port 443.

  • 50% of the backend daemons listen on UDP, 50% 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 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.

  • 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://config.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.

  • 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

3.6 Server load-balancing

  • 4 nodes with nft, one being active

  • nft round-robin on both backends and instances

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

  • TODO

6. Backlog

Legacy

  • Cisco ASA Abschaltung Ende 2025

Setup

  • config: shared secret for TLS-AUTH

  • logging?

  • nft proxy in HA

  • upgrade to trixie

  • harmonize linux and windows/macos config files wrt/ ca-certificates

  • documentation: vpn.bfh.info

  • documentation for end-users (FSS)

  • client deployment for end-users (MWS)

  • management port aggregation via e.g. vpn.bfh.info for sysadmin?

  • loadbalancer exclusion in config, one 1 or just the whole /29?

  • vpn always-on, even when inside BFH net?

  • enduseranleitung

  • vpn formular

  • ddns?

  • fail2ban?

  • geht auch user@bfh.ch?

  • link zu clients auf vpn.bfh.info

  • graphivz

Features

  • MFA

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

  • replace nft loadbalancer with udp aware proxy

  • authentication via certificates

Known issues

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

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

  • proto: udp6 keeps ipv4 enabled?

  • windows and macos clients do not support using system certificates

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

  • windows client on ipv4 only uplink doesn’t do ipv6 dns requests eventhough ipv6 is available through the tunnel.