Firewall and Network Requirements

Firewall and network requirements

Everything AudioHub sends stays on your own network. Nothing is relayed through a server, and AudioHub never asks your router to open a port for it — there is no UPnP, no NAT-PMP and no hole punching anywhere in the product. If a firewall sits between the two machines, you are the one who has to open it.

This page lists every socket the software binds, per platform, and what each one is for.

---

The short version

Two AudioHub machines on the same LAN need exactly this:

47810/TCP inbound	on both machines
47810/UDP inbound	on both machines
5353/UDP	on both machines, in and out — see mDNS

Nothing else. The browser interface and the service-to-interface channel never leave 127.0.0.1.

Receiving AirPlay needs more than a port list can express. Every session negotiates several ephemeral TCP and UDP sockets at connect time; see AirPlay.

---

Ports — macOS

Port	Proto	Direction	Bound by	When	Carries
47810	TCP	inbound	the audio service, all interfaces	always	control channel; also the second connection used by TCP relay, and inbound Single-link mux
47810	UDP	in + out	the audio service, all interfaces	always	media, when the connection method is Direct (UDP)
5353	UDP	in + out	the audio service	while advertising, while scanning, and while the AirPlay receiver is on	mDNS
random	TCP	—	the audio service, 127.0.0.1 only	always	the interface ↔ service channel (ipc.json)
47800	TCP	—	the app, 127.0.0.1 only	only when Web access is on	the browser interface
chosen once	TCP	inbound	the audio service	AirPlay receiver on	AirPlay control (RTSP)
ephemeral	TCP + UDP	inbound	the audio service	per AirPlay sender session	event channel, audio data, audio control, timing
ephemeral	TCP	outbound	the audio service	AirPlay receiver on, sender advertises DACP	volume pushed back to the sender

There is no PTP row on macOS. The kernel owns UDP 319 and 320 and does not hand those packets to ordinary application sockets, so AudioHub does not bind them; it asks the system's own timing service instead.

The macOS installers add no firewall rule. They do not run socketfilterfw and do not touch the built-in application firewall. If you have that firewall switched on in System Settings, its "accept incoming connections" prompt is macOS asking about audiohubd, and it is separate from everything on this page.

The real macOS gate is a permission, not a firewall

The failure users actually hit on macOS is the Local Network privacy grant, and it does not look like a permission failure — outbound connections fail with a fabricated No route to host. Read what a missing Local Network grant breaks before you start editing firewall rules.

Short form: without that grant this machine can still be advertised and can still accept inbound connections, but it cannot browse and cannot dial — including pairing by a typed IP.

---

Ports — Windows

Port	Proto	Direction	Bound by	When	Carries
47810	TCP	inbound	audiohubd.exe, all interfaces	always	control channel; also TCP relay and inbound Single-link mux
47810	UDP	in + out	audiohubd.exe, all interfaces	always	media, when the connection method is Direct (UDP)
5353	UDP	in + out	audiohubd.exe	while advertising, while scanning, and while the AirPlay receiver is on	mDNS
random	TCP	—	audiohubd.exe, 127.0.0.1 only	always	the interface ↔ service channel (ipc.json)
47800	TCP	—	the app, 127.0.0.1 only	only when Web access is on	the browser interface
chosen once	TCP	inbound	audiohubd.exe	AirPlay receiver on	AirPlay control (RTSP)
319	UDP	inbound	audiohubd.exe, all interfaces	AirPlay receiver on	PTP event messages
320	UDP	inbound	audiohubd.exe, all interfaces	AirPlay receiver on	PTP general messages
ephemeral	TCP + UDP	inbound	audiohubd.exe	per AirPlay sender session	event channel, audio data, audio control, timing
ephemeral	TCP	outbound	audiohubd.exe	AirPlay receiver on, sender advertises DACP	volume pushed back to the sender

319 and 320 are bound once, when the receiver starts, not per session, and the bind is fatal if it fails: if another program on the machine already owns them, the AirPlay receiver refuses to start and daemon.log records cannot bind AirPlay 2 PTP sockets.

Every socket in this table belongs to audiohubd.exe. That matters for the next section.

---

The Windows rule the installer adds

The NSIS installer creates exactly one inbound rule:

