I tried using both TCP and UDP. I compiled the DCO module with no luck. I regenerated the CA and client keys within F38 and, uploaded them to the Azure portal, regenerated the OpenVPN config script, but still nothing. I resolved to downgrade to the F37 OpenVPN package (OpenVPN-2.5.9-1.fc37) and restart Network Manager, and I could connect. In F38, it connects, initiates the connection, then loops in a reset connection panic. Reproducible: Always Steps to Reproduce: 1. Upgrade F37 to F38 2. Use the same OpenVPN script for connecting that worked previously. 3. Endless connection reset loop. Actual Results: An endless loop of connection reset. The connection appears successful and binds but constantly resets almost immediately. Expected Results: After a successful handshake/connection, I could access the resources in my Azure resource group and protected vnets. When I Downgrade to OpenVPN-2.5.9-1.fc37 and restart NewtworkManager, I am able to connect using the same OpenVPN configuration without issue. It works both on the CLI and within GNome's OpenVPN manager.
Created attachment 1960241 [details] OpenVPN client config file
blast, attached the file to the wrong bug. sorry! please remove it
Can you please try to start the connection from the command line directly, set the log level (--verb) to 4 and provide the output of that? Also might be worth a shot to try to connect using --disable-dco in the configs too, just to see if it is DCO related or not. If disabling DCO enables the connection, please try to set SELinux into permissive mode and see if that works with DCO. These are just a few potential areas I can imagine.