SignLogger Captive Portal User Guide

This document explains, step by step, how to use the Hotspot Management > Captive Portal module in the SignLogger management panel. The goal is for an administrator to list, add and edit captive portal (guest Wi-Fi sign-in page) records without friction. Sensitive values in the screenshots — IP addresses, device serial numbers, SSIDs and portal addresses — are masked for privacy.

1. NAC Preparation (Adding a Client and a Group)

Before the captive portal can work, the required definitions must exist on the NAC (RADIUS) side. Before granting clients internet access, the connecting network device (NAS) must be added as a client and the group objects that will classify its users must be created. Without these two definitions, captive portal authentication does not work. This section covers the preparation on the NAC Management menu's Clients and Objects (Groups) pages.

1.1 Adding a NAC Client (NAS)

NAC Management > Clients manages the client devices (NAS: switch, access point, firewall, etc.) that connect to the RADIUS server. Use it when a new network device will talk to RADIUS, when a client's IP/CIDR changes or when the shared secret is rotated. Click the plus (+) button in the top-right corner and fill in the form:

Client Name: an operationally meaningful name (letters, digits and hyphens only). Required.
IP/CIDR: the IP address or network block the client appears from (a single IP or e.g. a /24 subnet). Required.
Description: a short note (optional).
Secret: the shared secret between the NAS and RADIUS. Required for new records; leaving it empty while editing keeps the existing secret.
Type: the client type (e.g. FortiGate-NAS, SonicWall-Firewall, Aruba-AP, Generic-NAS).
Device (optional): selecting a device can auto-fill the IP field. For captive portal scenarios, associating the client with the relevant firewall/device here is recommended.
Require Message-Authenticator: enforces the Message-Authenticator attribute in Access-Request packets for extra security (per your policy).

Figure 1: NAC Add Client form.

1.2 Adding a Group Object

NAC Management > Objects manages the user / MAC / group objects used in NAC policies. The page has three tabs: Users, MAC Addresses and Groups. To classify captive portal users and reference them in rules, create a group object first: switch to the Groups tab, click + Add Group and fill in:

Type: group type — user, mac or ldap. Required.
Group name: a unique name; DN/CN format may be used for LDAP. Required.
Device (optional): selecting a device automatically appends a "Device: SERIAL" line to the description (for device scoping). For a group used by the captive portal, selecting the relevant device's serial here is recommended.
Description: free text. For non-root users the "Device: SERIAL" line may be mandatory.
Active: when ticked the group is usable in rules (default on).

Figure 2: NAC Add Group form.

2. Module Overview

The Captive Portal screen shows all defined portal records in a table. The plus (+) button in the top-right adds a new record; the refresh button next to it reloads the list. Clicking the Help icon in the top bar opens a panel with page-specific documentation. The screenshot above shows the list screen (sensitive fields masked).

3. The List Screen and Its Columns

Each row represents one portal record. The columns:

Logo: a small preview of the portal's logo; may appear empty or warn if the logo cannot be served.
Domain: the record's domain — visible only to the root user.
Device: serial/identity of the device the portal is bound to.
Location: the record's location or company name (the company_name field in the backend).
SSID: the wireless network redirected to the portal.
Portal URL: the portal address auto-generated from the SSID. Copyable.
Firewall IP: the firewall IP/CIDR value(s) allowed to reach the portal; multiple values comma-separated.
Default Language: the portal's default interface language.
Guest: the guest network CIDR list (guest_network). Required.
Actions: Edit or Delete; may be inactive depending on permissions.

4. Adding and Editing Records

Click the plus (+) button to create a record, or the row's Edit button to update one. Either way a form (modal) opens with collapsible sections. Fill the fields top to bottom, make sure the required ones are set, and finish with Save.

4.1 Basic

Device (required): the device the record binds to.
Location (required): location or company name; used to group records.
SSID (required): the wireless network to redirect.
Default Language (required): the language the portal opens with.
FQDN (optional): a domain name used for portal access, depending on the deployment.
SSID (optional): a legacy/secondary SSID or alias.
RADIUS Group (optional): the RADIUS group assigned to authenticated users.
Mail Server (optional): the defined mail server used for notification/approval e-mails.

Figure 3: New record form — Basic section.

4.2 Firewall IP and Redirect

Firewall IP (required): a single IP/CIDR or a comma-separated list.
Guest Network (required): the guest network CIDR (e.g. 10.10.10.0/24); multiple values comma-separated.
Redirect URL (required): the full URL the user lands on after signing in.

Figure 4: Firewall IP and Redirect section.

4.3 Images

Logo (optional): the logo shown on the portal page.
Background (optional): the portal's background image.
Delete: removes the existing logo or background (requires permission).

Figure 5: Images section.

4.4 Additional Information

Additional fields collect extra information from the user and do not affect authentication methods.

Additional Fields (optional): when this switch is on, the portal collects extra information from the user. It does not affect authentication.

Figure 6: Additional Information section.

4.5 Authentication Methods

SMS and LDAP are authentication methods. This section toggles the sign-in methods available on the portal:

Login: username/password sign-in on/off.
Form auth: form-based sign-in on/off.
SMS: SMS verification on/off.
LDAP: LDAP authentication on/off.
Trusted Domains (Form Auth): approval e-mails are sent only to sponsor addresses in these domains (comma-separated).
SMS Method (conditional): chosen when SMS is on; the request type (GET/POST).
SMS Provider (conditional): chosen when SMS is on; the provider record matching the method.
LDAP Config (conditional): chosen when LDAP is on; the primary LDAP configuration.
LDAP Fallback (conditional/optional): the backup configuration used when the primary is unreachable.

Figure 7: Authentication Methods section.

4.6 Extra Verification / Session

2FA provides an extra verification layer. This section holds additional security and session settings:

2FA (conditional): an extra verification layer; requires at least one of SMS/Form/Login/LDAP to be enabled.
Save user auth (optional): stores the user's credentials so they can sign in again later with their assigned password and token.

Figure 8: Extra Verification / Session section.

5. The Portal URL

The Portal URL is generated automatically from the SSID in the form http://<host>:8080/<SSID>, where <host> comes from the IP or FQDN in your browser and <SSID> from the form. It is shown at the bottom of the form with a copy button. The Redirect URL is not shown in the list — it is managed only in the Firewall IP and Redirect section.

Copy the generated Portal URL into the appropriate captive portal field on your firewall. When users request internet access, the firewall redirects them to this address and authentication happens on this portal.

Every firewall brand/model has its own way of configuring an external portal URL — confirm the right field in the device's admin panel or vendor documentation. It usually lives under headings like Guest/Hotspot, Captive Portal, External Portal or Authentication Portal. See our step-by-step firewall guides: FortiGate, Zyxel, SonicWall, WatchGuard, Sophos and Palo Alto.

6. Saving and Tips

Fill the fields top to bottom; never leave the required ones empty (Device, Location, SSID, Default Language, Firewall IP, Guest Network, Redirect URL).
Conditional fields apply only when their method is enabled (e.g. SMS Method and SMS Provider when SMS is on).
Enabling 2FA requires at least one of SMS, Form, Login or LDAP.
Review your values before saving; if the result surprises you, re-check filters and selections.
Finish with Save at the bottom of the form, or Close to discard.