Bryx Station Alerting Network/Firewall Configuration

Modified on Fri, 2 May at 2:45 PM

Bryx Station Alerting provides a state of the art system utilizing commercial off-the-shelf (COTS) technologies to reduce costs without sacrificing performance or responsiveness. Bryx Station is an Internet Protocol (IP) based alerting solution that must connect to the Bryx Cloud infrastructure to receive the data necessary to alert the station.


Network Traffic

The station control unit does not need access to, and will not access, any internal network or intranet of the department, agency, or municipality that it’s installed in, unless explicitly configured to do so (e.g. for connecting to a printer for “rip and run” reports). All access required to alert the station is retrieved from the outside internet. As such, wherever possible, it is recommended to set up a private, secure, VLAN for the Station Control Unit and allow outbound traffic. If that is not possible, then, at a minimum, the following domains/ports will be required. Because IPs are not fixed, and many services utilize content delivery services, it is recommended that domains - not IP addresses - be whitelisted.


Domain

Ports

Protocol

Use

bryx911.com


443


TCP/HTTPS

Access to the Bryx cloud for alerting and maintenance

carton.bryx.com

mirror.bryx.com

80, 443

TCP/HTTP(S)

Software update packages and operating system image deltas

aws.amazon.com

443

TCP/HTTPS

Text-to-Speech synthesization

mapbox.com

443

TCP/HTTPS

Map tiles (for Station Board)

security.debian.org

deb.debian.org

ftp.us.debian.org

80, 443

TCP/HTTP(S)

On older SCUs (software version 4.5.3 and below), direct package updates may fetched from the official Debian repositories

8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1

53

UDP, TCP

Domain name resolution services (Google DNS and Cloudflare DNS). Internet health checks also utilize public DNS to consider any internal DNS server issues when assessing SCU health



 Router Configuration Recommendations

  • Don't use "symmetric" NAT. Use "full cone" or "port restricted cone" NAT. Symmetric NAT is extremely hostile to peer to peer traffic and will degrade VoIP, video chat, WebRTC, and many other protocols - as well as the Bryx secondary remote access VPN..

  • No more than one layer of NAT should be present between the station control unit and the Internet. Multiple layers of NAT increase the likelihood of connection instability.

  • NATs should have a port mapping or connection timeout no shorter than 60 seconds.

  • Place no more than about 16,000 devices behind each NAT-managed external IP address to ensure that each device can map a sufficient number of ports.


These guidelines are consistent with the vast majority of typical deployments using commodity gateways and access points.

Secondary Remote Access VPN

  • In addition to a basic shell over HTTPS, Bryx utilizes Tailscale (tailscale.com) as a more robust mechanism to fully access a system remotely. Tailscale is a modern, software-defined networking solution that simplifies the setup and management of secure private networks. Built on top of the WireGuard protocol, Tailscale creates a peer-to-peer mesh network that connects devices directly to each other while maintaining strong encryption and minimal latency. Once authenticated, Tailscale establishes encrypted point-to-point tunnels between devices using WireGuard.

  • When direct connectivity isn’t feasible due to NAT traversal challenges, Tailscale uses a network of Distributed Encrypted Relay Protocol (DERP) servers to relay traffic while maintaining security and performance. The network’s coordination is managed by a central control plane that orchestrates connections and enforces access policies. Importantly, actual data traffic remains peer-to-peer, bypassing Tailscale’s servers to preserve privacy and reduce latency. Bryx sets access and security policies which are enforced consistently across the network. By leveraging NAT traversal and fallback relays, Tailscale ensures reliable connectivity even in environments with strict firewalls or carrier-grade NATs.

  • Tailscale is designed with security as a core principle. All data transmitted between devices is encrypted end-to-end using WireGuard’s advanced cryptographic techniques, ensuring both integrity and confidentiality. Unlike traditional IP-based access control, Tailscale employs a zero-trust architecture where authentication and access control are based on device identity. This reduces risks associated with IP spoofing or misconfiguration. The solution also minimizes the attack surface by not requiring open inbound ports on firewalls. All communication is initiated from within the network, making it resistant to external attacks.

  • To enable Tailscale functionality, certain network and firewall considerations must be addressed. Outbound traffic should be allowed on UDP 3478, UDP/HTTPS (443), and TCP/HTTPS (443). Additionally, traffic to Tailscale’s DERP server IPs or domains must be permitted; specific addresses can be found in Tailscale’s documentation (https://tailscale.com/kb/1082/firewall-ports

  • Inbound traffic does not require any configuration since Tailscale connections are initiated from within the network. However, devices may need to resolve Tailscale domains for control plane and relay server connectivity, so DNS resolution should also be permitted.

Tailscale is optional and can be disabled if the customer prefers. However, it should be noted that this will remove a redundant remote access pathway and thus can slow or inhibit incident response from Bryx support staff.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article