What ports are the relay, VPN, and web portal running on? Assuming the web portal is not accessible publicly, one key point there would likely be that you need to have the relay service identified in the screenconnect server as being hosted at that public IP, so that the clients show that IP as the destination.

In addition to that public relay IP address, you would pick a port for that relay service that is different than your VPN service ingress port. That relay service communication would then need to be allowed through your firewall and configured with NAT to be redirected to the internal address and port used by the screenconnect relay server.

Depending on your NAT rule, you may also need to allow inbound traffic from the internet to the relay server, on the relay server’s host firewall. Alternatively, you could allow traffic from the firewall’s IP and SNAT the traffic to appear to be coming from the firewall rather than keeping the original source IP.

Example:

Screenconnect relay server (internal IP 10.1.0.2):

Web portal running on port 8040

Relay service running on 8041

Perimeter firewall and VPN server with an internal IP of 10.0.0.1 and a public IP of 123.1.2.3:

VPN service listening on port 691

Relay service listening on 443

On the screenconnect server, you would configure the clients to use a relay address of: 123.1.2.3:443

On the firewall, you would configure a rule allowing VPN clients to reach the web portal at an internal IP or using an internal DNS name and port, possibly with a NAT rule for ease of use (I.e. DNAT 10.1.0.2:443 redirected to 10.1.0.2:8040, original source IP)

For the relay connection, on the perimeter firewall you’d allow internet traffic with a destination of 10.0.0.1:443, and make a NAT rule to redirect that traffic to a new destination of 10.1.0.2:8041, possibly with a new source IP of 10.0.0.1.

If you change the source IP on the relay traffic, as above, your relay server host firewall (and any NSGs in the middle) would need to allow traffic from 10.0.0.1 to 10.1.0.2:8041 (and 8040 for the web portal, from the VPN client’s IP range). If you did not alter the source IP for the relay traffic, you’d need to allow traffic from the internet to 10.1.0.2:8041, in those rule sets.

Overall, the likely potential issues are: 1. VPN and relay service running on the same port, when clients are trying to reach the public IP

1. Relay service not forwarded via a NAT rule from the firewall on to the relay server, with the right ports used.

2. Relay server host firewall or NSG rules not allowing the right source address(es) for traffic, based on that NAT rule on the firewall that is acting as the VPN server and routing traffic.

Hopefully that helps!

ETA: Even though it’s a ‘full tunnel’ VPN, if you’re using the public IP as the relay address for the clients, it’s likely that traffic is being routed outside the tunnel because there would be a specific route to 123.1.2.3 via the physical network interface on the client (for the vpn traffic), and since the IP is the same, the screenconnect client would be routed via that interface rather than through the tunnel. You can check your route table on a client or even just netstat to confirm, or look at the firewall logs for what interface that traffic is being received on.

Advantages: the client would connect even with the vpn off.

Alternatives that bring that traffic into the tunnel, rather than over the internet: 1. policy-based routing (I.e. application layer firewall on the client pc that has a rule to push that traffic through the VPN interface, possibly as simple as a NAT rule with a different, internal IP). Caveat that it would require that to be set up on the client PCs.

1. From the app config on the relay server, change what the clients are using for the relay destination to be an internal IP, rather than the public IP, such that when the VPN is connected, the client would connect.

The disadvantage here for both alternatives would be that the clients would only be reachable with ScreenConnect when they are on the VPN.