IP Allowlist
The allowlist stores permitted sources: individual IPs, CIDRs, periodically resolved CNAMEs, and CIDR groups generated by region. It is used both to open the host firewall in Direct mode and to supply source data for post-login IP authorization and legacy mapping rules.
Three Source Types
| Source | Created by | Typical use |
|---|---|---|
| Manual entry | An administrator under IP Allowlist | A fixed office egress, trusted VPN, CIDR, CNAME, or regional CIDR group |
| Automatic entry | The post-login IP authorization policy | Temporarily authorizes the current public IP |
| Local exemption | Built into the gateway; not shown as an entry | Loopback, private, link-local, and CGNAT sources |
Local exemptions take precedence over allowlist and sign-in checks. They cannot be disabled and should not be treated as proof that public-access security is working.
Manual Allowlist
Click Add target under IP Allowlist to configure:
| Field | Description |
|---|---|
| Type | A single IP, CIDR range, or domain/CNAME |
| CIDR source | Entered manually or selected by region |
| Check interval | Refresh interval for domain resolution; 5 minutes by default, with a 1-minute minimum |
| Validity | 1 hour, 24 hours, 7 days, or a custom number of hours; entries can also be permanent |
| Comment | Records the purpose, owner, or review date |
A regional CIDR selection is saved as a separate region allowlist group rather than expanding every address range into the standard allowlist table. Regions can also be filtered by Telecom, Unicom, or Mobile. Carrier filtering requires CIDR database version 0.1.3 or later.
Manual entries are appropriate for long-term trusted networks with stable source addresses. Do not make mobile data, temporary Wi-Fi, or unknown egress points permanent. A regional allowlist permits a large number of public addresses in the selected region and is substantially riskier than a fixed CIDR.
A CNAME updates its effective allowed range from the system's resolution results. Use only domains you control whose results are predictable. Regional and carrier CIDR groups depend on IP geolocation data. They are useful for coarse restriction, not as the sole high-precision identity check. Carrier filtering requires CIDR database version 0.1.3 or later; older services still support standard region and custom-CIDR selection.
The list shows the target, resolved IPs, source, status, expiration, creation time, and comment. Domain entries support Refresh now, and comments can be edited directly. After an entry or region group is deleted, the corresponding Direct-mode firewall allowance stops working if no other valid entry covers the same source.
A manual allowlist entry is also an independent access path for a Host with Require sign-in. Do not add broad public ranges, or visitors within that range may enter protected services without completing web sign-in.
Automatic IP Authorization
Automatic post-login entries are controlled under System settings → Sessions. Authorization can Follow session, be disabled entirely, or use a fixed duration. Automatic entries improve the post-login experience but should not replace long-term access planning.
Signing out removes automatic authorization associated with that session. Manual entries are unaffected.
Automatic entries show their sign-in credential or session source, expiration, and location so that they can be compared with active sessions. Deleting an automatic entry revokes the corresponding IP allowance but does not end the browser session automatically. Delete the session as well when a complete revocation is required.
Relationship to Access Policies
| Current mapping setting | Role of the allowlist |
|---|---|
| Public access (current login-first mapping) | Authentication is not required, and the allowlist is not used |
| Require sign-in | Manual source authorization can grant access independently; automatic IP authorization normally lets the same source continue to connect but does not override a service-scope denial carried by the credential; the session is checked when no usable source authorization exists |
Host mappings imported from older versions may still carry a strict_whitelist policy. Such a mapping is not necessarily public even when Require sign-in is disabled: it accepts only valid source authorization records, whether created manually or automatically after sign-in, and a browser session cookie alone cannot replace the source condition. When automatic post-login IP authorization is enabled, a successful sign-in normally creates an automatic entry that satisfies this legacy rule. The current Host editor has no switch for creating this policy. To leave it, record the complete mapping and recreate it through the current UI. If a strict rule must permit only manual entries, disable automatic post-login IP authorization and review any automatic entries that remain valid.
Effect in Direct Mode
Native fnOS FPK and OpenWrt deployments with host-management capability can synchronize valid allowlist entries to the host firewall. Docker does not manage the host firewall, so an allowlist entry cannot be relied upon to open an original service port.
General Linux, Synology DSM 7 SPK, and Windows x86_64 also do not provide fn-knock host-firewall synchronization. Entries on the page can still participate in gateway authorization but cannot replace each platform's own firewall.
In Direct mode, access to an original port does not trigger session continuation after a public source IP changes. Return to the gateway entry point and authenticate first, then retry the original service port.
Troubleshooting
Still Cannot Connect After Adding an Entry
Confirm that the entry has not expired, the domain resolves to the current source, and fn-knock actually manages the target port. On Docker or another platform without host-firewall support, check the host firewall separately.
Domain Allowlist Address Did Not Update
Review the last check time and resolution status, then run Refresh now. Check DNS, the check interval, and the CNAME's A/AAAA results. A domain that returns only private addresses or no records will not create the expected public allowance.
Access Still Works After Deleting an Entry
Check for an overlapping CIDR, region group, another resolved domain entry, an active session, a local exemption, or a Host configured for public access.