Overview
The lists below show the technical requirements before connecting an SLP to a network.
Wi-Fi Requirements
SLP can only connect to Wi-Fi channels 1 to 11.
SLP can only connect to a 2.4Ghz Network. To extend the SLP's battery endurance, 5Ghz is unsupported as it consumes much more power.
SLP supports WPA and WPA2 but doesn't support WPA3.
Wi-Fi MAC filter or any other kind of filtering should be disabled.
The signal strength should be above -70dBm for smooth communication. The locks use ultra-low-power Wi-Fi chips, which require strong signals to operate properly.
Note
You can find the MAC Address under the Wi-Fi section from the Portal Staff App > Lock Details > Wi-Fi.
For the network to not switch between 2.4 GHz and 5 GHz, the band shifting setting needs to be turned off.
Other Network Requirements
To let the SLP communicate with Portal's servers, please ensure the network configuration meets the following requirements:
Allow server access: the smart locks communicate on TCP port 4999 to sw.tryportal.com. If GokiAir gateways are present, they communicate on TCP port 2999 to sg.tryportal.com. Make sure both ports are open on the firewall, and allow by hostname rather than IP.
Confirmed configuration:
gatewayHost: 'sg.tryportal.com' gatewayPort: 2999 wifiServerHost: 'sw.tryportal.com' wifiServerPort: 4999
Access to the Internet: the smart locks should be able to access the Internet without authenticating on any authentication server.
Public and Private IP Addressing: as smart locks use private IP addresses within the local network, configure NAT to map these private addresses to a single public IP address when communicating with external servers or cloud services. The "IP Load Balancing" feature and "Asymmetric Routing" problem on firewalls are relevant to this requirement.
Address Reservation: reserve IP addresses for smart locks in the DHCP server configuration. This ensures that each smart lock receives the same IP address upon renewal.
Lease Duration: adjust DHCP lease durations to match the expected connectivity patterns of smart locks. Longer lease durations can reduce network traffic associated with frequent address renewals.
Separate Subnets: consider placing smart locks on a separate subnet using VLANs. This can help logically isolate smart lock traffic and simplify DHCP management for that specific subnet.
QoS Policies: QoS policy configuration may prevent smart lock traffic from passing through the network effectively. We advise implementing QoS policies to prioritize smart lock traffic, ensuring it receives sufficient bandwidth and low latency to operate effectively.
DoS Protection Policies: DoS protection policies could mark lock server traffic as a threat. Ensure there are no such policies interfering with lock communication.
5G is not supported — only 2.4G is supported. When the band shifts, the locks will go offline; make sure to untick that setting and review network best practices with a network engineer.
Q&A: Changing Wi-Fi/VLAN Settings for Existing Locks
Q: We're moving our lock SSID to a new VLAN/subnet but keeping the same SSID and password — will locks need re-provisioning?
No re-provisioning needed. The lock stores its server as a hostname (not an IP), so it re-resolves DNS and reconnects on its own. As a DHCP client, it re-associates and renews its lease automatically, picking up the new subnet. Most locks reconnect within minutes, but a lock only reconnects once its existing session drops, so some can take longer. If a lock is still offline well after the change, reconnect it to Wi-Fi from the Portal Staff App (lock details → Wi-Fi), or pull the battery and reinsert it — if you do a battery pull, re-sync the lock's time afterward from the Portal Staff App.
Q: What exact outbound destinations, ports, and protocols does the SmartLock Pro need for firewall rules?
TCP 4999 to sw.tryportal.com — allow by hostname, not IP.
If GokiAir gateways are present: TCP 2999 to sg.tryportal.com.
DNS (port 53) to the VLAN's resolver — the lock resolves the hostname itself.
No captive portal or authentication server on the lock VLAN — locks must reach the internet without authenticating.
NAT should egress to a single public IP — avoid load-balancing across two WANs or asymmetric routing.
Exempt the lock VLAN from DoS/IPS action and give it QoS priority rather than deprioritizing it.
There's no NTP requirement, but allowing it does no harm.
Q: Is there a recommended DHCP lease duration, and any sensitivity to lease renewal or IP changes?
Reserve an address per lock by MAC address and use a long lease. Frequent IP changes cause periodic disconnects.
Q: Do locks need to reach each other or a local hub, or is all communication northbound to the cloud? Is client isolation safe?
Client isolation is safe. All lock traffic is northbound to Portal's cloud — locks never talk to each other or to a local hub. Staff phones reach locks over Bluetooth, not IP.
Q: Any concerns with disabling Band Steering and 802.11v? What about 802.11r/802.11k?
Disabling Band Steering is required, not optional — band shifting takes locks offline. Disabling 802.11v is fine. When restoring a 1/6/11 channel plan, exclude channels 12/13 (SLP only supports channels 1–11) and set 2.4 GHz channel width to 20 MHz. Disable auto-optimize/nightly channel changes so APs don't drift back onto one channel. MAC filtering must stay off.
Q: Does the SmartLock Pro support WPA3 transition mode or PMF?
No — SLP supports WPA and WPA2 only, not WPA3. There's no support statement for PMF, so leave it off and keep the network on WPA2.
Q: Is there a recommended maximum number of locks per access point, or a minimum signal strength?
There's no published maximum locks-per-AP. Design for better than −70 dBm at each lock. Each lock's RSSI is visible in the network controller's client view and in the Portal Staff App, so weak signal locks can be identified after any network change.