Synology NAS With Two LAN Ports: Why the VPN Handshake Fails

The laptop reports a TLS handshake failure, which sounds like a certificate problem and usually is not one. On a NAS with two Ethernet ports, the most common cause is a router forward aimed at the address the package is not listening on, and the client's message is identical either way. The package does not answer on the second port merely because both cables are plugged in. Before anyone reissues a certificate, prove that a packet reaches the NAS at all.

What the Client Reports and What Actually Happened

A handshake failure from an OpenVPN client is a catch-all. It covers a certificate mismatch, a transport mismatch, a listener on another port, and a forward that delivered nothing. That is why the message is useless as a starting point and useful only as confirmation. Treat it as a statement that the session did not establish, and as nothing more specific.

The port and the bound address are the two facts that decide whether a packet ever arrives.

Write both down before changing anything, because a plausible fix applied to the wrong layer is how a fifteen-minute problem becomes an afternoon. Note the interface, the address on it, the port and the transport. Those four values are the whole inbound path, and the next section explains where each one lives.

Find the Address the Package Listens On

DSM numbers the Ethernet ports and each one carries its own address. The VPN Server page names the interface the OpenVPN service uses, and the network panel shows the address configured on that interface. Read them in that order, from the service outward, so you describe what is listening instead of what you assume it should use.

The service binds one address. Having both ports linked and up does not make the service respond on the second one. A static address on one interface beside a DHCP address on the other gives you two similar values that are easy to swap at a glance, particularly when they differ in the last octet alone. Copy the address out of the panel rather than typing it from memory. Then confirm on the NAS what is actually bound to the port.

sudo ss -lunp | grep 1194

If that output names an address you did not expect, the forward is aimed at the wrong interface and everything else here is bookkeeping. Fix the rule before reading further, or you will end up debugging a certificate over a packet that never left the router.

Fix the Forward, Then Watch the Counter

Edit the existing forward rule rather than adding a second one for the same external port. Two rules can coexist in a router's table with only one ever winning, which turns a debugging session into an argument about which is real. Point the internal address at the value you read from the NAS, and leave the internal port matching whatever the service listens on.

If DSM takes that address over DHCP, create a reservation first. A lease change silently breaks a forward that worked yesterday.

sudo tcpdump -i any -n udp port 1194

Begin capturing before the client tries to connect, and read the source address in whatever shows up. Nothing at all means something on the way discarded it: the forward, the DSM firewall, or the interface it was aimed at, and certificates cannot be the cause while that holds. Something arriving from the client's public address with no reply means the NAS received the request and chose not to answer. Those are different findings, and only the second one sends you back into the package's own settings.

Only Then Look at Certificates and Transport

Once packets arrive, re-export the profile after any certificate change, because the old file still carries the authority it was created with. A profile hand-edited to use a different transport leaves the client waiting on a listener that does not exist, and it reports the same generic failure as everything else. Compare the transport inside the profile with the transport the package is set to serve. Two profiles for two transports is a legitimate design, and one profile edited for both is not.

Test from outside your own network as the last step, since a connection from inside the LAN can succeed over a path that never touches the forward.

Keep the exported profile, the interface address and the forward rule together in one note. When an address changes, that note is the difference between a fix and a repeat performance. Nothing in this path required reinstalling a package, which is worth remembering before the next reboot gets blamed.