TCP works and UDP reaches another server on the same port

A profile works over TCP and fails over UDP with a certificate warning. The intuitive reading is that the UDP path broke trust, and the intuitive fix is to accept the certificate. Both assumptions skip a possibility that explains the symptom completely: the two transports reached different machines. A forwarding rule is matched per protocol, and nothing forces the TCP and UDP halves of one port number to point at the same host.

One port number, two independent rules

Forwarding is a table lookup keyed on protocol, destination address and port. A gateway with a rule for TCP 1194 and a rule for UDP 1194 is expressing two independent decisions, and they can name different internal hosts. The shared number is a convenience for humans, not a property the network enforces. Treat the port number as a label rather than as a service definition.

Look at the effective rules rather than the intended ones. Destination address, translated port and ingress interface all participate, and a leftover rule from an earlier migration is the usual reason the two halves disagree.

Write both mappings down before changing anything else. The pair of lines is the whole hypothesis.

What the client actually verified

During the handshake the client checks the certificate against its configured trust and against the name it expects. An unexpected certificate is a successful verification that failed the identity check, which is the correct outcome when the peer is not the one you meant to reach. Rejecting it is evidence the client works, not evidence the transport is broken. Read the reported name before the reported chain, because the name is what the client compared.

The distinction matters because the two failures lead to different fixes. A trust problem needs a trust fix, while an unexpected peer needs a routing or forwarding fix.

Note which identity the client reported. That name is the strongest clue about which machine answered.

Correlate the attempt with a server

Record the profile, the public address, the transport and the port the client used. Then match the attempt time against the log of the server you intended to reach. Absence there is a lead rather than proof of a firewall drop, because logging levels differ between deployments. A timestamp plus a source address narrows it further than either alone.

Compare the certificate identity you encountered with the expected identity through an administrative channel. Doing that comparison out of band is what keeps the check trustworthy.

Check old forwarding rules, alternate listeners and any load-balancing path before concluding that both transports share a backend. Each of those can redirect a flow without touching the other transport.

Do not fix trust to match a wrong peer

Importing the unexpected CA makes the symptom disappear and changes who the client trusts. That is a worse state than a failed connection, because it hides the mismatch instead of resolving it. The same applies to disabling verification just to see whether the tunnel comes up.

If the peer turns out to be legitimate but unintended, the correct action is to retire it or to point the rule at the right host. The trust store is not the place to reconcile an inventory mistake.

Keep the rejection text. It is the only record of what the client saw.

After the fix, test a new flow

Correct the mapping, then connect with a fresh client session. Stateful translation can keep an existing flow pointed at the old destination, so an established connection may survive the change and mislead you. Start a new one and confirm from the intended server's log that it handled the attempt.

If both transports demonstrably reach the same server and still behave differently, the remaining difference is that server's own listeners and configuration. The transport comparison only means something once the endpoint identity is fixed.