Which fields belong in a guest Wi-Fi access record?

A record is an answer

An access record is not an end in itself. It exists to answer one question: "Who was using this address on this date at this time?" Fields should be chosen with that in mind. A missing field makes the record worthless; an unnecessary field adds personal data you then have to protect.

Below we walk through the fields a guest Wi-Fi access record needs, which question each one closes, and why the record should be produced by one device rather than three.

The minimum set

Field	Which question it closes	Note
Verification channel and value	Who joined the network?	Phone number verified by SMS, coupon code or e-mail. The number is stored encrypted and shown masked in the panel.
Device MAC address	Which device?	One person may join with several devices; the MAC keeps them apart.
Assigned internal IP	Which address did it hold?	This is the field most requests start from: an IP and a time.
Session start	When did it begin?	The moment the portal login succeeded.
Session end	When did it end?	Logout, idle timeout or session limit.
NAT mapping (where applicable)	Which address and port did the outside world see?	The outside never sees internal IPs; the public IP and port mapping joins the two sides.

What "NAT where applicable" means

Devices on the guest network use private internal addresses (10.x.x.x, for example). When they reach the internet, the box translates those addresses to one public address. That is NAT. A server on the internet sees only the public address and a port number.

If a request arrives as "a connection came from this public IP, this port, at this time", internal IP records alone cannot answer it. You need the internal IP and the public IP-port mapping on the same timeline. Because the box performs NAT itself, it can produce that mapping.

If your internet line sits behind CGNAT (common on 4.5G backup links), your public IP is actually shared by the carrier. The box still keeps its own NAT mapping; the carrier's second layer is the carrier's record. The box keeps working behind CGNAT because every connection is established from the inside out.

Why one device?

When three separate devices produce the record, consistency is lost:

• DHCP on the modem, the portal in a separate application and NAT on another firewall each use their own clock.
• If those clocks drift apart by even 30 seconds, "who held this IP" gets three different answers.
• The portal says "MAC X logged in"; DHCP says "MAC X received this IP"; with no link between the two, you join them by hand, and the result is open to challenge.

In Hotspot-Box, DHCP, NAT and the captive portal run on the same device. The box is the firewall of the guest network (pfSense based). As a result:

1. The box hands out the IP, so it knows directly which MAC received which address.
2. The portal login happens on the same device, so "which MAC logged in with which verification" is written with the same clock.
3. NAT happens on the same device, so the public IP-port mapping lands on the same timeline.

One clock, one source, one record. You do not replace your modem or access points; the box sits behind your existing equipment.

No clock, no record

Every field depends on time. The box keeps its clock in sync with NTP, watches the drift, and raises a warning in the panel when the drift grows. Daily record files are linked with a SHA-256 hash chain and receive an RFC 3161 timestamp. The timestamp lets an outside service back up the claim "this file existed by this moment and has not changed since". The box's clock is also reported against the timestamp service, so drift is visible rather than hidden.

How to read a record line

Take a fictional example. A session line in the panel says, roughly: "On 14 March at 13:42:10 the device with this MAC address logged in with this SMS-verified (masked) number; it received 10.20.0.57; at 15:02:33 the session closed because the idle timeout expired; outbound traffic used this port range on your public IP."

If a request arrives as "who had 10.20.0.57 on 14 March at 14:15", the answer is a single line. If it arrives with a public IP and port, the NAT column does the work. In both cases you answer from the same file with the same clock. You never have to lay the logs of three devices side by side and reconcile their clocks.

Fields that should not be in the record

• Visited sites and URLs
• Content, messages, files
• Location
• Full name, date of birth or anything else not needed for verification

Before adding a field, ask "which question does it close?" If there is no answer, leave it out. Every extra field is a burden and a risk under data-protection rules.

What the export looks like

When a request arrives you verify the records in the panel with one click and export them as a ZIP. The archive contains day folders, line files, a manifest with the SHA-256 chain and the RFC 3161 timestamp file. The recipient can verify the timestamp independently with standard tools (openssl ts -verify). A second copy can also be pushed off the box over SFTP/FTPS.

If you want to see the record structure with your own eyes, contact us for a 7-day trial. Product details are on the box page.

This article is for general information only and is not legal advice.