Audience: network / IT administrators deploying Corvid Cloud Gateway. Purpose: everything that must be reachable, and from where, so that discovery, registration and streaming work without firewall-induced failures.
The Cloud Gateway is a small agent that runs either on the camera itself (Axis, Hanwha, i-PRO, Vivotek) or on a separate host on the same LAN (Linux server, NAS, Home Assistant, Windows). In both cases it acts as the single bridge between your internal camera network and the Corvid Cloud.
The Gateway only makes outbound connections. No inbound port forwarding, no public IP and no VPN are required on your side.
Internal network — Gateway to cameras
Two distinct levels of connectivity are required, and they are not interchangeable.
1.1 Layer 2 (same broadcast domain) — required for discovery
Automatic camera discovery relies on two mechanisms that cannot cross a router:
Mechanism | Protocol | Destination | Why it needs Layer 2 |
ONVIF WS-Discovery | UDP multicast |
| Multicast probes are not forwarded across subnets by default |
MAC address resolution | ARP | Local segment | The Gateway identifies each camera by its MAC address, read from the local ARP table |
Requirement: the Gateway must have an interface in the same VLAN / subnet / broadcast domain as the cameras.
Common causes of “no cameras found”:
Gateway and cameras on different VLANs with no L2 bridge between them.
Multicast filtering, IGMP snooping without a querier, or “block multicast” enabled on the switch or AP.
Client isolation / AP isolation on wireless segments.
The Gateway host running in a container with a NAT’d network namespace instead of host networking (on Home Assistant and Docker deployments, host networking is mandatory).
If Layer 2 adjacency is impossible in your topology, cameras must be added manually by IP instead of discovered. Discovery will not work over a routed link, by design.
1.2 Layer 3 (routed IP reachability) — required for everything else
Once a camera is known, all remaining functionality — ONVIF control, stream pulling, snapshots, PTZ, event subscription — happens over unicast TCP. The Gateway must be able to open these connections to every camera:
Port | Protocol | Purpose |
554 | TCP | RTSP — media streams. Also used by the Gateway’s periodic subnet sweep to detect live cameras |
80 | TCP | ONVIF / HTTP — device services, snapshots, capabilities |
443 | TCP | ONVIF / HTTPS, where the camera enforces TLS |
8000 | TCP | ONVIF on some vendors that do not use port 80 |
Notes for the network team:
The Gateway performs a periodic scan of its own /24 probing TCP 554. An IDS/IPS may flag this as port scanning — whitelist the Gateway’s IP.
Cameras must have a stable IP (DHCP reservation or static). The Gateway tracks cameras by MAC, but a camera that changes subnet will fall out of ARP range.
No firewall between the Gateway and the cameras should perform deep packet inspection or RTSP ALG rewriting. RTSP helpers on consumer firewalls are a frequent cause of broken streams.
External network — Gateway to Corvid Cloud
All connections are outbound only, initiated by the Gateway. The Gateway first contacts the API to obtain its assigned relay, then opens a long-lived connection to that relay and keeps it open. The relay assignment is sticky: once connected, the Gateway stays on that relay.
2.1 Required egress by environment
Allow the Gateway’s source IP to reach the following destinations. Allow by FQDN, not by IP address — see §2.3.
Production
Destination | Port | Protocol | Purpose |
| 443 | TCP / HTTPS | API — registration, relay assignment, updates |
| 8888 | TCP | Relay — persistent control and media channel |
| 8888 | TCP | Relay — second production relay, assigned by the balancer |
Staging
Destination | Port | Protocol | Purpose |
| 443 | TCP / HTTPS | API |
| 8888 | TCP | Relay |
Development
Destination | Port | Protocol | Purpose |
| 443 | TCP / HTTPS | API |
| 8888 | TCP | Relay |
The Gateway is assigned one relay by the API balancer, but which one is not known in advance. All relays of the target environment must be reachable, otherwise the Gateway may be assigned a relay it cannot connect to and will fail to register.
2.2 Required egress — all environments
Destination | Port | Protocol | Purpose | Required |
| 7376 | TCP / HTTP | Gateway binary download at startup | Yes on Hanwha WOP 25.04 and as a fallback on Axis |
DNS resolver | 53 | UDP / TCP | Resolving the FQDNs above | Yes |
NTP server | 123 | UDP | Clock sync — TLS certificate validation fails on a skewed clock | Yes |
| 443 | TCP / HTTPS | Remote diagnostic logs | Optional — used for support |
Note on openrepo.lighthousetech.io:7376: this is plain HTTP on a non-standard port. Proxies that only allow 80/443 will block it and the Gateway will never start on the affected platforms. If your policy forbids this, contact support to obtain a package with the binary pre-embedded.
2.3 Do not allowlist by IP
Relays currently have static IPs, but these are subject to change without notice as infrastructure moves.
APIs in production and staging sit behind AWS Application Load Balancers. Their IP addresses rotate without warning, and there is more than one at any moment. An IP-based rule will break, typically weeks after installation and with no obvious cause.
Configure firewall rules by FQDN / DNS name. If your firewall genuinely cannot do this, contact support before deployment so we can agree on an approach.
2.4 Proxies and TLS inspection
The Gateway does not read system proxy environment variables. Transparent proxies only.
The Gateway ↔ relay channel on port 8888 is not HTTP. It is a custom encrypted binary protocol. An HTTP-only proxy or a firewall that requires HTTP CONNECT semantics will drop it.
TLS interception / SSL inspection must be disabled for the API hostnames. Re-signing the certificate chain will not break the current build, but it defeats the purpose and is unsupported.
Some carrier-grade or enterprise DPI appliances have been observed to reset the port 8888 connection because it does not match a known protocol signature. If registration succeeds but the Gateway disconnects every few seconds, suspect DPI.
Bandwidth
Item | Requirement |
Idle upstream | Negligible — the control channel is a heartbeat |
Per live stream upstream | Equal to the camera’s configured bitrate. Budget ~2–4 Mbps per 1080p H.264 stream at 15–20 fps |
Concurrent streams | The Gateway multiplexes all camera streams over the single relay connection. Total upstream = sum of the bitrates of streams actually being viewed or recorded |
Idle sessions | The connection to the relay on port 8888 is long-lived. The firewall must not treat it as an idle session to be reaped — dropping it forces a re-registration cycle |
Streams are only pushed when a viewer or a recording rule requests them. An installation with 20 cameras and nobody watching consumes almost no upstream.
Viewer access (browsers, not the Gateway)
This section applies to the users watching the video, not to the Gateway host. If your operators are inside the same restricted network, they also need egress:
Destination | Port | Protocol | Purpose |
Corvid web application | 443 | TCP / HTTPS | Web UI |
Relay of the environment | 443 | TCP / HTTPS | Video playback |
Validating the network before deployment
When the Gateway runs on a camera, you cannot open a shell on it — cameras do not expose one. So this section is not run on the Gateway. Instead, use any laptop or server that you place in the same VLAN and subnet as the cameras, configured with the same firewall policy the Gateway will be subject to. That machine acts as a stand-in: whatever it can reach, the Gateway will be able to reach.
This is a validation aid, not a formal requirement. If your team already knows the firewall policy is correct, skip it.
Setup: connect the test machine to the camera VLAN, give it an address in the camera subnet, and make sure it is not exempted from any firewall rule, proxy or IDS policy that will apply to the Gateway. A test run from an admin workstation with unrestricted egress proves nothing.
Commands below are for Linux or macOS. Windows equivalents are noted where they differ.
# 1. Layer 2 — do the cameras answer ONVIF multicast discovery?
# Expect one SOAP reply per camera on the segment.
sudo nmap --script broadcast-wsdd-discover
# 2. Layer 2 — does the camera appear in the ARP table after pinging it?
ping -c 2 <camera-ip> && arp -an | grep <camera-ip>
# Windows: ping <camera-ip> && arp -a | findstr <camera-ip>
# 3. Layer 3 — is RTSP reachable on the camera?
nc -vz <camera-ip> 554
# Windows: Test-NetConnection <camera-ip> -Port 554
# 4. Layer 3 — is ONVIF reachable on the camera?
curl -sI http://<camera-ip>/onvif/device_service
# 5. Egress — do the Corvid hostnames resolve?
getent hosts stream-api.corvidcloud.com
# 6. Egress — is the API reachable over TLS? Any HTTP status is fine;
# what matters is that the connection and handshake succeed.
curl -sv https://stream-api.corvidcloud.com/ 2>&1 | grep -i "connected\|SSL"
# 7. Egress — are the relays reachable on 8888?
# They will not answer HTTP. A successful TCP connect is the whole test.
nc -vz relay001.corvidcloud.com 8888
nc -vz relay002.corvidcloud.com 8888
# 8. Egress — is the binary repository reachable?
nc -vz openrepo.lighthousetech.io 7376
# 9. Clock skew — the camera's own clock must be within a few seconds of
# real time. Check this in the camera's web UI, not on the test machine.
Interpreting the results:
Failing step | Consequence | See |
1 or 2 | Cameras will never be discovered | §1.1 |
3 or 4 | Cameras are discovered but produce no video | §1.2 |
5 to 8 | The Gateway will never register with the cloud | §2 |
9 | TLS to the API fails with a certificate error | §2.2 |
On step 9: the clock check must be done on the camera itself, through its web interface, because that is where the Gateway runs and where the TLS handshake happens. A correct clock on the test machine tells you nothing about the camera.
Summary table
Direction | Source | Destination | Port | Protocol | Mandatory |
Internal L2 | Gateway |
| 3702 | UDP multicast | Yes — discovery |
Internal L2 | Gateway | Local segment | — | ARP | Yes — discovery |
Internal L3 | Gateway | Cameras | 554 | TCP | Yes — media |
Internal L3 | Gateway | Cameras | 80 / 443 / 8000 | TCP | Yes — ONVIF |
Egress | Gateway |
| 443 | TCP | Yes |
Egress | Gateway |
| 8888 | TCP | Yes |
Egress | Gateway |
| 7376 | TCP | Platform-dependent |
Egress | Gateway | DNS | 53 | UDP/TCP | Yes |
Egress | Gateway | NTP | 123 | UDP | Yes |
Egress | Gateway |
| 443 | TCP | Optional |
Inbound | — | Gateway | — | — | None |
Support
If the Gateway does not come online and the cause is not obvious, contact [email protected] with:
The output of the §5 commands, if you were able to run them.
The Gateway version and platform (camera model, or OS if running on a separate host).
The environment being targeted (production / staging / development).
A description of the network path: VLANs, firewall between the Gateway and the cameras, egress proxy, IDS/IPS in use.
Open items — internal, remove before publishing
[ ] Viewer ports (§4): confirm the public hostname of the web app, and whether WebRTC playback needs UDP egress from the operator’s browser. The relay config exposes RTSP 554/555, RTMP 1935/1936 and HTTPS 443; unclear which of these a browser actually touches.
[ ] ONVIF port 8000: listed from vendor practice, not from our code. Confirm whether the Gateway ever probes it, or only 80/443.
[ ] Bandwidth figures (§3): the 2–4 Mbps per 1080p stream is an industry estimate, not measured on Corvid. Worth replacing with a real measurement.
[ ] Proxy support (§2.4): confirmed that the Go client does not use
HTTP_PROXY; the DPI claim comes from the X6000/WN5 findings, which may be specific to that camera rather than general.