Netgear OpenVPN: TUN and TAP Listen on Different Ports

A phone connects to the router's VPN without complaint, and a laptop using a profile from the same download page times out. Nothing about certificates changed between those two attempts, because the laptop never reached the point where certificates matter. The router publishes separate listeners for TUN and TAP, and a working profile has to pick the one belonging to its own device type.

Deciding which of three candidate faults to chase is the whole job here: the port, the device type, or the data-channel cipher negotiation.

Three things that have to agree

The device type, the profile's interface line and the listener port form one choice, not three. A profile declaring dev tun and aimed at the TAP listener cannot complete the session, and the reverse fails identically. For your model and firmware, read the port from the router's own VPN page rather than from a guide, because the numbers move between builds. Write the model and firmware version next to that number so the next person can verify it.

Reports from the field mention a pair such as 12973 for TUN and 12974 for TAP on one firmware, and a different number on another. Read those as proof that builds differ, not as constants to copy. The profile then needs the distance-appropriate hostname: the router's dynamic DNS name rather than a WAN address that will change.

After correcting the port and the interface line, the profile looks like a normal client configuration with one remote line and one dev line. If the two disagree, no amount of retrying produces a session.

Read the log in the order it prints

An OpenVPN client reports events in the order they happen, so the last line before silence identifies the layer to inspect. When the run ends at TLS Error: TLS key negotiation failed, or simply waits for a first response and gives up, certificate comparison never happened. That points at reachability, at the listener, or at a port that has nothing behind it. None of those is repaired by replacing the CA file.

A run that reaches VERIFY OK and then fails sits elsewhere entirely, with its own causes. Sorting those two outcomes before touching files prevents the classic detour through certificate bundles that were never consulted. Once the handshake completes but the tunnel does not come up, look at cipher negotiation instead of reachability.

Add the cipher list a modern client expects

Recent OpenVPN clients refuse older defaults that consumer firmware still offers, and the symptom is a negotiation failure immediately after a successful handshake. The fix is one profile line naming what the client will accept: set data-ciphers to AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 and AES-128-CBC in that order. Any algorithm the router does not implement is simply never selected, so a longer list costs nothing but a slightly longer negotiation.

Listing ciphers does not teach the router one it does not have. If negotiation still fails, check whether the router page has a cipher setting of its own and whether that setting includes at least one entry the client accepts. Two lists with no common member produce exactly the same failure as a wrong port, which is why both ends deserve a look.

Import once instead of hand-editing copies

Importing the corrected file into NetworkManager avoids a folder full of slightly different profiles: nmcli connection import type openvpn file client.ovpn, then bring it up by name. Keep the imported profile as the single copy you edit, and delete the duplicates that accumulate from repeated downloads.

Then test from outside the LAN. Connecting from the same network proves very little, because the traffic may never traverse the tunnel at all. Confirm that a request actually leaves through the router, not merely that the client shows a connected state.

Decide what to do about warnings

Consumer firmware usually mints its own certificate authority, and clients complain about verification in ways the firmware cannot suppress. Judge whether that complaint matters for what you are protecting instead of treating every warning as fatal, and do not switch off verification globally to silence one message. A warning you have assessed is a documented risk; a verification setting you disabled is an undocumented one.

When the firmware provides no supported way to correct a warning that does matter, that gap argues for hosting the VPN elsewhere. Choosing between repairing the profile, accepting the warning and moving the endpoint is a decision about how much you trust that certificate. Make it deliberately, and write down which option you chose, rather than clicking through dialogs until the icon turns green.