netsh advfirewall firewall add rule ^
  name="AudioHub daemon (Domain, Private)" ^
  dir=in action=allow ^
  program="C:\Program Files\AudioHub\audiohubd.exe" ^
  enable=yes profile=domain,private

Two properties are worth understanding, because between them they explain almost every "it works at home but not at the office" report.

It is scoped to a program, not to a port. Because every inbound socket in the Windows table above is opened by audiohubd.exe, one rule covers 47810, 5353, the AirPlay control port, 319, 320, and every ephemeral AirPlay session socket — including the ones that do not exist yet. You never have to add a port rule as the AirPlay session count grows.

It applies to the Domain and Private profiles only. On a network Windows has classified as Public, the rule does not apply and nothing reaches this machine: peers cannot connect, scans do not see it, AirPlay senders discover it and then fail. This is the single most common Windows symptom, and Troubleshooting covers recognising it.

The rule names the exact executable path recorded at install time. Reinstalling deletes the rule by that name and adds it again, so an upgrade or a move to a different folder repairs it. Uninstalling deletes it.

Checking and widening it

netsh advfirewall firewall show rule name="AudioHub daemon (Domain, Private)"

To make it apply on Public networks too — an explicit security decision, since Public means Windows does not trust the network you are on:

netsh advfirewall firewall set rule name="AudioHub daemon (Domain, Private)" ^
  new profile=domain,private,public

The safer alternative is to reclassify that one network as Private in Settings › Network & Internet, which leaves the rule alone.

A reinstall rewrites the rule from scratch, so a widened profile does not survive one.

---

mDNS is bound for scanning too, not just advertising

This catches people who allow mDNS in one direction only.

AudioHub binds 5353/UDP in three independent situations:

Situation	Why
Advertise on LAN is on	registers _audiohub._udp so others can find this machine
A scan is running	browsing opens its own mDNS socket — it is not a passive listener on the advertising one
The AirPlay receiver is on	a third, IPv4-only mDNS socket that registers _airplay._tcp and browses _dacp._tcp

So turning Advertise on LAN off does not free 5353, and a firewall that permits only outbound mDNS breaks scanning, not just discoverability.

mDNS does not cross subnets. Two machines on different VLANs will never see each other in a scan no matter what you open — pair them by typing the IP instead, which needs only 47810.

---

AirPlay cannot be reduced to a port list

Only the control port is advertised. Everything else is negotiated when the sender connects, on ports the operating system hands out at that moment.

Socket	Proto	Direction	Exists when
Control (RTSP)	TCP	inbound	receiver is on — port picked at first start, then remembered
Event channel	TCP	inbound	a sender completes setup
Audio data	TCP for buffered (AAC) senders, UDP for realtime (ALAC) senders	inbound	a stream is set up
Audio control	UDP	inbound	a stream is set up
Timing	UDP	out and in	NTP-timed senders only — AudioHub probes the sender's timing port and reads the replies. PTP senders use 319/320 instead

The control port is durable: AudioHub picks a free one on first start, records it beside the settings, and reuses it. It is shown in the AirPlay status row on the Sharing tab. If something else has taken it at startup, AudioHub picks a new one and records that instead — which is why a port-scoped firewall rule for AirPlay can silently stop matching. On Windows this is a non-issue: the installer's rule is program-scoped.

There is also outbound traffic. When a sender advertises DACP, AudioHub dials it to push volume changes back, so an egress-filtering firewall can break volume without breaking audio.

---

When 47810 is not reachable at all

If the two machines cannot reach each other's 47810 — different networks, a VPN that only forwards HTTP, a proxy — AudioHub does not attempt to work around it. It has no relay and no NAT traversal. What it offers instead is the ability to run over a tunnel you provide:

• Point the peer's Tunnel address at your tunnel's cleartext entrance and set the connection method to Single-link mux. See the tunnel address.
• On a tunnel that only carries connections one way, set the side that cannot originate to inbound-only — CLI only in 1.0.0, see peer-transport.

Pairing itself cannot be done over a tunnel. Pair over IP:port first.

---

Related

• Discovery and Pairing › Ports — the same numbers in the context of finding a peer, and what happens when 47810 is taken
• Troubleshooting — symptom-first
• Share Protocols › AirPlay — what the receiver does
• Web Access — why 47800 is loopback-only and cannot be exposed