Frequently asked questions

izgate is a two-column product for the networks behind your office firewalls: firewall log management, which collects firewall logs and writes them to a Law No. 5651-compliant signed archive, and guest/office Wi-Fi authentication. The two columns are linked by design: every network connection is matched to a person, so both the traffic record and the identity come together in a single panel. It is device-independent; each firewall is added through a driver (log parser + identity handoff).

izgate is designed for businesses that provide public internet access, such as hotels, cafes, hospitals, schools, shopping malls and offices. These businesses offer Wi-Fi to guests or employees, and may also be required to retain traffic records under Law No. 5651. izgate brings both needs together in a single panel. We recommend consulting your legal advisor for obligations specific to your organization.

No, the two are linked by design: when a guest or office user connects to Wi-Fi, izgate verifies that person and opens them as a temporary user on the firewall; all traffic logs that user generates are then automatically matched to them. Log management can also be used on its own (only firewall syslog is collected), but user matching only works fully once Wi-Fi management is enabled.

You can purchase izgate Cloud online from the /satin-al page and have your account up and running right away; your data is hosted at İzHost's data center in Turkey. If your logs need to stay inside your organization, the on-premises IzGate License is the right fit; this model is currently offered through a quote process, so contact us for a quote. The feature set is identical in both models; only the deployment differs.

Yes. Reach out to us via the demo request form; we'll assess your network setup together and prepare a live demo and trial environment for you.

izgate supports six different firewall families (FortiGate, Sophos, Palo Alto Networks, pfSense, OPNsense, MikroTik) in a single panel, offers RADIUS-based office Wi-Fi, and provides a signed and timestamped archive built in. Because log management and guest/office Wi-Fi authentication are combined in the same product, you don't need to set up and integrate separate systems. The device-independent design lets firewalls from different brands be managed in the same panel.

izgate Cloud is purchased online from the /satin-al page. Once payment is confirmed, your account and tenant are activated automatically; you'll be asked to change the temporary admin password on first login. No server or Docker is required for setup; the panel runs directly at panel.izgate.com.

izgate Cloud pricing is based on the device-count quota you select and your total disk space (GB). Current prices are shown on the /satin-al page; no price commitment is made outside that page. You decide how to split your total disk space between live logs and archive.

The on-premises IzGate License is priced as an annual seat per firewall device, with optional module flags (hotspot/Wi-Fi, 5651). This model isn't sold online at this time; contact us for a quote.

With izgate Cloud, your account and tenant open automatically the moment payment is confirmed; there's no manual setup step to wait for. A temporary admin password is generated and must be changed on first login. With the on-premises license, setup is done on your own server with Docker, so the activation time depends on your deployment.

Yes. The "Recommended Space" card on the Disk Management page calculates how much extra space you may need based on your event rate over the last 7 days; if your current disk is insufficient, the "Increase Space" link takes you to your izgate.com account page. See the Disk Management page for details.

izgate Cloud uses İzHost's account infrastructure; login, sub-users and permission management work on the same model shared with izhost.com. Your invoice and order history is viewed through your İzHost account. Reach us via the contact page with any questions.

With izgate Cloud, your account opens automatically right after purchase; adding a device and defining a guest network takes just a few steps after your first login. With the on-premises IzGate License, Docker-based setup is a single command (install.sh). See the deployment and licensing page for details.

When you complete your order on the /satin-al page, your account and tenant open automatically; you log in through panel.izgate.com with your İzHost account (email/password, plus OTP if required). If you have more than one company, you'll choose which one to log in as. Changing the temporary admin password is required on first login.

