Moving OpenVPN from TAP to TUN: a migration order that works

Swapping dev tap for dev tun changes what the tunnel carries, not just how it is named. A TAP interface hands Ethernet frames to a bridge, so clients behave as if they were plugged into the office switch. A TUN interface carries IP packets, so clients need routes and the far side needs a path back. The clients, the address plan and the LAN's return route all have to move with that change.

The migration is a network redesign with a tunnel attached, and the order below keeps it reversible.

Inventory what actually depends on Ethernet

List the applications, not the hosts. Determine whether each one uses routed TCP or UDP services, broadcast discovery, DHCP from the office LAN, a non-IP Ethernet protocol, or an assumption that both ends sit in the same subnet. Ordinary IP access survives a routed design. A protocol that needs raw Ethernet frames does not, and no amount of routing will make it work. Discovery-dependent applications need a replacement mechanism decided before the cutover, not during it.

That inventory is also the acceptance list. Every entry you cannot migrate becomes a documented exception or a reason to keep a small TAP segment alive for that workload alone.

Build the address and return-route plan

Choose a client prefix that does not overlap the LAN, the old bridge range or any network a client already reaches. A subnet-topology server needs a fragment like dev tun, topology subnet and server 10.78.0.0 255.255.255.0, but that is a fragment rather than a working profile. Keep the approved TLS, identity, transport and access policy around it, and use a prefix you have verified as free.

Then write down the destinations clients must reach and who provides the return path. The server needs forwarding enabled and a permitted onward path. LAN routers need a route back to the new prefix, or the design needs source translation with the visibility cost that implies. A route pushed to the client configures the client, not the LAN's reply path.

Pilot on a separate listener

Stand the new service up beside the old one on its own port and its own address range, rather than replacing the only entry point that works. Issue pilot profiles through the existing enrollment process so nobody rebuilds the CA for a migration. Connect one representative client with only the pilot path active, then compare assigned addresses, private DNS, the applications from the inventory and the paths that should stay blocked.

Include a reconnect and a return-traffic test. A handshake that completes says nothing about whether the far side can answer.

Move clients in groups with a rollback

Migrate in groups small enough that a failure is a support task rather than an outage. Keep the old service running and documented until each group's real workflows pass, and write the rollback as a switch back to the previous profile rather than a rebuild. Update address-based firewall rules, monitoring and any server-initiated access for the new prefix as each group moves.

Groups also give you a place to discover the application nobody mentioned, while the old path still exists to compare against.

Retire the bridge only after acceptance

Removing the TAP device is the last step, not the first. Check whether the bridge still carries the server's management address, a monitoring path or an unrelated workload before deleting anything. Retire startup dependencies, bridge membership and DHCP reservations through their owners, in that order, with a note of what was removed.

The migration is finished when the routed access model works for the inventory, not when a TAP interface disappears from the output of ip link.