FAQ

What firewall ports should I open to use openZro (Network Firewalls)?

This section covers network/perimeter firewall requirements (e.g., Fortigate, pfSense, cloud security groups). For host-based firewalls (Windows Firewall, UFW, iptables), see How does openZro interact with host-based firewalls?

Incoming ports

openZro's agent doesn't require any incoming port to be open; It negotiates the connection with the support of the signal and relay services.

Outgoing ports

openZro usually won't need open ports, but sometimes you or your IT team needs to secure and verify all outgoing traffic, and that may affect how openZro clients connect to the control layer and negotiate the peer-to-peer connections.

Below is the list of openZro Cloud endpoints and ports they listen to. If you are self-hosting openZro, your clients connect to your own server endpoints instead — see the self-hosted guide port requirements.

• Management service:

  • Endpoint: api.openzro.io
    • Port: TCP/443
    • IPv4: 35.186.199.111, 85.9.201.14, 85.9.206.109, 213.163.201.31, 213.163.206.27, 85.9.196.80, 209.151.150.249
    • IPv6: 2600:1901:0:adb3::, 2a04:3542:1000:910:2465:1fff:fe8a:5597, 2a04:3542:1000:910:2465:1fff:fe8a:2f9a, 2a04:3543:1000:2310:2465:1fff:fe8a:5f8d, 2a04:3543:1000:2310:2465:1fff:fe8a:1308, 2605:7380:8000:1000:2465:1fff:fe8a:3b62, 2605:7380:8000:1000:2465:1fff:fe8a:4dcd

• Signal service:

  • Endpoint: signal.openzro.io
    • Port: TCP/443
    • IPv4: 35.186.199.111, 85.9.201.14, 85.9.206.109, 213.163.201.31, 213.163.206.27, 85.9.196.80, 209.151.150.249
    • IPv6: 2600:1901:0:adb3::, 2a04:3542:1000:910:2465:1fff:fe8a:5597, 2a04:3542:1000:910:2465:1fff:fe8a:2f9a, 2a04:3543:1000:2310:2465:1fff:fe8a:5f8d, 2a04:3543:1000:2310:2465:1fff:fe8a:1308, 2605:7380:8000:1000:2465:1fff:fe8a:3b62, 2605:7380:8000:1000:2465:1fff:fe8a:4dcd

• P2P (STUN) service:

  • Endpoint: stun.openzro.io
    • Port range: UDP/80,443,3478,5555
    • IPv4: The list is dynamic and geo-distributed; we advise you to check the nearest cluster with the following command:
      • nslookup stun.openzro.io
    • In more restricted environments, openzro status will show keepalive ping failed errors without a firewall rule for STUN
      • Example nftables outbound firewall rule: ip daddr stun.openzro.io tcp dport 443-443 accept

• Relay (TURN) service:

  • Endpoint: turn.openzro.io
    • Port range: UDP/80,443 and TCP/443-65535
    • IPv4: The list is dynamic and geo-distributed; we advise you to check the nearest cluster with the following command:
      • nslookup turn.openzro.io
    • In more restricted environments, openzro status will show keepalive ping failed errors without a firewall rule for TURN
      • Example nftables outbound firewall rule: ip daddr turn.openzro.io tcp dport 443-65535 accept

• Relay service:

  • Endpoint: *.relay.openzro.io
  • Port: TCP/443
  • IPv4: The list is dynamic and geo-distributed; When looking at the openzro status -d output, you can see which relay you are connecting to.
  • It is advised to wildcard *.relay.openzro.io when possible, to avoid interrupts.

How does openZro interact with host-based firewalls?

openZro automatically manages host-based firewall rules to allow traffic on the openZro interface (wt0). This is separate from your network/perimeter firewall, which requires no inbound port configuration.

Platform behavior

Network firewall vs. host-based firewall

It is important to understand the distinction:

• Network/perimeter firewall (Fortigate, pfSense, cloud security groups): Controls traffic entering and leaving your network. openZro requires no inbound ports on these devices. All connections are initiated outbound using ICE/STUN for NAT traversal.

