How-to guides · 6 min read
How to make remote access work through firewalls without opening ports
Written for: Network and IT staff deploying remote access across sites with strict egress filtering or inspection proxies.
In short
Older remote access approaches expected you to forward an inbound port to each machine, which is both laborious and a standing invitation to attackers. Cloud-brokered tools invert it: the agent makes an outbound connection to a broker, and your session is relayed over that existing channel. Nothing inbound is exposed, and in most networks it works with no firewall change at all.
Key takeaways
- Outbound-only architecture removes the need for inbound port forwarding, which is a significant security improvement over exposed RDP.
- In most networks, standard outbound HTTPS on port 443 is all that is required.
- Deep packet inspection and TLS interception are the usual causes of failure on locked-down networks, not blocked ports.
- Allow-list by hostname where you can, because cloud service IP ranges change.
- Exposing remote desktop protocols directly to the internet is a well-documented route to compromise. Do not do it.
Outbound beats inbound
The old model required each remote machine to be reachable from outside, which meant port forwarding at the router, static addressing, and a service listening for connections from anyone who found it. That last part is the problem: internet-exposed remote desktop endpoints are routinely scanned and attacked, and are a well-documented initial access route for ransomware.
The modern model reverses direction. The agent on the remote machine opens an outbound connection to a broker service and holds it. When an operator wants a session, the broker matches the two sides over connections that were both initiated from inside their own networks. No inbound rule exists, so there is nothing on the perimeter to find and attack.
What to allow
Most deployments need outbound TCP on port 443 to the vendor's service endpoints, which the majority of corporate networks already permit for general web traffic. If your egress policy is default-allow, there is genuinely nothing to configure, and the deployment will simply work.
On a default-deny network, allow-list the vendor's published hostnames rather than IP addresses. Cloud infrastructure changes addresses without notice, and an IP-based rule will fail at an unpredictable moment months later, usually during an incident.
- Outbound TCP 443 to the vendor's documented endpoints
- Hostname-based allow-listing in preference to IP ranges
- An exclusion from TLS interception for those hostnames if you run an inspecting proxy
- No inbound rules at all, which is the entire point of the design
When it still does not connect
On tightly controlled networks the failure is rarely a closed port. It is usually TLS interception: the inspection proxy substitutes its own certificate, the agent correctly refuses to trust it, and the connection is dropped. The fix is a bypass rule for the vendor's hostnames, not a change to the agent.
Other recurring causes are proxy configuration that exists for the logged-in user but not for the system account the agent runs under, and captive portals that intercept everything until someone authenticates in a browser.
- TLS inspection breaking certificate validation, the most common cause on enterprise networks
- Proxy settings configured per-user but not for the system service account
- Captive portals holding the machine before it can reach anything
- Endpoint security software blocking the agent process rather than the network path
Diagnosing it in the right order
Work from the network outwards. Confirm the machine can resolve the vendor hostname, then that it can open a TLS connection to it, then look at the agent's own log. Each step tells you which team owns the next action, which is what actually gets these tickets closed in a large organisation.
Test from the system account context where you can. A great deal of time is lost proving that a connection works in a browser, when the browser is using per-user proxy settings the agent has never seen.
Getting remote access working through a firewall
1. Confirm the tool is outbound-only
If a product asks you to forward an inbound port to each machine, that is a meaningful mark against it on security grounds.
2. Check outbound 443 is permitted
On most networks this is already allowed and no change is needed at all.
3. Allow-list by hostname
Use the vendor's documented hostnames rather than IP addresses, so the rule survives infrastructure changes.
4. Bypass TLS inspection for those hosts
Interception breaks certificate validation and is the leading cause of failure on inspected networks.
5. Verify the system account's network path
The agent runs as a service. Per-user proxy settings do not apply to it, which explains connections that work in a browser but not for the agent.
6. Read the agent log before escalating
It will usually distinguish a name resolution failure from a certificate rejection, which points at the right team immediately.
7. Retire any exposed remote desktop ports
Once brokered access is working, close inbound remote desktop from the internet. Leaving it open alongside is the worst of both designs.
Common mistakes
- Leaving inbound remote desktop exposed to the internet alongside a brokered tool.
- Allow-listing IP addresses for a cloud service, which will break silently later.
- Forgetting that TLS inspection will break certificate validation for the agent.
- Testing only in a browser, under a user account with proxy settings the service account does not have.
- Treating a captive portal as a firewall problem when it is an authentication problem.
Frequently asked questions
- Do I need to open firewall ports for remote desktop software?
- Not for cloud-brokered tools. The agent connects outbound over HTTPS and the session is relayed over that channel, so no inbound rules are required. Older direct-connection approaches did need port forwarding, which is part of why they were risky.
- Which ports does remote support software use?
- Typically outbound TCP 443, the same port as ordinary secure web traffic, which most networks already permit. Check the specific vendor's documentation for the exact hostnames to allow on a default-deny network.
- Is it safe to expose RDP to the internet?
- No. Internet-exposed remote desktop endpoints are continuously scanned and are a well-documented initial access route for ransomware. Use a brokered service or a controlled gateway instead.
- Why does the agent fail to connect when a browser works fine?
- Usually because the agent runs as a system service and does not inherit the per-user proxy configuration the browser is using, or because TLS inspection is presenting a certificate the agent will not trust.
How this works in 247connect
247connect agents connect outbound over HTTPS to the cloud service, so there are no inbound firewall rules to create and no ports exposed to the internet on the machines you support.
More how-to guides
Support a home worker
Practical guidance for supporting staff at home: home network problems you cannot control, personal devices, VPN and connectivity faults, and the etiquette of working on someone's machine in their house.
Run PowerShell remotely
Using a command line during a remote support session: when scripting beats clicking, running commands without interrupting the user, safety practices, and keeping an auditable record of what you ran.
Audit remote access
Building a defensible audit trail for remote access: what each session record should contain, how long to keep it, what to review and how often, and the questions an auditor will actually ask.