Yes — a VPN is not required if you treat signalling and media as separate problems. HTTPS and WebSocket signalling terminate on a reverse proxy in front of the meeting web application, while the media bridge (the SFU that carries audio and video) is published on its own public address with its UDP ports reachable directly. An authenticated TURN relay covers guests on networks that block UDP. Customers need only a browser and a meeting link, and nothing about your internal network becomes generally reachable.
Two kinds of traffic, two paths
A browser meeting makes two very different kinds of connections. Signalling — the HTTP and WebSocket traffic that loads the page, authenticates the user and negotiates the call — is ordinary web traffic and proxies cleanly. Media — the raw audio and video packets — travels over UDP and must reach the media bridge itself. The two paths do not need to share a process, a machine or even a firewall rule:
Guest browser -- HTTPS/WSS --> reverse proxy --> meeting web app / signalling
Guest browser -- UDP media --> media bridge (SFU) on a published address
Guest browser -- TURN/TLS ---> relay --> media bridge (only if direct UDP fails)Because the endpoints are separate, you can keep the web application on an internal host behind the proxy while the media bridge sits in a DMZ, or run both on one machine with different ports. What matters is that each path is reachable and that neither grants broader access than it needs.
Deciding what is public and what stays inside
Put the externally reachable components in a DMZ or another isolated network segment rather than on your LAN:
- Public: the reverse proxy endpoint for the meeting interface, the media bridge's advertised address and its UDP media ports, and the TURN listener.
- Private: management interfaces, databases, directory or SSO backends, provisioning and monitoring tools.
- Between segments: only the specific flows the conferencing stack needs, such as the proxy reaching the signalling service.
Guests need the meeting interface and a working media path, nothing more. If the web tier is ever compromised, the firewall between the DMZ and the LAN is what limits the damage.
Publishing the media path behind NAT
The most common failure in this design is a meeting page that loads perfectly but carries no audio or video. That symptom means signalling works while media does not: the server advertises an address guests cannot reach, or its UDP ports are not forwarded.
Fix it by configuring the media bridge to advertise its externally reachable address and forwarding exactly the media ports your product uses. Defaults differ: Jitsi Videobridge uses a single UDP port (10000 by default), while LiveKit documents a UDP range with an optional single-port mode. Configure what your chosen product actually expects rather than opening both sets — an extra open UDP range is exposure without benefit.
STUN matters less here than people expect: it helps a browser discover its own public address, but when the server itself is published, the browser simply sends media to the advertised address. The component that rescues difficult networks is TURN.
TURN as the fallback for restrictive networks
Some guest networks — hotels, corporate guest Wi-Fi, mobile carriers — block or mangle direct UDP, leaving users with a page and no sound. Deploy an authenticated TURN server and list it in the meeting application's ICE configuration:
- Use short-lived, expiring credentials (the ephemeral-credential pattern most TURN servers support) so you never operate an open relay.
- Where supported, restrict relayed destinations to your own media bridge only.
- Enable TURN over TLS on TCP 443 as the last-resort transport, since it survives almost any firewall that still allows HTTPS.
TURN is not HTTP: a TURN-over-TLS listener cannot be handled by an ordinary reverse-proxy location block. Give it its own listener, or use layer-4 (SNI-based) routing if everything must share port 443.
Admission control and validation
Network reachability decides whether a guest can connect; it says nothing about whether they may join. Enforce admission inside the conferencing application with room-level permissions, lobby or moderator approval, and expiring invitation links. Treat the public URL as a door, not an invitation.
Then test from where guests actually are — inside the LAN everything tends to work because no NAT is involved:
- A meeting from an external network with unrestricted UDP, confirming the direct media path and NAT advertisement.
- A meeting from a network with UDP blocked, confirming the TURN relay and TLS-on-443 fallback.
- A check that management URLs and internal services are unreachable from outside.
Frequently Asked Questions
Can media traffic also go through the reverse proxy?
No. A reverse proxy handles HTTP and WebSocket at layer 7; WebRTC media is UDP and must reach the media bridge directly. Splitting the paths is the intended architecture, not a workaround.
Which ports do I actually need to open?
Follow your product's documentation: Jitsi needs TCP 80/443 for the web tier plus UDP 10000 for media by default; LiveKit uses a documented UDP range, optionally collapsed to a single port. Open only what your configuration expects.
Why does the meeting page load but there is no audio or video?
Signalling works but media has no path. Check the public address the media bridge advertises and confirm its UDP ports are forwarded to it from your firewall or NAT device.
Do I still need STUN if I have TURN?
Yes. STUN is cheap and lets browsers on friendlier networks connect directly, which is lower-latency and cheaper than relaying. TURN is the fallback, not a replacement.
How do I prevent strangers from abusing my TURN server?
Require authentication with short-lived expiring credentials and, where supported, restrict relayed destinations to your own media bridge. An open relay is an abuse magnet and a bandwidth bill.