• Host-based firewall (Windows Firewall, UFW, iptables): Controls traffic on the individual machine. openZro automatically adds rules to allow traffic on the wt0 interface.

UFW conflicts on Linux

UFW (Uncomplicated Firewall) is a popular frontend for iptables on Ubuntu and other Linux distributions. When you enable UFW, its default policy is:

• Incoming: Deny all
• Outgoing: Allow all

This can conflict with openZro because both UFW and openZro manage iptables rules. The conflict is about chain evaluation order, not about opening ports to the internet:

1. WireGuard UDP packets arrive via hole punching (no inbound port needed on your router)
2. openZro decrypts them and presents traffic on the wt0 interface
3. UFW may evaluate its deny rules before openZro's allow rules
4. Result: Traffic blocked at the host level despite successful hole punching

Solution: Allow traffic on the openZro interface:

sudo ufw allow in on wt0

This does not open any ports to the internet. It allows traffic on the virtual wt0 interface, which only carries already-authenticated, already-encrypted openZro traffic.

Verify the rule:

sudo ufw status | grep wt0

Windows Firewall

openZro creates a Windows Firewall rule automatically during installation/connection. This rule allows traffic on the openZro IP address (the wt0 interface after decryption).

If traffic is blocked despite openZro showing peers as connected, check for:

• Group Policy overriding the openZro rule
• Third-party security software (antivirus, endpoint protection) with its own firewall
• The rule failing to apply due to permissions

Check if the openZro rule exists:

Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*openZro*" }

Environments without NAT

In flat office networks or routed VLANs without NAT, an additional firewall rule may be needed for P2P to work. This is because Windows Firewall sees incoming WireGuard UDP packets as unsolicited traffic when there is no NAT state tracking the connection.

New-NetFirewallRule -DisplayName "openZro P2P" -Direction Inbound -Action Allow -Protocol UDP -LocalPort 49152-65535 -Program "C:\Program Files\openZro\openzro.exe"

See Environments without NAT for details.

Troubleshooting

If you suspect host-based firewall issues, capture a debug bundle:

openzro debug bundle --system-info

The --system-info flag includes network routes and interface configuration, which helps identify firewall-related issues. See Host-based firewall issues for detailed troubleshooting steps.

Why and what are the anonymous usage metrics?

Why did we add metrics collection?

As an open-source project and business, making data-driven decisions is essential. By collecting anonymous metrics, we can understand our adoption rate, feature usage, and the types of client operating systems in use. We kindly ask our community users to keep metrics enabled, as this helps us assess the impact of bugs and measure the quality of our software over time.

If the metric collection infringes any internal regulation or policy, it can be disabled by setting the flag --disable-anonymous-metrics=true to the management service startup command. the default interval is 12 hours, but it can be adjusted with the environment variable OPENZRO_METRICS_INTERVAL_IN_SECONDS.

What are the metrics being collected?

We are collecting the following metrics:

• Number of accounts, users, and service users
• Number of personal access tokens
• Number of peers (total, SSH-enabled, login expiration enabled, user-activated)
• Number of active peers and active users in the last collection interval
• Number of peers per operating system (total and active)
• Number of UI clients and their operating systems
• Number of setup keys usage (including ephemeral peer setup keys)
• Number of groups
• Number of routes (including routes with routing groups)
• Number of networks, network resources, and network routers
• Number of access control policy rules (by protocol and direction)
• Number of posture checks and rules with source posture checks
• Number of reverse proxy services (total, enabled, by status, by target type, by auth type)
• Number of service targets (by type: peer, host, domain, subnet)
• Number of custom domains (total and validated)
• Rosenpass usage
• IdP manager type and embedded IdP provider breakdown
• Store engine type
• Service uptime
• Service version (including min/max active peer versions)
• Metrics generation time

Metrics UUID

We are using an installation ID for each management service which is generated once and stored in your management store database. It doesn't have any trace of any other private information, and it helps distinguish each deployment.

Metrics pusher IP

We are not storing the pusher IP address; it gets discarded once the request is complete.