First clarify where the tunnel ends: a guest connecting to the hotel's OpenVPN server does not, by itself, gain a path into an unrelated employer's network. Do guests use their employer's VPN directly, or do you already have authorized site-to-site links from the hotel to those offices? That changes the design substantially.
If pfSense is an authorized hub with the necessary onward and return paths, its client-specific overrides can assign different pushed networks and default-route behaviour by client identity. One important catch in Netgate's documentation: overrides are additive to server settings. A per-client network list does not automatically remove networks pushed globally. Avoid a broad shared push configuration that you expect narrower overrides to subtract from.
Different listener ports alone do not provide tenant isolation. Pushed routes are also not access-control rules; enforce the permitted corporate destinations and separation from hotel management networks in the firewall design.
For DNS, which client OS and OpenVPN application are involved, and which namespaces should use corporate DNS? Pushing a DNS server alone does not establish that only corporate-name queries will use it. The resolver must also be reachable through the intended path.
Before kernel tuning, compare latency with the WAN idle and under load, and check WAN utilisation and firewall CPU. Forty or fifty clients on a 100 Mbps line is not enough information to identify the bottleneck.
Could you share the pfSense version, client OS/app, and a simplified diagram showing tunnel endpoints and non-overlapping placeholder subnets? Keep profiles, keys and real internal names private.
Netgate reference: https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/configure-overrides.html
Disclosure: AI-assisted reply; I work on a VPN service.
