Direct Connections – Network Requirements

When you open a venue in the VenueVue App, the app tries to talk to that venue's Control Server directly, rather than sending everything through our cloud. Direct connections are noticeably faster and use less of your internet connection.

This guide explains how those connections are made, what your firewall needs to allow for them to work, and how to tell which kind of connection a site is using. It is written to be handed to whoever looks after your network.

When to use this

• Setting up a new site and configuring the firewall for the first time
• A venue feels slow to load, or device controls lag behind
• Your IT team or provider has asked exactly what VenueVue needs opened
• Reviewing your network security and you want to know what the Control Server does

Approx time: 10 minutes to review; a few minutes to apply the firewall rules.

How connections are made

There are two connections involved, and it helps to keep them separate.

1. The cloud connection — always present. Your Control Server keeps a permanent, encrypted connection out to VenueVue over the standard secure web port. Your browser does the same when you log in. This is how the Control Server reports that it is online, and how the two sides are introduced to one another. It works on virtually any network with internet access.

2. The direct connection — the fast path. Once your browser and the Control Server have been introduced, they attempt to open a second, encrypted connection straight to each other, without our cloud sitting in the middle. Live device control, status updates, and file transfers then travel over that connection instead.

The introduction always happens through our cloud, but the direct connection itself does not touch it.

What happens when a direct connection cannot be made

If the two sides cannot reach each other, VenueVue automatically falls back to relaying the traffic through our servers. Everything continues to work — nothing is lost and nothing needs to be restarted — but the round trip is longer, so the app feels slower and both ends use more bandwidth.

The app will keep trying for a direct connection periodically, so a site that is temporarily relaying will move back to a direct connection on its own once the network allows it.

How long it should take

This is the easiest check you can make without any tools. If device controls consistently take twenty seconds or more to become live, that site is almost certainly relaying, and the firewall rules below are worth reviewing.

What your firewall needs to allow

The Control Server only ever makes outbound connections. It does not need port forwarding, a static IP address, or a place in your DMZ. Nothing on the internet can open a connection to it.

Only the first row is strictly required. The rest determine whether you get the fast path or the slow one.

If your firewall needs specific destination addresses rather than rules by port, contact VenueVue support and we will provide the current addresses for your region.

Settings that prevent direct connections

These are the common culprits, in the order they are worth checking.

1. UDP port 3478 is blocked outbound

This is by far the most frequent cause. Before two devices can connect directly, each needs to discover what its own address looks like from the outside. That discovery uses UDP port 3478. If it is blocked, neither side can work out how to be reached, and every session at that site will be relayed.

If you fix only one thing, fix this one.

2. Strict or symmetric NAT on your router

Routers share one public address between many devices, and how they do it matters here. A router using symmetric NAT presents a different external port to every destination, which means the address a device advertises is not the address traffic actually arrives on — so the two sides can never find each other.

Routers describe this setting in different ways. Look for NAT type, NAT filtering, or a strict / moderate / open setting, and choose the least restrictive option available. Some firewalls call the desired behaviour endpoint-independent mapping.

3. Outbound UDP restricted to known ports

A direct connection runs over UDP on high-numbered, randomly chosen ports at both ends. Firewalls configured to permit UDP only to a list of specific destination ports will block it. Outbound UDP needs to be permitted generally.

4. Short firewall session timeouts

Direct connections are quiet when nothing is happening. If your firewall closes idle UDP sessions aggressively, the connection is torn down mid-session and has to be rebuilt, which shows up as the app repeatedly reconnecting. A UDP timeout of 60 seconds or more avoids this.

5. Carrier-grade NAT from your internet provider

Some internet services — commonly mobile broadband, and some fixed-wireless and budget fibre plans — place many customers behind a single shared public address. This has the same effect as symmetric NAT, and it cannot be corrected by changing your firewall. If a site is on such a connection, direct connections will not be possible and traffic will always be relayed. A static or public IP address from your provider resolves it.

Not required

Port forwarding, UPnP, and DMZ placement are not needed and do not help. Nothing ever connects to the Control Server from the internet, so exposing it achieves nothing and increases your exposure. If someone has already set up port forwarding for VenueVue, it can be safely removed.

Best case: working on-site

If you are on the same network as the Control Server — in the venue, or connected to it over your own VPN — your browser and the Control Server find each other using local addresses and connect in about a second, without involving any of the above. On-site staff will always get the fastest experience.

How to tell which kind of connection you have

The VenueVue App works this out for you. Each connected device shows its connection status, which indicates whether the session is direct or relayed.

Together with the timing guide above, that is usually enough to diagnose a site:

If a site still relays after the rules above are in place, contact VenueVue support — we can see from our side which stage of the connection is failing.

Summary for network administrators

This section is self-contained and can be forwarded on its own.

The VenueVue Control Server makes outbound connections only. It requires no inbound port forwarding, no static IP address, and no DMZ placement.

Required

• TCP 443 outbound to venuevue.com

Recommended — these allow the Control Server to connect directly to VenueVue support and to your staff's browsers, rather than relaying through VenueVue's cloud. Direct connections are significantly faster and use less of your internet connection.

• UDP 3478 outbound to the VenueVue relay servers
• UDP 49152–65535 outbound to the VenueVue relay servers
• Outbound UDP permitted generally on high-numbered ports
• NAT configured for endpoint-independent mapping, rather than symmetric or strict
• A UDP session timeout of 60 seconds or more

Optional, for networks that block UDP entirely

• TCP 3478 and TCP 5349 outbound to the VenueVue relay servers

All traffic is encrypted in both cases. Without the recommended rules the system remains fully functional; traffic is simply relayed through VenueVue's cloud, which is slower and uses more bandwidth at both ends.