
You have run the same clicker app for years without a hitch. Then you present at a client's office, or your own company rolls out a new firewall policy, and suddenly nothing connects. The spinner spins, the slide does not move, and IT has already gone home. Corporate firewalls block presentation tools more often than most people realise, and the reasons are almost never a bug in your app.
The good news is that this is a solved problem, not a mystery. Once you understand what corporate networks are actually blocking and why, you can either fix it in minutes or pick a tool that never hits the wall in the first place.
- Two failures cause almost every case: an app that ignores the system proxy, and UDP being blocked outright.
- The fix is architectural: follow the system proxy, try an alternate route, and fall back to standard HTTPS ports over TLS.
- A well-built tool needs no firewall exceptions and no inbound ports opened, since it only makes outbound connections.
Why offices lock networks down this tightly
Corporate IT teams are not trying to ruin your keynote. Office networks are built to stop malware phoning home, stop data leaving through unmonitored channels, and keep an audit trail of what connects where. That usually means:
- Blocking arbitrary outbound ports, only allowing standard web traffic.
- Requiring all outbound traffic to route through a proxy server.
- Blocking UDP traffic entirely, since it is harder to inspect than TCP.
- Refusing any inbound connection request from outside the network.
Every one of those is reasonable security practice. The problem is that a lot of presentation and clicker software was built assuming an open home network, not a locked-down office one.
What actually breaks
| Network restriction | What it blocks | Why it matters for presenting |
|---|---|---|
| Proxy auto-configuration (PAC) | Apps that ignore system proxy settings | The app cannot reach the internet at all, even though the browser can |
| UDP blocked | Direct peer-to-peer media connections | Screen shares and camera feeds fail to connect |
| Non-standard ports blocked | Anything outside 80/443 | Signaling or media servers become unreachable |
| No inbound allowed | Any tool expecting an inbound connection | Increasingly rare in modern tools, but still catches some hardware bridges |
The most common failure by far is the first two: an app that does not respect the system proxy, combined with UDP being blocked outright. Together they produce the classic symptom, a login screen that says "bad gateway" or a clicker that connects but never actually moves a slide.

How well-built tools get through anyway
The fix is architectural, and it comes in three parts that work together:
Follow the system proxy automatically
If the machine already has a proxy configured, either manually or via PAC file, the app should use it rather than trying to reach the internet directly.
Try an alternate route when the primary one is blocked
A single hardcoded address is a single point of failure; a resilient app quietly switches to a backup route.
Fall back to standard web ports over TLS
If UDP is blocked, media and control traffic should be able to relay entirely over the same HTTPS port a browser already uses, via a TURN relay. It is slower than a direct peer-to-peer connection, but it works, and the switch should be automatic and invisible to the presenter.
This is exactly what Cliqer's desktop app does: it follows your system proxy automatically, switches to a backup route if the primary address is blocked, and can relay entirely over standard HTTPS ports on networks that only allow web traffic. No firewall changes and no exceptions request needed on the IT side. We cover the technical side of that relay path in is WebRTC secure and the underlying networking in the Security & Networking docs.
Getting IT on side before show day
Even a tool that works around firewalls automatically benefits from a heads-up to IT, especially at a venue you do not control. Two things speed this along:
- Ask for the outbound requirements in writing, not a verbal "it should just work." A vendor should be able to list exactly which hosts and ports it needs outbound, even if it never needs an exception granted.
- Get sign-off before the event, not during it. If your organisation runs a formal approval process for new software, our guide to getting AV software approved by IT walks through what that review usually covers.
If your team is evaluating tools at scale rather than fixing a one-off connection issue, run the full security checklist for presentation software alongside this, since network behaviour is only one part of the review. Teams standardising on a full venue tech stack, rather than a single clicker, may also want our broader look at the hybrid event tech stack.

How to fix it right now, mid-show
If you are staring at a broken connection five minutes before you present:
- Check whether the venue's guest Wi-Fi is separate from the main corporate network. Guest networks are often less restrictive.
- Try tethering to a phone hotspot as a same-day workaround. It bypasses the office network entirely.
- If the app has a "relay" or "TURN" fallback setting, confirm it is enabled rather than disabled for a speed test.
- Restart the app after switching networks. Some tools cache a failed connection state.
For a longer-term fix, raise it with IT using the outbound requirements above, so the next event does not repeat the scramble and the next presenter is not left refreshing a spinner two minutes before they are due on stage.
FAQ
Home networks are almost always open, with no proxy and no UDP restrictions. Office networks frequently enforce both, which is exactly where a tool that does not handle proxies or fall back to TCP will fail.
No. Cliqer only makes outbound connections and automatically falls back to standard HTTPS ports on restrictive networks, so no inbound port forwarding or special firewall exception is required.
A proxy problem stops the app reaching the internet at all, usually shown as a connection or gateway error at sign-in. A UDP problem lets sign-in succeed but stops direct media connections, usually shown as a share or camera that never connects while everything else works.
It adds a small amount of latency compared with a direct connection, but it is a reliable fallback rather than a downgrade in quality, and the switch happens automatically without the presenter needing to do anything.
Get started
If firewall trouble has burned you before, try Cliqer free on the next network you are worried about, corporate or otherwise. For teams standardising across venues and offices, see the Enterprise plan for centralised rollout and support.
Confidence Monitors Explained: What Speakers See and Why
What a confidence monitor shows a speaker, why it matters and how to build one from a spare display and a countdown.
How We Made Screen Sharing Four Times Faster
The engineering story behind cutting Cliqer’s screen sharing latency from over two seconds to about half a second.
Run your next show with Cliqer
Keep reading
More security & it for your next show


Presenting Confidential Content: Data Protection for Board Meetings

Passkeys Explained: Passwordless Sign-In for Busy Teams
Get the next guide before your next show
Practical guides for presenters, AV crews and event teams, plus the Cliqer releases that matter. No spam, one click to leave.
