Serving OpenVPN over TCP and UDP from one host
One process binds one transport before 2.7. Compare a bridged TAP pair, two TUN subnets and a shared pool, then match each profile to its listener.
Networks that allow only TCP 443 coexist with networks that pass UDP happily, and one server has to serve both. A profile with proto udp answers the second group and fails the first, and editing the same configuration to say proto tcp does not create a second listener. The directive selects one transport for one process. Everything else follows from that constraint.
Either you run more than one process, or you run a version that can bind several sockets at once.
One process binds one transport before 2.7
Community OpenVPN binds the socket that proto describes, and that directive picks a single transport for the instance. TCP and UDP are separate stacks, so the same port number can be occupied by both at the same time, but not by one process. The 2.6 line therefore gives you one transport per daemon. OpenVPN 2.7 removed that limitation for servers, which can bind several sockets through multiple --local statements in one process.
Check the version before designing around either answer, because the 2.7 arrangement is a different operational model with its own configuration syntax. A guide written for 2.6 describes two processes even when it does not say so.
Three ways to run two instances
With TAP interfaces, run one instance per transport and bridge the two tap devices on the host. Both client sets end up in the same broadcast domain, which lets one address pool cover them and keeps broadcast-dependent protocols working. With TUN, bridging is not available, so the simplest split gives each instance its own subnet and lets routing keep the two client sets apart. A third option keeps one pool by having each instance call a learn-address script that installs a /32 route for the client through that instance's device.
That third arrangement is the one people ask for and the one that needs the most care, because the script becomes part of the data path and has to handle add, update and delete events correctly.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Keep the two instances separate
Each instance also needs a separate port or address, a separate status file and a separate log destination. Two daemons appending to a single status file produce output that cannot be read during an incident, which is exactly when you need it. If a second instance binds a specific address, that address has to exist on the host when the process starts; otherwise it exits with a bind failure before it says anything about keys.
Name the units and the profiles so the transport is obvious from the file name. The next operator should not have to open a config to learn which one is TCP.
Match the profile to the listener
A server running proto tcp expects a client profile with proto tcp-client, and a profile still carrying proto udp against that listener times out without an error the user can act on. Keep two profiles if the deployment offers both transports, and label them so support can tell which one was tried. The port number alone does not describe the transport.
Firewall rules follow the same split: a rule for UDP 1194 says nothing about TCP 1194, and a rule for one address does not cover the other listener.
Read the server's view first
Start with ss -lntup on the server and confirm that both a TCP and a UDP listener appear. Then connect one client of each kind and check the status output for two entries with distinct addresses. If the sockets exist and no client arrives, the path or the firewall is refusing packets before the daemon sees them.
A socket that never appears is a configuration or bind problem, and a socket that appears but never logs a connection is a filtering problem. Those two look identical from the client, which is why the server's own view comes first. Keep in mind that TCP carries head-of-line blocking, so offering it is a reachability measure rather than an upgrade for clients with a clean UDP path.