izgate ships with a separate driver for every firewall family: log parsing, guest Wi-Fi handoff, the firewall API and the Rules page are all written specifically for each device. Ready-made support for FortiGate, MikroTik, pfSense, OPNsense, Sophos XG/XGS and Palo Alto; if you have a different device, logs can still be collected over generic syslog.
Field verification status: On FortiGate, both the log path and the firewall API path have been verified end to end on a real device (FortiOS 5.6.8): captive portal → Turkish ID verification → mg-… user → visible in the traffic log. MikroTik's log driver and one-click setup have passed unit tests and an end-to-end test against a mock RouterOS, but haven't yet been tried on a real RouterOS device. Sophos, Palo Alto, pfSense and OPNsense field mappings are ready in code but haven't been verified against a real device in the field.
The table below summarizes every path supported at the code level, showing which feature works on which device.
| Device | Log parsing | Guest portal handoff | Firewall API (guest) | Rules page | Device metrics | One-click setup | RADIUS |
|---|---|---|---|---|---|---|---|
| FortiGate | Yes | fgtauth POST + magic | Primary path (guest group) | Read+write | Yes | — | Supports (802.1X path) |
| MikroTik | Yes | Hotspot link-login-only (HTTP PAP) | REST API, hotspot guest user | Read+write | Yes | New | Supports |
| pfSense | Yes | portal_action | — | Not supported | — | — | Supports |
| OPNsense | Yes | Manual | — | Not supported | — | — | Supports |
| Sophos XG/XGS | Yes | Manual (the device's own portal queries izgate's RADIUS) | — | Not supported | — | — | Supports |
| Palo Alto | Yes | Manual | — | Not supported | — | — | Supports |
| Generic (syslog) | Best-effort generic parsing | Manual | — | — | — | — | Supports |
FortiGate and MikroTik are recognized from the log record by serial number; pfSense, OPNsense, MikroTik and generic syslog require the sending IP address to be defined in the panel. The Rules page and the firewall API path currently work only on FortiGate and MikroTik; Sophos/Palo Alto Rules adapters and GeoIP enrichment for the others are on the roadmap.
Log collection over syslog; guest Wi-Fi handoff is done primarily through the firewall's own management API: izgate opens a temporary account for the verified guest in the firewall's guest user group, and the browser is redirected to the firewall's own login page (fgtauth). The Rules page works as read+write, and device metrics (CPU/RAM/sessions) are sampled once a minute via the API. This flow has been field-verified on a real device running FortiOS 5.6.8.
Log collection over syslog; guest Wi-Fi handoff happens automatically through RouterOS hotspot's link-login-only (HTTP PAP) method. The REST API supports hotspot guest users, the Rules page (/ip/firewall/filter read+write), and device metrics. There's also a one-click setup (below) that automatically applies NTP, syslog, hotspot, Wi-Fi and Let's Encrypt steps. It has passed unit tests and an end-to-end test against a mock RouterOS; field testing on real RouterOS hardware is pending.
Log collection over syslog; since this device's logs don't carry a serial number, the sending IP address must be defined in the panel. On guest Wi-Fi, pfSense's own portal_action mechanism redirects to the izgate portal and the handoff completes automatically. The firewall API and the Rules page aren't supported on this driver.
Syslog log collection from the same driver family as pfSense; the IP address is defined in the panel. Guest Wi-Fi handoff is manual on this device (identity shows on screen, and the device's own portal queries izgate's RADIUS). The firewall API and the Rules page aren't supported.
Traffic and threat logs are collected over syslog. Guest Wi-Fi handoff is manual: identity shows on screen, and the device's own portal queries izgate's RADIUS server. The firewall API and the Rules page don't exist yet on this driver — Sophos and Palo Alto Rules adapters are on the roadmap.
Log collection over syslog; the device is recognized by its serial number. On guest Wi-Fi, handoff is manual; it can also be delivered through RADIUS integration or manual configuration by an administrator. The firewall API and the Rules page aren't supported.
If you have a device that isn't listed, raw log collection can still work through generic syslog support; field-level parsing and automatic guest handoff don't work in that case.
Once a device is registered with the MikroTik driver and RouterOS 7 REST API details (address + Basic Auth username/password), the panel's "Provision" step automatically writes the required configuration to RouterOS. Only objects tagged "izgate" are managed, and the operation is idempotent — running it again does no harm.
An NTP client, remote syslog (ISO 8601 format), and the forward + srcnat log rules required for 5651 are inserted at the top of the rule list.
IP pool, address/DHCP network, DNS, HTTP-PAP user profile, server, masquerade, walled garden (portal address + captive-bypass addresses + any extra allowed addresses).
The router fetches login.html from the izgate portal itself via /tool/fetch (the REST API has no file upload).
RouterOS 7's wifi package, or the older wireless package, is detected automatically; SSID (open network or WPA2), country, guest isolation and the access-point assignment rule are bound to the hotspot bridge. The step is skipped if neither package is present.
Obtains a certificate for the router via ACME HTTP-01 (port 80/tcp must be open on the WAN) and makes the hotspot login page HTTPS; the API service itself isn't touched.
The panel only manages objects it created itself, tagged "izgate"; it doesn't touch any other configuration on the router. Running it again doesn't break the existing setup.
Limitations: RouterOS's REST API has no interactive/long-running command; there's a 60-second-per-request limit and a single-object limit. Both of these (the Wi-Fi and Let's Encrypt steps) have been tested against a mock RouterOS; field verification on a real device is pending — as it is for the driver in general.
When you add a new firewall on the Devices page, izgate generates ready-made configuration on the "Log Shipping" screen based on the device type you chose: destination address, the port to use (UDP 5514, TCP 5515, TLS 6514 if a certificate is configured), and a device-specific command or step list.
In izgate, every firewall family is represented by an independent "driver" that parses its own log format and, where available, knows its own guest handoff method, firewall API and Rules page. This lets izgate grow without having to redesign itself every time a new device is added: even if an organization has more than one brand of firewall, all of their logs come together in the same panel, the same search screen, and the same signed archive.
On enterprise networks, a firewall's IP address can change when the network is reconfigured, the device is replaced, or you switch to a backup device. Because devices like FortiGate, Sophos and Palo Alto carry the device's serial number in their syslog records, izgate can correctly identify which device a log belongs to even if the address changes, and it learns the address automatically from the first incoming log. Because the standard output of pfSense, OPNsense, MikroTik and generic syslog sources doesn't carry a serial number, the sending IP address needs to be defined in the panel beforehand for these devices; otherwise incoming logs are grouped under an "unregistered device" of unknown origin, and no license can be assigned to it. If the address matches but the serial doesn't, the event isn't written at all — a "SERIAL @ address (unregistered)" quarantine device and a health alert are raised instead.
On FortiGate and MikroTik, izgate performs guest handoff through the firewall's own management API: a temporary user is opened on the firewall for the verified guest, and the browser is redirected to the device's own login page. This means it can work without requiring RADIUS, unlike most competing products; RADIUS can still be used for office Wi-Fi and for devices without a firewall API.
Being able to read and write firewall policies requires the device's management API to allow it. FortiGate's and MikroTik's REST/CMDB APIs support this operation safely; because this API integration hasn't been written yet for the other drivers (pfSense, OPNsense, Sophos, Palo Alto), the Rules page shows "not supported" there. Sophos and Palo Alto adapters are on the roadmap.
If you have a firewall or network device outside the listed families that can send logs over standard syslog, izgate can still collect these records through generic syslog support and write them to the signed archive. In this case, field-level parsing (extracting structured fields like source/destination IP, user, port) is best-effort, and automatic guest Wi-Fi handoff doesn't work; the records are still searchable, though.
Separate from guest Wi-Fi handoff, user authentication on office Wi-Fi networks is done with RADIUS (PAP; 802.1X/EAP isn't available yet). izgate's built-in RADIUS server works through local user accounts, MAC lists and a session table, providing a common authentication layer across all supported firewall/access-point families. RADIUS sessions are automatically merged with firewall logs, directly answering "which user, from which IP, and when."
When adding a new device in the panel, choosing the correct device type matters; each type activates its own driver and its own field mappings. For devices that carry a serial number (FortiGate, Sophos, Palo Alto), entering the serial field correctly is necessary for the address to be learned automatically. For devices without a serial (pfSense, OPNsense, MikroTik), the IP address of the interface sending syslog needs to match the device record exactly.
If your firewall can send logs over standard syslog, raw records are still collected and written to the signed archive through generic syslog support. However, field-level parsing (user, IP, port, etc.), the firewall API, the Rules page and automatic guest handoff only work on devices with a ready-made driver.
izgate opens a temporary account for the verified guest in FortiGate's own guest user group; the browser is redirected to FortiGate's own login page under that identity, and the firewall verifies the user locally. This flow has been field-tested on FortiOS 5.6.8.
Not yet. The MikroTik driver and one-click setup (NTP, syslog, hotspot, Wi-Fi, Let's Encrypt) have passed unit tests and an end-to-end test against a mock RouterOS; field verification on a real RouterOS device is on the roadmap.
Reading and writing firewall policies depends on the device's management API; this integration has currently only been written for FortiGate and MikroTik. Sophos and Palo Alto adapters are on the roadmap; the page shows "not supported" on other devices.
Yes. izgate is vendor-independent; firewalls of different brands and models are managed together in the same panel, the same search screen and the same signed archive.
Configure izgate Cloud based on your number of firewall devices and storage needs; no setup, get started in minutes. Call us with any questions.
