Port 53 (UDP and TCP) gets blocked when OpenVPN is operating

I am trying to debug a mind-boggling DNS failure when an OpenVPN client is operating. Although I can ping 8.8.8.8, when I run dig +trace example.com @8.8.8.8 I get as a reply connection timed out; no servers could be reached. Strangely, when I capture and inspect network packets, no port 53 packets appear on any of the computer's network interfaces. (Other packets appear fine in the packet dump when OpenVPN is connected, and port 53 packets also appear when OpenVPN is not connected.)

Through packet capture I've narrowed down the problem to the complete disappearance of port 53 packets when the OpenVPN client is running. Specifically:

• when the OpenVPN client is running no UDP or TCP port 53 packets appear on the packet trace if I execute echo hi | nc -u 1.2.3.4 53 or echo hi | nc 1.2.3.4 53,
• packets appear normally in the packet trace if I send them on a different port, e.g. echo hi | nc -u 1.2.3.4 52 or echo hi | nc 1.2.3.4 52,
• packets appear normally in the packet trace if the OpenVPN client is not running.

By tracing the CygWin nc (netcat) system calls, I further narrowed down the failure to a WSAEACCES (10013) error when the socket is created.

 23   21665 [main] nc 2406 cygwin_socket: 3 = socket(2, 1 (flags 0x0), 6)
204   21869 [main] nc 2406 __set_errno: void __set_winsock_errno(const char*, int):200 setting errno 1
 24   21893 [main] nc 2406 __set_winsock_errno: connect:810 - winsock error 10013 -> errno 1

This is a "Permission denied" error, documented as follows: "An attempt was made to access a socket in a way forbidden by its access permissions. An example is using a broadcast address for sendto without broadcast permission being set using setsockopt(SO_BROADCAST)."

OpenVPN is operating in tap mode using the default 1194 port on a Windows 10 machine. The Windows Defender Firewall and the Windows Defender antivirus are temporarily turned off to rule them out as culprits. For the same reason, no other firewall or anti-virus software is currently running on the specific computer. Exactly the same OpenVPN configuration works fine on a Debian GNU/Linux computer.