An on-premises installation starts on a Linux server with Docker installed, with two separate disks prepared for /log and /archive (install.sh stops the installation if a separate disk isn't present). The install script formats and mounts the disks and brings the stack up; the panel opens at http://<server>:8080, and the admin password is logged to the console once during first setup. You then enter your İzHost license key under Settings > License and add your devices.

You must change the temporary admin password shown to you on first login; in the cloud it's shown during sign-up, and on-premises it's shown once in the install console. After that, you'll need to enter your license key under Settings > License and add your first firewall device.

From the Devices page, use "New Device" to give the device a name, a driver type (FortiGate, Sophos, Palo Alto, pfSense, OPNsense, MikroTik) and a serial number. For devices that carry a serial number (FortiGate, Sophos, Palo Alto), entering a syslog address isn't required; it's learned automatically from the first incoming log. For drivers without a serial number (MikroTik, pfSense, OPNsense, generic), an address must be entered. See the supported devices page for details.

This panel opens automatically after a new device is registered; it shows the device's syslog address and ports (UDP 5514, TCP 5515, and TLS 6514 if a certificate is configured), plus a ready-made configuration based on the driver. For FortiGate, Palo Alto and MikroTik it offers directly copyable CLI commands; for Sophos/pfSense/OPNsense it offers step-by-step interface instructions. You can always get back to this panel from the relevant device on the Devices page.

izgate provides the technical infrastructure to collect traffic records, match them to a user, sign and timestamp them, and retain them for the period you choose. However, exactly how these obligations apply to your organization requires a legal assessment; we recommend getting your legal advisor's opinion. See the 5651 guide page for more information.

You set the live and archive retention periods from the panel; on izgate's side this isn't a regulatory constant, it's a setting you can change under Settings > Disk Management. The period set out in the regulation is two years (Regulation Art. 4/1-b); izgate uses this as the recommended/default value. See the Regulation on Internet Public Use Providers page for details.

A timestamp proves, via a server independent of your organization, the exact moment a record existed, showing that the signature wasn't applied after the fact. Once a day, izgate obtains a qualified timestamp from the Public Certification Authority (Kamu SM) through İzHost's central service; this central service address cannot be changed from the panel.

izgate uses three mechanisms together: the digest of each archive segment is chained to the digest of the one before it (a SHA-256 chain), the segment is signed with a key specific to your installation (Ed25519), and the day's not-yet-timestamped segments receive a qualified timestamp from Kamu SM once a day. Together, these three show that a record hasn't been altered since it was created and that it existed at the stated time. File, signature, chain and timestamp integrity can all be verified with one click from the panel.

Yes. You can select the relevant date and device range and export it as a signed package consisting of a README, a catalog, segment files, a manifest and a TSA token. Export runs synchronously and supports up to 500 segments / 4 GB at a time. We recommend making decisions about the procedure and scope of such a request together with your legal advisor.

izgate uses a secure on-disk queue; every incoming line is written to both the search database and the signed archive, and isn't removed from the queue until verified. If there's a power outage or the service restarts, any lines still waiting in the queue continue processing from where they left off; this is what guarantees zero log loss.

Firewalls send their logs via the syslog protocol; izgate supports all of UDP (port 5514), TCP (port 5515, reliable) and, if a certificate is configured, TLS (port 6514). Incoming lines are written to a secure on-disk queue and processed in batches (up to 2,000 lines / up to 500 ms per batch). Devices are recognized by serial number, not IP address.

Panel › Logs offers date range, device, category, action, source/destination/NAT IP, user, MAC and free-text filters, a timeline, category/action/device/user facets, and row-level detail. Search runs on the fast-search database with fast pagination for large result sets. Rows restored from the archive are also flagged. See the Live Logs page for details.

No. izgate recognizes every device by serial number, not IP address; even if the address changes (for example after a DHCP renewal), logs keep writing to the correct device. If the address changes but the serial doesn't match, the event isn't recorded and a quarantine warning is raised, preventing records from being mixed up with the wrong device.

The Reports page offers 17 ready-made reports across 8 categories; they can be generated instantly as PDF (with a branded cover, summary, charts and tables), Excel or CSV, or set up as a daily/weekly/monthly scheduled job. Generated reports are kept in Report History for 90 days.

This page shows, in one unified feed, events classified on the fly from firewall logs (IPS, virus, web filter, application control, port scan, DDoS, failed login, VPN, configuration change, HA, blocked traffic) alongside izgate's own events (guest login/failed login, approval request/denial, panel login, rule change, device offline/online). It also includes summary KPIs, a comparison with the previous window, and an attack-source country map; country data comes only from FortiGate's srccountry field. See the Alerts and Events page for details.

When izgate receives a log from an address it doesn't recognize, it automatically opens that address under an "(unregistered)" device record and tries to detect its driver line by line, so no log is ever silently lost. Editing the device on the Devices page and matching it to the correct name, driver and serial number makes the record permanent.

Logs accumulate as compressed archive files (segments), organized by tenant/device/type/day. Each segment's SHA-256 digest is chained to the one before it, the segment is signed with Ed25519, and it's sealed once a day with a qualified timestamp obtained from Kamu SM. See the Archive page for details.

The integrity of any segment, or the whole chain, can be verified from the panel with one click: the file digest is compared against the catalog, the manifest signature against your installation key, and the chain against the previous segment's digest, along with a check of the TSA token. The result is reported as either "chain intact" or the exact point where something's wrong.

The exported package consists of a README explaining the verification steps, a catalog listing the segments, the compressed segment files, a manifest carrying each segment's digest/previous digest/signature information, and a TSA token obtained from the timestamp server. Export runs synchronously and is capped at up to 500 segments / 4 GB at a time.

Yes, you can restore selected segments from the Archive page back to live; this makes the record temporarily searchable again, and it drops out automatically once the period you set expires. Events already in the live window aren't rewritten, they're skipped. Restored rows are also flagged in search results.

No, archive pruning cannot be undone. Pruning only deletes segments older than your chosen cutoff date that fall entirely outside the retained scope; no segment after the cutoff date, or only partially within scope, is ever touched.

The column-based ClickHouse database used for fast search and the signed archive are kept on separate physical disks, so one filling up or failing doesn't affect the other. In an on-premises installation, install.sh stops the installation if separate disks aren't found for /log and /archive. In izgate Cloud, this separation is achieved by splitting your total quota between live and archive.

A device connecting to the guest network has its browser redirected to the izgate login page; the guest is verified using the method you've chosen and accepts the privacy notice. Once verification completes, izgate opens a temporary user for that person on your firewall and starts their internet access within seconds; access closes automatically once the time limit expires. See the Guest Wi-Fi page for details.

Multiple methods can be chosen per network: SMS OTP, Turkish ID number plus NVİ (population registry) verification, bulk-generated visitor codes (vouchers), admin approval, an institutional account, an institutional service query (a query against the customer's own API), pre-registration (the organization's own system entering the person in advance) and device registration (by MAC). With "remember this device" turned on, the same MAC can also be re-authorized automatically without asking for identity again, within the period you set, the next time it connects.

Netgsm, İleti Merkezi and a generic HTTP-based provider are supported; you can define more than one provider, pick one as default, and send a test message. A provider's secret is never shown again in the panel once saved.

When Turkish ID verification is enabled on a network, the ID number, first name, last name and birth year entered are checked against the NVİ Identity Sharing System for an exact match; if there's no match, the login is rejected rather than silently falling back to the stated value. Current status: NVİ's public query service is currently blocked by bot protection and unavailable; real-time verification is ready in the software and will activate once a connection to the institutional KPS protocol (username/password-based) is in place.

Yes, you can generate as many codes as you like from the panel; you define a label, a validity window, a usage-count limit and a per-session duration, export the list as CSV, and revoke codes as needed.

No. Only a fixed alias code (mg-xxxxxx) for the person is written to the firewall and traffic logs; the real identity (phone number/Turkish ID) is kept encrypted only inside izgate and is resolved on an authorized search screen.

With "remember this device" turned on, the same MAC is re-authorized without asking for identity when it reconnects within the period you set (default 1,440 minutes). With device registration, once an admin approves it, the device gains access for an unlimited period (10 years), and on later connections its MAC is recognized and it logs in automatically. In both cases, you can block a guest or a registered device at any time from the panel and immediately remove their user from the firewall.

Office Wi-Fi runs on RADIUS auth/acct (PAP) against a local user list; users can be given a MAC list and a validity date. The NAS shared secret is read from the matching device record. Session-to-user matching is handled through the RADIUS Class attribute. See the Office Wi-Fi page for details.

Not yet; office Wi-Fi currently works only with RADIUS PAP. 802.1X/EAP (sourced from local/AD/LDAP directories) is on the roadmap.

The "RADIUS Sessions" tab on the Sessions page shows sessions for office Wi-Fi and non-802.1X RADIUS traffic; the "Guest Sessions" tab lists izgate's own guest flow separately (method, alias code, firewall user status). See the Sessions page for details.

The NAS (Network Access Server) shared secret is read from the record of the matching firewall/access point device; a RADIUS request from an unknown NAS goes unanswered. The Message-Authenticator field is verified with HMAC-MD5, and the packet is silently dropped if it's wrong.

A session whose accounting traffic has stopped (gone quiet) is automatically closed within 30 minutes. Accounting-On/Off packets only close that NAS's own sessions and don't affect other devices' sessions.

Ready-made drivers exist for FortiGate, Sophos (XG/SFOS), Palo Alto Networks, pfSense, OPNsense and MikroTik; there's also a "generic" driver for devices that send plain syslog. See the supported devices page for details.

A device's identity is its serial number, not its IP address; for devices that carry a serial number (FortiGate, Sophos, Palo Alto), the address is learned automatically from the first log. For drivers without a serial number (MikroTik, pfSense, OPNsense, generic), the address needs to be entered in the panel.

Once you enter RouterOS 7 REST API details (address plus username/password), the panel automatically applies NTP, remote syslog, 5651 log rules, the hotspot and login page, and optionally Wi-Fi (CAPsMAN) and a Let's Encrypt certificate steps to the device (one-click setup, managing only objects tagged "izgate"). This feature has passed mock-device tests but is still awaiting field testing on real RouterOS hardware.

Currently only on FortiGate and MikroTik: you can view, toggle, add, edit and delete policies from the panel, with a change history kept. The Rules page isn't supported yet on other device families (not even read-only). See the Firewall Rules page for details.

No, country information currently comes only from FortiGate's srccountry field. GeoIP enrichment isn't available yet on other drivers; it's on the roadmap.

Yes, izgate is device-independent; firewalls of different brands and models are managed together in the same panel, each sending logs through its own driver. See the firewall log management page for details.

With the on-premises license, your data stays entirely on your own server. izgate Cloud hosts data at İzHost's data center in Turkey. See the Security and Compliance page for details.

Guest identity data (phone number/Turkish ID) is stored encrypted; only the alias code is written to the firewall and the logs, the raw identity is never written. Access isn't opened for a guest until they accept the KVKK privacy notice and terms of use through the portal.

The RADIUS shared key, the firewall API token, the SMS provider secret and the KPS password are stored encrypted and are masked / never returned in API responses. Panel credentials are never written to any log line.

Firewall API connections use TOFU (trust on first use) pinning: the certificate fingerprint is recorded on the first connection, and the connection is rejected if it changes afterward. This prevents a device in the middle from quietly inserting itself.

After an access attempt that results in a 401/403, requests to the same address+key combination are automatically held back for 15 minutes. This is designed to avoid triggering the firewall's own login-failure lockout mechanism.

The license request is sealed to İzHost's central public key; no field, including the license key, travels in the clear. The response is a digitally signed document, and the verification gate only looks at that signed document; manually changing a field in the database unlocks nothing. Clock rollback attempts (cloning/copying) are also detected and locked.

From your İzHost account, you can add sub-users to your panel and define measured roles from an 8-key permission catalog shared with izhost.com (full access, view-only, logs, archive, devices, Wi-Fi management, guest reception, settings). See the Sub-Users page for details.

The permission key you assign automatically narrows the sub-user's panel menu and page access; for example, the "guest reception" permission only opens the Pending Approvals, Visitor Codes and Sessions pages. License and account management actions are only available to users with the "full access" key.

You log in with your email/password and enter an OTP code if required; if you have more than one company, you'll choose which one to log in as. In an on-premises installation, local login is also available, an İzHost account isn't required.

When you log in with your İzHost account, if your account is linked to more than one company/tenant, the panel shows you a company selection screen. Only the selected company's data is shown in izgate's panel.

You can log straight into the izgate panel with a one-time token from izgate.com or the izhost.com panel (/sso?token=); the token is used once and then becomes invalid. There's no need to enter a separate username/password.

The on-premises IzGate License is an annual seat per firewall device. izgate Cloud, instead, is priced by device-count quota and total disk (GB), and can be purchased online from /satin-al. See the License page for details.

On a device that's unlicensed or in an invalid state, log collection and archiving continue without interruption; no record is lost. However, search, statistics and device metrics are hidden, and the guest portal returns a "license required" error.

Log collection and archiving don't depend on an internet connection and continue without interruption. If İzHost's central service can't be reached for license verification, the system keeps working at full capability for a counting-down 3-day grace period; once that expires, only the display/portal gets locked.

active (normal operation), suspended (the portal and panel display shut down, but collection continues) and disabled (login and existing sessions are rejected; data is not deleted, per Law No. 5651) — three states in all. Suspension or disabling never deletes your existing log records.

You can split your total disk space between live logs and archive in whatever ratio you like; the default recommendation is 30%/70%, and the live side must be at least 10 GB. You can change the ratio under Settings > Disk Management. See the Disk Management page for details.

In an on-premises installation, you enter your İzHost license key on the Settings > License page. In izgate Cloud, the license is assigned to your account automatically at purchase; there's no key to enter separately.

You can reach us through the form on the Contact page; mentioning your product (log management/Wi-Fi), your deployment type (cloud/on-premises) and your device model, if applicable, speeds things up.

Reach out to us via the demo request form; we'll assess your network setup together and prepare a live demo and trial environment for you.

Yes, for every device, the Log Delivery panel on the Devices page and the network setup guide generate automatic, copyable setup steps/CLI commands. For the general setup flow, see the deployment and licensing page.

You can send feature requests and prioritization suggestions through the contact page; roadmap decisions such as GeoIP enrichment or 802.1X/EAP support are shaped by user feedback.

Some features on this page (for example, MikroTik one-click setup) have been verified in code and in a test environment but haven't yet been tried in the field on real hardware; these cases are explicitly flagged in their relevant answers. Before applying one to a critical device in your production environment, we recommend contacting us to confirm the current verification status.