5651 logging with pfSense and OPNsense.

Short answer: pfSense and OPNsense both send logs to izgate via syslog and are verified with SSH credentials when the device is added. On the 5651 access-record side, both work the same way; the difference shows up on guest Wi-Fi — pfSense's own portal_action mechanism completes the handover automatically, while on OPNsense the handover is manual and the device's own portal queries izgate's RADIUS server.

Common ground: logs via syslog, verification via SSH

Because these two open-source distributions derive from the same underlying firewall engine (pf), their log formats and management logic are close to one another; izgate's drivers reflect this similarity. The difference lies in the user interfaces and in how the captive portal implementations used for guest Wi-Fi behave.

Both devices are added on the Devices page via "New Device," where you select the driver (pfSense or OPNsense) and register it with SSH credentials; izgate connects to the device over SSH with this information to verify the registration. pfSense and OPNsense are not devices that carry a serial number, so the address of the interface sending syslog must exactly match the device record — if the address doesn't match, incoming logs are grouped under "unregistered device" and no license can be assigned.

In the "Log Delivery" panel that opens after registration, the syslog destination address and port (UDP 5514, delivery-guaranteed TCP 5515) are shown; for these drivers the panel doesn't generate a ready-made CLI command, but instead provides a step-by-step configuration guide to follow in the management interface. For the general framework of the access-record obligation, see the Law No. 5651 guide.

pfSense: automatic portal handover

This automatic flow relies on a redirect mechanism already supported within pfSense's own captive portal feature; izgate is simply defined as that mechanism's target, and you don't need to run any extra integration software on the pfSense side.

Once pfSense's own captive portal is handed off, when a guest redirected to izgate's portal address is verified, pfSense's portal_action mechanism is triggered and the handover completes automatically — the guest getting online requires no additional manual step. This driver does not support a firewall API or the Rules page (reading/writing policies from the panel); rule management is done from pfSense's own interface.

OPNsense: manual handover via RADIUS

On OPNsense, guest Wi-Fi handover is manual: the authentication screen appears in OPNsense's own captive portal, and the device's portal queries izgate's internal RADIUS server for verification (Authentication 1812/UDP, Accounting 1813/UDP — the same ports as the port table on the Deployment and Licensing page). To set up this flow, you need to enter izgate's real IP address and the shared secret into the RADIUS server definition on OPNsense; since the portal address is a hostname, an IP address is used separately in the RADIUS definition. OPNsense also doesn't support a firewall API or the Rules page.

Day to day: a café example

The example below describes what happens when a request arrives for a small café running pfSense on its guest Wi-Fi.

Syslog ports and network planning

Which of the UDP 5514 and TCP 5515 ports shown in the Log Delivery panel you choose depends on your network's reliability needs: UDP is lighter and sufficient for most setups, while TCP guarantees delivery on busier networks where you want to reduce the risk of packet loss. In both cases, the path from pfSense or OPNsense to the syslog destination needs to be open in your firewall rules (via a separate management VLAN, if you have one); otherwise logs never reach izgate at all, and this shows up on the "Alarms" page as a device-silence warning. If you're running RADIUS on OPNsense, restricting ports 1812/1813 so they're only reachable from izgate's address also reduces the risk of the shared secret being guessed from outside.

Exemptions for printers and IoT devices

Devices without a browser (printers, access-card readers, robot vacuums, and the like) can't pass through pfSense's or OPNsense's captive portal either. These devices show up in the izgate panel's "Unrecognized Devices" list and can be registered by their MAC address; however, unlike on FortiGate, an automatic portal exemption hasn't been built for these two drivers — the exemption is defined by you, in pfSense's or OPNsense's own captive portal settings (allowed MAC/IP list). Because the device is still registered in izgate, its traffic is still logged; it just doesn't need to go through the portal redirect.

What these drivers don't have

• Firewall API: not built for pfSense and OPNsense; guest handover is handled through the portal mechanism (pfSense) or RADIUS (OPNsense) rather than an API.
• Rules page: reading/writing firewall policies from the panel isn't supported on these drivers; rule changes are made from the device's own interface.
• Device metrics: CPU/RAM/session sampling only exists on FortiGate and MikroTik; these rings don't appear on pfSense and OPNsense cards.
• Automatic recognition by serial number: on these two drivers, the IP address sending syslog has to be correctly defined in the panel; if the address changes, the device record has to be updated too.
• Automatic portal exemption: the one-click exemption available on FortiGate doesn't exist on these drivers; exemptions are defined from the device's own interface.

If you have a firewall that isn't in this list, raw records can still be collected via generic syslog support as long as the device can send standard syslog; in that case, however, field-level parsing is best-effort and automatic guest handover doesn't work. These limits may expand over time; see the Supported Devices page in the panel for the current support status.

Which businesses is it a fit for?

pfSense and OPNsense are open-source firewall distributions generally preferred by cost-conscious small and mid-size businesses, companies with a technical team, and organizations that want to use their own hardware (e.g. a mini PC or an industrial box). If you need 5651 logging, pfSense's automatic portal handover is a practical choice for a small business with guest Wi-Fi (café, office); the manual RADIUS flow on OPNsense tends to be easier to set up at organizations whose IT team is already familiar with RADIUS. In either case, if advanced features like the Rules page and device metrics matter to you, the API-based integration offered by FortiGate or MikroTik may be a better fit.

Frequently asked questions

This page is for information only; for the current text of the legislation, refer to the official source (mevzuat.gov.tr).