What you're doing is crippling the Access Server software. Normally it uses ports TCP 443, TCP 943, and UDP 1194.
Limiting to UDP 1194 is technically possible. But you'll have to manually obtain the connection profiles and installers and get them set up just right so that they'll work.
The Connect Client and the Access Server communicate with each other over XML-RPC over an HTTPS link. If you log on to the web interface as a standard user (so not an autologin user) the Connect Client that user can download will contain a server-locked profile that doesn't contain the required information to establish a VPN tunnel directly. Instead, when you click 'connect' in that Connect Client it will talk to the Access Server on the client web services interface and present the credentials that you as a user have entered in the Connect Client. It will then fetch the correct user-locked profile for that user account and use it to establish a VPN tunnel. After the VPN tunnel is disconnected, the user-locked profile is removed from the client computer. This makes the Connect Client a universal client, meaning it will work for all the user accounts that exist in the Access Server.
By blocking port TCP 443 you are preventing this from functioning. Also, this makes it impossible for the TCP OpenVPN daemon to handle incoming connections. That means that if for some reason a firewall exists at the VPN client end that blocks UDP 1194, then the Connect Client will attempt to use TCP 443, as that is a port that is usually open on most simple firewalls (port 80 and port 443 are used for HTTP and HTTPS traffic respectively).
The web services actually run on port TCP 943 and an option called service forwarding forwards the traffic from browsers coming in on the default TCP 443 port to the TCP 943 port where the web services are, while OpenVPN traffic incoming on TCP 443 is handled directly by the OpenVPN TCP daemons that are available on port TCP 443.
So what you're doing breaks all this.
You can either live with only port UDP 1194 and having to switch the Connect Client to the advanced mode so that the import functions will become available, and then manually importing these connection profiles in the Connect Client, and then it will work. I would then also suggest that you disable the TCP OpenVPN daemons or else it will try to connect there (it will try UDP first but TCP next) which makes no sense since you know those TCP daemons are completely unreachable if you only forward UDP 1194.
Or, you can open up some more ports. For example under Server Network Settings you can set the TCP daemons to port 444, and forward port 444 from outside to your Access Server. You could then also forward port TCP 943, or another port, this port can be changed as well, so that you can reach the web services even if, for example, the TCP OpenVPN daemons have been stopped (since this disables service forwarding).
The Connect Client can be placed in advanced mode by looking at the instructions here;
https://docs.openvpn.net/under-the-hood/vpn-client-basic/
There are also command line scripts that can be used to generate a .dmg or .msi installer file that comes bundled with a user-locked or autologin type profile directly, so that you could hand this file to an end-user and they could just install it. A downside of disabling access to the web services is that the Connect Client will no longer be a universal client; once installed with a user-locked profile or autologin profile it will then only work for that specific user, and any additional user that needs to use the Connect Client on that computer will need to have his own profile imported for it to work, since it is not possible to use the connection profile from user a, with credentials from user b.
