Network & Firewall

Firewall Configuration

If the appliance runs in a restricted local network, allow outbound access to the following IronFlock endpoints so it can reach the cloud. All connections are initiated by the appliance — no inbound ports need to be opened on your firewall.

instance-registry.ironflock.com:443   # installing and updating the IronFlock software and agents; the AI assistant and SMS notifications
cbw.ironflock.com:443                 # managing the appliance remotely from the cloud
web.ironflock.com:443                 # activating and validating the license
registry.ironflock.com:443            # pulling app images when syncing from the public IronFlock Store
regauth.ironflock.com:443             # authenticating those public Store image pulls
app.ironflock.com:443                 # opening app and device user interfaces from the cloud (optional)
smtp-proxy.ironflock.com:2525         # sending account and notification emails (optional)

The registry.ironflock.com and regauth.ironflock.com entries are needed to sync apps from the public IronFlock Store into the local App Store. registry.ironflock.com serves the app images and regauth.ironflock.com issues the token that authorizes each pull — both must be reachable, or the sync (and remote app browsing/installation) fails. If your appliance only ever serves apps you build locally, you can leave them out. An app whose images come from a public registry such as Docker Hub is copied from that registry during the sync, so the appliance needs to reach it as well.

The app.ironflock.com entry carries the remote-access tunnel that makes the user interfaces of apps and devices reachable while you work on the instance from ironflock.com. It runs over port 443 like everything else, directly or through a corporate proxy; only an appliance installed with IRONFLOCK_CLOUD_TUNNEL_TCP=1 uses port 7000 instead. If the entry is blocked, nothing fails loudly — those interfaces simply don’t open from the cloud, while they keep working on the local network. Leave it out if you only use the appliance locally.

The smtp-proxy.ironflock.com entry is only needed if you use the built-in IronFlock email relay. If you configure your own SMTP server, you can leave it out.

Optional destinations. The AI assistant refreshes model and widget metadata from raw.githubusercontent.com and cdn.jsdelivr.net, and looking up addresses for device locations uses nominatim.openstreetmap.org. All three are optional: if they are blocked, the assistant falls back to its built-in data and address lookup is unavailable.

Time synchronization is not in this list because it does not go to IronFlock: the appliance still needs a working time source. Allow outbound UDP 123 to your time servers, or configure your internal time server on the host — see Time Synchronization (NTP).

If your network only reaches the internet through a corporate HTTP proxy, see Behind a Corporate Proxy — the installer can point the Docker daemon at your proxy automatically.

Devices Connecting to the Appliance

Edge devices connect to the appliance, not to the cloud. If devices sit on a different network segment than the appliance, allow the device networks to reach the appliance host on these ports:

<APPLIANCE_HOST>:18080   # device link (WebSocket) — required
<APPLIANCE_HOST>:15001   # local App Store registry (app image pulls) — required
<APPLIANCE_HOST>:15002   # registry authentication (image pull tokens), device agent updates and the device installer — required
<APPLIANCE_HOST>:7000    # remote access to device UIs (optional tunnel feature)

These are direct connections — they must not be routed through a corporate HTTP proxy. If a device’s network forces all traffic through a proxy, either exempt the appliance host from the proxy on the device, or switch the appliance to HTTPS with your corporate certificate: in that mode all device traffic — the device link, image pulls, agent updates, and the remote-access tunnel — moves to a single, proxy-friendly port: 443 on your domain, and works through corporate proxies and strict firewalls without per-port exceptions.

Port 15002 also serves device agent updates and the device installer: devices attached to the appliance download agent updates — and new devices the installer — from the appliance itself, never from the internet; in domain mode from https://registry.<APPLIANCE_DOMAIN>/dl on port 443 instead. See Device Agent Updates and Enrolling Devices Without Internet Access.

Devices need no internet access for normal operation. Everything an attached device does — the device link, app images, agent updates, remote access — goes to the appliance. A device only reaches the internet when it builds an app from a Dockerfile whose base image lives on a public registry, when you publish an app that uses public images, when Docker itself still has to be installed, and — on devices running FlockOS — to check for operating-system updates at instance-registry.ironflock.com. The apps you deploy may have network needs of their own.

Network Identity for IronFlock Hosts

The appliance and every edge device run IronFlock as an unattended system service: it starts at boot and stays connected around the clock, whether or not anyone is signed in. Firewall and proxy rules for these hosts must therefore be bound to the machine — never to the person who happens to be logged in on it. For edge devices this applies whatever platform they connect to; the device guide covers it in Identity-Aware Firewalls and Proxies.

This matters most on networks with an identity-aware firewall or proxy, which grants access by directory identity instead of by address. If the rule that admits an IronFlock host is tied to a user, the host loses access whenever that user’s session lapses. Connections that are already open keep running while every new one is silently dropped, so the host looks healthy until it next has to connect — then an app install, an agent update or a reconnect fails, and after its next restart the device stays offline.

No exemption from identity enforcement is needed. Ask your network team to identify each host by the identity it actually has:

How this maps to common products:

• Check Point Identity Awareness: in the Access Role, select the machine (computer object or group) instead of users. Machine identities are refreshed by the computer’s own domain activity; if they can lapse on your gateway, use a network object instead.
• Palo Alto Networks User-ID: computer accounts do not produce IP-to-user mappings, so use an address object, a tag or Device-ID.
• Fortinet FSSO and similar directory-based firewalls: use an address object for the host, or the dynamic address your network access control assigns.
• Zscaler, Prisma Access and other cloud security gateways: register the appliance’s address as a server or IoT location (a trusted source), so its traffic is identified by location rather than by user.

Recognizing the failure. A device that stays online but fails every new connection — image pulls, registry logins, reconnects — while pings and its existing session keep working points at an identity rule that has expired, not at the device. Don’t restart the agent until a fresh connection from the device succeeds again: the session that is still open is the only one that works.

Access Your Instance from ironflock.com

Even though the appliance is a fully local platform, you don’t have to be on the factory network to use it. As long as the appliance has an internet connection and your appliance account is connected to your ironflock.com account (see Linking Accounts), you can switch into your instance directly from the IronFlock cloud UI — no VPN, no port forwarding, no extra tooling.

This means:

• One unified UI — manage your cloud projects and your appliance instances side by side from a single browser tab.
• Work from anywhere — operators, developers, and support staff can reach the appliance over the internet, while all production data and workloads stay local on the appliance.
• Easy multi-site oversight — if you operate several appliances across different factories, each one shows up in your ironflock.com account and is one click away.

When the appliance loses internet access, it keeps running locally and remains reachable from inside the factory network at http://<appliance-host> — only the remote access path is paused until connectivity is back.