One TAP server or several? OpenVPN clients on a bridge

Multiple TAP clients do not require one server process, one UDP port, and one host TAP device each. One OpenVPN server in Ethernet mode can admit many authenticated clients and attach them to a single bridge, and doing so is the documented way to extend a layer-2 segment. The single-process design is the one the manual documents, and it is usually the right default.

Whether those clients should share that segment is the real question. Process count does not answer it, because the isolation properties come from the topology rather than from how many daemons are running. The rest of this comparison is about the two topologies and what each one makes easy.

Two architectures, not two settings

A routed TUN deployment gives each client a point-to-point link into the server's routing domain. Broadcasts stop at the server, clients cannot see each other's frames, and inter-client traffic, if any, has to be routed and filtered explicitly.

A bridged TAP deployment makes clients members of one Ethernet segment. They see broadcasts, can resolve each other with ARP, and depend on bridge and firewall policy rather than routing to keep them apart. That is useful when the clients must appear as if they were plugged into the same switch.

The comparison is therefore about what the clients need to reach, not about performance. Pick the layer first, then decide how many processes serve it.

What the server-bridge helper does

The server-bridge helper configures the multi-client Ethernet mode. Its address-pool form takes the gateway, the netmask, and a dedicated range inside the bridged subnet, for example a gateway at 192.168.50.1 with a pool from 192.168.50.160 to 192.168.50.199.

Reserve that range outside any other DHCP or static assignment. The helper allocates addresses from it, but it does not coordinate with another allocator on the same segment, and two pools that overlap produce duplicate addresses that look like random connectivity failures. Write the reserved range into the site's address plan so the next person does not reuse it. A comment in the server configuration is a poor substitute for that record.

A DHCP-proxy form exists for deployments where an external server hands out addresses. It has its own prerequisites, and mixing the two forms produces exactly the conflict the docs warn about. Choose one allocator for the bridged subnet.

Isolation does not come from process count

Eight OpenVPN processes attached to the same unrestricted bridge still share one broadcast domain. Clients can ARP for each other across the bridge, and the number of listeners changed nothing about that.

If the requirement is that groups of clients must not see each other at layer 2, the design needs separate bridges or VLAN attachments, with the access rules that go with them. That is a network design decision, and it is the same decision whether one server process or eight are involved. Bridge filtering can restrict some traffic, but it does not create separate broadcast domains. Treat it as a supplement to segmentation, not a replacement for it.

If the requirement is only that clients reach certain IP services, a routed TUN design is usually simpler than bridging plus filtering. Each client gets its own link, and the policy lives in routing and firewall rules instead of bridge internals.

When several processes are still right

Separate processes can be justified by operational needs: different authentication backends, different certificate authorities, separate upgrade cycles, or incompatible option sets. Those are real reasons and they are independent of client count.

If you use several, give each its own listener and device ownership and coordinate the address ranges. Two servers that both believe they own the same pool on the same bridge will eventually hand out the same address.

Then verify the design with several clients at once. Check that addresses are unique, that the intended inter-client traffic works, and that a pair which must not communicate cannot. A single client's successful ping exercises none of the multi-client design.

Read the bridge and the server mode from the running host before trusting the diagram. The configuration that matters is the one the kernel and the daemon actually loaded, and that is also the one a reviewer can check.