Ubiquiti Networks FAQs

Overview

After reading this article users should gain the knowledge to be able to configure and maintain the IPS/IDS functionality on their UniFi networks.

UniFi - USG: Responding to a Threat Detection Alert

NOTES & REQUIREMENTS:

Applicable to the following:

UniFi Network Controller software version5.9+

UniFi Security Gateway platform firmware 4.4.18+

UniFi Dream Machine platform

The configuration in this article refers to settings found in the UniFi Network Controller's beta settings. These new settings can be enabled by clicking "Try New Settings" at the top of the "classic settings" menu list.

Table of Contents

Introduction

Network Diagram

Intrusion Detection and Prevention

Categories

Whitelisting

Signature Suppression

GeoIP Filtering

DNS Filters

Filter Levels

Deep Packet Inspection

DPI Restrictions (Layer 7 Filters)

Network Scanners

Endpoint Scanner

Internal Honeypot

Honeypot Services

Testing & Verification

Privacy Statement

Related Articles

Introduction

Back to Top

An intrusion prevention system (IPS) is an engine that identifies potentially malicious traffic based on signatures. The signatures contain known traffic patterns or instruction sequences used by malware. This type of signature-based engine can only detect anomalies based on known malicious traffic patterns.

Network Diagram

Back to Top

Intrusion Detection and Prevention

Back to Top

To enable intrusion detection or intrusion prevention, navigate to the NewSettings > Internet Securitysection of the UniFi Network controller.

ATTENTION:

Enabling IDS or IPS will affect the maximum throughput on inter-VLAN and egress traffic.

USG: 85 Mbps*

USG-Pro: 250 Mbps*

USG-XG: 1 Gbps*

Enabling Smart Queues or DPI on top of IPS/IDS will also incur a further throughput penalty to maximum throughput.

UniFi Dream Machine throughput: 850 Mbps*

*Values are rough estimates and can vary depending on configuration.

Threat Management Modes

Intrusion Detection System: When set will automatically detect, and alert, but will not block potentially malicious traffic.

Intrusion Prevention System: When set will automatically detect, alert, and block potentially malicious traffic.

Firewall Restrictions

These restrictions can be found underNewSettings > Internet Security > Advanced.

Restrict Access to ToR: When enabled will block access to The Onion Router.

Restrict Access to Malicious IP Addresses:When enabled will block access to IP addresses or blocks of addresses that have been recognized as passing malicious traffic.

System Sensitivity Levels

The "system sensitivity levels" are pre-defined levels of security categories that will be loaded into the threat management daemon. Each level increase requires more memory and CPU usage. Additionally the "custom" level is utilized when manually selection categories.

Categories

ATTENTION:

Due to the amount of available memory on the USG3 and UDM a limited selection of categories can be enabled.

Click below to see a full list of categories.

Categories and Their Definitions

Click Here to Expand the IPS/IDS Categories Section

Activex: Attacks and vulnerabilities(CVE, etc.) regarding ActiveX.

Attack Response: Responses indicative of intrusionLMHost file download, certain banners, Metasploit Meterpreter kill command detected, etc. These are designed to catch the results of a successful attack. Things like "id=root", or error messages that indicate a compromise may have happened.

Botcc (Bot Command and Control)*: These are autogenerated from several sources of known and confirmed active Botnet and other Command and Control hosts. Updated daily, primary data source is Shadowserver.org. Bot command and control block rules generated from shadowserver.org, as well as spyeyetracker, palevotracker, and zeustracker. Port grouped rules offer higher fidelity with destination port modified in rule.

CIArmy: Collective Intelligence generated IP rules for blocking based upon www.cinsscore.com.

Compromised: This is a list of known compromised hosts, confirmed and updated daily as well. This set varied from a hundred to several hundred rules depending on the data sources. This is a compilation of several private but highly reliable data sources. Warming: Snort does not handle IP matches well load-wise. If your sensor is already pushed to the limits this set will add significant load. We recommend staying with just the Botcc rules in a high load case.

DNS*: Rules for attacks and vulnerabilities regarding DNS. Also the category for abuse of the service for things such as tunneling.

DOS: Denial of Service attempt detection. Intended to catch inbound DOS activity and outbound indications.

Dshield*: IP based rules for Dshield Identified attackers. Daily updated list of the DShield top attackers list. Also very reliable. More information can be found at http://www.dshield.org.

Exploit*: Exploits that are not covered in a specific service category. Rules to detect direct exploits. Generally, if you're looking for a Windows exploit, Veritas, etc, they'll be here. Things like SQL injection and the like, while they are exploits, have their own category.

FTP: Rules for attacks, exploits, and vulnerabilities regarding FTP. Also includes basic none malicious FTP activity for logging purposes, such as login, etc.

Games: Rules for the Identification of gaming traffic and attacks against those games. World of Warcraft, Starcraft, and other popular online games have sigs here. We don't intend to label these things evil, just that they're not appropriate for all environments.

ICMP: Rules for attacks and vulnerabilities regarding ICMP. Also included are rules detecting the basic activity of the protocol for logging purposes.

IMAP: Rules for the identification, as well as attacks and vulnerabilities regarding the IMAP protocol. Also included are rules detecting the basic activity of the protocol for logging purposes.

Malware*: Malware and Spyware related, no clear criminal intent. The threshold for inclusion in this set is typically some form of tracking that stops short of obvious criminal activity. This set was originally intended to be just spyware. That's enough to several rule categories really. The line between spyware and outright malicious bad stuff has blurred too much since we originally started this set. There is more than just spyware in here, but rest assured nothing in here is something you want running on your net or PC. There are URL hooks for known update schemed, User-Agent strings of known malware, and a load of others.

Misc.: Miscellaneous rules for those rules not covered in other categories.

Mobile Malware*: Specific to mobile platforms: Malware and Spyware related, no clear criminal intent.

Netbios: Rules for the identification, as well as attacks, exploits, and vulnerabilities regarding Netbios. Also included are rules detecting the basic activity of the protocol for logging purposes.

P2P*: Rules for the identification of Peer-to-Peer traffic and attacks against. Including torrents, edonkey, Bittorrent, Gnutella, Limewire, etc. We're not labeling these things malicious, just not appropriate for all networks and environments.

POP3: Rules for the identification, as well as attacks and vulnerabilities regarding the POP3 protocol. Also included are rules detecting the basic activity of the protocol for logging purposes.

RPC: RPC related attacks, vulnerabilities, and protocol detection. Also included are rules detecting the basic activity of the protocol for logging purposes.

Scan: Things to detect reconnaissance and probing. Nessus, Nikto, portscanning, etc. Early warning stuff.

Shellcode*: Remote shellcode detection. Remote shellcode is used when an attacker wants to target a vulnerable process running on another machine on a local network or intranet. If successfully executed, the shellcode can provide the attacker access to the target machine across the network. Remote shellcodes normally use standard TCP/IP socket connections to allow the attacker access to the shell on the target machine. Such shellcode can be categorized based on how this connection is set up: if the shellcode can establish this connection, it is called a "reverse shell" or a connect-back shellcode because the shellcode connects back to the attacker's machine.

SMTP: Rules for attacks, exploits, and vulnerabilities regarding SMTP. Also included are rules detecting the basic activity of the protocol for logging purposes.

SNMP: Rules for attacks, exploits, and vulnerabilities regarding SNMP. Also included are rules detecting the basic activity of the protocol for logging purposes.

SpamHaus*:This ruleset takes a daily list of known spammers and spam networks as researched by Spamhaus.

SQL: Rules for attacks, exploits, and vulnerabilities regarding SQL. Also included are rules detecting the basic activity of the protocol for logging purposes.

TELNET: Rules for attacks and vulnerabilities regarding the TELNET service. Also included are rules detecting the basic activity of the protocol for logging purposes.

TFTP: Rules for attacks and vulnerabilities regarding the TFTP service. Also included are rules detecting the basic activity of the protocol for logging purposes.

TOR*: IP Based rules for the identification of traffic to and from TOR exit nodes.

Trojan: Malicious software that has clear criminal intent. Rules here detect malicious software that is in transit, active, infecting, attacking, updating, and whatever else we can detect on the wire. This is also a highly important ruleset to run if you have to choose.

User Agents*: User agent identification and detection.

VOIP: Rules for attacks and vulnerabilities regarding the VOIP environment. SIP, h.323, RTP, etc.

Web Client: Web client-side attacks and vulnerabilities.

Web Server: Rules for attacks and vulnerabilities against web servers.

Web Apps: Rules for very specific web applications.

WORM*: Traffic indicative of network-based worm activity

* Identifies categories that can be enabled on the USG3 and UDM (base model).

The link to the PDF where these categories are described can be found here.

NOTE:The following configuration can be found in theAdvanced tab ofInternet Security.

Whitelisting

The whitelisting function of the IPS engine allows a UniFi Administrator to create a list of trusted IP's. The traffic, depending on the direction selected, will not get blocked to or from the identified IPs.

In the screenshot below traffic to or from the subnet 100.64.0.0/16 will not be tracked by the IPS engine.

Signature Suppression

The signature suppression function of the IPS engine allows a UniFi Administrator to mute the alerting on certain signatures. This will also disable blocking on traffic matching the designated suppression rule.

Adding a signature suppression rule for all traffic will suppress the signature regardless of host IP.

Adding a signature suppression rule with packet tracking based on traffic direction and by single IP, defined UniFi Network, or subnet of choice.

GeoIP Filtering

Back to Top

NOTE:For GeoIP Filtering to work on the USG, hardware offloading must be enabled. When Threat Management is enabled (under Settings > Internet Security > Threat Management), hardware offloading is disabled. Only one of these two features can be enabled at a time on the USG.

Blocking

Blocking individual countries can be configured on the Threat Management Dashboard section of the controller. Blocking is as easy as navigating to the map, clicking on a country, and confirming by clicking "Block".

Unblocking

Unblocking a country can be by performed on the Threat Management Dashboard by navigating to the left side of the map on the Overview tab. A list of blocked countries will be populated. Simply hover over the county that is to be unblocked and an "unblock" option will appear. Select "unblock" and the country will be taken off of the list.

Traffic Direction

The UniFi Network controller allows configuring the GeoIP filtering traffic direction. Follow the steps below:

1.Navigate to the top of the Threat Management Dashboard and select the direction.

2. Select the traffic direction.

3.ClickDone.

DNS Filters

Back to Top

ATTENTION:

DNS Filtering is only available on the UniFi Dream Machine.

Clients that use VPN, DNS-over-HTTPS, or DNS-over-TLS will have non-standard DNS requests that will not be seen by the UniFi Dream Machine.

The DNS Filter feature allows administrators to select levels of filtering per-network. This ensures that any DNS requests that go out from clients on configured LANs adhere to the filtering levels.

1.To configure DNS Filters, navigate to NewSettings > Internet Security > DNS Filters.

2. Enable DNS Filtering by clicking the slider button.

3. SelectAdd Filter.

4. Choose the desired level of filtering for the LAN.

5. Select which network this filter should apply to and confirm the selection.

6. DNS filtering will be enabled at this point.

Filter Levels

Security

Blocks access to phishing, spam, malware, and malicious domains. The database of malicious domains is updated hourly. Note that it does not block adult content.

Adult

Blocks access to all adult, pornographic and explicit sites. It does not block proxy or VPNs, nor mixed-content sites. Sites like Reddit are allowed. Google and Bing are set to the "Safe Mode". Malicious and Phishing domains are blocked.

Family

Blocks access to all adult, pornographic and explicit sites. It also blocks proxy and VPN domains that are used to bypass the filters. Mixed content sites (like Reddit) are also blocked. Google, Bing, and Youtube are set to the Safe Mode. Malicious and Phishing domains are blocked.

Deep Packet Inspection

Back to Top

To configureDeep Packet Inspection (DPI) navigate to NewSettings > Internet Security > Deep Packet Inspection.

NOTE: Device fingerprinting is not available on the UniFi Security Gateway.

DPI Restrictions

ATTENTION:DPI restrictions are limited to whole-category selections on the UniFi Security Gateway. This restriction is not applicable to the UniFi Dream Machine platform.

1. ClickAdd Restriction under "Restriction definitions".

2. In the configuration side-panel select a restriction group to add the rules to.

3. Select a category to block.

4. Select an application from the category or select "All applications" to block the entire category.

5. Ensure that "Enable This Restriction" is selected.

6. Add the restriction group to a network in the "Restriction assignments" section.

NOTE:A restriction definition can be applied to many networks. A restriction definition for each network is not required.

To manage the restriction definition, hover over the definition and selection either edit or remove.

Configuring Network Scanners

Back to Top

ATTENTION:Network Scanners are only available on the UniFi Dream Machine.

Endpoint Scanner

The "endpoint scanner" feature automatically scans the clients on all LANs for the following information:

IP address

Operating system (best effort)

Open ports

NOTE:Not all clients will have open ports or return a detectible operating system.

Scan reports can be found on the Threat Management Dashboard

Internal Honeypot

The "internal honeypot" feature is a passive detection system that listens for LAN clients attempting to gain access to unauthorized services or hosts. Clients that are potentially infected with worm or exfiltration type vulnerabilities are known to scan networks, infect other hosts, and potentially snoop for information on easy-to-access servers. The honeypot will report when hosts attempt to access the honeypot. Reports can be found on the Threat Management Dashboard.

To configure the internal honeypot follow the steps below:

1. Navigate to New Settings > Internet Security > Network Scanners.

2. Enable the honeypot service by clicking the slider button.

3. Select "Add Honeypot".

4. In the popup modal select the network and Honeypot IP.

5. Select "Create".

Honeypot Services

The honeypot service listens on the following ports:

FTP - TCP Port 21

SSH - TCP Port 22

Telnet - TCP Port 23

SMTP - TCP Port 25

DNS - UDP Port 53

HTTP - TCP Port 80

POP3 - TCP Port 110

SMB - TCP Port 445

MSSQL - TCP Port 1443

Testing & Verification

Back to Top

Intrusion Detection/Prevention

Linux or macOS

Input:

curl -A "BlackSun" www.example.com

Expected controller alert result:

Threat Management Alert 1: A Network Trojan was Detected. Signature ET USER_AGENTS Suspicious User Agent (BlackSun). From: 192.168.1.172:55693, to:172.217.4.196:80, protocol: TCP

Windows

The DNS category must be enabled

Input:

nslookup blacklistthisdomain.com 8.8.8.8

Expected controller alert result:

Threat Management Alert 1: A Network Trojan was Detected. Signature ET DNS Reply Sinkhole - 106.187.96.49 blacklistthisdomain.com. From: 192.168.1.1:53, to: 192.168.1.182:61440, protocol: UDP

Internal Honeypot

A few examples of manually testing the internal honeypot service are below. The following commands may or may not prompt for login credentials. The alerts will appear in the Honeypot section of the Threat Management Dashboard a few minutes after attempting the testing.

Telnet:

telnet <honeypot_ip>

SSH:

ssh <honeypot_ip>

NOTE:Replace <honeypot_ip> with the honeypot IP configured in the controller.

Privacy Statement

What information does the IPS/IDS engine send to the cloud?

1. When a UniFi Administrator enables IPS or IDS on the controller a token is generated for the gateway. The information listed below is sent over a TLS 1.2 encrypted connection whenever there is an IPS/IDS signature match.

timestamp

interface

source IP

source port

destination IP

destination port

protocol

signature id

2. Every 120-seconds there is a keep-alive to the ips1.unifi-ai.com hostname. This connection is to ensure reliable delivery of the violation message. The keep-alive is a connection to our cloud using port 443 so it is not just an ICMP ping or DNS resolution but a complete 3-way handshake and SSL Key exchange.

What information is kept on our servers regarding IPS/IDS?

The data listed above is only temporarily stored in the IPS Cloud until the controller downloads the information. After the information is downloaded by the controller, the data is deleted from our cloud except for the attacker IP. The attacker IP information helps Ubiquiti maintain an up-to-date and effective attacker list which will improve Ubiquiti’s services to Ubiquiti customers around the world.

How is the information from alerts used by Ubiquiti?

Ubiquiti will use the alert information to improve its products and services, including generating lists of IP Reputation, Malicious IP addresses, Threat Intelligence and creating blacklists and new signatures for Ubiquiti devices. A sanitized version of IP addresses (Ex: 200.200.x.x) can also be displayed on Ubiquiti Public Threat Map to help the public community to see malicious traffic around the world.

Related Articles

Back to Top

UniFi - USG Firewall: Introduction to Firewall Rules

UniFi - Regenerating an IPS/IDS Token(Debian-based Linux/Cloud Key)

Overview

This article reviews three different scenarios forblocking LAN to VLAN2 routing, as well as some other techniques to fine-tune the interVLAN communication.

UniFi - VLAN Traffic Tagging

NOTES & REQUIREMENTS: Applies to our UniFi Security Gateway v4.3.41+. We recommend to upgrade to the newest version, downloadable here.

Table of Contents

Introduction

Option 1: Disable interVLAN routing between LAN and VLAN2

Option 2:Block all VLANs to one another

Option 3: Block LAN to VLAN2, but allow VLAN2 to LAN

Related Articles

Introduction

Back to Top

Inter-VLAN routing is enabled by default between all Corporate LAN networks. In this article, blocking LAN to VLAN2 will be demonstrated, as well as some other techniques to fine-tune your inter-VLAN communication on corporate networks.

Option 1: Disable inter-VLAN routingbetween LAN and VLAN2

Back to Top

1. To disable inter-VLAN routing between LAN and VLAN2, head to the UniFi Controller and go to Settings > Routing & Firewall > Firewall > Rules > LAN IN 1

2. Create a new rule that Drops or Rejects 2 with the configuration shown below.

Name: to your liking.

Enabled: ON

Rule Applied: before Predefined Rules

Action: Drop or Reject 2

Protocol: All

Logging: to your liking

States: all unchecked (assumes all states)

Don't match on IPsec packets

Source Type: Network

Network: LAN - NETv4 3

Destination Type: Network

Network: VLAN2 - NETv4

NOTE:

1.LAN IN is where you want to filter all of your LAN/VLAN traffic, as IN is the first point of entry to the firewall, no matter the interface. The OUT ruleset will only be used in rare special cases.

2. "Drop" will completely drop the traffic resulting in a "request timed out" message on the client;"Reject" will send back a connection refused packet to the client.

3.NETv4 includes the entire network, ADDRv4 only includes the USG's interface address for that network (ex 192.168.1.1-192.168.1.254 vs 192.168.1.1)

Option 2:Block all VLANs to oneanother

Back to Top

1. First create a firewall group containing the RFC1918 private address range 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. This is done in Settings > Routing & Firewall > Firewall > Groups > Create New Group and then click Save.See the screenshot below:

2. Still within Firewall Settings, move from the Groups tabto theRules IPv4tab, select LAN IN 1 and clickCreate New Rule, filling in the following configuration data:

CREATE NEW RULE

Name: to your liking

Enabled: ON

Rule Applied: Before redefined rules

Action: Drop or Reject 2

IPv4 Protocol: all

ADVANCED

Logging: to your liking

States: all unchecked

IPsec: Don't match on IPsec packets

SOURCE

Source Type: Address/Port Group

IPv4 Address group: RFC1918 (the name of the group created in step 1)

Port Group: Any

MAC Address: Leave blank

DESTINATION

Destination Type: Address/Port Group

IPv4 Address Group: RFC1918

Port Group: Any

Using the above rule will block all private network communication between VLANs, however, same-subnet/VLAN traffic will be allowed as expected because it will never be sent to the default gateway (USG).The data will traverse the layer 2 network and be transmitted via frames by the switches in between.

Option 3: Block LAN to VLAN2, but allow VLAN2 to LAN

Back to Top

If you the objective isto block LAN to VLAN2, but allow VLAN2 to LAN, follow Option 1 first, then proceed with creating a rule at the top (first rule) of LAN_IN like the below screenshot. Adding this rule at the top of the ruleset will allow all established and related stateful firewall traffic to be able to pass, which is basically all "reply" traffic.

Name: to your liking

Enabled: ON

Rule Applied: before Predefined Rules

Action:Accept

Protocol:Any

Logging: to your liking

States:Established and Related

Don't match on IPsec packets

Source Type: leave blank

Destination Type: leave blank

NOTE:

Whenadding new rules, take into account that theywon't take immediate effect on existing stateful connections. To solve this, perform one of the following options:

Wait for the states to fall off (close all connections and wait for the state timeout which is roughly 30 seconds)

SSH to the USG and type clear connection-tracking.This wipes the entire state table of the USG

Reboot the USG

Related Articles

Back to Top

UniFi - USW: Using VLANs with UniFi Wireless, Routing & Switching Hardware

Overview

In this article we will provide the necessary steps to recover the UFiber OLT models. This process will completely restore the device to the factory default settings and erases all custom configuration.

UFiber GPON - Getting Started

NOTES & REQUIREMENTS:

The recovery image is different than the OLT update firmware. The recovery images can be found on the UFiber Downloads page.

Devices used in this article:

UFiber OLT (UF-OLT)

UFiber OLT 4 (UF-OLT-4)

Table of Contents

Console and Management Port Settings

Connecting to Serial Console

Setting up a TFTP Server

Starting the Recovery Process

Related Articles

Console and Management Port Settings

Back to Top

In rare cases when an OLT becomes unresponsive, these instructions may be suggested by our support team to recover the OLT back to its default state. This is typically not the first step in troubleshooting issues, but rather a last resort recovery method.

The default serial port settings are listed below:

Baud rate 57600

Data bits 8

Parity NONE

Stop bits 1

Flow control NONE

Connecting to Serial Console

Back to Top

A USB-to-Serial adapter will be used to connect to the console port of the UFiber OLT.

NOTE:In order to connect to the console we will need to use the following items/programs:

RJ45 to DB9 serial console cable (rollover cable)

USB to DB9 adapter

Terminal emulation program, such as PuTTY or the macOS/Linux terminal

1. Open the terminal emulator and specify the serial COM line and the baud rate/speed.

Windows Client

Enter the following information in the PuTTY window.

macOS Client

Open Terminal Application and find the serial interface ID.

ls -ltr /dev/*usb*

The serial interface will display as tty. Example output below:

ls -ltr /dev/*usb*

crw-rw-rw- 1 root wheel 21, 3 Feb 8 15:48 /dev/cu.usbserial-AI038TPF

crw-rw-rw- 1 root wheel 21, 2 Feb 9 08:56 /dev/tty.usbserial-AI038TPF

Use thescreen command to connect to console by pasting in the path to the serial interface.

screen/dev/tty.usbserial-AI038TPF 57600

ATTENTION: Replace/dev/tty.usbserial-AI038TPF with the value given when using thels -ltr /dev/*usb* command.

2. Connect to the OLT management port with a separate Ethernet cable.

3. Assign a static IP address to your computer's network interface, for example 192.168.1.10/24.

4. Leave the console window opened and both cables plugged in while continuing on to the next section.

Setting up a TFTP Server

Back to Top

The next step is to set up a TFTP server on the workstation to allow the recovery image to be uploaded to the OLT.

1.Download the latest OLT recovery file from the UFiber Downloads page.

2. Install a TFTP server.

Windows Client

In this example we are using Tftpd32 as the TFTP server.

macOS Client

Open a new terminal window to load and start the TFTP service.

sudo launchctl load -F /System/Library/LaunchDaemons/tftp.plist

sudo launchctl start com.apple.tftpd

Change the file permissions for the TFTP folder.

sudo chmod 777 /private/tftpboot

sudo chmod 777 /private/tftpboot/*

Place the OLT recovery file in the base TFTP directory.

Starting the Recovery Process

Back to Top

CLI: Access the UFiber OLT Command Line using the console connection.

1. Connect the power cable to the OLT and boot up the device.

2. Hold down the 1 (number one)key as the OLT starts upto interrupt the boot process.

3.When holding the 1 key, the bootloader will be interrupted and bring you to a prompt similar to the one below.

Please choose the operation:

1: Load system code to SDRAM via TFTP.

2: Load system code then write to Flash via TFTP.

3: Boot system code via Flash (default).

4: Entr boot command line interface.

7: Load Boot Loader code then write to Flash via Serial.

9: Load Boot Loader code then write to Flash via TFTP.

default: 3

4. Select option 1 and enter the required IP address and filename recovery information.

Device IP This is the IP address that the OLT should use for the TFTP session.

Server IP This is the IP address of the TFTP server (computer).

Linux Kernel Filename Exact name of the OLT recovery image in the base TFTP directory.

An example output is:

1: System Load Linux to SDRAM via TFTP.

Please Input new ones /or Ctrl-C to discard

Input device IP (172.16.3.211) ==:192.168.1.20

Input server IP (172.16.3.210) ==:192.168.1.10

Input Linux Kernel filename (vme600) ==:OLT.recovery.v4.1.0.2648.191120.1333.16de5fdde.img

After completing the steps above, the#symbol will be shown many times as the file is uploaded to the device. This is the expected behavior.

NOTE:The OLT will reboot automatically after the recovery process completes. During the process the fans may spin at full speed.

5. A successful recovery will allow management access via the web UI or CLI using the DHCP assigned IP address or the fallback address ( 192.168.1.20 ) on the management port.

Related Articles

Back to Top

Overview

Readers will learn how to configure an EdgeRouter as an OpenVPN server.

Intro to Networking - How to Establish a Connection Using SSH

NOTES & REQUIREMENTS:

Applicable to the latest EdgeOS firmware on all EdgeRouter models. Knowledge of the Command Line Interface (CLI) and basic networking knowledge is required. Please see the Related Articles below for more information.

Devices used in this article:

EdgeRouter-4 (ER-4)

Table of Contents

Configuring the OpenVPN Server

Setting up the OpenVPN Client

Related Articles

Configuring the OpenVPN Server

Back to Top

The EdgeRouter OpenVPN server provides access to the LAN (192.168.1.0/24) for authenticated OpenVPN clients.

CLI: Access the Command Line Interface. You can do this using the CLI button in the Web UI or by using a program such as PuTTY.

1. Make sure that the date/time is set correctly on the EdgeRouter.

show date

Mon Jan 21 12:13:07 UTC 2019

2. Log in as the root user.

sudo su

3. Generate a Diffie-Hellman (DH) key file and place it in the /config/auth directory.

openssl dhparam -out /config/auth/dh.pem -2 2048

NOTE: It is possible to use key sizes higher than 2048.

4. Change the current directory.

cd /usr/lib/ssl/misc

5. Generate a root certificate (replace <secret> with your desired passphrase).

ATTENTION: On older firmware versions (pre v2.0.0) the script is namedCA.sh.

./CA.pl -newca

PEM Passphrase: <secret>

Country Name: US

State Or Province Name: New York

Locality Name: New York

Organization Name: Ubiquiti

Organizational Unit Name: Support

Common Name: root

Email Address: [email protected]

NOTE:Replace the location and organizational fields with your own information.

6. Copy the newly created certificate + key to the /config/authdirectory.

cp demoCA/cacert.pem /config/auth

cp demoCA/private/cakey.pem /config/auth

7. Generate the server certificate.

./CA.pl -newreq

Country Name: US

State Or Province Name: New York

Locality Name: New York

Organization Name: Ubiquiti

Organizational Unit Name: Support

Common Name: server

Email Address: [email protected]

8. Sign the server certificate.

./CA.pl -sign

Certificate Details:

Validity

Not Before: Jan 21 13:02:57 2019 GMT

Not After : Jan 21 13:02:57 2020 GMT

Subject:

countryName = US

stateOrProvinceName = New York

localityName = New York

organizationName = Ubiquiti

organizationalUnitName = Support

commonName = server

emailAddress = [email protected]

Certificate is to be certified until Jan 21 13:02:57 2020 GMT (365 days)

Sign the certificate? [y/n]: y

1 out of 1 certificate requests certified, commit? [y/n] y

9. Move and rename the server certificate and key files to the /config/authdirectory.

mv newcert.pem /config/auth/server.pem

mv newkey.pem /config/auth/server.key

10. Generate, sign and move the certificate and key files for the first OpenVPN client.

./CA.pl -newreq

Common Name: client1

./CA.pl -sign

Certificate Details:

Validity

Not Before: Jan 21 13:05:03 2019 GMT

Not After : Jan 21 13:05:03 2020 GMT

Subject:

countryName = US

stateOrProvinceName = New York

localityName = New York

organizationName = Ubiquiti

organizationalUnitName = Support

commonName = client1

emailAddress = [email protected]

Certificate is to be certified until Jan 21 13:05:03 2020 GMT (365 days)

Sign the certificate? [y/n]: y

1 out of 1 certificate requests certified, commit? [y/n] y

mv newcert.pem /config/auth/client1.pem

mv newkey.pem /config/auth/client1.key

11. Repeat the process for the second OpenVPN client.

./CA.pl -newreq

Common Name: client2

./CA.pl -sign

mv newcert.pem /config/auth/client2.pem

mv newkey.pem /config/auth/client2.key

12. Remove the password from the server key file and optionally the client key file(s).

openssl rsa -in /config/auth/server.key -out /config/auth/server-no-pass.key

openssl rsa -in /config/auth/client1.key -out /config/auth/client1-no-pass.key

openssl rsa -in /config/auth/client2.key -out /config/auth/client2-no-pass.key

NOTE:When connecting, the OpenVPN clients will need to enter a password if this step is skipped.

13. Overwrite the existing keys with the no-pass versions.

mv /config/auth/server-no-pass.key /config/auth/server.key

mv /config/auth/client1-no-pass.key /config/auth/client1.key

mv /config/auth/client2-no-pass.key /config/auth/client2.key

14. Add read permission for non-root users to the client key files.

chmod 644 /config/auth/client1.key

chmod 644 /config/auth/client2.key

15. Verify the contents of the/config/auth directory.

ls -l /config/auth

-rw-r--r-- 1 root vyattacf 4477 Jan 21 13:02 cacert.pem

-rw------- 1 root vyattacf 1854 Jan 21 13:02 cakey.pem

-rw-r--r-- 1 root vyattacf 1675 Jan 21 13:06 client1.key

-rw-r--r-- 1 root root 4647 Jan 21 13:05 client1.pem

-rw-r--r-- 1 root vyattacf 1675 Jan 21 13:24 client2.key

-rw-r--r-- 1 root vyattacf 4647 Jan 21 13:24 client2.pem

-rw-r--r-- 1 root vyattacf 424 Jan 21 12:44 dh.pem

-rw------- 1 root vyattacf 1679 Jan 21 13:06 server.key

-rw-r--r-- 1 root root 4642 Jan 21 13:02 server.pem

16. Return to operational mode.

exit

17. Enter configuration mode.

configure

18. Add a firewall rule for the OpenVPN traffic to the WAN_LOCALfirewall policy.

set firewall name WAN_LOCAL rule 30 action accept

set firewall name WAN_LOCAL rule 30 description openvpn

set firewall name WAN_LOCAL rule 30 destination port 1194

set firewall name WAN_LOCAL rule 30 protocol udp

19. Configure the OpenVPN virtual tunnel interface.

set interfaces openvpn vtun0 mode server

set interfaces openvpn vtun0 server subnet 172.16.1.0/24

set interfaces openvpn vtun0 server push-route 192.168.1.0/24

set interfaces openvpn vtun0 server name-server 192.168.1.1

20. Link the server certificate/keys and DH key to the virtual tunnel interface.

set interfaces openvpn vtun0 tls ca-cert-file /config/auth/cacert.pem

set interfaces openvpn vtun0 tls cert-file /config/auth/server.pem

set interfaces openvpn vtun0 tls key-file /config/auth/server.key

set interfaces openvpn vtun0 tls dh-file /config/auth/dh.pem

21.Add the virtual tunnel interface to the DNS forwarding interface list.

set service dns forwarding listen-on vtun0

22. Commit the changes and save the configuration.

commit ; save

Setting up the OpenVPN Client

Back to Top

Windows Client

In this section, we are using a Windows 10 machine as the OpenVPN client.

1. Navigate to the OpenVPN config folder.

C:\Program Files\OpenVPN\config\

2. Create a new folder (optional) and an OpenVPN configuration file (er.ovpn).

3. Transfer the certificates and client key files from the EdgeRouter /config/auth directory to the OpenVPN client.

NOTE:In this example, WinSCP is used to transfer the files.

3. Add the following information to the er.ovpn configuration file (replace<server>with the EdgeRouter's external IP address or hostname).

client

dev tun

proto udp

remote <server> 1194

float

resolv-retry infinite

nobind

persist-key

persist-tun

verb 3

ca cacert.pem

cert client1.pem

key client1.key

4.To send all traffic through the VPN connection, append theer.ovpn configuration file with the following line.

redirect-gateway def1

5. Connect to the server.

macOS Client

In this section, we are using an Apple macOS computer as the OpenVPN client.

1. Open the macOSTerminal and create an OpenVPN directory and configuration file.

mkdir ~/Desktop/config

touch ~/Desktop/config/er.ovpn

2. From the macOSTerminal, transfer the certificates and client key files from the EdgeRouter /config/auth directory to the newly created directory on the client (replace username@<ip-address>with the username and IP address of the EdgeRouter).

scp username@<ip-address>:/config/auth/cacert.pem ~/Desktop/config

scp username@<ip-address>:/config/auth/client1.pem ~/Desktop/config

scp username@<ip-address>:/config/auth/client1.key ~/Desktop/config

3. Add the following information to the er.ovpn configuration file (replace<server>with the EdgeRouter's external IP address or hostname).

client

dev tun

proto udp

remote <server> 1194

float

resolv-retry infinite

nobind

persist-key

persist-tun

verb 3

ca cacert.pem

cert client1.pem

key client1.key

4.To send all traffic through the VPN connection, append theer.ovpn configuration file with the following line.

redirect-gateway def1

5. Connect using your favorite OpenVPN client management software (for example Tunnelblick ).

Related Articles

Back to Top

EdgeRouter - OpenVPN Site-to-Site

EdgeRouter - OpenVPN Layer 2 Tunnel

EdgeRouter - L2TP IPsec VPN Server

Overview

This articledescribes how to access the emergencyrecovery user interface (UI) and recover a UniFi Cloud Key or a UniFi Cloud Key Gen 2 (UCK-G2-PLUS and UCK-G2 models). From this recovery UI you can reset it to factory defaults, reboot it, power it off and upgrade the firmware.

UniFi - How to Change the Cloud Key's Controller Version via SSH

NOTES & REQUIREMENTS:

To upgrade the firmware, you will need to download a firmware binary for the Cloud Key found in our Downloads page. Use the left hand menu to select the correct Cloud Key model and find the newest firmware available.

To access this interface you will need to know the IP address of the Cloud Key (visible in the device screen).

Table of Contents

Cloud Key Gen 2 Emergency Recovery

Cloud Key Gen 1 Emergency Recover

Related Articles

Cloud Key Gen 2 Emergency Recover

Back to Top

For second generation Cloud Keys (UCK-G2 and UCK-G2-PLUS) follow these steps to access the Emergency Recovery UI:

Power off the system.

Press and hold the reset button and then power on the Cloud Key by connecting it to the power source.

Cloudkey G2:

CloudKey G2 Plus

Keep the reset button pressed for about 10 seconds, or until yousee the recovery LED pattern in a loop (blue - off - white). The LCD screen on the front panel will also read "RECOVERY MODE."

Once the LED is flashing in the recovery mode pattern, open your browser and type the IP address for the Cloud Key, visible on the device's screen. The IP address comes from your DHCP server, if you can't access DHCP, the fallback IP will work: 192.168.1.30. However, keep in mind that if your Cloud Key does have a IP address assigned by the DHCP server, the fallback IP will not work.

You should be taken to the Recovery Mode screen. From here you can reset, reboot, power off and most importantly you can upload an updated firmware bin file.

To update the firmware, go to the Downloads page, find the correct Cloud Key model on the left hand menu and then click on the download button, read and accept information, and then download the firmware file to your computer to upload in the Recovery Mode UI. Once it is uploaded you will have to reboot the Cloud Key to complete the firmware upgrade.

The LED will flash white while upgrading and then a steady white when it is ready.

Cloud Key Gen 1 Emergency Recovery

Back to Top

For first generation Cloud Keys follow these steps to access the Emergency Recovery UI:

Power off the system.

Press and hold the reset button and then power on the Cloud Key by connecting it to the power source.

Keep the reset button pressed for about 10 seconds, or until yousee the recovery LED pattern in a loop (blue - off - white).

Once the LED is flashing in the recovery mode pattern, open your browser and type the IP address for the Cloud Key. The IP address comes from your DHCP server, if you can't access DHCP, the fallback IP will work: 192.168.1.30. However, keep in mind that if your Cloud Key does have a IP address assigned by the DHCP server, the fallback IP will not work. If you are using a Gen 2 Cloud Key you will see its IP address on the device screen.

User Tip: If you don't know your Cloud Key's IP address, you can use thearp -a SSH command or software such as nmap to find the IP address.

You should be taken to the Recovery Mode screen. From here you can reset, reboot, power off and most importantly you can upload an updated firmware bin file.

To update the firmware, go to the Downloads page, find the correct Cloud Key model on the left hand menu and then click on the download button, read and accept information, and then download the firmware file to your computer to upload in the Recovery Mode UI. Once it is uploaded you will have to reboot the Cloud Key to complete the firmware upgrade.

Once it is uploaded you will have to reboot the Cloud Key to complete the firmware upgrade.

The LED will flash white while upgrading and then a steady white when it is ready.

Related Articles

Back to Top

UniFi - How to Create and Restore a Backup

Overview

This article will explain how to troubleshoot, resolve and prevent Cloud Key failures and stability issues.

UniFi - Supported PoE Protocols

NOTES & REQUIREMENTS:

This article applies to the UniFi Cloud Key,which should be updated to the latest stable firmware/controller version before troubleshooting further.

For best results, we recommend using the UniFi Cloud Key Gen2/UniFi Cloud Key Gen2+ which offers greater stability and performance over the UniFi Cloud Key.

Table of Contents

Introduction

Symptoms

Resolution

Reboot

Reset Cloud Key

Restore from Working Backup

Potential Causes & Prevention

Power Outages/Interruptions

Disk Space

Maximum Database Size Limit

Related Articles

Introduction

Back to Top

The UniFi Cloud Key offers perhaps the most convenient and simple UniFi management method available. Setup is easy and doesn’t require a desktop/server on-site to be running at all times to keep online. The Cloud Key still requires some maintenance and use of best practices to ensure proper function. This article will explain how to fix Cloud Key stability issues, troubleshoot and resolve root causes when repeated issues are seen.

Symptoms

Back to Top

All of the following symptoms can indicate stability issues with your Cloud Key:

Flashing white LED indicating the UniFi Cloud Key is disconnected.

Cloud Key may show as offline in UniFi Management Dashboard (https://unifi.ubnt.com)

Cloud Key UI may not be accessible via direct URL through browser

i.e. https://[cloudkeyip]:8443/manage/

UniFi service shows as not running through Web UI (https://, Select option Configure > Maintenance > Service > Stop UniFi will be grayed out indicating it is already offline)

UniFi Service will not start by clicking the button "Start UniFi".

Resolution

Back to Top

1. Reboot

As a first step, some Cloud Key issues can be resolved with a simple reboot. If you have not done this, do so now. This can be done by following these steps:

Open the Cloud Key management portal in a browser by typing the IP address of the Cloud Key as URL: i.e. https://192.168.1.15

You may receive a Privacy Error. Click continue.

In Chrome, click Advanced > "Proceed to [IP of Cloud Key](unsafe)"

Click Configure

Log in with UniFi Cloud Key credentials used at setup. See our Related Articles below for credential questions.

Select theMaintenancetab.

Under Maintenance > Actions, click the button to Reboot.

If this does not resolve the issue, then proceed to the next paragraph.

2. Reset Cloud Key

Nearly every UniFi Cloud Key failure, can be quickly resolved by a simple Reset and Restore of a backup file. The Cloud Key has made it easy to maintain backups in case of any failures. Auto Backup, if enabled, will create periodic snapshots that can be restored to in the case of any failures.

These are stored on the SD card and even if the Cloud Key is unable to be accessed manually, a reset of the device will permit a restore of the Auto Backup files on the SD card. Auto Backup is configured in the UniFi Controller underSettings > Auto Backup.

To ensure that you have enough intermittent backups should anything happen, it's recommended to have automated Weekly backups.

Steps: How to Reset your Cloud Key

ATTENTION:Prior to resetting your Cloud Key make sure you have backups available to restore from. To be safe, make sure to download from Cloud Key either through UI or via SSH prior to Resetting. Resetting the Cloud Key will lose all configuration. If no backup file is available, all settings will need to be reconfigured.

Reset Method 1: WebUI

Open the Cloud Key management portal in the browser by typing the IP address of the Cloud Key as a URL: i.e. https://192.168.1.15.

You may receive a Privacy Error, in Chrome, click Advanced > Proceed to [IP of Cloud Key](unsafe).

Click Configure.

Log in with UniFi Cloud Key credentials used at setup.See our Related Articles below for credential questions.

Select theMaintenancetab.

Click Reset to Defaults.

If access to the Cloud Key's management portal is not possible, use one of the following alternatives:

Reset Method 2: Hardware Button

The reset button is at one end of the Cloud Key. See each model's Quick Start Guide for exact location.

Insert a paper clip or similar object into the small hole until the button depresses.

Hold for five seconds, then release.

The LEDs should indicate the Cloud Key is restarting and being reset to default state.

Once completed, the Cloud Key should show a steady white LED if this was done properly.

Reset Method 3: SSH

Use an SSH client like Putty (Windows) or Terminal (macOS).

Connect to the IP address of the Cloud Key.

Authenticate using SSH credentials as previously configured. See this article for help on Cloud Key password disambiguation.

Once you log in successfully, enter the following command then hit enter:

ubnt-systool reset2defaults

The Cloud Key will then reset to default.

How to Restore from Last Working Backup

Once your reset has completed successfully your Cloud Key should be in a factory default state- which will eliminate any database corruption/corrupted configuration of the Cloud Key. Now you are ready to restore from your last known working backup. Here are directions on how to do this:

Restore Method 1: Via UniFi Setup Wizard

Open the Cloud Key management portal in the browser by typing the IP address of the Cloud Key as a URL: i.e. https://192.168.1.15.

You may receive a Privacy Error, in Chrome, click Advanced > Proceed to [IP of Cloud Key](unsafe).

Select Manage.

The UniFi Setup Wizard will present existing Auto Backup files stored on the SD card.

Select which backup to restore and click Restore.

Restore Method 2: Via WebUI

Open the Cloud Key management portal in the browser by typing the IP address of the Cloud Key as a URL: i.e. https://192.168.1.15.

You may receive a Privacy Error, in Chrome, click Advanced > Proceed to [IP of Cloud Key](unsafe).

Click Configure.

Login with default UniFi credentials:

Username: ubnt

Password: ubnt

Go to the Maintenance tab.

Click the Stop UniFibutton, once the Start UniFi buttonbecomes highlighted (appears clickable), proceed to the next step.

Under Auto Backupselect the most recent working backup file and click Restore.

If restoring from a local file, click Choose File.

Potential Causes and Prevention

Back to Top

Since Cloud Key gen1 was released, a number of features have been added and improved via firmware to improve stability and prevent common issues. Because of this, it is always recommended that you upgrade your Cloud Key firmware to the most recent stable version, especially if you repeatedly encounter any stability issues.

If Cloud Key stability issues are not resolved with a reset/restore, or repeatedly come back, it is particularly important to identify and resolve the root cause. The majority of such reported issues are found to be a result of one of the following causes:

Cause 1: Power Outages/Interruptions

User Tip:This cause is associated with Cloud Key Gen1. The Gen2 model has a "graceful shutdown" feature that should prevent sudden power interruptions.

The Cloud Key stores data and UniFi controller configuration in a MongoDB database. Even in small environments, there are ongoing database functions being performed at any given moment. If these database operations are interrupted as a result of a sudden power interruption, this can cause database corruptions which will ultimately hinder the proper function of the Cloud Key. In some cases, after a power outage, the Cloud Key may be unable to start the UniFi service properly due to database errors resulting from the interruption.

If you find your Cloud Key is losing power frequently despite no power loss, you may also have a bad Ethernet Cable being used to power the device via PoE- replace the cable to resolve this.

Symptoms

Stability issues arise after a known power outage/interrupted power.

Persistent Cloud Key stability issues; testing with different ethernet cable fails to reproduce.

How to Prevent

Power the UniFi Switch or other PoE supplying device up to a power source with battery backup to ensure that power remains uninterrupted in short power outages.

Plug a small charged battery like those used for charging mobile phones into the Cloud Key via the micro USB port- this will prevent the Cloud Key from being shut off in a power outage from interrupted PoE.

Replace faulty Ethernet cable with new cable if the Cloud Key loses power in cases where there is no power outage.

Shutdown/Reboot Cloud Key gracefully using the button in UI rather than unplugging/plugging back in.

Cause 2: Disk Space

The Cloud Key was built for compact form, ease of install and affordability. With this comes less disk storage than you’d find on a server that would otherwise be running the UniFi Controller substance. In most environments, this will not become an issue and requires little consideration. However, in larger environments or configurations that have opted to retain more detailed data and a larger number of backups, disk space can become an issue. For this reason, it is good to monitor the disk usage on the Cloud Key regularly just to ensure that the disk space isn’t over-utilized.

Symptoms

Storage Space Shows as close to 100\% utilized

Cloud Key will shut down the controller service without warning as disk space is exhausted/MongoDB is unable to write to the database further

How to Prevent

Periodically check the Cloud Key disk utilization through the WebUI > Configure > Main.

Limit the number of backups stored on the Cloud Key. If longer retention of backups/data is needed, download these files then remove from Cloud Key storage.

Decrease the length of data retention in the UniFi Controller under Settings > Maintenance > Data Retention.

Perform regular compacts on Database under Settings > Maintenance > Compact Database.

Remove excessive backups under Settings > Auto Backup

Cause 3: Maximum Database Limit

All UniFi controllers operate with the use of a MongoDB database. What’s unique about the Cloud Key over most other controllers is that it has an ARMv7 32-bit CPU, and as such can only run 32-bit MongoDB. 32-bit MongoDB instances have a limitation over 64-bit mongo instances in that they can only support database sizes of approximately 2GB. See more info here.

As complexity and scale of the UniFi management increases, the database will grow in size. As the Cloud Key is geared towards smaller sites and portability/compactness, in most cases this will not ever be anything to worry about. However, given the 32-bit limit on size on the Cloud Key, if used in the largest environments (more than a couple dozen APs/UniFi devices), this limit will quickly be reached and prevent healthy function.

If you are unsure of whether your controller should be using a Cloud Key or not, review the following guidelines: UniFi - Cloud Key's Device Management Limit

Symptoms

server.log indicates error identical or similar to the following:

<inform_stat-10> ERROR dev - Error in DeviceManager.processStat() com.mongodb.WriteConcernException: { "serverUsed" : "127.0.0.1:27117", "err" : "can't map file memory - mongo requires 64 bit build for larger datasets"`

The database is close to 2 GB in size

Restoring from a backup may work until the limit is reached again.

How to Prevent

Make sure your UniFi Deployment is not too large for the UniFi Cloud Key to handle. See here.

If thescale of the UniFi deployment on Cloud Key is growing too large, consider migrating to a software install of the UniFi Controller software on a server with a 64-bit OS.

Verify the size of your backups is not approaching the 2GB limit under Settings > Auto Backup.

Reduce Data Retention Settings, then Compact Database under Settings > Maintenance > Compact Database.

Other Causes

If you encounter an issue not covered by one of the above scenarios, get help on our Community. This article will continue to grow thanks to user feedback.

However, if you still don't find a solution you may be dealing with hardware issues. These are very rare but can be encountered. In such cases, usually, the Cloud Key will fail to power on or the SD card will not permit additional data to be written to the Cloud Key. If the issue is apparently a hardware issue and your device is under warranty, fill out the RMA form to arrange a replacement: https://www.ubnt.com/support/rma/

Related Articles

Back to Top

UniFi - Accounts and Passwords for Controller, Cloud Key and Other Devices

UniFi SDN - Repairing Database Issues on the UniFi Controller

UniFi - How to Manage & Upgrade your Cloud Key

UniFi - How to Manually Change the Cloud Key's Controller Version via SSH

Overview

This article describes the different sets of credentials UniFi uses, along with information on where each would have been set up initially and where they can be changed, if applicable. It is important to note that both passwords and usernames are case sensitive.

Table of Contents

UniFi Device Authentication Password

UniFi Network Controller Password

Cloud Key SSH

Ubiquiti SSO Cloud Credentials: UI Community, UI Store and UniFi Cloud Access Portal

Other Credentials

Related Articles

UniFi Device Authentication Password

Back to Top

The Device Authentication credentials are used in thedevice management user interfaces (UI). For example, when locally accessing a UniFi Security Gateway (USG) by typing 192.168.1.1 in the browser. They're also used when adopting a "managed by other" device. See this article for more: UniFi - Advanced Adoption of a "Managed By Other" Device.

UniFi - How To Use a Free Email Service as SMTP Server (Gmail)

To see what this password is, and to change it:

1. Launch the UniFi Network Controller and go toSettings > Site and enable Advanced Features. Save changes and refresh the screen.

2. Now you should see aDevice Authenticationsection underSettings > Site. Note that if you had previously enabled SSH Authentication and then disabled Advanced Features, this section would be visible without requiring Advanced Features to be enabled in step 1.

3. Check the box to Enable SSH authentication and set a Username and Password. Or click the eye to see what your Username and Password currently is if the password is already created.

If these have never been set by an admin, there are two possible combinations of default credentials for UniFi devices: ubnt / ubnt orroot / ubnt. However, if you went through the Setup Wizard, it would have required you toassign a new password and username in the Controller Access screen, under Device Authentication. The default credentials of ubnt/ubnt or root/ubnt will be useful when factory resetting a device and managing it in an already installed Controller (hence, forgoing the Setup Wizard).

NOTE: The default ubnt/ubnt username and password also applies to the Cloud Key (and SSH access to the Cloud Key)when accessing the Configuration UI of a new or factory-defaulted Cloud Key by typing its IP address in the browser (default is 192.168.1.30), instead of going through the Setup Wizard. Other than that specific moment, the Cloud Key and SSH password is not the same as the Device Authentication credentials. See the SSH and Cloud Key credentials section for details.

UniFi Network Controller Password

Back to Top

These credentials allow you to log in to the UniFi Network Controller, either accessing it directly by typing the IP address on your browser, or by going to the UniFi Cloud Access Portal and launching the Controller from there. You created these credentials in the Controller Access screen of the Setup Wizard. You have the option to use your SSO Cloud Account credentials for the Controller as well. See the SSO Cloud Credentials section for more information.

How to Change the Controller Admin Name and Password

If you have access to the Controller, you can change your Controller Admin Name and Password at any moment.

1. Within the Controller, click on your username in the upper, right-hand corner.

2. Select Edit account.

3. Here you can change the password, the Admin Name and the Admin email. It is important to note that when you are resetting your password, this is the only email you will be able to send a "reset password" email to, regardless of what email you are using as a SMTP server.

How to Reset the Controller Password

If you forgot the password of the UniFi Network Controller, you can click on theFORGOT PASSWORD?link under the controller login screen and enter the email you have associated with your Controller (as it appears in the Controller'sEdit account section). You will have to click the link in the email to properly reset your password. Until then your current password is still valid.

The password reset email is sent by SMTP server. If you have not enabled the SMTP server and configured it correctly, this option will not work even when appearing to successfully send the reset email. If the SMTP server has not been set up, but you have Cloud Access enabled, you can log in to unifi.ui.com and try to launch your controller using the Cloud, by clicking on the name of the controller and then selecting "Launch Using Cloud" from the drop down that appears in the Site Overview of the controller Details panel that pops out. If you can successfully launch the controller, then you will be able to set up SMTP under Settings > Controllerand then request a password reset with the Forgot Passwordlink afterlocally accessing the controller.

See this article on how to set up a SMTP server with Gmail: UniFi - How To Use a Free Email Service as SMTP Server (Gmail). You can also read the SMTP section in the UniFi User Guide, Chapter 3 (page 57).

If neither of these have been enabled, there is no method to recover the Controller password: it will have to be reinstalled. See this article on how to uninstall the Controller and reinstall by following the Quick Start Guide or User Guide downloadable in the Downloads page (select product on the left hand menu and scroll down to the documentation section).

Cloud Key SSH

Back to Top cloud key password

NOTE: The default device username and password described in the first section also applies to the Cloud Key (and SSH access to the Cloud Key)when accessing the Configuration UI of a new or factory-defaulted Cloud Key.For Cloud Keys that have already been set up, read the following section.

The Cloud Key's SSH credentials are the same as the one's used to enter the Cloud Key's configuration interface, accessed when typing the Cloud Key's IP address in the browser navigation bar. The Setup Wizard gives users the choice to use the same Controller administrator name and password for SSH access. However, if a user decides to leave that box unchecked, they will have to provide another set of credentials in the Wizard's Controller Access screen for SSH and Cloud Key access.

In other words: if the option to "Use the same name and password for SSH access to your Cloud Key" is checked, then the Cloud Key and the SSH credentials will be the same as the Controller's, unless you change them later on. To change them you would:

1. Go to the Cloud Key's configuration UI by typing the Cloud Key's IP address in your browser.

2. Select the Manage Cloud Keyoption and sign in.

3. Click on the username on the upper right hand corner and select change username or change password as applies to your needs. For Gen 1 Cloud Keys these settings are found underMaintenance > Security.

ATTENTION:There is no Cloud Key / SSH credential recovery, so if that password is lost, reset the device to factory defaults by pressing and holding the Cloud Key's reset button for more than 5 seconds. Once you launch the Setup Wizard for your freshly reset Cloud Key, you can restore from one of your backups. The backup will not restore the forgotten credentials, so you will be able to set new ones without any issues and without losing your other settings, as long as you do know your UniFi Network Controller username and password.

Ubiquiti SSO Cloud Credentials

Back to Top

The Ubiquiti Cloud username and password are your Single Sign-On, UI.com account credentials created in https://account.ui.com/. This set of credentials is used in the UI Community, the UI Store, and the UniFi Cloud Access Portal. To change this username and password go to https://account.ui.com. This is also where you would enable (or disable) your 2FA verification. See this article for more: How to Enable Two Factor Authentication.

How to create an account:

Click to Expand

Visit: https://account.ui.com

Under the Sign In button, click on Not a Member?Create account.

Fill in the required information.

First name - First name of the user account owner.

Last name - Lastname of the user account owner.

Username - Public display name for the account. Used for sign in on required Ubiquiti websites.

Email- Email address to receive notification emails. Can also be used for sign in. Will be used by Ubiquiti Support to contact you if necessary.

Password - This password can be any combination of characters as long as it meets the minimum of 8 characters in length.

Agree to the terms and policies, decide if you wish to receive periodic newsletters and updates and clickRegister.

After the account has been registered, check the email inbox for a verification email to make sure that the proper email account was used for the account.

User Tip:If you wish to use your SSO Cloud credentials for your Controller and have one less set of credentials to worry about, you can set this up by logging into your Controller and going to Settings > Remote Access and enabling the Enable Local Login with Ubiquiti Account. Please make sure to read the tooltip in the Controller before enabling.

Other Credentials

Back to Top

Ubiquiti Support and Help Center Credentials

The Ubiquiti Help Center ( https://help.ubnt.com/) uses a different set of credentials than the Community. If you have ever opened a ticket with Ubiquiti support you are already registered but do not have a password. In other words, Support will group tickets according to requester email. If you contact Support they can provide you with the reset password to finish the registering process.

NOTE:It is recommended to use Chrome as your browser.

1. Go to the Help Center and click on the Sign In link in the upper, right-hand corner.

2. In the bottom left of the dialog box that appears, click the Sign UporGet a password link. Fill in the information requested.The Get a password link is also the way to reset a password if it has been forgotten. With your Help Center account you can see your support tickets underMy Activities > Requests and you can also give a thumbs-up or down to the articles. Please remember to click the Send Feedback button and let us know what is missing in our articles!

Wireless Network SSID Password

This is not a common password to get confused, but it is listed in this article since it is also created during the Setup Wizard in theConfigure WiFi screen. You can change this SSID name and password, referred to as Security Key in the UniFi Network ControllerSettings > Wireless Networks > Edit.

Related Articles

Back to Top

UniFi - Advanced Adoption of a "Managed By Other" Device

Overview

Readers will learn how to configureVRRP(Virtual Router Redundancy Protocol) on an EdgeRouter.

Intro to Networking - How to Establish a Connection Using SSH

NOTES & REQUIREMENTS:

Applicable to the latest EdgeOS firmware on all EdgeRouter models. Please see the Related Articles below for more information.

Device used in this article:

EdgeRouter-4 (ER-4)

Table of Contents

Basic VRRP Configuration

Optional VRRP Additions

Related Articles

Basic VRRP Configuration

Back to Top

The VRRP Virtual IP address (VIP) that is shared between the routers is 10.0.0.254/24.

Follow the steps below to configure the VRRP functionality on ER-1:

CLI: Access the Command Line Interface on ER-1.You can do this using the CLI button in the GUI or by using a program such as PuTTY.

1. Enter configuration mode.

configure

2. Define the VRRP group and the virtual IP address.

set interfaces ethernet eth1 vrrp vrrp-group 10 virtual-address 10.0.0.254/24

3. Set the VRRP priority to ensure that ER-1 becomes the master (active) router.

set interfaces ethernet eth1 vrrp vrrp-group 10 priority 200

NOTE: A higher number equals a higher priority.

4. Commit the changes and save the configuration.

commit ; save

Repeat the the VRRP configuration steps on ER-2:

CLI: Access the Command Line Interface on ER-2.You can do this using the CLI button in the GUI or by using a program such as PuTTY.

1. Enter configuration mode.

configure

2. Define the VRRP group and the virtual IP address.

set interfaces ethernet eth1 vrrp vrrp-group 10 virtual-address 10.0.0.254/24

3. Set the VRRP priority to ensure that ER-2 becomes the backup (passive) router.

set interfaces ethernet eth1 vrrp vrrp-group 10 priority 100

4. Commit the changes and save the configuration.

commit ; save

You can verify the VRRP configuration with the following operational mode commands:

show vrrp

show vrrp summary

Optional VRRP Additions

Back to Top

In addition to setting the priority, VRRP supports the following optional additions:

Authentication

Preemption

Transition Scripts

Sync Groups

The VRRP authentication feature will protect the VRRP hello messages with a plain-text password or AH (Authentication Header) encryption. To enable authentication, run the following commands:

configure

set interfaces ethernet eth1 vrrp vrrp-group 10 authentication type < ah | plaintext-password >

set interfaces ethernet eth1 vrrp vrrp-group 10 authentication password < password >

commit ; save

The VRRP preemption feature determines whether the VRRP backup router can preempt the master router and is enabled by default. VRRP preemption is enabled by default. To modify the preemption, run the following commands:

configure

set interfaces ethernet eth1 vrrp vrrp-group preempt < true | false >

commit ; save

Sync groups are used to link VRRP groups together in order to propagate transition changes from one group to another group.To configure a VRRP sync group, run the following commands:

configure

set interfaces ethernet eth1 vrrp vrrp-group 10 sync-group < group-name >

set interfaces ethernet eth2 vrrp vrrp-group 20 sync-group < group-name >

commit ; save

NOTE: VRRP groups in a sync group should have similar configurations in terms of priority and preemption. Before enabling a sync-group you should verify that one router is master of both groups and the other is backup of both groups. If both side think they are master of the same group, then enabling a sync group can cause endless transitioning to get in sync.

Transition scripts are used to run a script whenever the state of the VRRP router changes. The available state changes are:

master Run a script when the EdgeRouter transitions to the VRRP master router.

backupRun a script when the EdgeRouter transitions to the VRRP backup router.

faultRun a script when the underlying Ethernet interface goes down.

To add a custom transition script to VRRP, run the following commands:

configure

set interfaces ethernet eth1 vrrp vrrp-group 10 run-transition-scripts < master | backup | fault > < script-location >

commit ; save

Related Articles

Back to Top

Overview

This article explains how to interpret the Debugging Metrics statistics view, and how to use the data therein to troubleshoot and resolve common Wi-Fi issues.

Table of Contents

1. Introduction

2. Most Active APs

3. Retries

4. Channel Utilization

5. Top Clients

6. Top Interference

7. Most Active Clients

8. Longest Connected Clients

9. Top Memory Usage

10. Top CPU Usage

11. Related Articles

Introduction

Back to Top

The Debugging Metrics page shows a collection of data that makes it easier to identify and fix common Wi-Fi performance issues.To access Debugging Metrics on current UniFi Controller versions navigate toStatistics >and select Debugging Metricsfrom the dropdown.TheDebugging Metrics section will include the following data tables:

Most Active APs

Retries

Channel Utilization

Top Clients

Top Interference

Most Active Clients

Longest Connected Clients

Top Memory Usage

Top CPU Usage

UniFi - Understanding and Implementing Minimum RSSI

Each category contains a table that summarizes the data and can display information on the 2.4GHz band or the 5GHz one. In order for this feature to be available, users need to have at least one UniFi Access Point (UAP), although the data will be much improved with the use of a UniFi Security Gateway (USG) and UniFi Switch (USW). The following sections will explain the different fields of the Debugging Metrics view, giving network administrators the tools needed to resolve Wi-Fi issues they might encounter.

Most Active APs

Back to Top

This view lists the access points (APs) on the network that are sending/receiving the most traffic. Tx indicates packets transmitted, and Rx indicates packets received. At a glance, an administrator can identify if there are areas of higher demand that could benefit from having another AP available. Excessive use of an AP can lead to over-utilized memory/CPU, as well as poorer performance for over-active APs.

Common Causes & Solutions:

Not enough APs to meet density demands:If traffic appears consistently too high on a given access point, add an additional AP to help handle the traffic. Alternatively, consider placing nearby APs closer to the over-utilized AP to help handle some of the client load.

Problematic Clients:Sometimes what may look like an over-active AP may be more the result of a client device using up excessive traffic with P2P applications, media streaming, intentional spamming, etc. Identify clients that use too much traffic; and if applicable, use Deep-Packet Inspection (DPI) to identify whether the traffic being used violates what is acceptable terms of use of the network. You can then decide to either limit the problematic client by adding it to a client group with controlled bandwidth limits or to block it altogether.

Poor Configuration on AP: If an AP has a Tx power that is set too high and nearby APs are set too low at lower levels, one AP can attract client devices with better signal strength but fail to deliver optimal Wi-Fi experience. To fix this, make sure all nearby devices are sharing the load with the over-active AP. Additionally, test lowering the Tx power on the active AP; and raise it on the nearby, less active APs.This can be accomplished through the device property panel under the Radio section.

Retries

Back to Top

This view exposes the retry rate for both transmitting (packets that had to be resent to the client) and receiving (RX) packets (packets that had to be resent to the access point). The Retry rate indicates packets that had to be re-sent because they were corrupted upon arriving at the proper destination.

Common Causes & Solutions:

Interference: This is the most common cause of packet loss/retransmissions. Identify whether the Retry rate is higher on one of the two bands: 2.4GHz or 5GHz, or if it is equally impacted on both. Then look for other nearby APs to see how local the interference is. This can point to a rogue access point, a very congested RF environment, a problematic client device near the AP, etc. To solve, perform an RF Scan, and place APs on less congested channels. Also, eliminate adjacent channel overlap on nearby UniFi APs. Another option would be to identify a problematic device causing the interference and re-configure/remove it.

Client/AP Tx Power mismatch: Another common cause of packet retries is the mismatch of broadcast power levels (Tx Power). If an AP and client device are communicating at much different broadcast strengths, then this can cause packet retries. Look for packet retries on Rx specifically as this would indicate the more likely issue of the AP broadcasting too strongly for ideal behavior with the client.

Suggested articles:

UniFi - RF Scan: Suggested Channels Feature

UniFi - Understanding and Implementing Minimum RSSI

Channel Utilization

Back to Top

This view reveals which APs are utilizing the most of their assigned channel on 2G or 5G.

Common Causes & Solutions:

Interference: If there is an access point with 59\% Channel Utilization but only 15\% combines Self Tx/Rx, this can indicate channel re-use/interference is the culprit. In a high-density environment, make sure you are minimizing the number of APs using each respective channel.

Legacy Clients/Poor Data Rates:If high channel utilization is seen on an AP that largely comes from Self Tx/Rx, check the Most Active APs table to see if it is handling excessive traffic. If not, it is possible that poor data rates of older Wi-Fi clients are slowing down the AP and eating up a disproportionate amount of airtime. If this is causing adverse behavior you may opt to not provide connectivity to the lower data rates on this AP to prevent these older clients from causing issues.

Top Clients

Back to Top

The Top Clients view shows what APs are handling the most client devices, and whether one band is more in use than the other. An over-utilized AP can limit network performance, and having too many devices on a particular band may also be undesirable.

Common Causes & Solutions:

Tx Power Levels: In a higher density environment, if clients are connecting to an AP but should be connecting to another nearby one, this can indicate the access point in question is broadcasting at a higher strength than other nearby APs and may benefit from decreasing the Tx power on either band. This can be accomplished through the device property panel under the Radio section.It could also indicate that the other device(s) should have the Tx power increased. Typically this is more of an issue for 5G given the limited range. If devices are connecting to 2G heavily, this can indicate the need to lower 2G Tx levels on the over-utilized AP.

2.4GHz Band Over-utilized: In cases where an AP is seen to have too many clients on 2.4GHz, an administrator may opt to enable Band Steering on the AP. Band steering requiresAdvanced Settings to be enabled underSettings > Site.Once Advanced Settings are enabled in the UniFi Controller, band steering can be enabled by clicking on the AP with the high number of clients, opening the Properties Panel. Go to Config > Band Steering, and select "Prefer 5G". Save and apply changes and then monitor the AP to see whether performance improves.More clients should now be seen on 5G.

AP Placement/Density: If one AP seems to have more clients connected to it than all the others, consider moving other APs closer, or adding another AP to ease the burden on the AP.

Top Interference

Back to Top

This table shows the APs that have the most RF interference. RF interference results from other wireless communications disrupting the normal wireless communication to and from the APs. Excessive interference can cause a number of adverse effects on the wireless network. Look out for sustained interference levels of double-digits and higher.

Common Causes & Solutions:

Poor Channel Assignment: Interference levels are specific to individual channels on each band, based on local RF environment. If you see high interference levels, do an RF Scan on the APs, then manually assign the AP to a channel on the 2.4G or 5G band that is less saturated with wireless signaling. If the network is dealing with severe interference, consider narrowing the channels (2.4GHz channels should in most cases stay at HT20 channel width, and 5GHz in noisy/high-density environments may warrant being narrowed to HT20 as well). Remember that channels must also be assigned correctly to avoid interference of other APs. Make sure to stagger channels and avoid using the same and adjacent channels on adjacent APs.

Tx Levels: If interference is exceptionally high in a certain location, even with devices located local to the device and assigned to the optimal channel, this may indicate that the device is broadcasting too quietly. Try tweaking the Tx power up to medium/high, or use custom levels to see if interference levels are lower with a stronger Tx level. Sometimes excessively high Tx levels in certain environments can cause self-interference. If the AP is placed on a stone/brick/metal surface, self-interference can severely impact performance. In such cases, try lowering Tx power to see if the wireless connection will perform better.

Most Active Clients

Back to Top

This table shows which clients are using the most bandwidth. Look out for highly utilized APs that are being over-used by a small number of clients.

Common Causes & Solutions:

Network Abuse/Misuse:Abnormally high traffic from individual client devices will often point to clients that are either using the network for things that they shouldn't like torrenting, excessive media downloads, or downloading large applications; or it could possibly also point to clients that are seeking to intentionally bring down or negatively impact the network. When this occurs in environments that include a USG, use Deep Packet Inspection (DPI) to find out what kind of traffic these clients are using and identify violations of the network's terms of use. Problematic clients can be added to a user group in UniFi with maximum bandwidth limits. Admins also can ban these users from the wireless network altogether using the "block" button in the UI.

High Demand Clients:Sometimes the high bandwidth may be expected if a client device is a media server, camera or the likes. In such cases, if normal client-use is adversely affected, you may opt to confine high-demand clients to their own wireless network or dedicated access point. This can ensure that other clients have the optimal Wi-Fi experience, while still serving the most demanding clients.

Suggested article: UniFi - How to Set Traffic Bandwidth Limits

Longest Connected Clients

Back to Top

This view displays which clients on the network have been connected for the longest time. This is useful to identify widespread network issues, for example, if client uptime is low across the board. As well as identifying devices that should not be staying on the network for that long, for example in a coffee shop that offers complimentary Wi-Fi for current customers.

Top Memory Usage

Back to Top

Top Memory Usage indicates the percentage of AP hardware memory that is being used by its operations. Devices that may be dealing with abnormally high demand or may be encountering an error of some sort, may have the top memory usage. Typically high memory usage will accompany high utilization/demand; if you see abnormally high amounts of memory utilization i.e. >80\%, clients may experience adverse performance.

Top CPU Usage

Back to Top

Top memory usage indicates the percentage of AP hardware processing resources in use by the AP at a given time. Similarly to memory usage, higher CPU usage will typically indicate the AP is more heavily in use. Abnormally high levels of CPU usage may point to a bug or an error on the AP.

Related Articles

Back to Top

UniFi - Troubleshooting Connectivity Issues

UniFi - RF Scan: Suggested Channels Feature

UniFi - How to Set Traffic Bandwidth Limits

Overview

Readers will learn how to create firewall rules that protect the router and limit traffic between multiple Local Area Networks (LANs).

EdgeRouter - Router on a Stick

NOTES & REQUIREMENTS:

Applicable to the latest EdgeOS firmware on all EdgeRouter models. Please see the Related Articles below for more information.

Device used in this article:

EdgeRouter-4 (ER-4)

Adding Firewall Rules

Back to Top

Firewall policies are used to allow traffic in one direction and block it in another direction.

The EdgeRouter uses a stateful firewall, which means the router firewall rules can match on different connection states. In the example diagram above, firewall rules will be added to limit the traffic between the trust LAN (192.168.1.0/24) and the GUEST network (172.16.1.0/24).

The following traffic restrictions are applied to the GUEST network:

Management access to the router is denied.

All traffic to the trusted LAN is denied, with the exception of HTTP and HTTPS traffic to the Webserver.

All other traffic is allowed (internet access)

Follow the steps below to manually create these firewall rules:

GUI: Access the EdgeRouter Web UI.

1. Navigate to the Firewall/NAT tab.

2. Create a network group that includes all of the RFC1918 private IP ranges.

Firewall/NAT > Firewall/NAT Groups > + Add Group

Name: LAN_NETWORKS

Description: RFC1918 ranges

Group Type: Network Group

3. Add the IP ranges to the newly created network group.

Firewall/NAT > Firewall/NAT Groups > LAN_NETWORKS > Actions > Config

Network: 192.168.0.0/16

+Add New

Network: 172.16.0.0/12

+Add New

Network: 10.0.0.0/8

NOTE:The 10.0.0.0/8 range is added to the group as well to include all RFC1918 ranges.

4. Add a GUEST_IN firewall policy and set the default action to accept.

Firewall/NAT > Firewall Policies > + Add Ruleset

Name: GUEST_IN

Description: guest to lan/wan

Default action: Accept

5. Add two firewall rules to the newly created firewall policy.

Firewall/NAT > Firewall Policies > GUEST_IN > Actions > Edit Ruleset > + Add New Rule

Description: allow webserver

Action: Accept

Protocol: TCP

Destination > Address: 192.168.1.10

Destination > Port: 80,443

Firewall/NAT > Firewall Policies > GUEST_IN > Actions > Edit Ruleset > + Add New Rule

Description: drop guest to lan

Action: Drop

Protocol: All protocols

Destination > Network Group : LAN_NETWORKS

6. Attach the firewall policy to the eth2 LAN interface in the inbound direction.

Firewall/NAT > Firewall Policies > GUEST_IN > Actions > Interfaces

Interface: eth2

Direction: in

7. Add a GUEST_LOCAL firewall policy and set the default action to drop.

Firewall/NAT > Firewall Policies > + Add Ruleset

Name: GUEST_LOCAL

Description: guest to router

Default action: Drop

8. Add a firewall rule to the newly created firewall policy that allows guests to use the EdgeRouter as a DNS server.

Firewall/NAT > Firewall Policies > GUEST_LOCAL > Actions > Edit Ruleset > + Add New Rule

Description: allow DNS

Action: Accept

Protocol: Both TCP and UDP

Destination > Port: 53

9. Add a firewall rule to the newly created firewall policy that allows guests to use the EdgeRouter as a DHCP server.

Firewall/NAT > Firewall Policies > GUEST_LOCAL > Actions > Edit Ruleset > + Add New Rule

Description: allow DHCP

Action: Accept

Protocol: UDP

Destination > Port: 67

10. Attach the firewall policy to the eth2 LAN interface in the local direction.

Firewall/NAT > Firewall Policies > GUEST_LOCAL > Actions > Interfaces

Interface: eth2

Direction: local

NOTE: EdgeRouter firewall policies only become active when they are attached to an interface + direction.

The above configuration can also be set using the CLI:

CLI: Access the Command Line Interface.You can do this using the CLI button in the GUI or by using a program such as PuTTY.

1. Enter configuration mode.

configure

2. Configure the LAN_NETWORKS network group.

set firewall group network-group LAN_NETWORKS description 'RFC1918 ranges'

set firewall group network-group LAN_NETWORKS network 192.168.0.0/16

set firewall group network-group LAN_NETWORKS network 172.16.0.0/12

set firewall group network-group LAN_NETWORKS network 10.0.0.0/8

3. Configure the GUEST_IN firewall policy.

set firewall name GUEST_IN default-action accept

set firewall name GUEST_IN description 'guest to lan/wan'

set firewall name GUEST_IN rule 10 action accept

set firewall name GUEST_IN rule 10 description 'allow webserver'

set firewall name GUEST_IN rule 10 protocol tcp

set firewall name GUEST_IN rule 10 destination address 192.168.1.10

set firewall name GUEST_IN rule 10 destination port 80,443

set firewall name GUEST_IN rule 20 action drop

set firewall name GUEST_IN rule 20 description 'drop guest to lan'

set firewall name GUEST_IN rule 20 destination group network-group LAN_NETWORKS

set firewall name GUEST_IN rule 20 protocol all

4. Configure the GUEST_LOCAL firewall policy.

set firewall name GUEST_LOCAL default-action drop

set firewall name GUEST_LOCAL description 'guest to router'

set firewall name GUEST_LOCAL rule 10 action accept

set firewall name GUEST_LOCAL rule 10 description 'allow dns'

set firewall name GUEST_LOCAL rule 10 log disable

set firewall name GUEST_LOCAL rule 10 protocol tcp_udp

set firewall name GUEST_LOCAL rule 10 destination port 53

set firewall name GUEST_LOCAL rule 20 action accept

set firewall name GUEST_LOCAL rule 20 description 'allow dhcp'

set firewall name GUEST_LOCAL rule 20 log disable

set firewall name GUEST_LOCAL rule 20 protocol udp

set firewall name GUEST_LOCAL rule 20 destination port 67

5. Attach the firewall policies to the eth2 interface in the inbound and local direction.

set interfaces ethernet eth2 firewall in name GUEST_IN

set interfaces ethernet eth2 firewall local name GUEST_LOCAL

NOTE: EdgeRouter firewall policies only become active when they are attached to an interface + direction.

6. Commit the changes and save the configuration.

commit ; save

Related Articles

Back to Top

Intro to Networking - How to Establish a Connection Using SSH

Intro to Networking - Network Firewall Security

EdgeRouter - How to Create a WAN Firewall Rule

Overview

This article describes the data collected by our analytics framework for UniFi Network products. Click on the question that interests you to expand and collapse the answers.

Frequently Asked Questions

What kinds of data are collected?

Analytics data can be categorized as personal data or other data. If the data can be used to identify a specific individual, it's personal data. Otherwise, it’s other data.

Here’s an example of personal data that our analytics framework may collect: In order to get the most useful statistics about Access Points, we need the MAC address. Even though it would be very difficult to use the MAC address to identify an individual, it could fall under the category of personal data as defined by some regulatory bodies and needs to be treated accordingly.

Here’s an example of other data that our analytics feature will collect: We want to evaluate how features impact overall performance of the products, so our analytics framework will identify if features, like Fast Roaming or Guest Networks, are enabled. By itself, this information cannot be used to identify an individual.

Why do we collect analytics data?

We have developed an analytics framework that is used to measure product performance and customer experience. This data enables us to make improvements that have the highest positive impact on products as a whole.

Some analytics require capturing personal data in order to provide an accurate context for the information and therefore make it as useful as possible. We strongly encourage you to enable this option and participate in our effort to make the products better.

You can enable the feature in controller version 5.12.35 (and later) under Controller Settings, then select Enable Analytics & Improvements.

When do we collect data?

We respect your privacy. We only collect personal data under the analytics framework, as described here, after the network administrator has given consent by enabling the feature through the controller. Other data is automatically reported.

All data collection is subject to our Privacy Policy and we will comply with any valid request under applicable privacy laws to export or delete the impacted data.

Overview

Readers will learn how to connect to and setupan EdgeRouter for the first time.There are many different environments where specific adjustments may need to be made. This article demonstrates a common setup scenario, but it is not necessary applicable in every network environment.

Intro to Networking - How to Establish a Connection Using SSH

NOTES & REQUIREMENTS:

Setup wizards were added to the Web UI starting from the EdgeOS v1.4.0 firmware. It is highly recommend to upgrade to the most recent firmware release before following this guide. See the How to Upgrade the EdgeOS Firmware article for more information.

This article is applicableto all EdgeRouter models and was written using the latest stable firmware release.

Table of Contents

Establishing Initial Connectivity

Running the Basic Setup Wizard

Related Articles

Establishing Initial Connectivity

Back to Top

1. Connect an Ethernet cable from a computer to the eth0 interface on the EdgeRouter.

2. Configure a static IP address on your computer in the 192.168.1.0/24 range (for example 192.168.1.11).

Windows Client

Navigate to the Windows 10 Network connections.

Settings > Network & Internet > Status > Change Adapter Options

Modify the IPv4 settings of the Ethernet adapter.

Ethernet Adapter properties > Internet Protocol Version 4 (TCP/IPv4) > Properties

Select to manually enter an IP address and add the following information:

IP address: 192.168.1.11

Subnet mask: 255.255.255.0

Default gateway: <blank>

DNS servers: <blank>

macOS Client

Navigate to the macOS Network connections.

System Preferences > Networks > Ethernet Adapter

Select to manually enter an IP address and add the following information:

IP Address: 192.168.1.11

Subnet Mask: 255.255.255.0

Router: <blank>

DNS server: <blank>

ATTENTION: If a wireless adapter is enabled and connected to another network it could conflict with the connection to the EdgeRouter. Disable the wireless adapter if necessary.

3. Open a Web Browser and enter https://192.168.1.1 inthe address bar.

4.Log into the router using the default credentials.

Username: ubnt

Password: ubnt

5.Confirm that the device is running the latest firmware from our Downloads page.Make sure to upgrade it before continuing on to the next section.

NOTE:There is more information about how to upgrade the EdgeRouter in the How to Upgrade the EdgeOS Firmware article.

Running the Basic Setup Wizard

Back to Top

The Basic Setup wizard which will accomplish all the necessary tasks to allow your router to connect to the Internet, including enabling the default firewall, setting up a Local Area Network and adding a DHCP Server. Each item is explained in more detail below.

NOTE:The current configuration will be replaced and a reboot is required when running the setup wizard.

3. Apply the changes and reboot the router when prompted.

1. Navigate to the Wizards tab and run the wizard.

Wizards > Basic Setup

2. Choose the interface that will connect to the ISP define the other router settings.

The available internet connection types are:

DHCP The most common scenario. Use this option if your ISP is distributing IP addresses via DHCP.

Static IP Use this option if your ISP provided you with a static public IP address.

PPPoE Use this option if your ISPauthenticates your internet connection using PPPoE.

NOTE:It is recommended to configure the ISP supplied modem/router in bridge mode. This setting will forward the public IP from the ISP modem/router to the EdgeRouter.

Having a public IP assigned to the EdgeRouter will open up additional features, while also negating the performance drop caused by a double NAT scenario.

The other available options are:

VLAN It is becoming more common forISPs toprovide FTTH (Fiber to the Home) and require that the Internet be distributed using a VLAN to separate Internet from IPTV and Voice services. Use this option to tag the Internet connection with a VLAN ID.

Firewall Enabled by default. See this article for more information on the default firewall policies that are added to the EdgeRouter.

DHCPv6 If your ISP supports IPv6 using DHCPv6-PD, you will need to assign the supplied Prefix length given from the ISP, enable the default IPv6 firewall, and define the LAN interfaces that will need IPv6 connectivity.

LAN IP Address Set to 192.168.1.1/24 by default. Change if necessary.

DHCP Server Enabled by default.

Username Set to ubnt by default. We strongly recommend that you configure your own user account with a strong password.

NOTE: When configuring a router with a built-in switch (such as the ER-10X, ER-X or ER-X-SFP ), the LAN will be set to the switch0 interface. In this case, all ports assigned to the switch will share the same LAN.

3. Apply the changes and reboot the router when prompted.

4. Unplug and reconnect the interfaces so that eth0 is connected to the ISP and the other ports are connected to your LAN.

ATTENTION:The computer's Ethernet connection can be changed back to DHCP if the DHCP server was enabled in the wizard.

Related Articles

Back to Top

EdgeRouter - How to Upgrade the EdgeOS Firmware

EdgeRouter - How to Access the EdgeRouter

EdgeRouter - How to Create a WAN Firewall Rule

EdgeRouter - Hardware Offloading

Overview

This article explains how device discovery works on UNMS and how to troubleshoot any issues that may be encountered.

UNMS - Optional Installation Steps

ATTENTION: Since the UNMS version 1.1.0 there is a new discovery tool called Remote DIscovery. If you are running 1.1.0 or higher please visit this link.

NOTES & REQUIREMENTS: Devices using older firmware will have to upgrade to latest version in order to be discovered. If the device has firmware versions as the ones listed below, please upgrade:

airCube no threshold is set

airFiber LTU older than 1.1.1

airFiber older than 4.1.0-beta.6

airMAX AC older than 8.4.3

airMAX M older than 6.1.3

EdgeRouter older than 1.9.7-hotfix4

EdgeSwitch older than 1.7.3. (older than 1.4.0. will have upgrade manually)

EdgeSwitch XP older than 1.4.0

EdgePower older than 1.2.0

UFiber OLT no threshold is set

Table of Contents

Introduction

How Discovery Works

Troubleshooting

Issue: I can't see any devices or some devices are missing

Issue: Ubiquiti devices are found as Unknown

Issue: I can discover the device but connection to UNMS is failing

Issue: There is an error message about contacting the support

Blocking the Discovery

Related Articles

Introduction

Back to Top

Understanding how device discovery works, helps interpret and solve issues if they arise. This article explains how the discovery process works and what to do if you either cannot discover a device or you can discover it, but it won't connect. In case you do not want your device to be discovered for some reason, this article also includes how to prevent discovery.

How Discovery Works

Back to Top

UNMS tries to find Ubiquiti and 3rd party devices through several tools. This is the process it follows:

UNMS uses a PING to make sure there is a device on the given IP address.

If UNMS gets an answer, the process continues and at that point, the device will appear as an 'Unknown device'.

Ubiquiti Discovery is leveraged to get detailed information about the device. In this step, the TCP protocol is used first and in the second wave the UDP protocol. If the device indeed is one of Ubiquiti's and it has discovery enabled it should send back basic information shown in the Discovery Manager: name, SSID, model, firmware version, MAC address and a list of all interfaces.

If the device doesn't reply to Ubiquiti Discovery then UNMS uses SNMP protocol to download some basic info about the device.

ATTENTION:If either UNMS or a device you need to discover are placed on a public IP range, please make sure all conditions for TCP discovery are met.

Issue: I can't see any devices or some devices are missing

Back to Top

Can you ping the device from the UNMS server?

Check traceroute/ping/curl from your UNMS server to the device's IP. Please note that the ping has to be lower than 400ms otherwise discovery can fail.

ping 192.168.x.x

traceroute -n 192.168.x.x

Is your OS supported?

Discovery doesn't work on Debian 8. It's recommended upgrading to Debian 9 which is officially supported.

Are you using virtualization? If yes, is it the supported one?

Discovery doesn't work on UNMS instances running on an LXC container. This is only one of several issues with LXC containers, which is why they are not officially supported. Please use KVM instead.

Do you have a supported storage driver?

Discovery doesn't work on systems without overlay2 storage driver. Please check that your Kernel includes this driver and your Docker is using it. Here are some pointers on adding the overlay2:

#stop the Docker as a first step

sudo systemctl stop docker

#backup of docker folder, just in case

cp -au /var/lib/docker /var/lib/docker.bak

#into the file /etc/docker/daemon.json put this

{

"storage-driver": "overlay2"

}

#install the Docker again

sudo systemctl start docker

Are you searching for the correct IP range?

Make sure that you are using only 24 ranges for public IP addresses. For public IPs, UNMS doesn't allow to search higher ranges. For private IPs it is possible to go to /16 but the search will be very long.

Is device discovery enabled on the device?

Discovery doesn't work on devices with disabled Discovery. Please make sure that Discovery is enabled in your device in the following locations or by following these instructions:

airMAX: UnderSettings > Services > Device Discovery. If the checkbox is set to OFF change it to ON and click Save Settings.

EdgeRouter:UDP discovery is always active on EdgeRouters, but in some cases, you need to make sure TCP discovery is enabled as well. For example when UNMS is on the public IP and the device is on a private one. You can enable TCP discovery by running:

set service ubnt-discover-server protocol tcp_udp

commit

save

Are UDP packets allowed through?

Discovery doesn't work with blocked port 10001. Please check if there isn't an active firewall record for blocking UDP packets on port 10001, as seen in the Blocking the Discovery section.

Do you use an IP address in range 172.x.y.z? Is there a possible collision with Docker?

Check collision with Docker's virtual subnet. While rare, the container's IP might collide with the real IP in your network. Run ifconfig on your UNMS server to see Docker's IPs:

$ ifconfig

br-6805a10e2e92 Link encap:Ethernet HWaddr 02:42:d3:f8:f1:64

inet addr:172.18.0.1 Bcast:0.0.0.0 Mask:255.255.0.0

inet6 addr: fe80::42:d3ff:fef8:f164/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:196618 errors:0 dropped:0 overruns:0 frame:0

TX packets:10 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:5506244 (5.5 MB) TX bytes:764 (764.0 B)

docker0 Link encap:Ethernet HWaddr 02:42:dd:1c:c3:57

inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0

inet6 addr: fe80::42:ddff:fe1c:c357/64 Scope:Link

UP BROADCAST MULTICAST MTU:1500 Metric:1

RX packets:8 errors:0 dropped:0 overruns:0 frame:0

TX packets:8 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:536 (536.0 B) TX bytes:648 (648.0 B)

If such an IP exists in your network you will have to change Docker's subnet with the following:

cd /home/unms/app

docker-compose -p unms down

docker network create unms_default --subnet 172.30.0.1/24

docker-compose -p unms up -d

If you find there is a collision with docker, please note that you can change the docker subnet which UNMS uses, through installation script parameters.See UNMS - Optional Installation Steps for more information.

Are the UDP packets arriving?

Check with tcpdump that your device receives UDP packet from your UNMS instance and sends back an answer.

Issue: Ubiquiti devices are found as Unknown

Are you running UNMS on a public IP?

If UNMS (up to 0.13.1) has a public IP address and a device has a private IP, there will be an issue with device discovery. UNMS most likely won't recognize this device correctly. This was fixed in 0.13.2.

Is your device supported?

Consider if your device is supported by UNMS, here is a list of supported devices.

Is discovery enabled on the device?

If discovery is disabled the device will show as unknown in UNMS device discovery.

Are UDP packets allowed through?

If they are not, the device willshow as unknown in UNMS device discovery.

Are the UDP packets arriving?

If not, thenthe device will show as unknown in UNMS device discovery.

Issue: I can discover the device, but the connection to UNMS is failing

NOTE: Not every tool is available on all devices. Only EdgeRouters are guaranteed to have all the tools described below.

Is it possible to ping UNMS from the device?

Check traceroute/ping/curl from the device to your UNMS server IP / domain name:

ping unms-server.com

traceroute -n 192.168.x.x

curl --insecure https://192.168.x.x:443/v2.1/nms/version

Does the connection upgrade to WebSocket?

Check HTTPS upgrade to WebSocket:

curl --insecure --include --no-buffer --header "Connection: Upgrade" --header "Upgrade: websocket" --header "Host: example.com:80" --header "Origin: http://example.com:80" --header "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" --header "Sec-WebSocket-Version: 13" https://192.168.x.x:443/

The values of the --header parameters do not matter, you can use example.com as shown. Only the last parameter must be the real address of your UNMS server. This should return an output similar to the following, indicating that the upgrade to WebSocket was successful:

HTTP/1.1 101 Switching Protocols

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Accept: qGHgK3En71di5rrssAZTmtRTyFk=

db332780afad264425162cb11d19ffd1ac9ad3658f63cb56968a8a2592054a39aac950bcdae301e39eea75f28c7d3e7dd32a568f0fcf67f25b692434c825ffc7d13b7f8bcec1fb649919d784723f039ef50deb939eeb2b1bd602f56339ac20b65b3

Is the time configured correctly?

Make sure the device has the correct time and date set. SSL connection requires valid time and date. This might be an issue for devices not connected to the internet or with NTP service which is disabled.

Is the AES key correct?

If the device has been connected previously try refreshing its UNMS key by clicking Refresh on the corresponding row in the Devices table. If this doesn't succeed, it is also possible to manually paste the universal UNMS key via the device's UI.

Issue: There is an error message about contacting support

Do you know where to contact us?

This error means that some device sent a block of data which UNMS cannot parse. Usually, it is a single device and if its IP address is omitted from the search range the discovery continues without issues. In any case please write a post in our community forum and we will gladly help you.

Blocking the Discovery

Back to Top

If you wish to prevent your device from being discovered, you can perform the following configuration.

airMAX: Go to Settings > Services > Device Discovery > set checkbox to OFF and click Save Settings

EdgeRouter: Currently this can be done only through the firewall rule. To set up the rule issue the following commands:

configure

edit firewall name disable-discover

set default-action accept

set rule 100 action 'drop'

set rule 100 description 'Drop discovery packets'

set rule 100 protocol 'udp'

set rule 100 destination port 10001

exit

# apply rule to the interface that is connected to the Internet

set interfaces ethernet eth0 firewall local name 'disable-discover'

commit

save

show interfaces

NOTE: The rule will block entire incoming UDP communication to port 10001, potentially disabling more than just the discovery.

To disable the rule, issue the following:

configure

delete interfaces ethernet eth0 firewall local name 'disable-discover'

commit

save

Related Articles

Back to Top

Overview

This article describes how to install a fresh copy of UNMS on a server, or update an existing installation. This is a guide for a Linux installation, see the following note for Windows and OS X users:

UNMS - The UNMS Key and the Device Registration Process

NOTES & REQUIREMENTS:

Unfortunately proper operation, smooth backups and upgrades of critical Docker containers cannot be ensured on Windows and macOS systems. At this time we recommend that you install VirtualBox with the latest version of Ubuntu 18.04.3 (Bionic Beaver) 64 bit and then follow the Linux instructions provided below.

Table of Contents

Prerequisites

Installation Instructions

Related Articles

Prerequisites

Back to Top

NOTE:It is recommended to install UNMS on a server, with a public IP address and FQDN, which is directly connected to the main gateway of the network. In this setup, UNMS will automatically have a valid certificate, it will report outages in the most precise manner and all of its advanced functions will perform optimally.It is certainly possible to place UNMS server in a different spot in a topology, but there may be some limitations involved.

Supported Distros (LXC virtualized Distros aren’t officially supported please use KVM):

Ubuntu 16.04.1 LTS (Xenial Xerus) 64-bit

Ubuntu 18.04 LTS (Bionic Beaver) 64-bit

Debian 9 64-bit

2 GB RAM (Minimal)

16 GB storage (Minimal)

64-bit (x64) CPU

Local Ports:

80 (Let's Encrypt certificate automation)

81 (Suspension page)

443 (UI, API, Devices connector)

(see Changing the HTTP and HTTPS ports )

Allow ping (see Devices Latency and Outage Statistics )

A kernel with overlay2 storage driver (see Docker Storage Drivers )

bash, curl, sudo, netcat (see Installing prerequisites )

Installation Instructions

Back to Top

Run the command below on the host to install and start UNMS (it will automatically install Docker if it is not installed already). If a UNMS installation already exists, it will be overwritten, but all data will be kept. It is possible to use the attribute--update if the new installation needs to have the same parameters as the old one. Registering new devices to UNMS can be done by following the steps in this article: The UNMS Key and the Device Registration Process. If it is necessary to customize the installation process, please read Optional installation steps, or if you wish to install a UNMS version that is not the current, stable version see this article. Otherwise, the following command will always install the newest, stable version as seen in the Community Releases section (to view, select the Stable Status, the General tab, and the Management Tools > UNMS tag.

curl -fsSL https://unms.com/v1/install > /tmp/unms_inst.sh && sudo bash /tmp/unms_inst.sh

The installation script will check if ports :80 and :443 are open and if they are not, it will ask which ports should UNMS to use. The same applies to the overcommit memory settings. If thevm.overcommit_memory is not set to '1', the installation script asks for permission to do it. In case those interrupts are unwanted in the installation process it is possible to suppress them with --unattendedattribute to let the installation script do all the necessary arrangements by itself.

When the process is complete, UNMS is accessible at http://server_hostname_or_ip/. Please don't use localhost. Use server hostname or its IP address.

NOTE: The installation script needs to use sudo permissions. Those are required to install Docker in case it is not available in the OS already. It is also needed to create the UNMS user, under which the UNMS application runs as well as to set up a cron task that manages the UNMS updates.

Related Articles

Back to Top

UNMS - Optional Installation Steps

Overview

Readers will learn how to configure Dynamic DNS on the EdgeRouter using the built-in services.

Intro to Networking - How to Establish a Connection Using SSH

NOTES & REQUIREMENTS:

Applicable to the latest EdgeOS firmware on all EdgeRouter models. Please see the Related Articles below for more information.

Device used in this article:

EdgeRouter-4 (ER-4)

Configuring the Built-in Dynamic DNS Service

Back to Top

The following Dynamic DNS services are available for use in EdgeOS:

Afraid Requires server to be hard-coded.

Dnspark

Dslreports

dyndns

Easydns

Namecheap

Noip

Sitelutions Requires serial number to be set as the hostname.

Zoneedit

See the Custom Dynamic DNS article for instructions on how to configure a custom Dynamic DNS service.

CLI: Access the EdgeRouter Command Line Interface.

1. Enter configuration mode.

configure

2. Add the Dynamic DNS service and the login credentials.

set service dns dynamic interface eth0 service <dyndnsservice> host-name <host>

set service dns dynamic interface eth0 service <dyndnsservice> login <username>

set service dns dynamic interface eth0 service <dyndnsservice> password <password>

3. Configure the location of the Dynamic DNS server.

set service dns dynamic interface eth0 service <dyndnsservice> server <server>

NOTE: This step is required when using afraid.org.

4. Commit the changes and save the configuration.

commit ; save ; exit

You can verify the status and force an update of the Dynamic DNS service using the commands below:

show dns dynamic status

update dns dynamic interface <interface-name>

By default, EdgeOS will only update Dynamic DNS when the IP address actually changes.

Related Articles

Back to Top

EdgeRouter - Custom Dynamic DNS

Overview

This article lists the different CLI commands supported by the USW-Leaf switch and their equivalent command on a Cisco switch.

Back to Top

NOTE:The commands with asterisks (*) below are not fully supported yet, and may change without notice.

Table of Contents

1. General Commands

2. VLAN Commands

3. Port Operation Commands

4. LAG (Link Aggregation) Commands

5. SPAN (Port Mirroring) Commands

6. Storm Control Commands

7. Port Isolation (Protected Port) Commands

8. Flow Control Commands

9. QoS (Scheduling, Shaping and Policing) Commands

10. ACL Commands

11. STP; RSTP Commands

12. MSTP Commands

13. Port Error Disable / Auto Recovery Commands

14. DHCP Guard / DHCP Snooping (Cisco)

15. ARP

16. DHCP Client/Static IP

17. IP Route(Static)

General Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Show OS version information.

show version

show version

Show base MAC address.

show system

show version

Show USW Model.

show platform info

show version

Show current configuration (DRAM).

show running-config

show running-config

Show startup configuration (NVRAM).

show startup-config

show startup-config

Show all logs that the router has in its memory.

show log

show log

Overview all IPv4 interfaces on the switch.

show ip interface brief

show ip interface brief

Display current routing protocols.

show ip protocol

show ip protocol

Display IPv4 routing table.

show ip route

show ip route

Display IPv6 routing table.

show ipv6 route

show ipv6 route

Display access list.

show access-list <list_name>

show access-list

Display MAC addresses table.

show platform mac address-table

show mac address-table

Show ARP table.

show arp

show arp

Display all users connected to the switch.

NA

show users

Display all info about flash memory.

NA

show flash

Display history of commands used.

NA

show history

Display the system clock.

NA

show clock

Information about hardware status.

show environment

show environment

Show the amount of switch free memory.

show memory

show memory

VLAN Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Display VLAN information, all ports which belong to specific VLAN, and information about the number of VLANs configured on the switch.

UBNT# show bridge-domain

SW# show vlan

Create new VLAN 2.

UBNT# configure terminal

UBNT(config)# bridge-domain 2

UBNT(bridge-domain)# exit

UBNT(config)#

SW# configure terminal

SW(config)# vlan 2

SW(config-vlan)# exit

Add VLAN 2 membership to the port swp1, configure the native VLAN ID 10.

NPOS operates VLAN inside bridge-domain, so it's necessary to associate port with VLAN in bridge-domain.

UBNT(config)# interface swp1

UBNT(config-if)# switchport mode trunk

UBNT(config-if)# switchport trunk allowed vlan 2

UBNT(config-if)# switchport trunk native-vlan 10

UBNT(config-if)# exit

UBNT(config)# bridge-domain 2

UBNT(bridge-domain)# vlan 2 swp1

UBNT(bridge-domain)# exit

UBNT(config)# bridge-domain 10

UBNT(bridge-domain)# vlan 10 swp1

UBNT(bridge-domain)# exit

SW(config)# interface fa1/0

SW(config-if)# switchport mode trunk

SW(config-if)# switchport trunk allowed vlan add 2

SW(config-if)# switchport trunk native vlan 10

SW(config-if)# exit

Remove VLAN 2 membership from port swp1 and the native VLAN.

NPOS port with VLAN association to bridge-domain is removed automatically.

UBNT(config)# interface swp1

UBNT(config-if)# switchport trunk allowed vlan remove 2

UBNT(config-if)# no switchport trunk native-vlan

UBNT(config-if)# exit

SW(config)# interface fa1/0

SW(config-if)# switchport trunk allowed vlan remove 2

SW(config-if)# no switchport trunk native vlan

SW(config-if)# exit

Enable or disable dot1q tagging for native VLANs on specific port. Cisco's method operates dot1q native tagging globally.

UBNT(config)# vlan do1q tag native

UBNT(config)# interface swp1

UBNT(config-if)# vlan dot1q tag native

UBNT(config-if)# no vlan dot1q tag native

UBNT(config-if)# exit

SW(config)# vlan do1q tag native

SW(config)# no vlan do1q tag native

Configure the swp1 interface as a nontrunking nontagged single-VLAN 3 access mode.

Before switching, disable the current mode.

UBNT(config)# interface swp1

UBNT(config-if)# no switchport

UBNT(config-if)# switchport mode access

UBNT(config-if)# switchport access vlan 3

UBNT(config-if)# exit

UBNT(config)# bridge-domain 3

UBNT(bridge-domain)# vlan 3 swp1

UBNT(bridge-domain)# exit

SW(config)# interface fa1/0

SW(config-if)# switchport mode access

SW(config-if)# switchport access vlan 3

SW(config-if)# exit

Remove any configuration specific to Layer 2 on this interface (include VLAN's membership), switch interface to Layer 3 mode.

UBNT(config)# interface swp1

UBNT(config-if)# no switchport

UBNT(config-if)# exit

SW(config)# interface fa1/0

SW(config-if)# no switchport

SW(config-if)# exit

Disable MAC address learning on a specified VLAN 2.

Maximum number of learning MAC records equal 1000.

Configure a secure sticky MAC address for interface swp1.

UBNT(config)# bridge-domain 2

UBNT(bridge-domain)# no learning enable

UBNT(bridge-domain)# learning limit 1000

UBNT(bridge-domain)# learning sticky aa:bb:cc:dd:11:22 interface swp1

UBNT(bridge-domain)# exit

SW(config)# no mac-address-table learning vlan 2

SW(config)# mac-address-table limit vlan 2 maximum 1000

SW(config)# interface fa1/0

SW(config-if)# switchport port-security mac-address aa:bb:cc:dd:11:22

SW(config-if)# exit

Port Operation Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Show port status and admin state.

UBNT# show interface status

SW# show interface status

Verify the FEC feature status on the interface.

UBNT# show fec status

View the interface status of interface swp1.

UBNT# show port status swp1

UBNT# show interface swp1

SW# show interface fa1/0

Display interface statistics.

UBNT# show statistics interface

SW# show interface counters

Clear interface statistics counters.

UBNT# show statistics clear

SW# clear counters

Display information about the connected transceivers.

UBNT# show interface transceiver swp1

UBNT# show platform fwd interface sfp

SW# show interface transceiver

*Information about the switchport interface.

NA

show interface switchport

Configure interface speed 100g, autonegotiation, and FEC cl-91.

UBNT(config)# interface swp54

UBNT(config-if)# speed 100g

UBNT(config-if)# autonegotiation enabled

UBNT(config-if)# fec cl-91

UBNT(config-if)# exit

SW(config)# interface fa1/0

SW(config-if)# speed 100g

SW(config-if)# speed auto

SW(config-if)# fec cl91

SW(config-if)# exit

Configure maximum transmission unit (MTU) size per specific interface.

UBNT(config)# interface swp54

UBNT(config-if)# mtu 9216

UBNT(config-if)# exit

SW(config)# interface fa1/0

SW(config-if)# ip mtu 9216

SW(config-if)# end

LAG (Link Aggregation) Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Display LACP internal information.

UBNT# show lacp internal

SW# show lacp internal

Display the status of a port-channel interface.

UBNT# show interface po1

SW# show interface port-channel 1

Display the traffic statistics for port channels.

UBNT# show lacp counters

SW# show lacp counters

Clear LACP counters.

UBNT# clear lacp counters

SW# clear lacp counters

Display the LACP system identifier.

UBNT# show lacp sys-id

SW# show lacp system-identifier

Display information about the LACP neighbor.

UBNT# show lacp neighbor

SW# show lacp neighbor

Configure the LACP system-priority and priority for the physical interface.

UBNT(config)# lacp system-priority 65535

UBNT(config)# interface swp54

UBNT(config-if)# lacp port-priority priority 20000

UBNT(config-if)# exit

SW(config)# lacp system-priority 65535

SW(config)# interface fa1/0

SW(config-if)# lacp port-priority priority 20000

SW(config-if)# exit

Specify the port mode as active for the links in a port channel.

Define the minimum and maximum number of active bundled.

Define LACP ports allowed in a port channel.

UBNT(config)# interface swp1

UBNT(config-if)# no switchport

UBNT(config-if)# channel-group 1 mode active

UBNT(config-if)# interface swp2

UBNT(config-if)# no switchport

UBNT(config-if)# channel-group 1 mode active

UBNT(config-if)# interface port-channel 1

UBNT(config-if)# lacp min-links 2

UBNT(config-if)# lacp max-bundle 8

UBNT(config-if)# exit

SW(config)# interface fa0/1

SW(config-if)# channel-group 1 mode active

SW(config-if)# interface fa0/2

SW(config-if)# channel-group 1 mode active

SW(config-if)# interface port-channel 1

SW(config-if)# lacp min-links 2

SW(config-if)# lacp max-bundle 8

SW(config-if)# exit

Delete all interfaces from port-channel interface.

UBNT(config-if)# int po1

UBNT(config-if)# delete all-lag-members

UBNT(config-if)# exit

NA

SPAN (Port Mirroring) Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Display information about the Switched Port Analyzer (SPAN).

UBNT# show mirror

SW# show monitor session

Set up a SPAN session (session 1) for monitoring ingress & egress port traffic to a destination port.

UBNT(config)# mirror tx session 1

UBNT(config-mirror)# source interface swp1

UBNT(config-mirror)# destination interface swp2

UBNT(config)# mirror rx session 1

UBNT(config-mirror)# source interface swp1

UBNT(config-mirror)# destination interface swp2

UBNT(config-mirror)# exit

SW(config)# monitor session 1 source interface fastEthernet0/1 tx

SW(config)# monitor session 1 source interface fastEthernet0/1 rx

SW(config)# monitor session 1 destination interface fastEthernet0/2

Delete SPAN sessions.

UBNT(config)# no mirror tx session 1

UBNT(config)# no mirror rx session 1

SW(config)# no monitor session 1

Storm Control Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Display storm control statistics for specified interface.

UBNT# show statistics storm-control interface swp1

SW# show interface fa0/1 counters storm-control

Traffic Storm Control Configuration (level as a percentage of the total interface bandwidth).

UBNT(config)# interface swp1

UBNT(config-if)# storm-control unicast level 50

UBNT(config-if)# storm-control multicast level 50

UBNT(config-if)# storm-control broadcast level 50

UBNT(config-if)# exit

SW(config)# interface fa0/1

SW(config-if)# storm-control unicast level 50

SW(config-if)# storm-control multicast level 50

SW(config-if)# storm-control broadcast level 50

SW(config-if)# exit

Port Isolation (Protected Port) Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Display protected port state for specific interface.

UBNT# show interface swp1 switchport

SW# show interface fa0/1 switchport

Enable or disable the interface that will be a protected port.

UBNT(config)# interface swp1

UBNT(config-if)# switchport protected

UBNT(config-if)# no switchport protected

UBNT(config-if)# exit

SW(config)# interface fa0/1

SW(config-if)# switchport protected

SW(config-if)# no switchport protected

SW(config-if)# exit

Flow Control Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

*Display the flow control settings.

NA

SW# show interface flowcontrol

Configure flow-control mode

Configure flow-control priority

UBNT(config)# interface swp1

UBNT(config-if)# flow-control mode both

UBNT(config-if)# priority-flow-control mode both

UBNT(config-if)# exit

SW(config)# interface ethernet fa0/1

SW(config-if)# flowcontrol receive on

SW(config-if)# flowcontrol send on

SW(config-if)#priority-flow-control mode on

SW(config-if)# exit

Disable Link Level Flow Control and its priority on a specific interface.

UBNT(config)# interface swp1

UBNT(config-if)# no flow-control

UBNT(config-if)# no priority-flow-control

UBNT(config-if)# exit

SW(config)# interface ethernet fa0/1

SW(config-if)# flowcontrol receive off

SW(config-if)# flowcontrol send off

SW(config-if)#priority-flow-control mode off

SW(config-if)# exit

QoS (Scheduling, Shaping and Policing) Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Verify existing scheduling policy, queues weight, and bound interfaces.

UBNT# show qos policy scheduling

SW# show mls qos interface queueing

Verify existing shaping policy.

UBNT# show qos policy shape

SW# show policy-map interface

Verify existing policing policy.

UBNT# show qos policy policing

Configure the QoS Scheduling policy, binding the policy to a specific interface.

UBNT(config)# qos policy scheduling sch_pol

UBNT(qos-policy)# queue 0 dwrr 5

UBNT(qos-policy)# queue 1 dwrr 10

UBNT(qos-policy)# queue 2 dwrr 20

UBNT(qos-policy)# queue 3 dwrr 30

UBNT(qos-policy)# queue 4 dwrr 40

UBNT(qos-policy)# queue 5 dwrr 50

UBNT(qos-policy)# queue 6 dwrr 60

UBNT(qos-policy)# queue 7 dwrr 70

UBNT(qos-policy)# exit

UBNT(config)# interface swp1

UBNT(config-if)# qos policy scheduling sch_pol

UBNT(config-if)# exit

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# wrr-queue bandwidth 5 10 20 30 40 50 60 70

SW(config-if)# exit

Configure the QoS Shaping policy, binding the policy to a specific interface.

UBNT(config)# qos policy shape shape_pol

UBNT(qos-policy)# queue 0 min 2000 64000 max 10000 640000

UBNT(qos-policy)# queue 1 min 2000 64000 max 20000 640000

UBNT(qos-policy)# queue 2 min 2000 64000 max 20000 640000

UBNT(qos-policy)# queue 3 min 2000 64000 max 30000 640000

UBNT(qos-policy)# queue 4 min 2000 64000 max 40000 640000

UBNT(qos-policy)# queue 5 min 2000 64000 max 50000 640000

UBNT(qos-policy)# queue 6 min 2000 64000 max 60000 640000

UBNT(qos-policy)# queue 7 min 2000 64000 max 70000 640000

UBNT(qos-policy)# exit

UBNT(config)# interface swp1

UBNT(config-if)# qos policy shape shape_pol

UBNT(config-if)# end

SW(config)#policy-map shape_pol

SW(config-pmap)#class shape_cl

SW(config-pmap-c)#shape avarage 640000

SWconfig-pmap-c)# exit

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)#service-policy output shape_pol

SW(config-if)# exit

*Configure the QoS Policing policy that utilizes two ACLs (associated with policer), binding the policy to a specific interface.

UBNT(config)# ip access-list voice-acl

UBNT(config-ip-acl)# 10 permit ip 192.168.10.0/24 any

UBNT(config-ip-acl)# exit

UBNT(config)# ip access-list database

UBNT(config-ip-acl)# 10 permit tcp any any eq 1810

UBNT(config-ip-acl)# 20 permit tcp any any eq 2481

UBNT(config-ip-acl)# 30 permit tcp any any eq 1521

UBNT(config-ip-acl)# exit

UBNT(config)# policer aggregate voice-acl-aggr

UBNT(qos-policer)# conform-action transmit

UBNT(qos-policer)# exit

UBNT(config)# policer aggregate database-aggr

UBNT(qos-policer)# conform-action set-dscp 18

UBNT(qos-policer)# exit

UBNT(config)# qos policy policing test-policing

UBNT(qos-policy-policing)# 10 access-list voice-acl

UBNT(qos-policy-policing-acl)# policer voice-acl-aggr

UBNT(qos-policy-policing-acl)# exit

UBNT(qos-policy-policing)# 20 access-list database

UBNT(qos-policy-policing-acl)# policer database-aggr

UBNT(qos-policy-policing-acl)# exit

UBNT(qos-policy-policing)# exit

UBNT(config)# interface swp1

UBNT(config-if)# qos policy policing test-policing input

UBNT(config-if)# end

SW(config)#ip access-list extended voice-acl

SW(config-ext-nacl#permit ip 192.168.10.0 0.0.0.255 any

SW(config-ext-nacl)#exit

SW(config)#ip access-list extended database

SW(config-ext-nacl)#permit tcp any any eq 1810

SW(config-ext-nacl)#permit tcp any any eq 2481

SW(config-ext-nacl)#permit tcp any any eq 1521

SW(config-ext-nacl)#exit

SW(config)#class-map class-voice

SW(config-cmap)#match access-group name voice-acl

SW(config-cmap)#exit

SW(config)#class-map class-database

SW(config-cmap)#match access-group name database

SW(config-cmap)#exit

SW(config)#policy-map test-policing

SW(config-pmap)#class class-voice

SW(config-pmap-c)#trust cos

SW(config-pmap-c)#exit

SW(config-pmap)#class class-database

SW(config-pmap-c)#set dscp af21

SW(config-pmap-c)#exit

SW(config-pmap)#exit

SW(config)#interface gigabitEthernet 1/0/1

SW(config-if)#service-policy input test-policing

SW(config-if)#exit

Unbind the scheduling, shaping and policing policies from a specific interface.

UBNT(config)# interface swp1

UBNT(config-if)# no qos policy scheduling

UBNT(config-if)# no qos policy shape

UBNT(config-if)# no qos policy policing input

UBNT(config-if)# exit

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# no wrr-queue bandwidth

SW(config-if)# no service-policy output shape_pol

SW(config-if)# no service-policy input test-policing

SW(config-if)# exit

ACL Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Show the MAC access list configuration.

UBNT# show access-lists mac-acl

SW# show mac access-lists mac-acl

Show the IP access list configuration.

UBNT# show access-lists ip-acl

SW# show ip access-lists ip-acl

*MAC ACL Configuration

UBNT(config)# mac access-list mac-acl

UBNT(config-mac-acl)# 10 permit any 0000.aaaa.0001 ffff.ffff.ffff any

UBNT(config-mac-acl)# 20 permit any 0000.aaaa.0002 ffff.ffff.ffff any

UBNT(config-mac-acl)# no sequence 20

UBNT(config-mac-acl)# exit

SW(config)#mac access-list extended mac-acl

SW(config-ext-macl)#permit any host 0000.aaaa.0001

SW(config-ext-macl)#permit any host 0000.aaaa.0002

SW(config-ext-macl)#no permit any host 0000.aaaa.0002

SW(config-ext-macl)#exit

IP ACL Configuration

SW(config)# ip access-list ip-acl

SW(config-ip-acl)# 10 permit ip 192.168.10.0/24 any

SW(config-ip-acl)# 20 deny tcp any any eq 8080

SW(config-ip-acl)# exit

SW(config)#ip access-list extended ip-acl

SW(config-ext-ipacl)#permit ip 192.168.10.0 0.0.0.255 any

SW(config-ext-ipacl)#deny tcp any any eq 8080

SW(config-ext-ipacl)#exit

Apply MAC ACL and IP ACL to the specific interface.

UBNT(config-mac-acl)# interface swp1

UBNT(config-if)# mac access-group mac-acl in

UBNT(config-if)# ip access-group ip-acl in

UBNT(config-mac-acl)# exit

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# mac access-group mac-acl in

SW(config-if)# ip access-group ip-acl in

SW(config-if)# exit

Remove MAC ACL and IP ACL from the specific interface.

UBNT(config-mac-acl)# interface swp1

UBNT(config-if)# no mac access-group in

UBNT(config-if)# no ip access-group in

UBNT(config-mac-acl)# exit

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# no mac access-group mac-acl in

SW(config-if)# no ip access-group ip-acl in

SW(config-if)# exit

STP; RSTP Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Display Spanning Tree information.

UBNT# show spanning-tree stp

SW# show spanning-tree

Display a brief summary about STP.

UBNT# show spanning-tree interface brief

SW# show spanning-tree brief

Display the STP interface status and configuration of specified interface.

UBNT# show spanning-tree interface swp1

SW# show spanning-tree interface gigabitEthernet 1/0/1

Display Rapid Spanning Tree information.

UBNT# show spanning-tree rstp

SW# show spanning-tree

Configure Spanning Tree Properties.

UBNT(config)# spanning-tree

UBNT(config)# spanning-tree mode stp

UBNT(config)# spanning-tree priority 32768

UBNT(config)# spanning-tree forward-time 15

UBNT(config)# spanning-tree max-age 20

UBNT(config)# spanning-tree hello-time 2

UBNT(config)# spanning-tree transmit hold-count 4

UBNT(config)# spanning-tree pathcost-method long

UBNT(config)# exit

SW(config)# spanning-tree

SW(config)# spanning-tree mode stp

SW(config)# spanning-tree priority 32768

SW(config)# spanning-tree forward-time 15

SW(config)# spanning-tree max-age 20

SW(config)# spanning-tree hello-time 2

SW(config)# spanning-tree transmit hold-count 4

SW(config)# spanning-tree pathcost-method long

SW(config)# exit

Specify that the Rapid STP is enabled.

UBNT(config)# spanning-tree mode rstp

SW(config)# spanning-tree mode rstp

Disable Spanning Tree globally.

UBNT(config)# no spanning-tree

SW(config)#no spanning-tree

*Enable or disable BPDU Guard for an interface.

UBNT(config)# interface swp1.1

UBNT(config-if)# spanning-tree bpdu-guard

UBNT(config-if)# no spanning-tree bpdu-guard

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# spanning-tree bpduguard enable

SW(config-if)# spanning-tree bpduguard disable

*Enable or disable Loop Guard for an interface.

UBNT(config)# interface swp1.1

UBNT(config-if)# spanning-tree loopback-detection

UBNT(config-if)# no spanning-tree loopback-detection

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# spanning-tree loopguard default

SW(config-if)# no spanning-tree loopguard default

*Enable or disable Root Guard for an interface.

UBNT(config)# interface swp1.1

UBNT(config-if)# spanning-tree root-guard

UBNT(config-if)# no spanning-tree root-guard

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# spanning-tree guard root

SW(config-if)# no spanning-tree guard root

MSTP Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Display Multiple Spanning Tree configuration information.

UBNT# show spanning-tree mst configuration

SW# show spanning-tree mst configuration

Display Multiple Spanning Tree specific instance information.

UBNT# show spanning-tree mst 1 status

SW# show spanning-tree mst 1

Displays a brief summary about specific MSTP instance.

UBNT# show spanning-tree mst 1 interface brief

Configure Multiple Spanning Tree Properties.

UBNT(config)# spanning-tree mode mst

UBNT(config)# spanning-tree mst max-hops 22

UBNT(config)# spanning-tree mst name test_inst

UBNT(config)# spanning-tree mst revision 32768

SW(config)# spanning-tree mode mst

SW(config)# spanning-tree mst max-hops 22

SW(config)# spanning-tree mst configuration

SW(config-mst)# name test_inst

SW(config-mst)# revision 32768

SW(config-mst)# exit

Configure instance priority, and add VLAN 100 to MST instance 2.

UBNT(config)# spanning-tree mst 2 priority 61440

UBNT(config)# spanning-tree instance 2 domain 100

SW(config)# spanning-tree mst 2 priority 61440

SW(config)# spanning-tree mst configuration

SW(config-mst)# instance 2 vlan 100

SW(config-mst)# exit

*STP/MSTP interface related commands for special interface(swp1) in specific vlan(100).

UBNT(config-if)# interface swp1.100

UBNT(config-if)# spanning-tree link-type point-to-point

UBNT(config-if)# spanning-tree cost 10000

UBNT(config-if)# spanning-tree port-priority 32

UBNT(config-if)# spanning-tree edge-port

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# spanning-tree link-type point-to-point

SW(config-if)# spanning-tree mst <instance-id> port-priority 32

SW(config-if)# spanning-tree mst <instance-id> cost 10000

SW(config-if)# spanning-tree portfast

Port Error Disable / Auto Recovery Commands

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Display the time period after which the interfaces are enabled for 'errdisable' conditions.

UBNT# show errdisable recovery

SW# show errdisable recovery

Display the reason for the 'errdisable' status.

UBNT# show errdisable detect

SW# show errdisable detect

Configure 'errdisable' recovery interval.

UBNT(config)# errdisable recovery interval 400

SW(config)# errdisable recovery interval 400

*Enable or disable the BPDU guard 'errdisable' recovery condition.

UBNT(config)# errdisable recovery cause bpduguard

UBNT(config)# no errdisable recovery cause bpduguard

SW(config)# errdisable recovery cause bpduguard

SW(config)# no errdisable recovery cause bpduguard

DHCP Guard / DHCP Snooping (Cisco)

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Display DHCP guard settings.

UBNT# show ip dhcp guard

SW# show ip dhcp snooping binding

Enable or disable DHCP Guard.

UBNT(config)# ip dhcp guard

UBNT(config)# no ip dhcp guard

SW(config)# ip dhcp snooping

SW(config)# no ip dhcp snooping

Add or remove trusted DHCP server to special VLAN (Cisco uses the trust interface approach).

UBNT(config)# ip dhcp guard vlan 23 server 172.16.1.1

UBNT(config)# no ip dhcp guard vlan 23 server 172.16.1.1

SW(config)# ip dhcp snooping vlan 23

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# ip dhcp snooping trust

SW(config-if)# no ip dhcp snooping trust

ARP

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Display ARP table.

UBNT# show arp

SW# show ip arp

Configure ARP aging time globally and per specific interface.

UBNT(config)# arp aging-time 300

UBNT(config)# int swp1

UBNT(config-if)# arp aging-time 3600

UBNT(config-if)# exit

SW(config)# arp timeout 300

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# arp timeout 3600

SW(config-if)# exit

Add or remove static ARP entry.

UBNT(config)# ip arp 10.1.1.1 44:d9:e7:9e:b6:db port swp1

UBNT(config)# no ip arp 10.1.1.1 44:d9:e7:9e:b6:db

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# ip arp 10.1.1.1 44:d9:e7:9e:b6:db

SW(config-if)# no ip arp 10.1.1.1 44:d9:e7:9e:b6:db

Clear the ARP table.

UBNT# clear arp all

SW# clear ip arp

DHCP Client/Static IP

Back to Top

Command Description

USW-Leaf Command

Cisco Command

Overview all IPv4 interfaces on the switch.

UBNT# show ip interface brief

SW# show ip interface brief

Enable/Disable DHCP Client on bridge-domain interface.

UBNT(config)# interface bridge 1

UBNT(config-if)# ip address dhcp

UBNT(config-if)# no ip address dhcp

UBNT(config-if)# exit

SW(config)# interface vlan1

SW(config-if)# ip address dhcp

SW(config-if)# no ip address dhcp

SW(config-if)# exit

Configure/Remove static IP address on interface.

UBNT(config)# interface swp1

UBNT(config-if)# ip address 172.16.0.1/24

UBNT(config-if)# no ip address 172.16.0.1/24

UBNT(config-if)# exit

SW(config)# interface gigabitEthernet 1/0/1

SW(config-if)# ip address 172.16.0.1 255.255.255.0

SW(config-if)# no ip address 172.16.0.1

SW(config-if)# exit

IP Route(Static)

Command Description

USW-Leaf Command

Cisco Command

Display IPv4 routing table.

UBNT# sh ip route

SW# show ip route

Configure/Remove default static route.

UBNT(config)# ip route 0.0.0.0/0 192.168.1.1

UBNT(config)# no ip route 0.0.0.0/0 192.168.1.1

SW(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.1

SW(config)# no ip route 0.0.0.0 0.0.0.0 192.168.1.1

Configure/Remove static route to specific network.

UBNT(config)# ip route 172.16.1.0/24 192.168.1.1

UBNT(config)# no ip route 172.16.1.0/24 192.168.1.1

SW(config)# ip route 172.16.1.0 255.255.255.0 192.168.1.1

SW(config)# no ip route 172.16.1.0 255.255.255.0 192.168.1.1

Configure static route with administrative distance.

UBNT(config)# ip route 172.16.1.0/24 192.168.1.1 15

SW(config)# ip route 172.16.1.0 255.255.255.0 192.168.1.1 15

Configure/Remove null0(blackhole) route.

UBNT(config)# ip route 172.16.1.0/24 null0

UBNT(config)# no ip route 172.16.1.0/24 null0

SW(config)# ip route 172.16.1.0 255.255.255.0 null0

SW(config)# no ip route 172.16.1.0 255.255.255.0 null0

Configure/Remove ICMP reject route.

UBNT(config)# ip route 172.16.1.0/24 reject

UBNT(config)# no ip route 172.16.1.0/24 reject

NA

Overview

This article lists the ports used by theUniFi Network Controller. To learn how to change ports please see this article: UniFi - Change Default Ports for Controller and UAPs.By default, the UniFi Controller will operate on the ports listed in the following sections. This is applicable to a UniFi Network Controller installed on the UniFi Cloud Key as well as other hosts.

Table of Contents

Local Ingress Ports

Ingress Ports Required for L3 Management Over the Internet

Egress Ports Required for UniFi Remote Access

Related Articles

Local Ingress Ports

Back to Top

TCP or UDP

Port Number

Usage

UDP

3478

Port used for STUN.

TCP

8080

Port used for device and controller communication.

TCP

8443

Port used for controller GUI/API as seen in a web browser

TCP

8880

Port used for HTTP portal redirection.

TCP

8843

Port used for HTTPS portal redirection.

TCP

6789

Port used for UniFi mobile speed test.

TCP

27117

Port used for local-bound database communication.

UDP

5656-5699

Ports used by AP-EDU broadcasting.

UDP

10001

Port used for device discovery

UDP

1900

Port used for "Make controller discoverable on L2 network" in controller settings.

UniFi - Changing Default Ports for Controller and UAPs

NOTE:Although TCP 22 is not one of the ports the UniFi Network Controller operates on by default, it is worth mentioning in this article since it isthe port used when UniFi devices or the controller is accessed via SSH.

Ingress Ports Required for L3 Management Over the Internet

Back to Top

TCP or UDP

Port Number

Usage

UDP

3478

Port used for STUN.

TCP

8080

Port used for device and controller communication.

TCP

8443

Port used for controller GUI/API as seen in a web browser

TCP

8880

Port used for HTTP portal redirection.

TCP

8843

Port used for HTTPS portal redirection.

TCP

6789

Port used for UniFi mobile speed test.

NOTE:These ports need to be open at the gateway/firewall as well as on the controller host. This would be achieved by creating port forwards on the gateway/firewall where the controller host is located.

Egress Ports Required for UniFi Remote Access

Back to Top

TCP or UDP

Port Number

Usage

UDP

3478

Port used for STUN.

TCP/UDP

443

Port used for Remote Access service.

TCP

8883

Port used for Remote Access service.

NOTE:In most cases, these ports will be open and unrestricted by default.

Related Articles

Back to Top

Overview

Readers will learn how to create a Bridged interface on an EdgeRouter.

EdgeRouter - Hardware Offloading

NOTES & REQUIREMENTS:

Applicable to the latest EdgeOS firmware on all EdgeRouter models. Please see the Related Articles below for more information.

Device used in this article:

EdgeRouter-4 (ER-4)

Creating a Bridged Interface

Back to Top

Bridged interface are used to place multiple physical ports on the same LAN, similar to how a switch functions.

Generally, it is not recommended to bridge ports as it will greatly reduce the performance. If multiple ports need to be placed on the same LAN, it is advisable to use a router with a built-in switch-chip such as the ER-X, ER-X-SFP, ER-10X, EP-R6, ER-12 or ER-12P.

ATTENTION: Packets passed through a bridged interface are not eligible for offloading on some EdgeRouter models. See the Hardware Offloading article for more information.

1. Enter configuration mode.

configure

2. Delete the existing configuration from the interfaces that are to be added to the bridge group.

delete interfaces ethernet eth1

delete interfaces ethernet eth2

delete interfaces ethernet eth3

set interfaces ethernet eth1

set interfaces ethernet eth2

set interfaces ethernet eth3

3. Commit the changes.

commit

4. Create a bridge interface (br0) and assign it an IP address.

set interfaces bridge br0 address 192.168.1.1/24

5. Add the physical interfaces to the bridge group.

set interfaces ethernet eth1 bridge-group bridge br0

set interfaces ethernet eth2 bridge-group bridge br0

set interfaces ethernet eth3 bridge-group bridge br0

6. Commit the changes and save the configuration.

commit ; save

Related Articles

Back to Top

Intro to Networking - How to Establish a Connection Using SSH

Overview

This article describes how to adopt a UniFi Security Gateway (USG) into an existing network, and replacing analready functioning router. For first time setup where an existing router is not being replaced, please use the USG's Quick Start Guide (QSG), followed by the UniFi User Guide, both available for download in the Documentation section of our Downloads page. If additional information is required, please see the UniFi - Device Adoption article.

UniFi - Advanced Adoption of a "Managed By Other" Device

NOTES & REQUIREMENTS:This article applies to the all USG models: UniFi Security Gateway, UniFi Security Gateway Pro or UniFi Security Gateway XG.

Table of Contents

Introduction

Plan the Deployment

Upgrading Firmware Before Adoption

Configure the LAN Network

Change the USG LAN IP Before Adoption

Adopt the USG and Configure the WAN

Related Articles

Introduction

Back to Top

With gateway devices having a static LAN IP, the process of adopting a USG can differ from that of a UniFi Access Point (UAP) and a UniFi Switch (USW) in that it may require some initial IP configuration prior to adoption. This article will guide users through the process.

Plan the Deployment

Back to Top

When deploying into an existing network, the USG will replace thecurrent router or firewall device. The USG's WAN will plug into theInternet connection and its LAN into the switch for theinternal network.

IMPORTANT:When replacing a current router, the USG will substitute it and take over its IPs,so to prevent issues during the process,remove the old router before attempting to adopt.

If anInternet Service Provider's (ISP) modem is currently acting as therouter, there are additional considerations in the modem’s configuration. It is usually best to put themodem into bridge or passthrough mode, so the USG’s WAN obtains thepublic IP, and themodem’s involvement is limited to bridging. See themodem’s and ISP’s documentation for instructions and options, as these can vary widely. Thecurrent router’s LAN subnet and IP will need to change, as it will no longer be connected directly into theLAN network.

Upgrading Firmware Before Adoption

Back to Top

To upgrade the firmware before adoption an SSH client is required. The USG will need internet access to complete the upgrade process.

1. Open your SSH client and open up a session to 192.168.1.1.

2. Log in with the default username and password of "ubnt".

3. Use the following command:

upgrade LINK_TO_FIRMWARE_HERE

Find the different USG models' Downloads page here: USG, USG Pro, USG-XG-8.

To find the firmware link, navigate to the downloads page. From here, select download button shown below.

Accept the terms if you wish to proceed. Then selectCopy URL. This URL will be used in step 3 above.

After entering the upgrade command the USG will reboot with the newest firmware image. If the USG has not been adopted it will still be in a default state.

Configure the LAN Network

Back to Top

To configure the IP and other LAN parameters that will be deployed to the USG once adopted, launchthe UniFi Controller. Once there:

Go to Settings >Networks

Find the network you wish to edit, and click on Edit, underActionson the far rightof the LAN table.

Set the IP and DHCP parameters as desired, and click Save.

Now the configuration is ready to deploy to the USG. It may be adopted now.

Change the USG LAN IP Before Adoption

Back to Top

If the controller is on a subnet other than the USG’s default 192.168.1.0/24, it is necessary to change the USG’s LAN IP so the controller and USG can communicate. To do so, follow these steps (for USG version 4.3.60 and newer):

Go to https://192.168.1.1 on your browser.

It will prompt you to enter your username and password. Use ubnt/ubnt if device is in default state.

Go to the Configuration section and edit the LAN IP and DHCP server parameters as necessary.

If the USG is using an older version prior to 4.3.60 or if for some reason performing this configuration via CLI is preferred, click here to see the CLI steps. It is recommended to always upgrade to the newest firmware available to avoid security issues.

1. Connect a computer to the LAN NIC (LAN port) of the USG. It will obtain a 192.168.1.x IP from DHCP.

2. SSH into 192.168.1.1 using username and password combination ofubnt / ubnt.See this article for more on default username and password and this article if you need guidance with SSH.

3. For this example, thecontroller is on 10.0.0.50/24, so let's change the USG’s LAN IP to 10.0.0.1.Choose an available IP within the subnet of thelocal controller.

4. In the SSH session, run the following:

For USG:

configure

set interfaces ethernet eth1 address 10.0.0.1/24

delete interfaces ethernet eth1 address 192.168.1.1/24

commit

For USG Pro:

configure

set interfaces ethernet eth0 address 10.0.0.1/24

delete interfaces ethernet eth0 address 192.168.1.1/24

commit

Now the USG’s LAN IP is 10.0.0.1/24. TheSSH session will drop.

NOTE:On the USG Pro, if the controller is in the 192.168.2.0/24 subnet, it is necessary to delete the eth2 address 192.168.2.1/24 before committing the changes.

5. Plug the USG’s LAN into the network with the controller at 10.0.0.50

6. Go to the UniFi Controller and adopt it. Note: Before adopting, make sure you changed the LAN network in the Controller Settings as described above, so it doesn’t revert back to the default controller configuration of 192.168.1.1/24.

Adopt the USG and Configure the WAN

Back to Top

To adopt the USG, navigate to the Devices section using the side menu on the left.

Find the USG and click the Adopt button. The controller will provision the configuration as currently defined in thecontroller and reboot. While it’s doing that, configure your WAN interface specifics.

User Tip:If you experience an issue where the status of the device loops from trying to adopt > disconnected > trying to adopt, it may be an issue with the firewall of the machine hosting the UniFi Network Controller. Port 8080 must be open for inbound traffic. Either open up that port or turn off the firewall if that’s a possibility. See what ports are needed for UniFi here: UniFi - Ports Used.

Navigate to Settings > Network > WAN and edit the network.In the Connection Type drop-down, pick the appropriate type for your Internet connection. Refer to information provided by your ISP to obtain this information. If using a static IP WAN, make sure to also define two DNS servers here. This is optional for DHCP and PPPoE WANs, as your ISP will likely assign a DNS server, but can be manually specified in that case if desired.

After the WAN configuration provisions to the USG, plug the USG's WAN port into the ISP modem/router. For cable and DSL service, it is often required to power cycle the modem after connecting a new gateway device. In those cases, power cycle the modem after plugging in the USG’s WAN.

After the modem boots back up, you should have Internet connectivity from your LAN via the USG. Verify the WAN information in the controller (following step 2 once again).

Related Articles

Back to Top

UniFi - Device Adoption

UniFi - Accounts and Passwords for Controller, Cloud Key and Other Devices

Intro to Networking - How to Establish a Connection Using SSH

Overview

This article will answer the question of how to access the UniFi Network Controller on the UDM platform by IP or hostname.

UniFi - USG Port Forward: Port Forwarding Configuration and Troubleshooting

NOTES & REQUIREMENTS:

This article applies only to the UniFi Dream Machine Pro (UDM-Pro).

Table of Contents

Introduction

Network Diagram

Steps: How to Access the Controller via IP

Testing & Verification

Related Articles

Introduction

Back to Top

Users may wish to access the UniFi-OS local portal by IP in certain situations. Since the local portal is on the UDM Pro, and not on a host that is on the LAN, a firewall pin-hole is suggested instead of port forwarding as would be done on other hosts (see Related Articles below).

NOTE:Applying a port forward rule to a UDM Pro LAN IP will provision a destination network address translation (DNAT) rule and is not recommended.

Network Diagram

Back to Top

Steps: How to Access the Controller via IP

Back to Top

1. Open the UniFi Network Controller.

2. Navigate to Settings > Routing & Firewall > Firewall > WAN_LOCAL.

3. Select "Create New Rule".

4. Fill in the fields with the following information:

Action : Accept

IPv4 Protocol : TCP

Rule Applied : Before pre-defined rules

Destination : Create a new port group withport 443 in the group

OPTIONAL PARAMETERS:

If desired, also apply a "source restriction" to this rule to make the access only available to certain IP addresses.

When restricting direct access to UniFi-OS on a dual-WAN configuration also indicate the proper destination IP in this firewall rule.

5. Click"Save".

Testing & Verification

Back to Top

To verify that the firewall pin-hole has been properly configured, try to access the UDM Pro by its WAN IP or hostname associated with the IP. If the test does not provide the desired results, check any source IP restrictions configured. If the rule appears to be applied properly, advanced troubleshooting with tcpdump may provide the clearest indication of the issue.

CLI: Access the command line interface (CLI). You can do this by using a program such as PuTTY.

WAN 1

tcpdump -npi eth8 dst port 443 and host <WAN1_IP_ADDRESS_HERE>

WAN 2

tcpdump -npi eth9 dst port 443and host <WAN2_IP_ADDRESS_HERE>

For further support please reach out to the UniFi Support Team.

Related Articles

Back to Top

Overview

This article provides details about UNMS's generic key and how it works, as well as describing the fundamentals of the device registration process.

UNMS - Device Discovery

NOTES & REQUIREMENTS

This article applies to the following firmware versions:

EdgeRouter: 1.9.7+ /EdgeSwitch: 1.7.3+ /UFiber OLT: 1.0.0+ /airMAX (AC): 8.4.1+ /airMAX (M): 6.1.3+ /airCube: 1.0.0+

Also please note that UNMS doesn't support older airMAX devices with firmware versions 4.x, 5.x or 7.x.

WARNING:For security reasons, never share your UNMS key publicly. If you need to share it for whatever reason, always obscure the hostname and AES string parts of the key.

Table of Contents

Introduction

How to Register a Device via UNMS Discovery

How to Manually Register a Device via Device UI

How to Register a Device via SSH

UNMS Generic Key Details

Behind the Scenes: How Does the UNMS Key Work?

Related Articles

Introduction

Back to Top

The purpose of the UNMS key is to provide a secure communication using AES encryption while telling a device where to look for a UNMS server. The process of device registration using the generic UNMS key and the device specific UNMS key ensures secure communication between the user's devices and UNMS.

How to Register a Device via UNMS Discovery

Back to Top

1. Go to the UNMS Discovery Manager.

2. Fill in the subnet or IP addresses of the devices.

3. Click the START button.

4. Fill in the credentials.

5. Click theCONNECT button.

How to Manually Register a Device via Device UI

Back to Top

This is only necessary if UNMS is not on the same network as the devices being registered and they cannot be found with UNMS Discovery.

1. Open UNMS and go to the Devices section.

2. In the upper, right had side, click the ADD DEVICE button.

3. Click the "Copy UNMS key to clipboard" to copy the key which will be pasted in step 6. The key is the same for all devices.

4. Open the device's administration page.

5. Go to the System or Services section.

6. Paste the UNMS key.

7. Enable the UNMS connection.

8. Save the device configuration.

9. Authorize the device in the UNMS devices list.

How to Register a Device via SSH

Back to Top

ATTENTION: The NTP protocol must be enabled to add the device into UNMS this way

EdgeMAX

admin@ER-X:~$ configure

admin@ER-X# delete service unms disable

admin@ER-X# set service unms connection generic UNMS key

admin@ER-X# commit

admin@ER-X# save

Saving configuration to '/config/config.boot'... Done

airMAX

Danger: Be extremely careful when changing airMAX devices'configurations. There is no validation before this manual change applies and a mistake in configuration may lead to losing connectivity to the device.

1. Edit device configuration in file /tmp/system.cfg

unms.uri=wss://XX.YY.ZZ.XX:XX+XYZYXZYXYZYXZYXYZXZYXZ+allowSelfSignedCertificate

unms.uri.changed=wss://XX.YY.ZZ.XX:XX+XYZYXZYXYZYXZYXYZXZYXZ+allowSelfSignedCertificate

unms.status=enabled

2. To apply the configuration use command /usr/etc/rc.d/rc.softrestart save

UNMS Generic Key Details

Back to Top

In the following two sections we will discuss what happened in the background as the devices were registered using one of the two processes described above. Here is an example of the UNMS key:

wss:// your.domain.com :443 + n9yU137QSwTzBXnF...9Sk0pC7sDKGnpbxiHRI9W +

The UNMS key consists of several parts (shown in different colors above), each with their own purpose. In the table below the UNMS key appears split in its different parts, and each section's purpose described.

Key Part

Purpose

wss://

WebSocket Secure connection protocol

your.domain.com

Hostname or IP of the server where UNMS runs

:443

Port for devices to access UNMS server

n9yU137QSwTzBXnF...9Sk0pC7sDKGnpbxiHRI9W

Advanced Encryption Standard key (AES key)

Behind the Scenes: How Does the UNMS Key Work?

Back to Top

When a new instance of UNMS is installed, it creates its own UNMS key which is called The Generic UNMS Key. This key represents a pointer for any device being added to the system for the first time. When the generic UNMS key is entered into a device's settings, that device will try to connect to UNMS using the hostname / IP and the port part of that key (see the third row of the table above).

If the connection is successful, the AES key part of UNMS key is used for secure communication between the device and UNMS. When the connection is established for the first time then a new AES key is generated for the device. This new AES key replaces the original AES key in the generic UNMS key, creating The Device Specific UNMS Key. Then the device specific UNMS key rewrites the generic UNMS key on the device and UNMS stores the device’s MAC address and AES key in PostgreSQL database.

From that point forward, each time the device wants to communicate with UNMS, the AES key part of the device specific UNMS key is used and UNMS uses the AES key from the PostgreSQL database for decryption/encryption.

Related Articles

Back to Top

Overview

This article answers some of the most common questions about airFiber LTU.Click on the question that interests you to expand and collapse the answers.This articlewill be updated as more common questions are brought to our attention. If you feel that a question is missing, please click thefeedback button at the bottom of the pageand let us know!

Frequently Asked Questions

Are LTU products compatible with other airMAX or airFiber products?

LTU is a completely new platform based on proprietary technology, which doesn't use 802.11 protocol, making it incompatible with 802.11n and 802.11ac devices. For that reason it is NOT compatible with airMAX M5 nor with airMAX 5AC.

On the other hand, although LTU is based on airFiber technology, it uses a different protocol for communication, making it incompatible with other 5GHz airFiber products such as AF-5X or AF-5/5U.

Does LTU support licensed frequencies in the United States?

Currently, the LTU products are capable of operating on both 4.9GHz and 6GHz bands but are not approved for these licensed bands under FCC regulations.

What products are part of the LTU family?

LTU family is composed today of several products:

LTU-Rocket

LTU-Pro

LTU-Lite

LTU-LR

AF-5XHD

However, new products are coming this year.

What is the input voltage range of the airFiber LTU products?

Both AF-5XHD and the AF-LTU support any voltage from +18Vdc to +56Vdc. Just make sure the PoE source can deliver at least 24 Watts to compensate any voltage drop because of cable length.

Does AF-5XHD support NxN mode?

The current firmware version doesn't support NxN mode (multiplexing). However, we are working on new firmware versions that will support NxN mode. Target for release is 2020.

What is the difference between the AF-5XHD and the AF-LTU?

There are four main differences:

Dual RJ45 port only available in the AF-5XHD. Both ports can be used for PoE IN and the Config port can be configured to also work as DATA port, but both RJ45 ports don't support bonding.

Connectorization: AF-5XHD comes with 3 RP-SMA ports, the one in the middle for GPS, and the other two for chain 0 and chain 1, for antennas like the RocketDish or AF-5G23/30/34-S45 antennas. On the other hand, the AF-LTU comes with a waveguide connector for waveguide antennas, like the PrismAP antennas. Also, the AF-LTU comes with a built-in GPS antenna.

Only the AF-5XHD offers IP67 protection (optional adapter could be required)

here

NOTE:AF-5XHD chains can work in V&H or Dual Slant polarization depending on the antenna you are using.

What are the differences between the AF-5X and the AF-5XHD

AF-5XHD includes all AF-5X features but NxN mode and TDD Frequency Split (both under development for the HD version), plus:

1024QAM modulation on the entire 5GHz band (will soon support 4096QAM modulation)

Extended frequency range from 4800MHz to 6200MHz for licensed applications (only for International units)

Built-in Accelerometer for better alignment andtampering detection

Bluetooth for easier configuration from Smartphones

Up to 1+Gbps performance and 2,000,000pps processing power

More channel width options adding 60, 80 and 100MHz channels

Improved interference mitigation

Active Live airView (doesn't drop the wireless link for scan)

More powerful Web UI

Dual PoE IN

Re-configurable Config port to operate as DATA port

Among many others

What antennas are compatible with each LTU product?

LTU-Rocket supports connectorizedRP-SMA MIMO antennas including but not limited to: AF-5G23-S45, AF-5G30-S45, AF-5G34-S45,RD-5G30, RD-5G30-LW, RD-5G34, AM-5AC21-60, AM-5AC22-45, AM-5G16-120*, AM-5G17-90*, AM-5G17-90A*, AM-5G19-120*, AM-5G20-90*, AM-M-V5G-TI, AM-V5G-Ti.

AF-LTU supports Ubiquiti waveguide antennas, including but not limited to:PrismAP-5-30, PrismAP-5-45, PrismAP-5-60, PrismAP-5-90 and LTU-Extend (27dBi dish) antennas.

* Supported antenna but not recommended.

What LTU models support Station mode?

LTU-Lite, LTU-LR, LTU-Pro, AF-LTU and AF-5XHD.

What is the maximum number of CPE per AP in LTU PtMP mode?

The maximum number of active CPEs per AP in PtMP mode is 250 subscribers. However, if you want to offer high-speed services (over 50Mbps per customer) we highly recommend to limit the number of CPEs per AP to 100, or even lower if you offer a low oversell ratio.

What kind of services are supported in LTU networks?

Any IP-based service should work fine on LTU networks, including but not limited to:

High-Speed Internet

IPTV

VoIP

IP Video surveillance

Machine to Machine communication based on TCP/IP

What is the maximum link distance in Point to Point (PtP) and Point to MultiPoint (PtMP) Modes?

There's no strict limit on the platform. However, there are two factors that will determine the maximum link distance (always assuming clear Line of Sight):

The antenna gain of each side (the higher the antenna gain the longer the link)

Tx Power (the higher the Tx Power in most cases will allow longer distance links). This value is determined by your country and could vary depending on the frequency you are using.

Tips:

In order to simulate the expected link capacity for your link, please simulate it using our free link planning tool, https://airlink.ui.com

Always select the right country code for your installation, using a different country code could violate local telecommunication laws and involve high fines.

What is the expected latency?

It depends on the Frame Length selected, but using the shortest Frame Length average latency will be 2-3ms under normal circumstances.

How do I synchronize my network?

GPS Sync only needs to be enabled in the Access Point, there's no need to enable it on the CPEs.Simply enable the GPS Sync option in the Wireless section and make sure Duty Cycle and Frame Length is the same in all the APs you wish to synchronize, like so:

Most of the data on my network is "download heavy", why can't I have higher ratios like 85/15 or 95/5 for example?

TCP-based download traffic requires TCP ACKs to be sent using the UL. In a PtMP network, there will be multiple TCP downloads going on, each requiring TCK ACKs being sent using the UL. Having enough time on the UL to allow multiple CPEs to send TCP acknowledgments, reduces the latency experienced by TCP, thereby increases the actual DL throughput.

As an example:

There are 50 clients connected to an AP. If 10 of these clients are simultaneously downloading and the UL allocation is extremely small like in 95/5, the UL time may only be enough to carry the TCP ACKs of one of the stations. The others will need to wait for their turn, which will arrive according to the TDD framing cycle. But during this time the TCP may stall its window and not send any further traffic until the ACKs are received. This causes underutilization of DL.

Hence extremely low UL allocations may end up reducing the effective throughput of the DL on larger PtMP networks.

Is GPS Sync built in or is there a cost associated with it?

GPS Sync is built in, there is no cost to use this technology.

Can I manage and monitor my LTU products with UNMS?

Yes, UNMS (version 0.12.0) offers basic monitoring for LTU products. Newer UNMS versions will support configuration of most important LTU settings.

What is the maximum MTU size allowed by LTU products?

LTU products support Jumbo Frames up to 9000 bytes in the DATA interface.

NOTE:ifconfig info will only display 1500 bytes because that command only shows MTU size for the interface connected to the CPU. Since DATA traffic pass through an ASIC, which is not displayed in theifconfig command, it will not show real MTU size. Just make sure you set MTU value above 1600 and Jumbo Frames support will be enabled.

Does LTU support SNMP?

Yes, MIBs can be downloaded for airFiber5XHD firmware v1.1.2.

Can you connect the AF5X to the AF5XHD?

No, the AF5XHD is a brand new architecture that is not compatible with the AF5X.

Overview

This article describes what an ideal network structure should look like from a UNMS standpoint.

UCRM - WISP Management Platform Help Articles

NOTES & REQUIREMENTS:This article applies to UNMS 1.0.0 with integrated CRM module.

Table of Contents

Introduction

UNMS Terminology

Example Deployment Scenarios

Related Articles

Introduction

Back to Top

The goal of this article is to exemplify what type of network structure UNMS has been designed for; and what an ideal topology looks like from a UNMS point of view. Please note that UNMS is primarily designed for Internet Service Providers (ISP) who want to take full advantage of the benefits Ubiquiti devices provide. UNMS strives to offer advanced, fully automated functions that need a specific network topology in order to run as they were intended to. It is certainly possible to run UNMS in different types of networks and deployments, but some features may be unavailable or perform suboptimally.

UNMS Terminology

Back to Top

The UNMS side of the integrated UNMS-UCRM application (referred to as the "Network" in the rest of this guide) is exclusively dedicated to the physical structure and real topology of a network. The focus is either on backbone devices and their placement on towers or buildings, or CPE devices and their location. The CRM part of the application takes care of the business side: management of real people, services, and customers along with their personal data.

Network

Device: a physical device like a router, switch or wireless antenna. It can be a Ubiquiti device or a manually specified 3rd party device.

Site: a location where a device is placed. It can be a tower, roof, building or even a roompretty much any geographical spot with an address. Sites are key components of a network and they create its backbone.

Client Site: a specific type of location (site) with an address, where there are devices providing internet to a single CRM client. Client Sites can be paired with services defined in CRM, allowing business-oriented operations, such as blocking a customer when payment is due or setting a traffic Shaping on specific devices associated with a particular customer.

NOTE:The term Client Site will be first introduced in version 0.14.0. Currently, the structure is defined by Sites (which will remain the same) and Clients (which will be turned into Client Sites for better clarity).

AP: an Access Point is a connection point with the potential to offer an internet connection to several devices.

Stations / Clients:Stations or CPEs are the devices connected to an AP of the airMAX family. Those CPE devices create the endpoints of the network. On the other hand, a home WiFi router like an airCube will have a list of connected devices, called clients. Those are devices that usually belong to a customer (like a mobile phone or laptop) and are not managed via UNMS. So a possible connection between these could be:airMAX AP > Station (CPE) > home WiFi (airCube) > client (laptop).

NOTE:Please be aware that there is a difference between a UNMS client, which is a client device and the CRM client which represents a customer paying for a Service (more info in the CRM section below).

GW: A gateway in a network. There can be several gateways in the network. These are necessary for advanced features such as client suspension, setting up a traffic Shaping client or measuring the throughput with NetFlow protocol. UNMS facilitates a way to automatically configure NetFlow usingan EdgeRouter with firmware 2.0.1. or higher.

CRM

Client: a person or a company, who is receiving a service such as the Internet or VoIP, for example. A client can have several services in different locations with different parameters.

NOTE: Notice the difference between a UNMS client, which is a client device such as a laptop; and the CRM client which basically means "customer"be it an individual or a company.

Service: One specific internet connection which represents an item on an invoice and is providing a connection to one or more devices in a specific location. In the future (UNMS 1.0.0. with integrated UCRM 3.0.0), CRM will allow pairing this Service to a Client Site in the UNMS structure and subsequently offer some business actions, such as blocking a CRM Client. An action such as blocking would translate into configuration changes of specific devices, that can be easily done thanks to UNMS and this integration.

Example Deployment Scenarios

Single location (Eg. Flat)

A simple deployment, where the customer receives internet service at home. In CRM there will be one client, a real person, with a single service. That service is paired with a specific Client Site in UNMS. The Client Site might contain:

One CPE, connected to an AP which is also assigned to another Site.

Behind that CPE there could be an airCube, for example, which also belongs to the Client Site.

Or instead of the airCube, there might be a 3rd party WiFi router that belongs to the customer. A network element such as that WiFi router can be added to UNMS as a 3rd party device.

Instead of the CPE, the client might have an Optical Network Unit (ONU) like the UFiber Nano G or UFiber loco, connected to an Optical Line Terminal (OLT) such as UFiber OLT or UFiber OLT 4, which is inserted into a Site.

User Tip:

For simple, inexpensive installations it is effective to use the airCube ISP (ACB-ISP).For classic installations where a mesh WiFi network needs to be supported, we would recommend the airCube AC (ACB-AC). For more demanding users it is possible to use AmpliFi, which is not supported by UNMS at this time, but will be added soon.

Larger Area (Eg. Farm)

A farm, a hotel or a school are classic examples of a more complex customer. From the CRM point of view, it is one paying Client, with a single Service for the internet provision. In this example, it is necessary to have all devices which the Client owns, assigned to only one Client Site. The general recommendation for this situation is to use Ubiquiti's Enterprise WiFi solution: UniFi. In the future, it will be possible to integrate a UniFi site as a virtual device into UNMS and to insert such a device into a Client site.

Once that happens, there will be a dashboard of the UniFi site available in UNMS with a direct link to the UniFi Controller. Particular devices will not be manageable directly through UNMS but only via the link to the UniFi Controller. However, the UNMS unified alert system will work seamlessly with this setup.

NOTE: For customers with more complex networks it is possible to use EdgeMAX, airMAX, and other devices: it is just not the primarily supported scenario. For example, using such device configuration may cause the dashboard of that Client Site to be rendered suboptimally.

Multiple locations (Eg. Chain Store)

A chain store is an example of a deployment where a single customer has several locations at a considerable distance with an internet connection. In this case, it is suggested to create separate Services in CRM for each location and pair them with Client Sites in UNMS. Each branch of the chain store can be then treated as a "simple flat" or a more complex "larger area" as described in the previous examples.

Repeater Point

The repeater point is a relatively common scenario which can be confusing at first glance from the UNMS configuration perspective. From the geographical perspective, however, it is a single location, for example, a family house roof with both a PtP connection as well as an AP for local coverage. At the same time, the house itself is connected to the internet. In such cases, it is recommended to model the deployment in such a way that the end of the PtP and AP belong to a Site in this location. The customer's own devices inside the family house belong to a Client Site, which will have the same address as the aforementioned Site.

User Tip:

It is important to mention that UNMS doesn't support a situation where two Client Sites are connected to each other. In order to make the structure clear and readable, the Client Site must always be an endpoint in the network topology. Sometimes it will be necessary to create an artificial duplicate Site, just as described in the repeater point example.

Related Material

Back to Top

Overview

This article will discuss how to use and configure the auto backup function of the UniFi Network Controller. The minimum version of the UniFi Network Controller required for this is 5.1.0.

Table of Contents

Auto Backup Overview

How to Change the Location of Backup File

Related Articles

Auto Backup Overview

Back to Top

Intro to Networking - How to Establish a Connection Using SSH

In the UniFi Network Controller, navigate to Settings > Auto Backup. To start using this feature you must first enable it by turning the toggle to the ON position. This will reveal some configuration options. Choose the frequency of backups and time to run the backup by editingOccurrenceand Occurrence Timezone. Define how many backups (Number of Files) you wish to retain andthe amount and what data you wish to save within these backups.

NOTE:Controllers hosted on Cloud Keys will only be able to enable Auto Backup if there is an SD card inserted in the Cloud Key.

How to Change the Location of the Backup File

Back to Top

The default storage location of the backup file is as follows:

On the Gen2 Cloud Keys autobackups are stored on both the eMMC ( HDD for UCK-G2-Plus ) and SD card if inserted.

/data/autobackup/ (SD card)

/usr/lib/unifi/data/backup/autobackup/ (eMMC/HDD)

On the Gen1 Cloud Key autobackups are saved on the SD card.

/data/autobackup/ (SD card)

For software installs: {data.dir}/backup/autobackup

The location of the backup file cannot be modified in the Controller UI: it must be configured via the system.properties file. To change the default location add the following line to the system.properties file (substituting /some/path with the chosen storage place):

autobackup.dir=/some/path

For a more detailed explanation about the system.properties file please see our Related Articles below.

Related Articles

Back to Top

UniFi - system.properties File Explanation

Overview

This article provides an overview of how VLAN traffic gets tagged on UniFi. If you are searching for how to configure VLANs on UniFi, please see our UniFi - Using VLANs with UniFi Wireless, Routing & Switching Hardware article.

Table of Contents

Tagging and Untagging Traffic

Guest Portals and VLANs

Related Articles

Tagging and Untagging Traffic

Back to Top

So, how does VLAN traffic get tagged on UniFi? In short, the UniFi access point (AP) tags packets when they go out from WLAN to wire. When tagged traffic comes in from the wire, it will untag it and forward it to WLAN. Take in consideration the following points:

Traffic initiated from the AP is untagged and sent through br0 (or bond0 if link aggregation is enabled). This includes management traffic and RADIUS traffic, as described below:

AP <-> Controller (management traffic)

AP <-> RADIUS (when WPA-EAP is used)

Traffic from WLAN without VLAN configured is untagged (the athX is bridged to br0).

Traffic from WLAN with VLAN configured is always tagged (athX bridged to br0.VLAN to eth0.VLAN):

AP <-> RADIUS (when WPA Enterprise is used)

Station -> AP (tags) -> switch

Station <- AP (untags) <- switch

Whether it's redirected (to the guest portal) doesn't matter. When WLAN is configured with VLAN, the traffic will be tagged when it leaves the AP. However, after traffic is tagged by the AP, it's up to you where it should be passed upstream.

Intro to Networking - Introduction to Virtual LANs (VLANs) and Tagging

EXAMPLE

Management network: 10.1.0.0/24

Guest VLAN network: 10.2.0.0/24

Switch

AP connected to port 5 (VLAN 1-untagged and VLAN 5-tagged)

Ubuntu connected to port 1 (VLAN 1-untagged and VLAN 5-tagged)

Controller connected to port 8 (VLAN 1-untagged)

Ubuntu (acting as a Router)

eth0: 10.1.0.2/24, routable to the Internet (gateway 10.1.0.1)

eth0.5: 10.2.0.1/24, NATed to eth0

Controller is at 10.1.0.26.

Guest Portals and VLANs

Back to Top

It's natural to think of a VLAN when guest access is mentioned since guests placed in their own VLAN, are isolated from other parts of the network. However, there are a few technical details worth mentioning talk about.

Let's start with the basic VLAN deployment where the guest portal is not enabled:

UniFi AP tags WLAN->wire traffic.

AP-controller is untagged.

Controller is likely running on untagged interface.

Configured inside the AP: guest --- br0.3 --- eth0.3 --3--+ br0 ------------------+--u,3---port1 corp -----+

DEPLOYMENT EXAMPLE:

port8 connecting to router's DMZ port, add port8 as a member of VLAN 3 and untagging. Enable DHCP server on your DMZ.

port5 connecting to an internal network, have port5 untagged.

So what would happen when the guest portal is enabled with VLAN? When the guest portal is enabled, the UniFi Controller acts as a portal server and the guests will be redirected to http://unifi_ip:unifi_http_portal_port/guest/. Some issues might arise, for example a guest is on VLAN 3, bridged to DMZ, and can't reach unifi_ip:unifi_http_portal_port. This issue could be addressed by adding rules to the router:

Add a route for traffic from DMZ->unifi_ip

Allow DMZ->unifi_ip:unifi_http_portal_port

Related Articles

Back to Top

UniFi - USW: Using VLANs with UniFi Wireless, Routing & Switching Hardware

Overview

This article describes how to back up or migrate UNMS application data.

Table of Contents

Introduction

How to Backup UNMS Application Data

How to Restore UNMS

Related Articles

Introduction

Back to Top

Backing up data is always a good idea, but it is especially important in certain scenarios. For example, when migrating UNMS to a different server, or when testing different features or configurations on UNMS. Performing a backup first is a best practice that allows experimentation without the danger of losing carefully polished settings.

How to Backup UNMS Application Data

Back to Top

For most users, it may be most convenient to use the automatic backup feature available since version 1.0.0. The list of automatic backups is available underSettings -> Backups. At the same place, a fresh backup can be initialized in case the automatic one is too old. It is also possible to apply older backup here.

UNMS - Installation Guide

NOTE:

The UNMS backup combines databases from both Network and CRM modules.

User Tip:

In case users would like to use scripts to perform automated actions like downloading a fresh backup to a remote location, it can be achieved by using the powerful UNMS API.

In order to keep the size of automatic backups manageable, only the essential data is stored. This backup doesn't contain for example stored firmware files. In order to backup, absolutely everything a wholeUNMS data folder can be archived. The folder is located on this path/home/unms/data on the Docker host and includes settings, logs, statistics, images, backups, and SSL certificates. In order, to back upthis data first pause the running containers. Go to the directory, where docker-compose.yml is located (probably /home/unms). Then archive the data and save it somewhere safe. As the final step, unpause the containers.

# go to your UNMS home directory

cd /home/unms

#stop docker containers

sudo /home/unms/app/unms-cli stop

# pack the data directory

sudo tar -cvjSf unms-data.tar.bz2 data

# start docker containers

sudo /home/unms/app/unms-cli start

This set of commands will create an archive for all UNMS settings and data. Then it can be moved to another machine or archive.

Howto Restore UNMS

Back to Top

In the UNMS user interface this can be done from section Settings -> Backups.

If there is no GUI access for some reason, apply the backup from the command line. Please note that the 'unms-data.tar.bz2' from the example above will be needed.

# go to your UNMS home directory

cd /home/unms

#stop docker containers

sudo /home/unms/app/unms-cli stop

#rename the current data folder

sudo mv data data_old

#create the empty data folder

sudo mkdir data

# extraxt the data directory

sudo tar -xvjSf unms-data.tar.bz2 data

# run the installation script (make sure to include any optional tag that was used in previous installation)

sudo curl -fsSL https://unms.com/v1/install > /tmp/unms_inst.sh && sudo bash /tmp/unms_inst.sh

ATTENTION:Automatically create backups should be always the minimal possible size, but manually created ones are not limited in this regard. If the backup file is huge it can take even a couple of hours to apply it.

Related Articles

Back to Top

Overview

This article describes the logic between theBSSID (Basic Service Set Identifier) and corresponding radio's MAC address.

Back to Top

NOTES & REQUIREMENTS: This article applies toGen 1, Gen 2 and Gen 3 UAPs, excluding the Broadcom based models (Gen 1 UAP-AC and UAP-AC-Outdoor). See what Generation your UAP is here.

Table of Contents

Introduction

How to Find Mapping in the UniFi Controller

Related Articles

Introduction

Back to Top

An access point uses multiple MAC addresses for layer 2 communication on the different interfaces. The MAC address of a wireless interface is called the Basic Service Set Identifier (BSSID). A wireless access point needs a way to dynamically create those BSSIDs as it can have different numbers of SSIDs. In general, each radio and network interface has a globally unique MAC address programmed when the AP leaves the factory. The MAC Address rule (including Ethernet, if it has any) is as follows:

For Gen 3: UAP-nanoHD, UAP-IW-HD, UAP-FlexHD, UDM, and UAP-BeaconHD

The default MAC ID (found on the back of the AP) is reserved for ethernet. If the model doesn’t have an ethernet port, such as UAP-BeaconHD, it is still reserved for this purpose.

The 6th byte (counting from right to left) of the default MAC ID indicates the base MAC address of each radio for deriving the BSSID. The base MAC address is derived as follows:

2.4G radio (raX) - 6th byte + 1

5G radio (raiX) - 6th byte + 2

Software uses that base MAC address to derive the BSSID (by changing the 3rd byte) by using the following logic for each radio:

Every subsequent SSID sets the U/L bit (bit 1 of the first octet) to 1, indicating a locally administered MAC address.

In addition, the 3rd byte is determined by the following rule:

MacMSK = b’10001111

3rd byte of (rai0 or ra0) = 3rd bytes of original MAC ID

3rd byte of (raiX or raX, X is non-zero) = (3rd bytes of original MAC ID & MacMSK) + (X << 4). (Where "&" stands for a logical "AND".)

For example, for an an access point like the one in the image to the left, with a MAC ID of 78:8a:20:df:88:70 and four SSIDs: SSID1, SSID2, SSID3, SSID4 (SSID1-2 is for 2.4G, SSID3-4 is for 5G) would use the following mapping:

SSID1: 78:8a:20:df:88:71 (2.4G, ra0, 0xdf = original 3rd byte of MAC ID)

SSID2: 7a:8a:20:9f:88:71 (2.4G, ra1, MacMSK = b’10001111, 0x9f = 0xdf & 0xef + 1 << 4)

SSID3: 78:8a:20:df:88:72 (5G, rai0, 0xdf = original 3rd byte of MAC ID)

SSID4: 7a:8a:20:9f:88:72 (5G, rai1, MacMSK = b’10001111, 0x9f = 0xdf & 0xef + 1 << 4)

Note that this MAC address (78:8a:20:df:88:71) is the MAC of the radio broadcasting SSID1 (and so on and so forth for the other SSIDs), and does not correspond to the MAC address of the wired ethernet port (which is 78:8a:20:df:88:70 in this example case)

For Gen 1, Gen 2, Gen 3 UAPs

Excluding Gen 1 UAP-AC and UAP-AC-Outdoor and Gen 3 UAP-nanoHD, UAP-IW-HD, UAP-FlexHD, UDM, UAP- and BeaconHD)

The first SSID uses the default hardware MAC of the radio

Every subsequent SSID sets the U/L bit (bit 1 of the first octet) to 1, indicating a locally administered MAC address. In addition, it increments the most-significant 4 bits of the first octet by (SSID index - 2).

For example, an AP with MAC address 80:2a:a8:17:74:b5 and four SSIDs: SSID1, SSID2, SSID3, SSID4 would use the following mapping:

SSID1: 80:2a:a8:17:74:b5

SSID2:82:2a:a8:17:74:b5

SSID3: 92:2a:a8:17:74:b5

SSID4: a2:2a:a8:17:74:b5

Note that this MAC address, 80:2a:a8:17:74:b5, is the MAC of the radio broadcasting those SSIDs, and does not correspond to the MAC address of the wired ethernet port. The ethernet port is usually close by (i.e. modification of one of the octets by 1 or 2, depending on the number of radios), but it is not defined which octet gets modified.

How to Find Mapping in the UniFi Network Controller

1. Navigate to theDevices section of the controller.

2. Click on the AP of your choice to reveal the AP's properties panel.

3. In the properties panel, within the Details tab check out theWLANSsection. There is a BSSID column where this information is available.

Please note that this is a basic example of a network with one wireless network.

Overview

This article covers some basics about connecting to the UniFi Protect Cloud interface at https://protect.ui.com/, and the steps to diagnose and then solve issues regarding this connection. It is important to read and follow the initial diagnostics section, followed by the network, operating system, and browser troubleshooting. If only one is aspect is investigated the solution might be missed.

Table of Contents

Introduction

General Network Connectivity Requirements

Initial Connectivity Diagnostics

Network Troubleshooting

Troubleshooting Android Devices

Troubleshooting iOS Devices

Troubleshooting Browser Connectivity

Introduction

Back to Top

UniFi Protect’s Hybrid Cloud uses WebRTC technology to facilitate direct, configuration-free, and encrypted peer-to-peer connections between the client device (computer browser or mobile app) and the Protect controller. WebRTC allows connections to be established through NAT and Firewalls (such as a UniFi Gateway) without requiring explicit port forwarding or editing firewall rules.

Under normal circumstances, UniFi Protect users should not need to make any changes to their network environment, device or client configuration in order to connect locally or remotely using the Cloud interface at https://protect.ui.com/ or any of the mobile apps. That said, certain network environments, third-party software, or client-side settings may interfere. This article provides an overview of known causes for connectivity problems and potential solutions or workarounds that can be implemented.

If you are interested in the technical aspects of WebRTC, please visit https://webrtc.org/

General Network Connectivity Requirements

Back to Top

For a WebRTC connection to be established, the conditions listed below must be met by both networks: the one where the Protect controller is connected, as well as the one where the client is connected. The client may refer to your home network, your cellular carrier’s network, or your remote WiFi network such as the one at your workplace or public WiFi.

Reliable access to Internet and DNS service.

Adequate bandwidth for basic connectivity and video transport.

Ability to establish outbound TCP connections on port 443 (no need to port forward).

Ability to establish outbound UDP connections on ports 0 - 65535 (no need to port forward).

Firewall configured to accept solicited inbound UDP traffic.

No network security appliances (IPS) or services blocking WebRTC (STUN or DTLS).

No gateways configured to use Symmetric NAT (uncommon), as this will cause the peer-to-peer connection to fail forcing the use of a relay (TURN) server or failing altogether.

If you are using UniFi Protect in an isolated environment (where Protect has no access to the Internet), WebRTC is still used for connectivity. In this case, only browser-based access is available by connecting directly to the Protect controller/*- IP address on port 7443 ( https://<your-protect-ip>:7443 ).

Initial Connectivity Diagnostics

Back to Top

In order to focus troubleshooting efforts efficiently, it is best practice to try to identify any patterns to the connectivity issues by attempting to connect using different methods. Try the following and take note of results:

Use different mobile devices, such as different phones or tablets, ideally running different operating systems (Android / iOS) if possible.

Use different supported browsers, such as Chrome, Firefox, or Safari, on different computers.

Connect from different client locations:

From the local network (same subnet as Protect).

From the mobile carrier network (on a mobile device, or via tethering).

From a remote network (such as workplace or public WiFi network).

If you can isolate which scenarios work or do not work, you can focus your troubleshooting accordingly:

If a mobile device fails to connect regardless of network location, but browser-based devices work, the problem is likely specific to your mobile device, its configuration, or the software installed.

If a browser-based device fails to connect regardless of network location, but mobile devices work, and the experience is consistent across multiple browsers (Chrome, Firefox, Safari), the problem is likely specific to your computer’s configuration or installed software.

If a browser-based device fails to connect, but works in one browser but not the other, then the problem is likely specific to the browser’s configuration or environment.

If any connection methods (browser or mobile devices) work from one network location but not another, then the problem is likely caused by the network configuration or environment for that location.

If no connection methods work regardless of the device or location, the problem is likely caused by either the Protect Controller, its host device or, most likely, its local network configuration. See Network Troubleshooting.

Network Troubleshooting

Back to Top

If you can isolate connectivity problems to a particular network (for example, you can connect to your business Protect deployment from your home, but can’t connect while at a friend’s house), focus troubleshooting on the network where the connection fails. If the connection fails from any remote location, focus troubleshooting first on the network where Protect is located. Perform the following troubleshooting:

Verify that both the device hosting UniFi Protect, as well as the client device have proper Internet access, including a valid gateway IP and DNS servers. Please note that some DNS providers have been known to cause problems, such as 1.1.1.1. Try changing to Google's 8.8.8.8.

Verify that selected DNS servers properly resolve the following domains:

device.svc.ubnt.com

device.amplifi.com

global.stun.twilio.com

global.turn.twilio.com

Review the firewall configuration to ensure the connectivity requirements established in the section “General Network Connectivity Requirements” are met. If you have custom firewall rules configured, try disabling them temporarily to test.

Remove any port forwards for UniFi Protect, which may have been mistakenly configured.

Disable any network-level security appliance or service rules intended to block WebRTC’s internal protocols: STUN or DTLS. If you are using a UniFi Gateway, the UniFi Intrusion Prevention System (IPS) does not require specific configuration to prevent blocking WebRTC connectivity.

Symmetric NAT

While uncommon, Symmetric NAT poses a challenge for WebRTC (and most other peer-to-peer connections). Symmetric NAT does not maintain a 1:1 port mapping for established connections, which in all cases will cause the WebRTC peer-to-peer connection to fail. WebRTC will then attempt to fall back to connecting via a relay (TURN) server, providing a degraded user experience and in some cases may not work at all.

If you are behind a Symmetric NAT, the only solution is to either establish a VPN connection between the client and Protect, or configure the router in question to a mode other than Symmetric NAT (typically Cone NAT).

The UniFi Protect Controller detects and logs if the controller-side connection is behind a Symmetric NAT, but is unable to determine the NAT type on the client side. If you suspect Symmetric NAT on the controller-side connection, connect to the Cloud Key via SSH and execute the following command:

grep -Ri "symmetric" /srv/unifi-protect/logs

Any results will reveal evidence that the connection failed due to Symmetric NAT.

Troubleshooting Android Devices

Back to Top

Follow these steps to troubleshoot the Android mobile device that has the UniFi Protect app installed on it:

Verify that the Android UniFi Protect application is up to date and running the latest version available in the Play Store.

Ensure that the UniFi Protect application has not been restricted from accessing WiFi or Cellular data. On most Android phones this can be configured by going to Settings > WiFi & Internet > Data Usage > Cellular Data Usage > select UniFi Protect, and in App data usage make sure WiFi and Cellular data has not been disabled.

If a VPN is configured and enabled, try disabling it. Some VPNs and VPN services will block WebRTC connectivity.

If enabled, try disabling Private DNS under Settings > WiFi & Internet > Private DNS. On some networks and carrier networks, certain Private DNS providers such as CloudFlare’s 1dot1dot1dot1 may interfere with WebRTC.

Disable or remove any third-party applications that may interfere with network connectivity. Many security and privacy applications such as Blockada will block WebRTC connections in their default configuration.

Force quit the UniFi Protect application and attempt to connect again.

Uninstall the UniFi Protect application, re-install, and attempt to connect again.

Troubleshooting iOS Devices

Back to Top

Follow these steps to troubleshoot the iOS mobile device that has the UniFi Protect app installed on it:

Verify that the iOS UniFi Protect application is up to date and running the latest version available in the Apple Store.

Ensure that the UniFi Protect application has not been restricted from accessing WiFi or Cellular data. In iOS, go to Settings > Cellular Data and make sure UniFi Protect is toggled ON.

If a VPN is configured and enabled, try disabling it. Some VPNs and VPN services will block WebRTC connectivity.

Force quit the UniFi Protect application and attempt to connect again.

Uninstall the UniFi Protect application, re-install, and attempt to connect again.

Troubleshooting Browser Connectivity

Back to Top

In most cases, browser-specific failures to connect are typically caused by third-party software installed either as an extension in the browser, or an application on the host computer. To troubleshoot browser issues try the following:

Disable all suspected third-party extensions and security or privacy software installed on the computer. If connectivity is restored, re-enable extensions or software one at a time, testing each time, until the extension or software causing the problem is identified.

Once the extension or software has been identified as the cause, either leave it disabled or uninstall it. You may reach out to that software's support team for further assistance on how to configure itso it does not interfere with UniFi Protect. Unfortunately, we are unable to provide assistance on how to configure third-party software.

Common extensions known to cause issues include uBlock Origin, Privacy Badger and WebRTC Leak Prevent. Various VPN services such as Tunnelbear, as well as ad blockers or general tracking blockers are likely to interfere with WebRTC connectivity across all platforms that use the technology. If you identify conflicting software that is not included in this list, please let us know by emailing [email protected] so it can be added.

If using Chrome, please disable the following feature flag "Anonymize local IPs exposed by WebRTC." by copying and pasting the following address into the address bar, selecting Disabled, then restarting the browser:

chrome://flags/#enable-webrtc-hide-local-ips-with-mdns

Overview

This article explains what to doif a SSL Certificate Error is shown upon attempting to open the UniFi controller page.

Table of Contents

What does this error look like?

Cause: Missing a Valid SSL Certificate

Cause: Adopting UniFi for the First Time

Related Articles

What does this error look like?

Back to Top

UniFi - How to Setup your Cloud Key and UniFi Access Point (for beginners)

Missing a Valid SSL Certificate

Back to Top

UniFi relies on HTTPS for extra security. This means that the browser will check for valid certificates when making a secure connection to the web server. Although the alert message may prove annoying, there's no risk to the connecting user. To avoid this error you must:

Buy a signed SSL certificate from any web hosting provider (or if you decide to generate one, see a few notes on that below ).

Then make the following changes to the controller:

sudo su -

# cd <unifi_base>

# on Windows, "\%USERPROFILE\%/Ubiquiti Unifi"

cd /usr/lib/unifi

# create new certificate (with csr)

java -jar lib/ace.jar new_cert <hostname> <company> <city> <state> <country>

# Enter your password if prompted and then it will create your CSR in /var/lib/unifi

# - unifi_certificate.csr.der

# - unifi_certificate.csr.pem

# have this CSR signed by a CA, you'll get a few certificates back...

# copy the signed certificate(s) to <unifi_base>

# import the signed certificate and other intermediate certificates

java -jar lib/ace.jar import_cert <signed_cert> [<other_intermediate_root_certs>...]

NOTES:

Following notes for X509Subject Alternative Name:

If you're using Windows to generate the certificate, make sure the alternative name is set as DNS within thecertificate's properties window, and fill out the value.

If you're on Ubuntu / Debian and using openssl to generate acertificate, make sure to use the SANextensions or you will be promoted that the cert is invalid. Which is indication for the mission X509Subject Alternative Name. See external documentation about Subject Alternative Name here.

Once you have created theCSRitcan be found in the \%USERPROFILE\%\Ubiquiti UniFi\data folder. On Mac find it here:/Users/username/Library/Application\ Support/UniFi/data.Not sure where to find <unifi_base>? See this article.

Troubleshooting

If the error "Unable to import certificate into keystore" appears when importing the signed certificate & intermediate certs, try the following steps:

1. Edit the certificate file using a text editor and remove any blank spaces and line breaks after each line of the cert. The cert should be one single line.

2. Save changes re-import the certificate.

Adopting UniFi for the First Time

Back to Top

This error should not be confused with the one seen when adopting a Cloud Key for the first time. This error can be safely ignored by:

1. Click Advanced

2. ClickProceed to <your IP>

Verify if this is your case by seeing our UniFi - How to Setup your Cloud Key and UniFi Access Point (for beginners) article (in step 3.5 of the section 3. Configuring your Cloud Key & Access Point).

Related Articles

Back to Top

Overview

This article provides the steps to migrate froma live UCRM instance to a live UNMS instance.

Back to Top

NOTES & REQUIREMENTS:

This guide assists in migrating from live UCRM to live UNMS. However, if you wish to get familiar with UNMS with its CRM module, it is possible to test it in a sandboxed VM beforehand. When testing, it is important to make sure you are not running two CRMs in production mode at the same time to avoid duplicate invoices and other unwanted consequences. To play it safe, it’s recommended to turn off these features in the sandboxed CRM’s System Settings: Billing, Payment Gateways, Mailer, and Plugins. When you are done with testing, drop the whole sandboxed CRM module or the whole testing UNMS and return to this guide to migrate your live UCRM properly.

Table of Contents

Introduction

Considerations Before Migrating from UCRM to UNMS v1

What to Expect from the UCRM to UNMS Upgrade Process

Steps: How to Upgrade from UCRM to UNMS v1

Important Notes

Introduction

Back to Top

The process of the migration that will be followed in this article is:

Prepare the current UCRM for the migration and turn it off.

Install UNMS v1(or upgrade your current UNMS to this new version).

Enable the new CRM module in UNMS with the current UCRM backup file.

Run the wizard designed to move the devices from CRM to UNMS.

Check the configuration of UNMS including its CRM module

Considerations Before Migrating from UCRM to UNMS v1

Back to Top

Make sure you are using the latest firmware version 2.0.6 or newer on your gateway EdgeRouter. Please upgrade to this latest version using UNMS or the router's web interface. Note that you can use another router device or firmware version but the new fully automatic Shaping, Suspension, and NetFlow features won’t be available.

Suspension on Mikrotik routers is not supported in UNMS v1. Workaround: use the existing UCRM Plugins.

CRM backup sync to Dropbox has been removed and replaced by the Dropbox plugin. It is also possible to back up UNMS/CRM manually or automatically using a cron job.

UNMS v1 works directly with devices instead of IP. For Ubiquiti devices, it can easily gather all available IP addresses, but for 3rd party devices, it is necessary to insert them manually. Please note that IP ranges can no longer be set to client's devices, only single IPs can now be inserted manually.

We recommend only upgrading to stable UNMS versions.

What to Expect from the UCRM to UNMS Upgrade Process

Back to Top

The upgrade and migration process ensures that all the devices are present only in the Network module, all the sites are moved to the Network module, and the CRM Client’s Services are linked to appropriate Network Client Sites. In other words, all the devices configured manually in UCRM won’t be lost, they will be moved to the UNMS Network module, or just skipped when the given device is already there.

All the existing UCRM Site/Service Devices will be moved into the UNMS Network module automatically. If a device is already there, it will be detected by matching MAC or IP and no duplicate will be created. This is applied to all 3rd party devices as well, they will be migrated to UNMS.

Sites missing in UNMS will also be created automatically. The "missing site" is the site where all its devices are present only in UCRM and not in the UNMS Network.

The migration wizard will never modify or delete the existing Sites or Devices in UNMS. Additionally, no duplicate Sites or Devices will be created during the process.

CRM Client Services will then be linked to the corresponding Network Client Sites. Only 100\% matches are linked automatically, i.e. only when all the previous service devices (in CRM) are matching to all the client site devices (in Network). The missing Client Sites are also created automatically.

CRM will never modify or delete the existing sites or devices in UNMS. Additionally, no duplicate Sites or Devices will be created during the migration process.

NOTES

The primary device matching key is the MAC ID, the secondary matching key is IP and it is used only when the MAC value is empty.

If you were using UCRM and UNMS simultaneously and the devices or network topology were configured manually, there might be some ambiguous cases disabling automatic linking of client’s service (CRM) and client sites (Network).

For example, when the CRM Service has two devices that match devices of two different Network Client Sites. The network migration wizard will help you solve these cases but you can also "fix" the data in your current UNMS or UCRM beforehand or skip the migration tool and match all services manually.

Steps: How to Upgrade from UCRM to UNMS v1

Back to Top

1. Prepare the Current UCRM Instance for Migration

These are the recommended steps to prepare the current data and the whole UCRM system for migration. The goal is to terminate the current UCRM instance properly and migrate the data into the new UNMS’ CRM module in order not to run two CRM systems at the same time to avoid duplicate invoicing and other issues.

User Tip: Choose a part of a day with low activity, when there are not many clients in the client zone, no automatic invoices are being created, no emails waiting in the sending queue, etc.

1.1. As of UCRM v2.16+, go to or use the "Upgrade to UNMS" button in the top-left corner of the UCRM interface.

1.2.Follow the steps shown on that page to properly terminate billing and online payments, and to remove the shaping and suspension rules from the HW.

NOTE:This is the correct way of moving your online payments to UNMS’ CRM. It’s ok to keep UCRM switched off while the new UNMS’ CRM is not yet online. The online payment gateways repeat the notifications for many times until the system is back online. However, if you are migrating to a completely new domain, please make sure you check the configuration of the payment gateways according to the in-app guide on <yourdomain>//crm/help/online-payment-gateways.

1.3. By the end of the instructions provided in the UCRM "UNMS Integration" page, you should havethe Backup in UNMS format ready for the next step and your production UCRM should be turned off. Make sure you have downloaded the"Backups in UNMS format" (only this format can be used for upgrading to UNMS' CRM module. See the bottom of the System > Tools > Backup page).

2. Install UNMS v1

2.1.Install UNMS v1 or upgrade your existing UNMS to this version. Follow the UNMS installation guide or use the in-app upgrade tool in your existing UNMS.

2.2. If you are already a UNMS user and you have some data and devices configured in UNMS, it’s recommended to create a backup file of your UNMS instance at this point.

3. Verify that the New CRM Module in UNMS is Enabled

3.1.Go to Network > Settings > UNMS > UNMS Mode and make sure the ISP mode is enabled. Now you can enter the CRM Module through the top menu bar.

3.2. Once you are in the CRM module, go to System > Tools > Backup >Restore your UCRM v2and restore the backup in UNMS format from your previous UCRM v2 instance. Once the backup is restored, continue with the Network Migration Wizard.

4. Follow the Network Migration Wizard.

The Network Migration Wizard will be automatically skipped if there were no devices in the old UCRM instance since there would be nothing to migrate to UNMS. If the Network Migration Wizard is launched, go through the two sections: migration of Sites, and the migration and binding of Services to Client Sites.

A few pointers:

If you haven't been using UNMS before, the migration will be very simple: all of the "network data" will be moved to the Network module by clicking "Start Migration".

If you have been using UNMS, pay attention to the migration plan offered by the wizard. Most of the data will be just moved or linked with the existing entities in UNMS. However, there might be some ambiguous items which cannot be migrated or linked automatically. Please follow the information and tooltips shown for these cases. These are examples of some cases which wouldn't be migrated automatically and which might need your attention:

A single CRM service match multiple Network Client Sites (e.g. the CRM service ends up with 2 devices that belong to two different Client Sites in UNMS).

Multiple services match a single Client Site (e.g. you added all your CPEs into a single Client Site in UNMS).

CRM services match Sites in UNMS instead of Client Sites and vice versa, or former UCRM Sites match Client Sites in UNMS.

Mismatching IPs (e.g. one of the service device IP matches one Client Site in UNMS, while the second IP of the same device belongs to another Client Site).

CRM services that have no devices will not be bound to any Client Site.

Similarly, service devices with neither an IP nor a MAC or unattached service devices are not migrated to UNMS. Additionally, devices with non-unique Management IP are skipped by the wizard.

NOTE: UCRM service devices having more than one IP address (including the management IP) are migrated as separate devices for each IP to ensure no IP is lost during the migration, and the shaping and suspension feature will continue to work unaffected. If these IPs belongs to the same Ubiquiti device, UNMS will recognize this and merge these devices into one automatically.

USER TIP: In case it is necessary, you can re-run the migration wizard by doing the following:

If using UNMS version 1.1.x and up:Perform a factory reset of the CRM data in CRM > System > Tools > Factory reset.

If using UNMS versions older than 1.1.x:Toggle the Sandbox mode on and off to trigger the wizard.

Optional step: Force Mode for Service Devices

This option is available only when at least one UCRM service device exists also in UNMS. This mode for migrating UCRM service devices can be useful for those who have been using UNMS along with UCRM, while the UNMS network data related to Client Sites is incorrect. For example, if you have one Client Site containing 300 devices in UNMS which is obviously incorrect. If you think your UCRM data pertaining to Service Devices is better (for the example mentioned it might be: 300 services, having one device each), you can use it to "force push" the UCRM data into UNMS. This mode is not applied to UCRM Sites and the migration of Sites and their devices is not affected by this mode. More details about Force Mode:

When turned on, all the Client Sites and their devices are pushed into UNMS based on the UCRM data, regardless of the devices and network topology in UNMS.

The existing UNMS Client Sites won’t be deleted. Note that this means that the number of Client Sites in UNMS can be doubled.

No device duplicates are created, the existing UNMS devices will be just relocated from Client Site or Site to the proper Client Site according to the CRM info.

To sum it up, this Force Mode never deletes anything and it never creates any duplicate devices in UNMS. It will just create a non-existing Client Site for each UCRM service according to UCRM data and create the missing devices or relocate the existing ones.

User Tip:Before you start the migration, click on the Force Mode toggle to preview the planned actions. When you are satisfied with the proposed migration plan, start it up. When completed, go to finalize the UNMS configuration.

It is also possible to skip this wizard and manage the binding of services and client sites on your own one by one. If you prefer this method, click "I want to do this manually".

5.Check and Finalize UNMS Configuration

5.1. Check that the bindings between the CRM services and the Network Client Sites are correctly set.

Feel free to finalize the bindings manually: go to the CRM client service page and bind some Client Site in the “Network” box.

5.2. Use the old UCRM hostname for the new UNMS

It’s highly recommended to use the same hostname of the previous UCRM for the new UNMS to ensure smooth transition of all CRM features and for seamless replacement of the client zone. Go to Network > Settings > UNMS > UNMS Hostname/IP.

Note that the new UNMS hostname will be used by the payment gateways to communicate with your UNMS’ CRM and also your clients might be used to the previous hostname, and might be still using the URLs in old emails sent from UCRM.

If you were already using UNMS with some connected devices. The change of its hostname will require to reconnect the devices, read more in this guide.

WARNING: If you use another hostname for UNMS (e.g. when migrating to the UNMS cloud version), you should reconfigure the settings of your payment gateways, go through the config guide for your gateway from the first step. Otherwise the payment gateway will try to send the payment info to a wrong URL.

5.3. If you are new to UNMS, check its configuration.

Configure UNMS Mailer settings which are used by the CRM module as well in Network >Settings > UNMS > Mail Server. Note thatthe Mailer settings haven't been migrated from your old UCRM.

Configure the SSL certificate. Establish a new Let’s Encrypt certificate in Network >Settings > UNMS > SSL Certificate. If you need to use the SSL certificates from your previous UCRM, go to /home/ucrm/data/ucrm/ssl/ on your previous UCRM server, or you can also find them migrated at /home/unms/data/ucrm/ssl/ on your current UNMS server if you used the UCRM backup file including these keys.

Configure the Google map keys in UNMS.

5.4. Configure the UNMS Home Page.

The new UNMS has 2 separate login screens:

For both Network and CRM administrators (at yourdomain/nms), which is the default option.

For clients accessing the Client Zone (at yourdomain/crm).

You can choose which should be used as the default UNMS home page when the domain name is accessed without any suffix /crm or /nms by configuring it inNetwork > Settings > UNMS > Home page.

If you have been providing your clients with access to the Client Zone in your old UCRM, it’s recommended to set the client zone login screen (the second option) as the default login screen.

Note that payment gateways are not affected by this choice, the one-time payments and subscriptions will work regardless of the UNMS homepage selected.

5.5. UNMS and CRM Administrators:

NOTE: Please note thatthe CRM login screen only works for clients attempting to access the Client Zone.

All the UNMS and CRM administrators can sign in using the same administrators screen at yourdomain/nms. All the UCRM accounts (usernames/passwords) from your previous UCRM will work in this UNMS login screen, except the super-admin account. If there is just one super admin in UNMS and one in CRM, these super-admins accounts are considered as beingfor the same person and are merged into one.This user will need to use the username/password set in the UNMS app, configured during the first run of UNMS.

5.6. If you were using the Traffic Shaping feature in the old UCRM v2.x:

The UNMS Network module will take care of it: just turn it on for the gateway router in UNMS v1.0. For an easy configuration, use this UNMS Traffic Shaping guide.

5.7.If you were using the Suspension feature in the old UCRM v2.x:

Follow the guide to enable suspension feature in UNMS settings.

You might also need to recheck the configuration of Excluded Destination IP for suspended connections. To do so, you need to goNetwork > Settings > Network, select the appropriate active gateway and click the Edit link on the right. A popup will be shown with the 'Allow IP addresses' field.

5.8.If you were using the NetFlow feature in the old UCRM v2.x:

You can continue using it in the new UNMS as well, just make sure the destination IP for NetFlow packets is aiming at the UNMS server IP.

The NetFlow data usage measured by UCRM won’t be removed from the CRM module. But as of UNMS v1, any new usage data shown in the CRM module are obtained from the Network module automatically (only for client’s services bound to a client site in UNMS Network).

5.9.If you were using UCRM Plugins:

All of your UCRM Plugins and their data will be migrated into UNMS' CRM module using the UCRM backup file (if you haven’t explicitly excluded Plugins from the creation of backups). However, all of these plugins are turned off and need to be upgraded manually to the new version compatible with the CRM module in the new UNMS v1.

To do so, go to CRM > System > Plugins and click "update" to all of your existing plugins.

Important Notes

Backward compatibility for Client Zone URL and payment processing URL is ensured automatically by UNMS. For example, clients going to yourdomain/client-zone will be automatically redirected to yourdomain/crm/client-zone. You just need to make sure you are using the same domain for UNMS as the old UCRM instance was using.

Files uploaded to System > Tools > Webroot are now accessible using a new URL starting with /crm. For example: “wispdomain.com/crm/clients-guide.pdf”. You may need to change the URL used in your documents or email templates.

The following data is not transferred from the old UCRM to UNMS: device stats, logs, backups, and charts.

If you migrate to UNMS Cloud, the UCRM Plugins cannot be migrated automatically due to security reasons (workaround: you need to reinstall the plugins manually). Also, note that custom made plugins (unofficial versions) are not allowed on the UNMS Cloud version.

Overview

This article will outline how to reset a UniFi Video Installation under the Linux operating system (also applies to our hardware NVR) and how to restore recordings. The article for resetting a Windowsinstallation can be found here.

Intro to Networking - How to Establish a Connection Using SSH

NOTES & REQUIREMENTS:

Please note that this will clear out all settings and managed cameras but therecordings will remain. If you do not restore a configuration backup, it will be necessary tore-manage thecameras, set up motion zones/sensitivities, reconnect theinstall to the cloud, etc. This method should only be used after a database repair has been attempted and been advised by a Ubiquiti employee.

Table of Contents

Steps: How to Reset a UFV Installation

Steps: How toRestore Recordings

Related Articles

Steps to Reset a UFV Installation

Back to Top

For versions 3.10.1 or Earlier:

If you wish to restore your current configuration after the reset, ensure you have a configuration backup, or generate one from the Settings page in UniFi Video.

SSH into theUniFi Video server or hardware NVR. (Need guidance on SSH? Click here.)

Edit /usr/lib/unifi-video/data/system.properties

You can use vi,nano, orpicoto do this. However, on our hardware NVR, viis the only text editor. You can quickly install nanoby executing apt-get update; apt-get upgrade; apt-get install nano; apt-get clean

Locate the line that reads: is_default=false and change it to: is_default=true

Restart UniFi Video service unifi-video restart

It will take a moment to wipe out the database and restart the web service.

Access your install as usual (https://[UniFi-Video IP address]:7443).The complete process of how to access the initial setup wizard can be found in the UniFi Video User Guide.

The initial setup wizard will appear. Either restore the backup saved prior to recover your configuration or complete the configuration wizard to configure the system.

As always, the first thing you should do after completing the wizard is go to Settings > NVR Settings > Configure tab and check your storage path as well as the "Space to Keep Free" setting.

For versions 3.10.2 or Later:

If you wish to restore your current configuration after the reset, ensure you have a configuration backup. You can generate one from the Settings page in UniFi Video.

Navigate to Settings > System Configuration > Configure > Tools > Controller -Check the Reset Box, and Click the Restart button. (You will need to be the Super Administrator to see this option.)

After a couple minutes,The initial setup wizard should appear (you may need to refresh your browser) - Either restore the backup saved prior to recover your configuration or complete the configuration wizard to configure the system.

As always, the first thing you should do after completing the wizard is go to Settings > NVR Settings > Configure tab and check your storage path as well as the "Space to Keep Free" setting.

Steps to Restore Recordings

Back to Top

The following methods willguide a user to attempt to restore theirrecordings.

ATTENTION:Please note that the analysis tool may actually remove therecordings. It is recommended to make a backup of your recordings prior to performing thesesteps.

For versions 3.9.0 or later:

Go to Settings > NVR Settings > Configure tab > Expand Tools section.

Check the "Restore Recordings" option, and click ANALYZE:

For versions 3.8.5 or earlier:

Edit the system.properties file (/usr/lib/unifi-video/data/system.properties) and add the following to the bottom:

recording.recovery=true

Restart the UniFi Video service viaservice unifi-video restart.

Log in to the web interface.

Go to Settings > NVR Settings > Configure tab > Expand Tools section > Click the Analyze button. Your recordings will only restore if the storage path is correct.

Restoring recordings can take some time (anywhere from 30 minutes to 5+ hours depending on how many you have). You can continue to use the system as normal, as well as continue to manage your cameras and set up your configuration, but make sure you stay logged in while the analysis is complete. A simple way to do this would be to open a Live Feed from a camera or a Live View to prevent the systemfrom logging you out.

Related Articles

Back to Top

UniFi Video - How to Reset a UniFi Video Installation forWindows

UniFi Video - Repairing a Database

Overview

In this article we will show a roadmap for UNMS.

UNMS - Supported devices

NOTE:Content listed here is based on our Community feature requests.

Table of Contents

Introduction

Upcoming Features

Related Articles

Introduction

Back to Top

We have opened UNMS development to the feedback of our community as much as possible. For that reason, it is paramount for us to hear your feature requests and allow you to influence our plans for new features accordingly.We prioritize on those requests that are most desired by the community so here is a short list of those.

Upcoming Features

Back to Top

NOTE: Planned featuresin the table below are ordered neither by importance nor by the expected time of implementation.

Our top priority is to complete support for all Ubiquiti devices. Here is a table showing,what is already done and what needs to be added. We are committed to listen to your feedback and drive the development of UNMS in a direction that our community will appreciate. For that, we would like to encourage you to express your desires in our feature request section.

Stations

For airMAX and airCube devices in AP mode, we will show more detailed info about connectedclients. You will be able to investigate any client issues much more effectively with this feature.

UNMS Team

Feature

Description

Submitted By

AirLink

(First gen. already available in 1.1.0)

UNMS will be integrated with AirLink. This will allow you to easily plan new connections and simulate the coverage of an area with Ubiquiti devices. This solution will provide a clear view of your network topology on a satellite map background, showing all your AP, stations, clients and datalinks.

UNMS Team

Parallel FW upgrade

(First gen. already available in 1.1.0)

Smart FW upgrade for APs and their stations together. This feature will allow scheduling FW upgrade as well. The mass parallel upgrade will be able to evaluate the structure of a site and recognize if a device is providing energy to other devices through PoE. This is necessary to prevent a restart of any device in the middle of an upgrade.

UNMS Team

Insights

Real-time analysis and evaluation of issues in your network. Each discovered issue is immediately followed by an alert. This system will be able to recognize the wide scale of issues: outages, signal strength, capacity overload, configuration mistakes etc...

Rebelwireless

Roles

Advanced system for roles and multi-tenancy. This feature will allow restricting access to specific sites/clients for particular users.

MajoV

Justmeccsn

IP management

Subsystem for IP management. This feature allows attaching a specific IP address to any device. UNMS will not only offer a list of all used IP addresses, but it will be able to assign IP addresses to devices according to business requirements of UCRM as well. Also, the new smart installation wizards in the UNMS mobile app will be dependent on this feature to work properly.

Tech53

Firewall configuration

On EdgeRouters it will be possible to configure selection of the most important firewall settings remotely from UNMS.

UNMS Team

IPv6

Full support of IPv6 protocol everywhere in UNMS. UNMS will be able to run on IPv6 server, connect devices from IPv6 networks and correctly display and manage IPv6 addresses.

UNMS Team

Site survey

UNMS will be able to scan nearby networks for all wireless airMAX and airCube devices. This feature will give you a useful overview of neighboring networks and their devices.

UNMS Team

UniFi integration

This feature will allow connecting a whole UniFi network as a single UNMS device for simple monitoring only. It will not be able to manage the UniFi network in any way but we will add a one-click link to the UniFi controller.

Phastier

Tsial

VPN management

A configuration of VPN on EdgeRouters.

Horfic

Related Articles

Back to Top

Overview

This article specifies what data is shared with Ubiquiti via the automatic stability issues reporting.

Table of Contents

Introduction

Sample Data Export

Introduction

Back to Top

Ubiquiti's goal is to improve products intelligently, by tracking and prioritizing the most common errors. Issues reporting enables the team to be able to fix any issue quickly and improve the product design by having a better understanding of our real customers' use cases. With that in mind, the data shared with the developer team is limited to information and configuration which doesn't have personal character. That is why all IP addresses, MAC addresses, SSIDs and any unnecessary information is omitted from the reported data. Please see an example of a real set of reported data in the section below.

Sample Data Export

Back to Top

The crash report example below is from a real case and is shown unencrypted to reveal the data that is being sent. Please note that in reality, all this data is sent encrypted.

=> Send header, 236 bytes (0xec)

0000: POST /api/v1/core-dump HTTP/1.1

0021: Host: crash.ubncloud.com

003b: User-Agent: curl/7.47.0

0054: Accept: text/plain

0068: Content-Length: 9791

007e: Expect: 100-continue

0094: Content-Type: multipart/form-data; boundary=--------------------

00d4: ----d1daba1c5ab6abf6

00ea:

<= Recv header, 23 bytes (0x17)

0000: HTTP/1.1 100 Continue

=> Send data, 9791 bytes (0x263f)

0000: --------------------------d1daba1c5ab6abf6

002c: Content-Disposition: form-data; name="device_id"

005e:

0060: 5f40abdf4a0447105252f2f2f2e66fa1

0082: --------------------------d1daba1c5ab6abf6

00ae: Content-Disposition: form-data; name="bomrev"

00dd:

00df: 13-00488-19

00ec: --------------------------d1daba1c5ab6abf6

0118: Content-Disposition: form-data; name="model"

0146:

0148: ACB-AC

0150: --------------------------d1daba1c5ab6abf6

017c: Content-Disposition: form-data; name="version"

01ac:

01ae: ACB.feature/aircube-114.f876678.191209.1309

01db: --------------------------d1daba1c5ab6abf6

0207: Content-Disposition: form-data; name="system_time"

023b:

023d: 2019-12-09T14:36:01

0252: --------------------------d1daba1c5ab6abf6

027e: Content-Disposition: form-data; name="kernel_version"

02b5:

02b7: 4.1.16

02bf: --------------------------d1daba1c5ab6abf6

02eb: Content-Disposition: form-data; name="architecture"

0320:

0322: mips

0328: --------------------------d1daba1c5ab6abf6

0354: Content-Disposition: form-data; name="load_average"

0389:

038b: 0.56 0.47 0.41

039b: --------------------------d1daba1c5ab6abf6

03c7: Content-Disposition: form-data; name="df"

03f2:

03f4: Filesystem 1K-blocks Used Available Use\% Mounted

0434: on./dev/root 5888 5888 0 100\% /.tmp

0474: fs 30240 1536 28704 5\% /tmp.tmpfs

04b4: 512 0 512 0\% /dev

04ec: --------------------------d1daba1c5ab6abf6

0518: Content-Disposition: form-data; name="free"

0545:

0547: total used free shared buffers

0587: cached.Mem: 60480 49364 11116 1536

05c7: 4948 15600.-/+ buffers/cache: 28816 31664.Swa

0607: p: 0 0 0

062e: --------------------------d1daba1c5ab6abf6

065a: Content-Disposition: form-data; name="ps"

0685:

0687: PID USER VSZ STAT COMMAND. 1 ubnt 1536 S /sbi

06c7: n/procd. 2 ubnt 0 SW [kthreadd]. 3 ubnt

0707: 0 SW [ksoftirqd/0]. 5 ubnt 0 SW< [kworker/0:0H].

0747: 7 ubnt 0 SW< [khelper]. 77 ubnt 0 SW< [wri

0787: teback]. 78 ubnt 0 SW< [crypto]. 79 ubnt 0

07c7: SW< [bioset]. 81 ubnt 0 SW< [kblockd]. 83 ubnt

0807: 0 SW [kswapd0]. 84 ubnt 0 SW [kworker/0:1].

0847: 165 ubnt 0 SW [fsnotify_mark]. 186 ubnt 0 SW

0887: [spi0]. 326 ubnt 0 SW< [ipv6_addrconf]. 332 ubnt

08c7: 0 SW< [deferwq]. 337 ubnt 0 SW< [kworker/0:1H].

0907: 369 ubnt 0 SW [kworker/0:2]. 502 ubnt 1180 S

0947: /sbin/ubusd. 503 ubnt 1188 S -ash. 801 ubnt 202

0987: 4 S /sbin/rpcd. 844 ubnt 0 SW< [cfg80211]. 875 ubn

09c7: t 0 SW< [ath10k_wq]. 876 ubnt 0 SW< [ath10k_a

0a07: ux_wq]. 1012 ubnt 0 SW< [krfcommd]. 1063 ubnt 0

0a47: SW [kworker/u2:1]. 1228 ubnt 2184 S /sbin/logd -S 102

0a87: 4. 1287 ubnt 1700 S /sbin/netifd. 1356 ubnt 1916 S

0ac7: /usr/sbin/uhttpd -f -h /usr/www -r airCube-AC -l /ap. 1449 ub

0b07: nt 4188 S /sbin/infctld -n. 1470 ubnt 1184 S /us

0b47: r/sbin/crond -f -c /etc/crontabs -l 5. 1578 ubnt 0 SW

0b87: [kworker/u2:2]. 1666 ubnt 1184 S /usr/sbin/ntpd -n -S /u

0bc7: sr/sbin/ntpd-hotplug -p 0.ubn. 1696 ubnt 1180 S udhcpc -

0c07: p /var/run/udhcpc-wan0.pid -s /lib/netifd/dh. 2048 ubnt 263

0c47: 2 S /usr/bin/lua /usr/share/ubnt/uacbd. 2065 ubnt 4620 S

0c87: /usr/bin/udapi-bridge -w -g -p 81 -U /var/run/ubnt-u. 2086 u

0cc7: bnt 4812 S {exe} /usr/bin/udapi-bridge -w -g -p 81 -U /v

0d07: ar/run/. 2099 nobody 4616 S /usr/sbin/lighttpd -D -f /etc/

0d47: lighttpd/lighttpd.conf. 2139 nobody 1052 S /usr/sbin/dnsma

0d87: sq -C /var/etc/dnsmasq.conf -k -x /va. 2354 ubnt 1768 S

0dc7: /usr/sbin/hostapd -s -P /var/run/wifi-phy0.pid -B /v. 3362 ubnt

0e07: 1740 S /usr/sbin/hostapd -s -P /var/run/wifi-phy1.pid -B

0e47: /v. 5772 ubnt 2892 S /usr/bin/udapi-server -g -s /var/r

0e87: un/ubnt-udapi-serv. 5970 ubnt 1200 S {crash-handler.s} /

0ec7: bin/sh /usr/share/crash-report/cr. 5997 ubnt 1180 R ps.1

0f07: 3201 ubnt 0 SW [kworker/u2:0]

0f30: --------------------------d1daba1c5ab6abf6

0f5c: Content-Disposition: form-data; name="uptime"

0f8b:

0f8d: 5033.07

0f96: --------------------------d1daba1c5ab6abf6

0fc2: Content-Disposition: form-data; name="cmd"

0fee:

0ff0: udapi-server

0ffe: --------------------------d1daba1c5ab6abf6

102a: Content-Disposition: form-data; name="cmd_fullpath"

105f:

1061: !usr!bin!udapi-server

1078: --------------------------d1daba1c5ab6abf6

10a4: Content-Disposition: form-data; name="cmd_envvars"

10d8:

10da: HOME=/.TERM=linux.board=AIRCUBE.PATH=/usr/sbin:/usr/bin:/sbin:/b

111a: in

111e: --------------------------d1daba1c5ab6abf6

114a: Content-Disposition: form-data; name="cmdline_params"

1181:

1183: /usr/bin/udapi-server -g -s /var/run/ubnt-udapi-server.sock

11c1: --------------------------d1daba1c5ab6abf6

11ed: Content-Disposition: form-data; name="signal"

121c:

121e: 11

1222: --------------------------d1daba1c5ab6abf6

124e: Content-Disposition: form-data; name="file_descriptors"

1287:

1289: dr-x------ 2 ubnt ubnt 0 Dec 9 14:36 ..dr-xr

12c9: -xr-x 8 ubnt ubnt 0 Dec 9 14:35 ...lr-x-----

1309: - 1 ubnt ubnt 64 Dec 9 14:36 0 -> /dev/null.l

1349: -wx------ 1 ubnt ubnt 64 Dec 9 14:36 1 -> /de

1389: v/null.l-wx------ 1 ubnt ubnt 64 Dec 9 14:36

13c9: 2 -> /dev/null.lrwx------ 1 ubnt ubnt 64 Dec

1409: 9 14:36 3 -> socket:[357992].lrwx------ 1 ubnt ubnt

1449: 64 Dec 9 14:36 4 -> anon_inode:[eventpoll].lr-x------

1489: 1 ubnt ubnt 64 Dec 9 14:36 5 -> pipe:[357994].l-

14c9: wx------ 1 ubnt ubnt 64 Dec 9 14:36 6 -> pipe

1509: :[357994].lrwx------ 1 ubnt ubnt 64 Dec 9 14:

1549: 36 7 -> socket:[357995].lrwx------ 1 ubnt ubnt

1589: 64 Dec 9 14:36 8 -> socket:[358008].lrwx------ 1 ubnt u

15c9: bnt 64 Dec 9 14:36 9 -> socket:[358015]

15fe: --------------------------d1daba1c5ab6abf6

162a: Content-Disposition: form-data; name="memory_map"

165d:

165f: 00400000-0042d000 r-xp 00000000 1f:03 1541 /usr/bin/udapi-

169f: server.0043c000-0043d000 r--p 0002c000 1f:03 1541 /usr/bin

16df: /udapi-server.0043d000-0043e000 rw-p 0002d000 1f:03 1541 /

171f: usr/bin/udapi-server.0043e000-00441000 rwxp 00000000 00:00 0 .00

175f: ac1000-00b27000 rwxp 00000000 00:00 0 [heap].77c40000-7

179f: 7c52000 r-xp 00000000 1f:03 870 /usr/lib/lua/uci.so.77c52

17df: 000-77c53000 r--p 00002000 1f:03 870 /usr/lib/lua/uci.so.

181f: 77c53000-77c54000 rw-p 00003000 1f:03 870 /usr/lib/lua/uc

185f: i.so.77c54000-77c67000 r-xp 00000000 1f:03 863 /usr/lib/l

189f: ua/ubus.so.77c67000-77c68000 r--p 00003000 1f:03 863 /usr

18df: /lib/lua/ubus.so.77c68000-77c69000 rw-p 00004000 1f:03 863

191f: /usr/lib/lua/ubus.so.77c6a000-77c7d000 r-xp 00000000 1f:03 866

195f: /usr/lib/lua/cjson.so.77c7d000-77c7e000 r--p 00003000 1f

199f: :03 866 /usr/lib/lua/cjson.so.77c7e000-77c7f000 rw-p 0000

19df: 4000 1f:03 866 /usr/lib/lua/cjson.so.77c80000-77c91000 r-

1a1f: xp 00000000 1f:03 862 /usr/lib/lua/bit32.so.77c91000-77c9

1a5f: 2000 r--p 00001000 1f:03 862 /usr/lib/lua/bit32.so.77c920

1a9f: 00-77c93000 rw-p 00002000 1f:03 862 /usr/lib/lua/bit32.so

1adf: .77c94000-77ca6000 r-xp 00000000 1f:03 852 /usr/lib/libre

1b1f: g.so.77ca6000-77ca7000 r--p 00002000 1f:03 852 /usr/lib/l

1b5f: ibreg.so.77ca7000-77ca8000 rw-p 00003000 1f:03 852 /usr/l

1b9f: ib/libreg.so.77ca8000-77cc1000 r-xp 00000000 1f:03 876 /u

1bdf: sr/lib/libiwinfo.so.77cc1000-77cc2000 r--p 00009000 1f:03 876

1c1f: /usr/lib/libiwinfo.so.77cc2000-77cc3000 rw-p 0000a000 1f:03

1c5f: 876 /usr/lib/libiwinfo.so.77cc4000-77cd7000 r-xp 0000000

1c9f: 0 1f:03 864 /usr/lib/lua/iwinfo.so.77cd7000-77cd8000 r--p

1cdf: 00003000 1f:03 864 /usr/lib/lua/iwinfo.so.77cd8000-77cd9

1d1f: 000 rw-p 00004000 1f:03 864 /usr/lib/lua/iwinfo.so.77cda0

1d5f: 00-77cfc000 r-xp 00000000 1f:03 776 /lib/libgcc_s.so.1.77

1d9f: cfc000-77cfd000 rw-p 00012000 1f:03 776 /lib/libgcc_s.so.

1ddf: 1.77cfe000-77d2a000 r-xp 00000000 1f:03 877 /usr/lib/libl

1e1f: ua.so.5.1.5.77d2a000-77d2b000 r--p 0001c000 1f:03 877 /us

1e5f: r/lib/liblua.so.5.1.5.77d2b000-77d2c000 rw-p 0001d000 1f:03 877

1e9f: /usr/lib/liblua.so.5.1.5.77d2c000-77d3e000 r-xp 00000000

1edf: 1f:03 779 /lib/libsw.so.77d3e000-77d3f000 r--p 00002000 1

1f1f: f:03 779 /lib/libsw.so.77d3f000-77d40000 rw-p 00003000 1f

1f5f: :03 779 /lib/libsw.so.77d40000-77d55000 r-xp 00000000 1f:

1f9f: 03 825 /usr/lib/libnl-tiny.so.77d55000-77d56000 r--p 0000

1fdf: 5000 1f:03 825 /usr/lib/libnl-tiny.so.77d56000-77d57000 r

201f: w-p 00006000 1f:03 825 /usr/lib/libnl-tiny.so.77d58000-77

205f: d69000 r-xp 00000000 1f:03 790 /lib/libblobmsg_json.so.77

209f: d69000-77d6a000 r--p 00001000 1f:03 790 /lib/libblobmsg_j

20df: son.so.77d6a000-77d6b000 rw-p 00002000 1f:03 790 /lib/lib

211f: blobmsg_json.so.77d6c000-77d82000 r-xp 00000000 1f:03 738

215f: /lib/libuci.so.77d82000-77d83000 r--p 00006000 1f:03 738

219f: /lib/libuci.so.77d83000-77d84000 rw-p 00007000 1f:03 738

21df: /lib/libuci.so.77d84000-77d9b000 r-xp 00000000 1f:03 755

221f: /lib/libubox.so.77d9b000-77d9c000 r--p 00007000 1f:03 755

225f: /lib/libubox.so.77d9c000-77d9d000 rw-p 00008000 1f:03 755

229f: /lib/libubox.so.77d9e000-77db1000 r-xp 00000000 1f:03 721

22df: /lib/libubus.so.77db1000-77db2000 r--p 00003000 1f:03 721

231f: /lib/libubus.so.77db2000-77db3000 rw-p 00004000 1f:03 721

235f: /lib/libubus.so.77db4000-77dca000 r-xp 00000000 1f:03 873

239f: /usr/lib/libjson-c.so.2.0.1.77dca000-77dcb000 r--p 000060

23df: 00 1f:03 873 /usr/lib/libjson-c.so.2.0.1.77dcb000-77dcc00

241f: 0 rw-p 00007000 1f:03 873 /usr/lib/libjson-c.so.2.0.1.77d

245f: cc000-77e5d000 r-xp 00000000 1f:03 761 /lib/libc.so.77e6a

249f: 000-77e6b000 r--s 00000000 00:0e 1184 /tmp/TZ.77e6b000-77e

24df: 6c000 r-xp 00000000 00:00 0 [vdso].77e6c000-77e6e000 rw

251f: -p 00090000 1f:03 761 /lib/libc.so.77e6e000-77e70000 rwxp

255f: 00000000 00:00 0 .7f7fc000-7f81d000 rw-p 00000000 00:00 0

259f: [stack]

25ac: --------------------------d1daba1c5ab6abf6

25d8: Content-Disposition: form-data; name="crash_log"

260a:

260c: xxx

2611: --------------------------d1daba1c5ab6abf6--

<= Recv header, 17 bytes (0x11)

0000: HTTP/1.1 200 OK

<= Recv header, 31 bytes (0x1f)

0000: Server: nginx/1.14.0 (Ubuntu)

<= Recv header, 37 bytes (0x25)

0000: Date: Mon, 09 Dec 2019 14:36:11 GMT

<= Recv header, 41 bytes (0x29)

0000: Content-Type: text/plain; charset=utf-8

<= Recv header, 19 bytes (0x13)

0000: Content-Length: 2

<= Recv header, 24 bytes (0x18)

0000: Connection: keep-alive

<= Recv header, 25 bytes (0x19)

0000: cache-control: no-cache

<= Recv header, 2 bytes (0x2)

0000:

<= Recv data, 2 bytes (0x2)

0000: OK

Overview

This article explains how to reset an NVR Appliance to its original factory settings.

How to Establish a Connection Using SSH

NOTES & REQUIREMENTS:

The following guide is based on UniFi Video version 3.1.x and later.

Factory resetting an NVR will remove all previous management settings and video data. Any custom configuration changes applied by the system administrator will be lost, such as file-systems mounted on iSCSI volumes or locally attached external disk drives.

The default IP address of the NVR appliance is 192.168.1.30 (but will retrieve a DHCP-assigned address if a DHCP server is present).

Table of Contents

Introduction

Graphical User Interface (GUI) Reset

Command Line Interface (CLI) Reset

Hard (Physical) Reset

Related Articles

Introduction

Back to Top

There are three methods to factory reset your NVR: via Graphical User Interface, Command Line Interface, or the reset button on the actual device. After resetting your NVR to factory defaults, please follow this article to bring it back to current firmware: UniFi Video - How to Update the NVR via SSH.

Graphical User Interface (GUI)

Back to Top

Open the NVR landing page in a browser (http://<NVR_APPLIANCE_IP>/). You do not need to include the default port "7443" as the NVR hardware itself is what will be managed, not UniFi Video.

Click on the gear icon on the upper right hand corner of the page to access the Configure Devicepage.

Log in as "root" system account (username/password should be either ubnt/ubnt or root/ubnt). If you've changed this password, and don't have it anymore, proceed to the Hard (physical) reset method.

Navigateto the Maintenance tab.

Click "Reset to Defaults" button next to "Reset To Factory Defaults:"

Re-open the NVR landing page in a browser (http://<NVR_APPLIANCE_IP>/).

Command Line Interface (CLI)

Back to Top

Open a shell session to the NVR appliance e.g. ssh root@<NVR_APPLIANCE_IP>

Enter the following command-line

nvr-systool reset2defaults

Re-open the NVR landing page in a browser (http://<NVR_APPLIANCE_IP>/).

For more options, typenvr-systool --helpto list other administrative parameters. Thenvr-systoolis used by the NVR management console where this CLI approach is equivalent to the GUI steps.

Hard (Physical) Reset

Back to Top

Press and hold the Reset button (the crescent moon button) located below the Power button for 10+ seconds. The device will take up to 60+ seconds to restore the default configuration and return to the original factory version.

Re-open the NVR landing page in a browser (http://<NVR_APPLIANCE_IP>/).

Related Articles

Back to Top

Overview

This article will explain what broadcast traffic is and why it's important to manage it in your UniFi-managed network.

Table of Contents

What is Broadcast Traffic?

Effects of Excessive Broadcast Traffic

Managing Broadcast/Multicast Traffic

How-to EnablePort Isolation in UniFi Controller

How Broadcast Blocking Works

Related Articles

What is Broadcast Traffic?

Back to Top

Broadcast traffic is a topic of critical importance for network administrators, especially in larger networks. Without managing broadcast and multicast traffic, most networks will likely suffer the consequences sooner or later which can be detrimental to network health.

With UniFi, administrators have a number of methods of both monitoring broadcast/multicast traffic and taking action to prevent the network issues that can come from too much of it. In this article, we'll explain why broadcast/multicast traffic is an important consideration for network administrators and suggest some methods of managing this traffic.

First let's define the three fundamentally different ways communication occurs over a network- unicast, broadcast and multicast.

Unicast is the most common method used for network transmissions. Unicast involves one device sending info to another single network address. This is the method used most often on networks when users browse the internet or download files from a file server.

Broadcast involves sending a single packet on a network to every possible recipient on the network. This method has its own advantages/disadvantages over unicast and is very efficient. It can, however, only extend so far as the broadcast domainwhich is usually defined by subnet. Common uses of broadcast transmissions include UniFi device discovery, ARP (Address Resolution Protocol) requests, DHCP, etc.

Multicast functions in a sort of mix between broadcast/unicast. With multicast one device sends data only to systems that are set to receive this data but unlike unicast can send to multiple devices. This means it's more efficient than unicast while consuming fewer resources than broadcast. This most commonly occurs on local networks. An example of a common function that uses multicast transmissions is media streaming like a live stream of a sporting event.

Since unicast communication is the most common and essential on most networksand the least intensive of the three, special precautions will usually need to be taken to ensure that broadcast/multicast requests do not consume so much network resources that they adversely impact network performance. Let's explore how this happens and how you can identify the symptoms.

Effects of Excessive Broadcast Traffic

Back to Top

Chances are most of us have been on a network when someone plugged in a router or IP phone incorrectly and basically took down the network. The cause of these network outages is most often broadcast/multicast traffic. When a router plugs into the local network incorrectly and starts broadcasting ARP requests in a loop- this consumes such a large amount of bandwidth that there are is quickly no room for normal network operations. This is what is called a broadcast storm.

While many networks can experience problems from time to time, the less obvious consequences of unmanaged broadcast/multicast traffic often go unnoticed while still severely impacting the network. In such cases, dropped packets, intermittent connectivity issues with APs and slower network speed can tip administrators off.

This diagram will give a closer look at how this happens. Thisis what 400 packets/second of broadcast traffic looks like on a WLAN network with 5 APs:

UniFi - Guest Network, Guest Portal and Hotspot System

While 393 kbps isn't a particularly large amount of data, when sent via broadcast it can consume 80\% of airtime. This takes roughly the same amount of airtime as trying to send 639 Mbps (500 packets/second * 123 bytes * 8bytes/bit * 1300 unicast frames/multicast frame) through the AP at full PHY rate.

In the above example, both AP1 and AP4 will likely experience intermittent connectivity issues and dropped packets, which will adversely further affect the performance of other APs. These conditions would result in APs having intermittent connectivity with a maximum of 17 Mbps of actual user throughput (unicast data). This would drastically limit the number of users that could connect to each access pointand make the wireless network particularly slow.

As broadcast transmissions increase, this will continue to choke out network function with cascading failures.

For these reasons, it is critical to manage the broadcast/multicast traffic. Let's take a look at how beneficial this can be through another example:

As you can see, with proper control of broadcast/multicast traffic, the same APs can handle over four-fold the user throughput without experiencing any intermittent connectivity. This means the same number of users will all have four times the amount of throughput, or for the same throughput, the system will be able to handle four times the number of users.

In the next section, we’ll explain how this traffic can be managed.

Managing Broadcast/Multicast Traffic

Back to Top

Depending on what tools are available to you in your network, there are a number of ways to manage broadcast/multicast traffic. With UniFi Switches/hardware, the currently recommended method is using "port isolation". This method both ensures that broadcast/multicast data is kept to a minimum while allowing critical services that rely on broadcast/multicast transmissions. Let’s look at an overview of what this would look like:

How to EnablePort Isolation in UniFi Controller

Back to Top

ATTENTION: Port isolation between access points is generally not recommended, since it breaks communication between the UAPs.

Here’s how to set this up as shown in the above example in the UniFi controller:

First, open theUniFi Controller that manages the network.

Click the Devices tab on the left to see the devices.

Click on the switch to enable port isolation, and go to the Ports tab.

Either select the ports individually or click the box to select all.

Click Edit Selected at the bottom.

Go to Advanced.

Expand Advanced Options.

Under Isolation, select Enable port isolation.

Click Applyto finalize changes.

How Broadcast BlockingWorks

Back to Top

It's important to note that theLAN-WLAN Broadcast blocking feature underWireless Network Settings does not actually block stations from sending broadcast frames to the AP for forwarding onto the wired network. Instead, it blocks broadcast frames that are destined to the athX interface and avoids them from being transmitted.

The frames are dropped atawireless driver level. Therefore, if you run a tcpdumpon the athX interface ofthe AP itself, traffic that will wind up being blocked later will appear. The bridge to Ethernet/VLAN forwards everythingto the athX interface, which is whattcpdumppicks up, completely unaware of which frames the wireless driver willdropafterwards.

This is why verifying the blockage viatcpdumpwon't work. You will however, be able to observe by listening on their wireless interface, that once this feature is enabled, broadcast traffic will not be received by any computer connected to that AP, even though you wouldstill be able to see thattraffic when runningtcpdump -i athX on the AP.

Related Articles

Back to Top

UniFi - Troubleshooting Connectivity Issues

UniFi - Methods for Capturing Useful Debug Information

Overview

This article describes howto select the correct firmware, either for the XW or XM platforms of an airMAX M device; or the XC or WA platforms of an airMAX AC device.

airMAX - How to Update Device Firmware

NOTES & REQUIREMENTS:

The "correct firmware" will always be the latest release. The airMAX team is hard at work adding improvements to each new version. For security reasons, please be prompt to update all your devices to the latest firmware available in the Downloads page.

If you wish to test beta firmware versions, you will need to get beta access and then navigate to the Releases section of our Community. Once there, select RC (Release Candidate) status, choose to filter byCategoryandBeta and then select airMAX from the ISP grouping.

Table of Contents

Introduction

Identifying a Device's Platform

How to Download the Correct Firmware

Related Articles

Introduction

Back to Top

In 2015, the new airMAX AC line of products was released. This platform requires different firmware than the XM/XW used with the airMAX M line. The airMAX AC products use either XC or WA. You can easily check to see which firmware is needed for your specific model by checking the Main Dashboard of the airOS webUI.

Identifying a Device's Platform

Back to Top

airMAX M

The airMAX M devices use XW or XM platforms. Identify which one by looking at the firmware version in the device's SYSTEMtab; or by checking the firmware version in theMAINtab.

XW devices will display an 'XW' before the firmware version. In the example above, the firmware is 6.1.6 and for XW devices. XM devices will show an 'XM' before the firmware version.

Older M devices are XM while most new M devices are XW. The first Rocket Titaniums were TI, but new Titanium Rockets are also XW. These changes were rolled in over an extended period of time.

If you cannot log into a device to check the board version, it is safe to attempt the wrong firmware first. You will only see an error.

airMAX AC

Identify if your airMAX AC product uses XC or WA platform by looking at the firmware version in your device'smaintab. The device's platform, as well as the firmware version will appear in the top bar of the UI as well as in the version line.

XC devices will display an "XC" next to the firmware version. In the example above, the firmware is 8.0.2 and uses the XC platform.On the other hand, WA devices will show a "WA" next to the firmware version.

For those rare cases where logging into the device is not possible, use this table to see which firmware is required for each AC device.

airMAX AC Board List

XC

WA

2XC

2WA

R5AC-Lite

PBE-5AC-300

R2AC

NBE-2AC-13

R5AC-PTP

PBE-5AC-400

PBE-2AC-400

R5AC-PTMP

PBE-5AC-300-ISO

PBE-5AC-500

PBE-5AC-400-ISO

PBE-5AC-620

NS-5ACL

PBE-5AC-500-ISO

NS-5AC-GEN2

R5-AC-PRISM

NBE-5AC-16

PS-5AC

IS-5AC

LBE-5AC-23

NBE-5AC-GEN2 (Single ethernet port)

LBE-AC-16-120

RP-5AC-GEN2

LAP-GPS

NBE-5AC-19

LBE-5AC-LR

LBE-5AC-GEN2

NBE-5AC-GEN2 (Dual ethernet port)

PBE-5AC-GEN2

PBE-5AC-ISO-GEN2

How to Download the Correct Firmware

Back to Top

1. Download the latest firmware for your device from https://www.ubnt.com/download.

2. Use the left hand menu to go to the airMAX M or airMAX AC section, depending on your device, and select your product from the list.

3. Click on the correct firmware, selecting the correct board: airMAX M's XM or XW, and airMAX AC's XC or WA. In some cases, the board firmware version number could be different. In all cases, it's recommended to have the latest firmware version available for your device's platform.

ATTENTION: If you attempt to install the wrong firmware on your device, the following error message will be displayed: "Please check that you have selected the correct firmware architecture for your device."

Related Articles

Back to Top

Overview

This short guide describes how to retrieve a list of all the UNMS login names and how to perform password recovery when needed.This method should be used when email password recovery is not possible.

Password recovery (0.14.0+)

Back to Top

In version 0.14.0 we changed the password recovery to have the same format as the rest of UNMS CLI commands. To change a user's password, specify the username as a parameter and enter a new password when asked:

sudo ~unms/app/unms-cli set-password --username <username>

In case of any issues with two-factor authentication this command can be used to completely disable it:

sudo ~unms/app/unms-cli disable-two-factor --username <username>

Another new feature is the role of the super admin. When it is necessary to set super admin from outside of UNMS GUI, this command is available

sudo ~unms/app/unms-cli set-superadmin --username <username>

UNMS - How to Find Logs and Report Bugs

NOTE:It is possible to use all of the commands above without the --username tag, to display the list of users instead of changing their password or disabling 2FA for them.

Related Articles

Back to Top

Overview

This article will explain in detail how to use the UniFi Site Export Wizard to quickly and easily export sites from one Controller (including configuration and devices) to another.

UniFi - Device Adoption Methods for Remote UniFi Controllers

NOTES & REQUIREMENTS:

The Site Export Wizard is compatible with UniFi Controller versions 5.4.11 and above.

The new Controller version (the one you will be migrating the site to) must be the same or newer than the original Controller's.

Exporting a site using the method described in this article will create a new site in your Controller. Since the default site cannot be deleted, the Controller would have two sites (as minimum). If this is not something you want, we would recommend using the "backup and restore" method described in this article: UniFi - How to Create and Restore a Backup

Table of Contents

Introduction

Steps - How to Migrate a Site with the Site Export Wizard

Related Articles

Introduction

Back to Top

The Site Export Wizard allows UniFi administrators (with Super Administrator roles only) to export sites from one UniFi Controller to be managed by a different or new UniFi Controller. This was previously possible with manual configuration, but thewizard offers a more convenient, anduser-friendly way to do this. This process can work to/from any type of UniFi Controller including locally hosted Controllers, Cloud Keys, and UniFi Cloud Controllers, so long as Controller version is 5.4.11 or later.

IMPORTANT:It is important to note that the Site Export Wizard is not meant to be used to create a complete backup or to perform a restoration via the setup wizard since it does not include the admin accounts or credential information.

The migration process is virtually seamless, with a downtime of about a minute as devices provision anda few minutes for devices to appear in the new controller between steps 10 and 11 when changing the "inform URL".

How-to/Instructions

Back to Top

NOTE:To minimizecomplications, make sure to complete every step of the process and to not skip any steps. Please verify that the new Controller version (the one you will be migrating the site to) is the same or newer than the original Controller's.

To get started, open the Controller and site that is to be exported.

1.Go to Settings > Site

2.Select the gray “Export Site” button in the bottom-right of the page. This will initiate the wizard.

3.In the first step, click “Download Backup File” to download the file that contains the site configuration to be imported into the Controller you are migrating to.

4.Next, import this site into the new controller. To do so, open up the second controller web UI, click “Current Site - (Site Name)” in top-right of the display. Within this drop-down box select “Import Site” as shown:

5. The site input will need a name(itdoes not have to match the original site name). Once the site has been named, select “Choose file” and select the backup file that was just downloaded i.e. "5.9.29_default.unf"

6. Once the import has finished, a confirmation that the site was imported will appear. Once the import step has been completed, go back to the export controller and click "confirm".

7. Once import step has been completed (step 5) click "Confirm".

The following steps will migrate the devices. To do so:

8.First, find the URL or IP of the destination Controller. In this case, the new controller has an IP of 192.168.1.8. So that is what is entered into the "Custom Inform URL" input field.

9.Next, select the devices that are to migrated over by clicking the boxes next to one otherwise select the entire group.

10.Click “Migrate Devices”.

11.As the last step verify that all devices are connected to the new controller and are visible on the devices page. Note this may take a few minutes. Once verification of the devices showing "connected" in the new controller site select "forget devices".

IMPORTANT: Verify that the devices are visible and appear as connected in the new Controller's Devices section before clickingForget Devices.

Once the site export wizard has completed with success, the devices will be configurable in the new controller. At this time, unless the site was a default site, it should be safe to remove the site from the previous controller.

Related Articles

Back to Top

UniFi - How to Create and Restore a Backup

UniFi - Advanced Adoption of a "Managed By Other" UAP

Overview

Before beginning a Return Merchandise Authorization (RMA) process, please follow these three basic troubleshooting steps to ensure the device is truly defective.

Steps to Troubleshoot a Defective Device

Back to Top

1. Power the unit using the designated power supply as described in the product's Quick Start Guide (found in the Downloads page or at the bottom of each specific product page).

If the devicedoes not power onand is still under warranty, please begin an RMA process by filling out this form: https://rma.ui.com/

If devicedoes power on, proceed to step 2.

2. Factory default the unit as described in the product's Quick Start Guide, or you can also find specific articles in the Troubleshooting section of each product category.

3. Access the user interface of the device.

3.1. Make sure the device is powered on and connected via a working ethernet cable to a computer.

3.2. Follow the configuration instructions found at the end of the product's Quick Start Guide to access the User Interface and proceed with setup. The Configuration section name can vary product to product, but it will usually be found after the Hardware Installation section and before the Specifications table.

Where is my MAC ID and Date Code?

NOTE: ForUniFi and UniFi Video products make sure to have the Controller software running on the latest version, thensimply power on the unit and see if the unit is adoptable/manageable in the Controller devices section, as described in the UniFi User Guide or the UniFi Video User Guide.

4. If issues continue make sure to check if any cables are at fault: perform same steps with a different Ethernet cable, using another power supply or PoE port.

Related Articles

Back to Top

Overview

This is a complete guide for designing the best deployment for a high-density environment. The article is divided in Planning, Design, Deployment, and Config. For information on what UniFi Access Points (UAPs) to select for a high density deployment, please see the UniFi - Access Point Comparison Charts article.

Table of Contents

Introduction

Planning

Application Requirements

User Bandwidth

WLAN Capacity

Design

Cell Sizing & Channel Patterns

Minimizing Interference

Deployment

Access Point Placement

Wireless Site Surveys

Configuration of the UniFi Controller

Recommendations for High-Density WLANs

Related Articles

Introduction

Back to Top

This article will provide a detailed explanation of the concepts/principles behind high-density Wi-Fi deployments. For users who are already comfortable with their understanding of the basics, we have added a brief list of configuration recommendations/advanced tips for high-density UniFi deployments. Click here to proceed to this section.

What is High-Density Wireless?

By definition, High-Density (HD) wireless scenarios refer to WLANs whose coverage area contains a relatively high concentration of APs and connected client devices. As mobile networking trends toward scenarios where users carry multiple client devices, HD WLANs become increasingly more commonplace. Therefore, WLAN administrators tasked with designing a successful HD network can do so using Ubiquiti’s UniFi platform, provided they carefully consider and account for all of the unique design variables surrounding the enterprise project.

UniFi Demo Simulator - FedEx Forum Site

Throughout the HD WLAN Design Guide, we’ll reference the “FedEx Forum” Site, inside the UniFi Demo Simulator. The “FedEx Forum” Site mimics a real-world HD deployment that supports more than 7,000 simultaneous Wi-Fi users today: https://demo.ubnt.com

Why HD WLANs Generally Fail?

Ubiquiti identifies three major areas that impact the performance of every HD WLAN deployment:

Problem Area

Description

Solution

Broadcast/Multicast Domain Control

Uncontrolled network traffic jeopardizes airtime, resulting in decreased speed, increased latency, and potential connectivity problems.

Besides assigning VLANs to WLANs, configure Port Isolation at the switch layer to limit unnecessary traffic and conserve precious airtime available to stations in the HD WLAN.

WLAN Planning & Design

Inadequate and improper planning/design physically inhibits wireless performance and cripples user activity on the network.

Carefully anticipate and plan for network capacity parallel to the user requirements for the HD WLAN prior to methodically designing the coverage area with proper channel reuse patterns.

Site Survey, Analysis, & System Characterization

Lackadaisical attention of the RF environment results in careless placement and inept configuration of APs for poor wireless performance.

Before, during, and after deployment, consciously track, measure, and evaluate signals, noise, traffic, and other metrics to optimize the HD WLAN accordingly.

Planning: Application Requirements

Back to Top

The Purpose of the HD WLAN

Regardless of user density, the purpose of every WLAN is to support the wireless users’ application requirements. Therefore, the very first step when planning for the WLAN is to understand the user applications and behavior. Typical projects involving HD WLANs include stadiums, auditoriums, concerts, and other events where a high volume of users gather across the coverage area. The most common applications for these HD scenarios range from social media to live video/VoIP streams to simple web browsing. Consequently, use of these applications may see varied levels of activity due to the nature of the event, such as with spontaneous traffic bursts (e.g., everyone posts to social media during breaks) or as more constant streams of data (e.g., students taking notes in a lecture hall).

Core Applications Define Planning & Design

Recognizing the core applications and types of users on the network, begin to plan and design the HD WLAN with regards for the unique limitations and requirements of the planned project. For example, the performance of latency-sensitive applications like VoIP can degrade as WLAN usage reaches peak levels. Why? Because the wireless channel is shared among all nearby, active stations, an 802.11 station (i.e., the VoIP user) must ‘wait’ to transmit until the channel is free of activity. Fundamentally speaking, the principal applications and services on the network dictate the architecture and design of the WLAN, especially in HD scenarios.

Realistic WLAN Planning/Design

Can a WLAN simultaneously support latency-sensitive applications, as well as high bandwidth users? With total control over all of the variables affecting the WLAN, including client devices and the physical environment for deployment, the realization of both objectives in a single, culminating project becomes more realistic. When faced however with “bring your own device” (BYOD) scenarios, as HD WLANs often are limited control over environmental variables during planning, forces the network to choose between supporting high throughput or low latency applications.

Planning: User Bandwidth

Back to Top

Client Traffic Analysis via UniFi DPI

Following deployment, enterprise network administrators can take advantage of the Deep-Packet Inspection (DPI) engine running on the UniFi Security Gateway (USG) to review the applications in use by client devices on the network. The UniFi Controller summarizes the total bandwidth consumed by the user applications, as well as the individual activity of users, so WLAN administrators can make firewall and other configuration changes to improve the performance of the network.

What is “Service Level Assurance”?

Prior to deployment, however, anticipate which applications will be serviced by the HD WLAN to develop a plan for “Service Level Assurance” (SLA) ahead of estimating the “Per-Client Bandwidth”. A clearly-defined SLA identifies the primary applications and services to be supported on the intended network (such as VoIP or YouTube), and therefore, guides the early stages of planning and designing the WLAN architecture. Keep in mind that although low-end VoIP and video calls require minimal bandwidth, their tolerance for latency is also much lower, and therefore are designed uniquely. Although UniFi APs give “Quality of Service” (QoS) priority to such traffic (per WMM standards), initial planning/design for the HD WLAN should cater to the specific needs of the applications.

Create an SLA for the HD WLAN

To help formulate the SLA for the users on our unique HD WLAN, let’s reference the client device “current-e58ba353” as a baseline example. A quick analysis of the DPI section under the UniFi Client Properties tab reveals its top three applications to be:

Web Browsing

Social Media, and,

Video Download.

“Application Requirements” Data Table

The following “Application Requirements” table relates info about the speed and connection required to service some of the most popular applications used in today’s WLANs.

Type

Example

Bandwidth (Mbps)

Latency Tolerance

Packet Flux

Email & Instant Messenger

Gmail, Messages

0.1

High

Bursty

VoIP

Skype Audio Call

0.1

Low

Constant

Podcast/Radio Download

Pandora, Spotify

0.2

Medium

Bursty

Social Media

Instagram, Facebook

0.25

High

Bursty

Video Call

Skype Video (Low)

0.3

Low

Constant

Skype Video (High)

0.5

Low

Skype Video (HD)

1.5

Low

Web Browsing

Wikipedia, Google Web Results

0.5

High

Bursty

Reddit, Google Image Results

1

High

Bursty

Video Download

YouTube 240p

0.4

Medium

Bursty

YouTube 360p

0.75

YouTube 480p

1

YouTube 720p

2.5

YouTube 1080p

4.5

Online Gaming

League of Legends

2

Low

Constant

Internet TV

Netflix 720p

4

Low

Bursty

Netflix 1080p

5

Low

Bursty

File Sharing

BitTorrent

10

High

Bursty

File Backups

Dropbox

10

High

Bursty

SLA for Multitasking & Multiple Users Types

In some WLAN scenarios, the SLA may seek to support a variety of user types, or even multiple applications per client device (i.e., network multitasking, background services), and should, therefore, sum together the total Bandwidth required for each application.

“Application A Bandwidth + Application B Bandwidth + Application C Bandwidth + ”

“Per-Client Bandwidth”

For purposes of our HD WLAN example, our SLA assumes that the user (guest) is single-tasking, and therefore, seeks to support the most bandwidth intensive application used by client “current-e58ba353”: Video Download (0.3-4.5Mbps, with 1Mbps, assumed for mobile resolution playback). This means that the “Per-Client Bandwidth” (that is, the HD WLAN’s SLA) is approximate 1Mbps.

“Maximum Aggregate Throughput Requirement”

To discover the “Maximum Aggregate Throughput Requirement,” that is, the total amount of bandwidth needed for the HD WLAN to support ALL client devices simultaneously, multiply the “Per-Client Bandwidth Requirement” (1Mbps) by the “Total Number of Client Devices” (the “FedEx Forum” has a seating of 18,119). While not all 18,119 in attendance will bring one mobile device to the event, planning for future growth is an important consideration for every WLAN.

“Per-Client Bandwidth Requirement” x “Total Number of Client Devices” = “Aggregate User Throughput Requirement”

(1Mbps) x 18,119 Clients = 18,119Mbps Aggregate

“Expected Peak Aggregate Throughput”

Therefore, the “Maximum Aggregate Throughput” at the “FedEx Forum” is 18,119Mbps. However, since it is impractical to assume that all 18,119 will ever pass traffic simultaneously, let’s multiply the “Expected Peak Usage” (let’s estimate 50\% of total attendance) by the “Maximum Aggregate Throughput Requirement” to determine the “Expected Aggregate Throughput”.

“Maximum Aggregate Throughput Requirement” x “Expected Peak Usage” = “Expected Peak Aggregate Throughput”

(18,119Mbps) x (50\%) = 9059.5Mbps “Expected Peak Aggregate Throughput”

Later on, the “Expected Peak Aggregate Throughput” value will directly help to estimate the minimum number of Access Points required for the HD WLAN deployment.

Upstream Data Links

The ~9Gbps of data passed on the HD WLAN by the guest users is Internet traffic, and therefore, the upstream pipe to the ISP should support the “Expected Peak Aggregate Throughput” to account for the offered SLA at the event. Throughout the HD WLAN, make sure that upstream network infrastructure (e.g., switches) accommodates the traffic bandwidth downstream (i.e., aggregation switches at the core, access switches at the edge).

Planning: WLAN Capacity

Back to Top

What is Capacity?

In the context of all WLANs, capacity is defined as the data rates supported by an AP and its respective clients. Capacity is, therefore, twofold dependent on the characteristics of both client devices and APs (hereafter called “stations”). By anticipating and analyzing the characteristics of stations, we can accurately calculate the capacity of the network in order to estimate the total number of access points required to support the planned HD WLAN.

Choose the Best AP Possible

Although “bring your own device” (BYOD) scenarios mean client devices cannot be consciously chosen, fortunately, WLAN administrators can select access points whose wireless characteristics offer the best performance to match their particular HD WLAN scenarios. This is also important to ensure that the HD WLAN has longevity through down-the-road support for the client devices of today and tomorrow.

For example, the UAP-AC-M unit supports versatile coverage options through external connectors for pairing with directional antennas. By pairing the UAP-AC-M with a 45 airMAX sector antenna, WLAN administrators can produce small, controlled 5GHz cellsideal in certain HD WLAN scenarios. By comparison, the omnidirectional antennas and mounting capabilities make the UAP-HD well-suited for low-ceiling and wall deployments, while the UAP-AC-M (a Wave 1 “Single User” (SU) MIMO AP) is ideal for high-vaulted ceilings seen in auditoriums, stadiums, and concert halls.Please see the UniFi - Access Point Comparison Charts article for information on the complete HD and Mesh lines.

WLAN Capacity Variables

To review, there are five variables that determine the supported data rates of a WLAN, including:

802.11 Protocol - the hardware standard characterizing the 802.11 stations on the WLAN (a, b, g, n, ac Wave 1, ac Wave 2). As a backward-compatible AP, the UAP-HD immediately serves in HD deployments today, while anticipating growth as WLANs scale to support more client devices for years to come.

Spatial Streams - the total number of data streams simultaneously transmitted and received by the AP and clients. “Multiple In, Multiple Out” (MIMO) operation traditionally has been limited by the supported data streams of the single client with whom the AP communicates. As a Wave 2 802.11ac access point, the UAP-HD boosts the available airtime through true “Multi-User” MIMO mode, concurrently pushing up to 8 streams of data to clusters of 2G & 5G clients. And since most client devices opt for fewer antennas (i.e., fewer spatial streams) to conserve battery life, the UAP-HD’s MU-MIMO technology is critically important to ensuring maximum WLAN performance.

Channel Width - the bandwidth over which an AP and its clients transmit data signals (20/40/80 MHz). While 40/80 MHz channels are tempting, HD WLANs dictate the use of 20 MHz channel widths to conserve the number of channels available for reuse during deployment (especially true in extreme HD scenarios). In contrast, larger channel widths in HD scenarios generally creates a fundamentally flawed WLAN design where closely-placed AP cells operating on same or nearby channels see degraded SNR performance and increased contention for use of the wireless channel.

Signal-to-Noise Ratio (SNR) - the difference in receive signal (the desired data signal) and noise (the combined level of in-band interference). From the point-of-view of HD networks, SNR poses the greatest threat to performance since by nature, densely-packed WLANs face greater interference. In order to ensure strong SNR levels for clients, HD WLANs necessitate careful cell planning, including methodical channel assignments, very low, controlled transmit power levels, and precisely deployed AP locations.

Guard Intervals (GI) - 802.11n/ac WLANs support “long” and “short” waiting periods between transmitted symbols (data). Although a short GI is desirable, UniFi APs automatically toggle between “long” and “short” GI depending on the WLAN performance.

PHY Rates vs. Throughput

Now that we have identified the factors that determine capacity, it's important to distinguish that these are physical-layer (PHY) data rates. What does this mean? Due to overhead in the 802.11 protocol, the actual amount of real TCP data payload sent over wireless signals is approximately half of the advertised PHY rates. When estimating the capacity of the HD WLAN, we’ll factor a 50\% reduction of the calculated PHY rates to align with speed results experienced in the real world.

Estimate Client Throughput

Returning to “current-e58ba353” as our baseline example, the reported 72.2Mbps PHY rate assumes that a ‘typical’ client device is characterized as:

An 802.11n client device,

With a single (1x1) data stream,

Operating on a 20MHz channel,

With the best SNR,

And short GI.

By cutting the PHY rate in half (72.2Mbps), we estimate that for the planned HD WLAN, the “Achievable Real-World Client Throughput” of 36.1Mbps.

Estimate Minimum Required APs

By dividing the total “Aggregate User Throughput Requirement” (9059.5Mbps) by the “Achievable Real-World Client Throughput” (36.1Mbps), we calculate 251 radios (rounded up from 250.955679) as the minimum number of radios required to service the HD WLAN.

“Aggregate User Throughput Requirement” Achievable Real-World Client Throughput” = “Minimum Required Radios”

(9059.5Mbps) (36.1Mbps) = 250.955679 Radios

In some scenarios, 2G and 5G bands can and should be used. Note, however, that in many HD WLANs, such as stadiums and arenas, only 5G channels are deployed since propagation characteristics make 2G difficult to control.

Therefore, a “Minimum AP Estimate” of 251 APs could satisfy the capacity requirements for the “FedEx Forum” site, based on the following assumptions:

Full person attendance at the event is 18,119.

“User-to-Client Device” ratio is 1:1.

“Total Client Devices” at the event is 18,119.

“Expected Peak Usage” is 50\%.

“Expected Peak Aggregate Throughput” is 9059.5Mbps.

‘Typical’ client device is 802.11n, 1x1, with strong SNR.

WLAN operates on 20 MHz channels with short Guard Intervals.

“Achievable Real-World Client Throughput” is 36.1Mbps.

Capacity Conclusions

The “Minimum AP Estimate” is a function of two capacity variables: “Aggregate User Throughput Requirement” and “Achievable Real-World Client Throughput”. In simpler words, a client’s speed and bandwidth requirements directly affect the capacity offered by an AP. Increased client speeds (e.g., more spatial streams, improved SNR) means fewer APs are required since each AP reaches greater capacity. Conversely, decreased client speeds means more APs are required. And bandwidth consumption on the network increases, more capacity is needed to support user applications, thereby requiring more APs.

Theoretical vs. Actual APs Deployed

As a theoretical number, the “Minimum AP Estimate” gives network administrators starting point as they undertake the important task of designing the HD WLAN. The actual number of APs deployed will depend on a broad range of physical factors noted during site visits, floor plan analysis, as well as site surveys conducted at the intended HD WLAN site.

Design: Cell Sizing & Channel Patterns

Back to Top

Capacity, Coverage & “Cells”

Recall that WLAN capacity is directly dependent on the SNR of stations across the wireless coverage area. The primary design objective of each HD WLAN is to limit the coverage area provided by each AP (hereafter called “cells”), then apply an effective channel reuse pattern to ensure a high SNR for every station. HD WLANs perform poorly when AP cells are overextended or if channel reuse patterns are not respected.

2G/5G Characteristics

Although the 2.4GHz band contains eleven 20MHz channels on which a WLAN can operate, only 3 may be used in a non-overlapping channel pattern: 1, 6, and 11. By contrast, the 5G band supports over 20 non-overlapping 20MHz channels, depending on the region. The availability of more channels gives the 5G band a distinct advantage in limiting the interference of neighbor cells through more flexible channel reuse patterns. And due to propagation characteristics, certain HD WLANs may only deploy on 5G channels, especially in open settings like stadium and arena, where controlling the effective size of a 2G cell can be physically challenging.

Cell Characteristics

There are seven fundamental points to consider that can affect a cell’s coverage area:

Factor

Description

HD WLAN Recommendation

Frequency

Due to “Free Space Path Loss”, 2G signals propagate farther than 5G.

Deploy on 5Guse 2G with extreme discretion.

Channel Width

Increased channel width (e.g., 80MHz) means decreased range for signals.

From the standpoint of channel reuse patterns, only use 20 MHz channels.

Transmit Power

High transmit power increases an AP’s coverage area.

Reduce transmit power to “Low” to for small, controlled cells.

Antenna

Antenna gain influences the directivity and size

Consider UAP-AC-M with directional antenna capability in areas with ceilings 25 feet or higher should.

Obstacles

Obstacles attenuate signals at different rates and influence the propagation behavior of signals (e.g., reflect, absorb, scatter).

Consider the structural elements at the site when choosing how and where APs will be mounted since walls can help control cell size.

Clients

Like APs, client devices also transmit and generate signals.

Implement strict channel reuse patterns and limit overlap between neighbor cells.

DFS Channels

In the 5G band, Dynamic Frequency Selection (DFS) operation requires APs stop broadcasting if radar signatures are detected. As part of the site survey, WLAN administrators must scan these channels prior to deployment and for planning. Whenever possible, include DFS channels in the HD WLAN design for a more robust channel reuse pattern.

Floor Plan Example

The FedEx Forumfloor plan shows the wireless cells of 118 UAP-AC-M deployed for high-density coverage. The 5G heatmap shown belowuses very lowtransmitpower levels and directional antennas to create distinct coverage areas with the strongest possible SNR for clients. Often, in environments like stadiums or arenas,disabling the 2G radiosacross the AP networkis desirable toavoid poor scalability and exaggerated noise/interference levels, colloquially described as "fishbowl effect".

UniFi - Access Point Comparison Charts

In order to design a working HD WLAN, consider these three fundamental characteristics:

Characteristic

Reason

Diagram

Small, controlled cell sizes

Each coverage area features a distinguishable channel for high SNR

(i.e., channel 1 inside daisy flower of 6 & 11 around perimeter...show client SNR from Channel 1 = SNR Strong, Channel 6/11 weak -80)

Neighbor cells (2G/5G) never use the same channel

Avoid channel contention by two competing stations

(i.e., station 1 & station 2 in overlapping AP cells, both on channel 6)

Neighbor cells (5G) assigned non-adjacent channels

Improve SNR inside the cell

(i.e., Channel 36 & 165 instead of 36 & 40

Adjacent channels refer to WLAN channels whose bandwidth (channel width) edges touch. By contrast, non-adjacent channels are WLAN channels whose bandwidth edges are spaced with 20 MHz or more. For example, 5G channels 36 and 40 are adjacent channels; 36 and 44, non-adjacent channels. When deployed on neighbor and overlapping cells, non-adjacent channels see better performance, a principle that holds especially true in HD WLANs, where the combined total of competing, in-band signals is much higher. The adjacency of 2G channels 1, 6, and 11 causes SNR to degrade quickly, giving 5G the advantage in HD WLAN scenarios.

Design: MinimizeInterference

Back to Top

Interference & HD WLANs

Interference represents the total amount of competing, in-band signals that prevent a station from ‘hearing’ the intended receive signal with clarity. The extreme proximity of so many client devices on adjacent and non-adjacent channels increases interference levels, and therefore, reduces SNR and performance across the HD WLAN service area. When properly designed, an HD WLAN ensures each connected client device has a strong SNR, while mitigating the potential for collisions and limiting the impact of in-band interference.

What is Co-Channel Interference?

Whenever WLAN administrators deploy two neighbor AP cells on the same channel, the overlapping coverage areas encounter Co-Channel Interference (CCI). With the resulting transmit collisions that occur as a result of CCI, stations must retransmit data, which results in decreased speeds, increased latency, and problems for client device connectivity. This is due to the Clear Channel Assessment (CCA) mechanism, which requires an 802.11 station to listen prior to transmission, and yields the channel in case a station is already transmitting on the wireless channel. An HD WLAN with poor channel design and uncontrolled coverage areas will suffer as CCI plagues the wireless network. Conversely, HD WLANs that deploy AP cells with strict channel reuse patterns and controlled coverage areas can avoid CCI in the wireless network.

What is Adjacent Channel Interference?

Although CCI is largely avoidable in a properly designed, well-controlled wireless network, Adjacent Channel Interference (ACI) presents a significantly greater challenge for HD WLANs, and is not easily countered. ACI describes the overall increase in interfering, in-band wireless signals faced by stations as multiple AP cells are placed in relatively close proximity. By overextending the coverage area in a dense wireless setting, ACI increases aggressively throughout the HD WLAN, thereby reducing SNR levels for client devices, and dropping speeds dramatically. More generally, ACI speaks to the type of interference generated along the ‘tail-ends’ of an 802.11 transmission, which raise noise levels for other nearby in-band stations. Because adjacent channels (i.e., 36 & 40) suffer greater interference levels than non-adjacent channels (i.e., 36 & 165), the channel design for HD WLANs should position AP cells on adjacent channels as distantly as possible.

Best Practices for HD WLAN

To review, an HD WLAN should follow a series of best design practices:

Characteristic

Reason

Diagram

Small, controlled cell sizes

Each coverage area features a distinguishable channel for high SNR

(i.e., channel 1 inside daisy flower of 6 & 11 around perimeter...show client SNR from Channel 1 = SNR Strong, Channel 6/11 weak -80)

Neighbor cells (2G/5G) never use the same channel

Avoid channel contention (CCI) by two competing stations

(i.e., station 1 & station 2 in overlapping AP cells, both on channel 6)

Neighbor cells (5G) assigned non-adjacent channels

Control ACI and maintain high SNR inside the cell

(i.e., Channel 36 & 165 instead of 36 & 40

Deployment: AP Placement

Back to Top

Omnidirectional Antennas

In general, most client devices, as well as all UniFi Access Points, feature antennas that are omnidirectional. Similar to a light-bulb, omnidirectional antennas radiate wireless signals in all directions. More specifically, however, the coverage area produced by an omnidirectional antenna looks similar to a donut pattern, with peak signal strength nearest to the center of the donut, and weaker signals at the edges of the ‘cell’. Recognizing that not only UAPs but client devices radiate signals in all directions is crucially important to understanding interference from all station types contributes to the SNR across the HD WLAN coverage area.

Ceiling & Wall Mounted APs

Indoor UniFi Access Points like UAP-HD and UAP-AC-PRO feature easy mount fixtures for quick installation into walls and ceiling tiles. The UAP-HD provides excellent wireless coverage in extremely dense indoor with ceilings under 25 feet height. Although the antenna coverage pattern of each indoor UAP is similar, understand that reflective surfaces and multipath effects in crowded, more dense settings can result in unexpected signal readings from distant and/or nearby APs, therefore necessitating careful cell adjustments based on site survey analysis.

Directional Antennas

Alternatively, directional antennas can be paired with select UniFi Access Points like UAP-AC-M to produce distinct, controlled coverage areas, making them very popular in outdoor or open indoor settings. When mounting UAPs in open rooms with high ceilings (25 feet and higher), omnidirectional antennas are incapable of producing distinct coverage areas vital in the design of the HD WLANs. Instead, pair the UAP-AC-M with directional antennas pointed at specific areas of the HD WLAN event to produce controlled areas of coverage with robust SNR. Note that when using 5GHz directional antennas with the UAP-AC-M that the 2G radio should be disabled.

“Under Seat” APs

An increasing more popular AP placement trend in today’s HD WLANs, such as seated sporting events, is mounting APs below users in attendance. By securely installing an AP in a locked box under seats or within the building foundations itself, this coverage technique seeks to improve the SNR of client devices by placing APs in closer to the users themselves. The “under seat” technique, however, presents new challenges for the HD WLAN, including coverage overextension during low attendance events, since fewer users mean fewer bodies attenuating (controlling) the size of each wireless cell.

Deployment: Wireless Site Surveys

Back to Top

Site Visit

While important during the planning phase, visiting theHD WLAN sitebefore and after deploymentis totally necessary in order to criticallyassess the area fordesign and installation guidelines, as well as to conductcrucial site surveys to gather RF information needed forchannel assignment.Although the UniFi Controller supports RF scanning with second-generation UniFi Access Points, be sureto also bring sample client devices with spectrum analysis and WLAN scanning software, as well as cameras to document the key areas involved in deployments, such asinstallation areas, potentially problematicregions, and cable drops.

Map, Topology & Deployment

After visiting the intended deployment site and making adjustments to the final channel plan, WLAN administrators can begin to install UAPs. In addition to the high capacity requirements at HD wireless events, the same-channel requirement for two neighbor UAPs to perform a Wireless Uplink make this topology inappropriate for HD WLANs. Instead, connect each UAP via wired Ethernet cables back to UniFi Switches to support the bandwidth requirements at both the access and core layers of the network.

Site Walkthrough

After supplying POE to the UAPs and updating with the intended channel pattern, consider defining simple SSIDs to uniquely identify each UAP as you walk around the HD WLAN coverage area. With any site walkthrough, you should carry a sample client device (anticipated at the time of HD WLAN Planning) to measure and track the most important metrics throughout and across the coverage area including signal strength, noise floor, and SNR. Since the purpose of the initial site walkthrough is to establish, define, and adjust the intended wireless coverage area, be sure to also bring a laptop make immediate configuration changes to the deployed UAPs as well.

Controller Tips for Site Surveys

As part of the Site Walkthroughs, consider using the WLAN Override function to temporarily rename the primary SSID broadcast by each AP to uniquely identify each individual cell to the client device performing the Site Survey. To tweak the HD WLAN coverage area between events, create a backup of the Site that contains the “one-SSID-per-AP-radio” naming convention.

Client Benchmarking

The UniFi Mobile App allows WLAN administrators to collect the most important metrics conducted during the Site Survey, including signal strength and noise levels. Following deployment, use the UniFi Speed Test as well as intended applications during live events to ensure that client devices support the SLA requirements for the HD WLAN.

UniFi RF Scanning

In order to make educated decisions regarding channel operation throughout the wireless network, WLAN administrators must study and analyze the RF environment within the HD WLAN. Before and after deployment, use the RF Scan tool to conduct a spectral analysis from the perspective of each UAP. During the RF Scan, the UAP radio will stop broadcasting WLANs for up to 5 minutes in order to ‘listen’ the RF environment. Following the RF Scan, the UAP radio reports two important characteristics needed to the level of interference as well as utilization percentage. Based on the results of each scan, record, re-plan, and reassign channels before reevaluating the RF environment of the HD WLAN. Be sure to run the RF Scan tool on all APs individually, but not simultaneously, otherwise, the data presented by the spectral analysis will not accurately represent the RF environment in which the HD WLAN operates (furthermore, all clients will experience connectivity issues).

UniFi Statistics & Insights

The UniFi Controller gathers and reports the most important Client and WLAN information in real-time needed to make ‘on-the-fly’ changes to the wireless network under management. Here are a few of the most important in-Controller Statistics and Insights to review from the perspective of HD WLANs.

UniFi Info

Description

Recommendation

Traffic Statistics

Relates the aggregate network bandwidth consumed on the network.

Ensure that the aggregate traffic statistics match WLAN capacity plans, otherwise add/remove UAPs as needed.

User Activity

Relates the level of activity and bandwidth consumed by individual users.

Enforce stricter traffic shaping policies to high-activity client devices to minimize their negative effect on the HD WLAN.

Deep-Packet Inspection

Relates information about the applications in use on the network.

Create traffic-shaping and/or firewall rules to limit or eliminate the negative effect of select apps on the HD WLAN.

Configuration of the UniFi Controller

Back to Top

Broadcast/Multicast Control

When left unchecked, broadcast and multicast network traffic can severely reduce the available airtime on the HD WLAN, leading to a decrease in speed, increase in latency, and potential connectivity problems for clients. Consider segmenting the wired and wireless portions of the network through VLAN assignment at the time of WLAN creation. Alternatively Port Isolation at the switch layer to limit unnecessary traffic and conserve precious airtime available to stations in the HD WLAN.

SSIDs

To ensure maximum Access Points make efficient use of airtime, limiting the number of SSIDs announced throughout the HD WLAN is a vital detail. Although UAPs support up to 4 SSIDs per radio band, most scenarios (including HD WLANs) only require two SSIDs to support two types of security: Open for ‘Guests’ and WPA2-PSK or -EAP for trusted, ‘Corporate’ users). For client roaming reasons, use the same SSIDs throughout the entire HD WLAN coverage area (e.g., SSID-event) rather than complicated naming schemes (e.g., SSID-11th-floor, SSID-lobby). Any SSID that serves a nominal purpose separate from the capacity objectives of the HD WLAN (e.g., SSID-admins) does not warrant existence.

Traffic Shaping

To limit the impact of data-hungry users and applications that jeopardize the availability of bandwidth and airtime on the HD WLAN, define widespread rate limits (in Mbps) via the User Groups feature. Speed limits that are too strict can detrimentally affect the performance of the wireless network, while too high of speed limits the effectiveness of traffic shaping.

Minimum RSSI

Following association and/or when roaming in the HD WLAN coverage area, client devices negotiating at low speeds (due to long distance from the AP) have a negative impact on the aggregate performance of the wireless cell through poor airtime efficiency. Therefore, proper design and architecture of HD WLANs paired with signal threshold levels help ensure that clients remain connected to the intended AP cell offering them the best performance. When defining the Minimum RSSI setting, WLAN administrators must be careful, since too strict threshold levels can result in severe, widespread connectivity problems that cripple user activity on the network. For HD WLANs, Ubiquiti recommends setting the Minimum RSSI to no greater than -75 dBm, where lower thresholds levels (e.g., -80 dBm) mean clients will remain connected to the AP at greater distances from the center of the cell coverage area. Because UniFi Minimum RSSI uses a ‘soft’ kick implementation, whether or not the station disassociates from the AP is ultimately determined by the client device itself.

Band Steering

Although an increasing number of client devices today support and even prefer 5G operation, balancing the client activity between wireless bands often fail in large part due to the strong signals and propagation characteristics of the 2G band. In dual-band HD WLAN scenarios, therefore, steering capable wireless clients to the 5G band is a particularly vital configuration setting to avoid 2G band congestion. Because UniFi Band Steering uses a ‘soft’ steering implementation, whether or not the station associates and remain connected to the 5G band is ultimately the decision of the client device itself.

Load-Balancing

The unpredictability introduced by variables like user attendance and roaming can often result in scattered wireless activity through the HD WLAN. While an emphasis on proper design, architecture, and AP placement precedes and carries more importance than post-deployment configuration ‘tricks’, the UniFi load-balancing technique defines a soft user-ceiling whereby APs attempt to kick the clients with the weakest signals until the total number of associated clients returns to the defined threshold. Because UniFi load-balancing uses a ‘soft’ kick implementation, whether or not the station disassociates from the AP is ultimately determined by the client device itself.

802.11 Rate Configuration

In High-Density WLANs, where airtime efficiency is critically important to the overall performance of the wireless network, carefully consider adjusting the 802.11 RATE AND BEACON CONTROLSalbeit with extreme caution. Improper configuration of this advanced feature can lead to disruptive performance or widespread connectivity problems for clients throughout the WLAN.

Disabling lower rates benefits HD-WLANs in a few important ways:

Forces “sticky” roaming clients to re-associate to another AP. If the WLAN is well-designed/implemented, the new AP to which the client roams will offer a better signal and have a twofold impact on improving that client’s speeds as well as the aggregate performance of the previous BSS, since low-rate clients no longer drag down the airtime.

Lessens the probability of channel contention (i.e., the likelihood that a transmitted signal collides with another signal being received by a receiver in the WLAN) since there is less overhead from associated clients within the BSS. With low data rates disabled, clients transfer data as quickly as possiblethen remain quiet. This frees up the WLAN for other clients that need to use the channel.

Reduces the chance of hidden nodes on the network since associated clients are within a close proximity of each other, and therefore, able to 'hear' whenever a transmitter is actively using the wireless channel.

Recommendations for High-Density WLANs

Here are some additional performance recommendations that may improve performance in high-density deployments:

1. Only use 5GHz in high-density deployments.

If used at all, 2.4GHz Wi-Fi should be only enabled on a very few number of APs/and only as an exception to the rule.

2. Enable multicast block on any VLANs with over 100 devices.

This can be done in the UniFi SDN Controller under Settings > Wireless Networks > Edit > Advanced Options, and clicking the checkbox next to "Block LAN to WLAN Multicast and Broadcast Data".

ATTENTION:You will need to whitelist any devices that require clients be able to communicate via multicast/broadcast data, such as your gateway.

3. Increase ARP Timeout on the Router.

If using a USG, this can be done by adding lines as shown in the following example to the config.gateway.json file as explained here.

ATTENTION:This is an advanced configuration and should only be considered if you are experienced and familiar with manual USG configuration process.

{

"system": {

"ip": {

"arp": {

"base-reachable-time": "7200",

"stale-time": "1200"

}

}

}

}

4. Enable minRSSI at -75 dBm, with strict minRSSI as well.

Ensure that the venue is covered with at least -60 dBm throughout all locations where it's important to have WiFi. This can be done in Devices > Config > Radios > Advanced Options under "RADIO 5G(11N/A/AC)".

ATTENTION:This is an advanced configuration and should only be considered suggested in high-density environments and for those experienced with advanced WLAN management.

Related Articles

Back to Top

Overview

This article provides the steps to enable guest authentication with Facebook and Google+.

UniFi - Viewing Guest Connection Information

NOTES & REQUIREMENTS:

Applicable to UniFi Network Controller 5.4.2.1 and later. In order to use 3rd party guest authentication, there must have a publicly-resolvable hostname pointing to the Controller. If your company already uses a public domain, such as 'example.com', you may want to set up a subdomain such as 'portal.example.com'. There are a variety of Dynamic DNS providers where you can register a hostname, then have your router update it to your WAN IP.

Table of Contents

Introduction

Facebook App Setup

Google+ API Setup

UniFi Controller Setup

Related Articles

Introduction

Back to Top

Social media guest authentication can be enabled to allow clients to log in to a guest network using their Facebook or Google+ credentials. Start by creating a facebook app, google+ API login, or both.

Facebook App Setup

Back to Top

1. Register a Facebook App

Use the guide HERE to register a Facebook authentication app, keeping this help article open for reference.

Step 3 prompts you to choose a display name for your application. Choose a name that will represent your WiFi portal. Users will see this when authenticating. For this example, I’ll use the name "CMurphy Hotspot Login," and keep the default email, which is the email linked to my Facebook account. For Category, I’ll use Communication. Category isn’t critical here, so feel free to use a different category if it better represents your business.

You will be prompted to either enter a quick-start guide, or go back. If you click go back, you can get to the dashboard by clicking My Apps in the top right corner. Select Choose Platform > Website to begin the quick start quide.

2. Complete Facebook Website Quick Start.

Choose Website.

Under Tell us about your website, enter the domain name of your controller as the Site URL. Next, click Skip to Developer Dashboard.

3. App Settings

Navigate to Settings in the sidebar to open up the basic app settings.

App ID and App Secret will be automatically assigned to your app. Choose a Display Name and Namespace for your app - these can be anything, but users will see them when authenticating.

Under both App Domains and Site URL, enter the domain or subdomain of your controller.

You must add URLs for privacy policy and terms of service. These are required for proper function.

You can add Privacy Policy/Terms of Service to guest portal through Settings > Guest Control > Enable Terms of Service, then can use the url of your controller, for example: https://controller:8843/guest/s/<site-id>/#/tos

Replace controller with publicly accessible controller URL, and if using non-default site, replace site id with the site's unique 8-digit identifier, i.e. ryx7y4tf in the following example:

Be sure to save your changes.

4. Add Product

Next, click Add Product, then Facebook Login to create the login page.

5. Add Controller Redirect URI and Port

Under Facebook Login settings, include the following URL under "Valid OAuth redirect URIs". Use the toggle options in the below image.

Or if using http (which may not be permitted by current Facebook settings):

Replace domain.com with your publicly accessible controller URL, and site <siteid> with the 8-digit site identifier from your UniFi Controller URL, for example:

In this example, the siteid is "ryx7y4tf" and would need to be included in the URL added to the "Valid OAuth redirect URIs" in Facebook App settings:

https://unifi.exampleurl.com:8443/guest/s/ryx7y4tf/oauth.html?by=facebook

Save changes before continuing.

6. Publish App

Finally, publish the app to live, by changing the "Off" dialog button at the top of the Facebook for developers page to on.

If you are setting up Google authentication as well, continue reading. Otherwise, skip to Controller Setup.

Google+ API Setup

Back to Top

1. Enable Google Login

Use the Enable the Google+ API Guide HERE to enable Google login.

When prompted to enter the app origin, use the subdomain, followed by port 8880 (and/or 8843). Note the Client ID and Client Secret, which will be used later in the Controller Setup.

You will need to add your customized version of the following URL to Google API Credentials Settings:

If using Secure Portal (https):

https://<controller-url>:8843/guest/s/<site-id>/oauth.html?by=google

Or if you do not have Secure Portal enabled (http):

http://<controller-url>:8880/guest/s/<site-id>/oauth.html?by=google

Replace <controller-url> with your publicly accessible controller URL, and site <siteid> with either default if using the default site, or the 8-digit site identifier from your UniFi Controller URL, as in the following example:

In this example, the siteid is "ryx7y4tf" and would need to be included in the URL added to Google API settings.

2. Add Redirect URIs

The following would need to be added to Authorized redirect URIs in Google API settings:

https://unifi.exampleurl.com:8443/guest/s/ryx7y4tf/oauth.html?by=google.

If client device gets a redirect error after setup, add the redirect URI below under "Authorized redirect URIs" in the above step:

3. Enable People API for your project.

Follow Google's instructions on how to enable People API.

UniFi Controller Setup

Back to Top

1. Activate Guest Policies

Once you have configured your Facebook or Google app, open your publicly hosted controller. Begin by activating Guest Policies by navigating to Settings > Wireless Networks and making sure the Guest Policy box is checked to enable.

2. Configure the Guest Portal

2.1 Next, open Setting > Guest Control to configure the guest portal. To view these options, the "Enable Guest Portal" box must be checked.

2.2 Select Hotspot authentication.

2.3 If you wish, enter a Promotional URL to forward clients to your website after they are authenticated. Or leave it in Redirect to the original URL to allow user to continue to the website they were trying to get to.

2.4. Select Redirect using hostname, and enter the URL of your subdomain in the field provided.

2.5. Check Enable encrypted redirect URL.

2.6 Under Settings > Guest Control > Access Control, allow Google Sites for pre-authorization access by adding the IP number 172.217.20.0/19.

3. Activate Third Party Authentication Method

Under theSettings > Guest Control >Hotspotsection, select the third party authentication methods that you wish to activate (Facebook and Google). Enter the ID and Secret for the selected app(s) as configured in those platforms.

4. Add Facebook and Google's Public IPs

Under Access Control, add the following public IPs that Facebook uses to the Pre-Authorization Access list:

31.13.24.0/21

31.13.64.0/18

45.64.40.0/22

66.220.144.0/20

69.63.176.0/20

69.171.224.0/19

74.119.76.0/22

103.4.96.0/22

129.134.0.0/16

157.240.0.0/16

173.252.64.0/18

179.60.192.0/22

185.60.216.0/22

204.15.20.0/22

If you haven't yet, add the following public IP that Google uses to the Pre-Authorization Access list:

172.217.20.0/19

5. Test the Guest Network

Finally, use a device to connect to the guest network and verify that the guest portal works properly.

Related Articles

Back to Top

UniFi - Guest Network, Guest Portal and Hotspot System

Overview

This article discusses how to use VLANs with UniFi products. Find a link to an introductory article on VLANs in the Related Articles below.

Table of Contents

UniFi Device Management

UniFi Access Points (UAP)

UniFi Switch (USW)

UniFi Security Gateway (USG)

Related Articles

UniFi Device Management

Back to Top

Initially, you need to adopt your UniFi access points or switches over the native, or untagged, VLAN, and this will be the continued requirement. That being said, L3 management is supported, so your UniFi Network Controller can be on a different L3 network (or remote, etc.). See more about that on our UniFi - Device Adoption Methods for Remote UniFi Controllers article.

As of Controller software version 5.8, access points and switches can be set to tagged VLANs. After you adopt the device over the untagged VLAN, you can define a tagged management VLAN to use. This is found under the device Properties window (from the Devices page click on the device to reveal) > Configuration > Services > Management VLAN.

UniFi - Configuring Access Policies (802.1X) for Wired Clients

UniFi Access Points (UAP)

Back to Top

You can have upwards of one tagged VLAN per SSID, and 4 SSIDs per radio. You can set the VLAN that an SSID uses by going to Settings > Wireless Networks > Advanced Options. The advanced options area is shown either when you create a new wireless network (SSID), or when you edit an existing SSID. You can use VLANs on standard or guest SSIDs.

Currently, the only VLAN you can't tag to an SSID is 1, although that may change in the future, once we expand the ability to define a management VLAN to all UAPs.

Within UniFi Network Controller v5, and subsequent releases, you can use RADIUS controlled VLANs with UniFi APs and Switches. Instead of defining a VLAN, you enable this within the RADIUS profile.Find this section under Settings > Profiles. Below is an example of the RADIUS profile section.

Set the following RADIUS attributes in the RADIUS server for each user or group, based on your RADIUS configuration:

Tunnel-Type = 13,

Tunnel-Medium-Type = 6,

Tunnel-Private-Group-Id = "149" # <=== add your vlan id for each user.

At the time of writing, one known limitation withRADIUS controlled VLANs is that you can't share a VLAN ID between RADIUS users and a static VLAN assignment on another SSID on that AP. So, if SSID1 has a static VLAN assignment of 10, and SSID2 is configured for RADIUS controlled VLANs, the users on SSID2 cannot use the VLAN ID of 10, but they can use any other VLAN ID. If you had a 3rd SSID, that also used RADIUS controlled VLANs, you can use the same VLAN IDs as you would for the users on SSID 2 (except for 10). This applies on a per-AP basis. Disabling the wireless network on the controller is sufficient means to avoid the static VLAN overlap while transitioning to dynamic VLAN.

NOTE:Where using RADIUS-assigned VLANs, the UAP's switch port must have all the RADIUS-assigned VLANs configured as tagged VLANs on its switch port. With UniFi switches, the default "All" network assignment on the UAP's switch port covers that requirement, as long as those VLAN IDs are defined in the controller under Settings > Networks, as either a VLAN-only, corporate, or guest network.

UniFi Switch (USW)

Back to Top

As with UAPs, you can use VLANs with UniFi Switches. By default, your ports are set to All, so it'll have an untagged VLAN 1, and then the rest will be tagged. VLANs need to be defined in the UniFi Network Controller under Settings > Networks. To simply set up a VLAN you would set a network as VLAN only.

To change the profile on a port, or port group, you would click on the Switch in the Devices tab to reveal the Properties window, then go to Ports,and either choose the edit button on the right or select the desired ports and click "edit selected" on the bottom. In editing mode, you can choose the profile for the port(s). The Networks/VLANs profile on a port can be used to define the untagged and tagged networks on the selected port(s).

You can create port profiles in the controller's Settings > Profiles > Switch ports > Add new Profile.Currently, UniFi switches are different from UAPs in the sense that you can tag VLAN 1 on a port.

The UniFi switch is currently the only device where you can tag VLAN 1 if needed. The default LAN network in the controller is VLAN 1. So to tag it, you would create a custom profile and tag it. VLAN 1 is the default LAN network in Settings > Networks in a fresh controller.

In UniFi Network Controller 5.5.x+ versions, support for RADIUS controlled VLANs was added. You would first have to enable 802.1x control and choose a RADIUS profile. This is found under the switch Properties Window > Configuration > Services.You then need to either create a new RADIUS profile, with it RADIUS VLAN enabled for the switch, or make sure it's enabled on an existing profile.

You may also need to configure the switch port profile for 802.1x in Settings > Profiles > Switch Ports > "Add New Port Profile" or edit existing. 802.1x Settings can be found under "Advanced Settings".

You can manage RADIUS profiles from Settings > Profiles.

UniFi Security Gateway (USG)

Back to Top

The USG can be used to manage DHCP server, routing, and VLANs on your network. It would also use the Settings > Networks area to define subnets. A corporate network has no restrictions, whereas a guest network cannot communicate with other subnets on your network. The guest control settings are also applied to guest networks (i.e. wired guest portal).

The default physical LAN interface's network is, by default, using untagged VLAN 1. There can be multiple VIFs (virtual interface/VLANs) per physical LAN interface. You cannot edit the VLAN ID of the untagged subnet (it is 1 or 4010, depending on if it's LAN or VoIP subnet). The settings window looks similar for both corporate and guest networks, so we'll only picture a corporate network. Basically, enter the desired IP with CIDR, and then choose your VLAN ID.

Related Articles

Back to Top

Intro to Networking - Introduction to Virtual LANs (VLANs) and Tagging

UniFi - VLAN Traffic Tagging

UniFi - Device Adoption Methods for Remote UniFi Controllers

Overview

Readers will learn how to forward UDP and TCP ports to an internal server using the Port Forwarding feature.

Intro to Networking - How to Establish a Connection Using SSH

NOTES & REQUIREMENTS:

Applicable to the latest EdgeOS firmware on all EdgeRouter models. Please see the Related Articles below for more information.

Devices and products used in this article:

EdgeRouter-4 (ER-4)

Ubiquiti Network Management System (UNMS)

Table of Contents

Frequently Asked Questions (FAQ)

Adding Port Forwarding Rules

Related Articles

Frequently Asked Questions (FAQ)

Back to Top

What is the difference between Destination NAT and Port Forwarding?

Destination NAT and Port Forwarding serve the same purpose and can both be used to forward ports to an internal host behind NAT.

Do I need to manually add firewall entries for each Port Forwarding rule?

No, see the steps below.

Do I need to manually configure Hairpin NAT?

No, see the steps below.

When using Hairpin NAT, add the LAN interfaces of all networks that need to use the router's external address to access the internal host(s).

Adding Port Forwarding Rules

Back to Top

The HTTPS traffic with TCP port 443 and 10443 from external clients will be forwarded to the UNMS server.

Follow the steps below to add the Port Forwarding rules to the EdgeRouter:

GUI: Access the EdgeRouter Web UI.

1. Select the WAN and LAN interfaces that will be used for Port Forwarding. The auto-firewall feature will automatically open the required ports in the firewall.

Firewall / NAT > Port Forwarding

Check:Show advanced options

Check:Enable auto firewall

Check: Enable Hairpin NAT

WAN interface: eth0

LAN interface: eth1

ATTENTION:The WAN and LAN interfaces might differ depending on your EdgeRouter model and setup. For example, the ER-X / ER-X-SFP / ER-10X / ER-12 / ER-12P and EP-R6 are able to use switch0 as the LAN interface.There is an example in this community post.

2. Add the port-forwarding rules for TCP ports 443 and 10443.

+Add Rule

Original port: 443

Protocol: TCP

Forward-to address: 192.168.1.10

Forward-to port: 443

Description: https443

+Add Rule

Original port: 10443

Protocol: TCP

Forward-to address: 192.168.1.10

Forward-to port: 443

Description: https10443

3. Apply the changes.

The above configuration can also be set using the CLI:

CLI: Access the Command Line Interface.You can do this using the CLI button in the GUI or by using a program such as PuTTY.

configure

set port-forward auto-firewall enable

set port-forward hairpin-nat enable

set port-forward wan-interface eth0

set port-forward lan-interface eth1

set port-forward rule 1 description https443

set port-forward rule 1 forward-to address 192.168.1.10

set port-forward rule 1 forward-to port 443

set port-forward rule 1 original-port 443

set port-forward rule 1 protocol tcp

set port-forward rule 2 description https10443

set port-forward rule 2 forward-to address 192.168.1.10

set port-forward rule 2 forward-to port 443

set port-forward rule 2 original-port 10443

set port-forward rule 2 protocol tcp

commit ; save

Related Articles

Back to Top

EdgeRouter - Destination NAT

EdgeRouter - Hairpin NAT

Overview

In this article, readers will learn about the different modes that are used in the EdgeOS Command Line Interface (CLI).

Intro to Networking - How to Establish a Connection Using SSH

NOTES & REQUIREMENTS:Applicable to the latest EdgeOS firmware on all EdgeRouter models. Knowledge of the Command Line Interface (CLI) and basic networking knowledge is required. Please see the Related Articles below for more information.

Device used in this article:

EdgeRouter-4 (ER-4)

Table of Contents

Configuration and Operational Mode Basics

Making Configuration Changes

Related Articles

Configuration and Operational Mode Basics

Back to Top

There are two modes in the EdgeOS command line, this article describes what each does, how to switch from one to another in the Command Line Interface and finally how to make configuration changes via CLI. TheOperational Mode, represented by a dollar sign $ is used to display the status of the device. TheConfiguration Mode,represented by a hashtag # is used to make configuration changes to the device.

The default mode when logging into the command line is Operational Mode. To switch to Configuration Mode, use theconfigurecommand:

ubnt@edgerouter:~$ configure

[edit]

ubnt@edgerouter#

NOTE: Operational Mode is indicated by a dollar sign $, whereas Configuration Mode uses the hashtag #.

To go back to operational mode, use the exit command:

[edit]

ubnt@edgerouter# exit

exit

ubnt@edgerouter:~$

Each mode has its own unique commands. You can use the question mark?key to display all the available commands in both modes. Press the?key twice to also display the command descriptions:

ubnt@edgerouter:~$ ?

Possible completions:

configure Enter configure mode

ping Send Internet Control Message Protocol (ICMP) echo request

reboot Reboot the system

show Show system information

shutdown Shutdown the system

traceroute Track network path to <hostname|IPv4 address>

traceroute6 Track network path to <hostname|IPv6 address>

<...output shortened...>

ubnt@edgerouter:~$ configure

[edit]

ubnt@edgerouter# ?

Possible completions:

commit Commit the current set of changes

compare Compare configuration revisions

delete Delete a configuration element

edit Edit a sub-element

exit Exit from this configuration level

run Run an operational-mode command

save Save configuration to a file

set Set the value of a parameter or create a new element

show Show the configuration (default values may be suppressed)

<...output shortened...>

NOTE: The second question mark?does not display onscreen.

If you wish to run an Operational Mode command from while inConfiguration Mode, use the runcommand.

[edit]

ubnt@edgerouter# run show ?

Possible completions:

interfaces Show network interface information

ip Show IPv4 routing information

ipv6 Show IPv6 routing information

<...output shortened...>

Making Configuration Changes

Back to Top

The EdgeRouter uses three configuration sets:

Boot/Startup ConfigWhen the EdgeRouter reboots, it loads the boot/startup configuration (config.boot)

Active Config Currently active configuration with changes that have not been saved to the boot/startup configuration yet.

Working ConfigNon-active configuration with changes that have not been applied (committed) yet.

Use the following commands to make changes to the configuration:

setAdds a configuration statement from the device

deleteRemoves a configuration statement from the device

commitApplies any changes that were added with thesetordeletecommands

save Saves the active configuration to the boot/startup configuration

Let's say that we want to enable the Telnet service, we would issue the following:

[edit]

ubnt@edgerouter# set service telnet port 23

ubnt@edgerouter# compare

[edit service]

+telnet {

+ port 23

+}

[edit]

ubnt@edgerouter# commit

[ service telnet ]

Starting the telnet service. Check /var/log/messages.

NOTE: Thecomparecommand will show you the difference between the working and the active configurations.

Save the configuration changes to the boot/startup configuration by using thesavecommand:

[edit]

ubnt@edgerouter# save

Saving configuration to '/config/config.boot'...

Instead of applying changes with thecommitcommand, you can also usecommit-confirm. The latter command reboots the device in 10 minutes (you can customize this value) unless the commit is confirmed with theconfirmcommand. This is helpful when you are making changes to a remote device and you do not want to risk losing access to it. If you accidentally lock yourself out of the device, the EdgeRouter will reboot after 10 minutes and the boot/startup configuration is re-loaded.

[edit]

ubnt@edgerouter# delete service telnet

[edit]

ubnt@edgerouter# commit-confirm 5

commit-confirm will automatically reboot in 5 minutes unless confirmed

Proceed? [yes][y]

Type 'confirm' to stop reboot

[edit]

ubnt@edgerouter# confirm

Related Articles

Back to Top

EdgeRouter - How to Configure an Interface

EdgeRouter - User Accounts

EdgeRouter - How to Create a WAN Firewall Rule

EdgeRouter - Archiving and Managing the Configuration Files

Overview

This article provides step-by-step instructions on how to use Facebook Wi-Fi for Guest Authorization with UniFi.

Table of Contents

Introduction

Requirements

Directions

Related Articles

Introduction

Back to Top

UniFi introduced the Facebook Authentication method for Guest Wi-Fi beginning in UniFi Network Controller version 5.6.12. This feature allows businesses to permit users to authenticate to Wi-Fi via Facebook. Using Facebook authorization can provide an easy and straight-forward way of ensuring customers are able to access Wi-Fi while also gaining benefit for marketing your business via social media. This guide will show you how to set up a Facebook Wi-Fi Network in UniFi.

Requirements

Back to Top

Much of how Facebook Wi-Fi works is based on Facebook's requirements which will differ from standard UniFi networks. In order to use Facebook Wi-FI with UniFi the following requirements must be met:

Must be on UniFi Network Controller version 5.6.12 or later.

Must have created a Facebook page for your business, and this page MUST be published publicly. See directions here.

UniFi Network Controller must remain online to process Guest Authorization.

Directions

Back to Top

1. Open your UniFi Network Controller.

UniFi - Viewing Guest Connection Information

User Tip:The following instructions are on the Controller's "Classic Settings Mode", if you are using the New Settings, use the search bar on top to find the settings mentioned in these steps.

2. Go to Settings > Guest Control, and check "Enable Guest Portal" if not already enabled.

3. For Authentication, select "Facebook WiFi".

4. Once Facebook WiFi is selected as Authentication, a new section titled "Facebook WiFi" will appear on this page.In this section, provide a Gateway Name. This is only used on the Facebook WiFi and will not be visible to clients. Notice the note under Gateway Configuration: "Facebook Wi-Fi gateway configuration will be available after registering the gateway with Facebook. The registration will happen automatically after applying the changes with the Facebook Wi-Fi feature enabled for the first time. Once you select the name, it won't be possible to change it without gateway re-registration."

5. Once you have provided a name for the Gateway, hit "Apply Changes".

6. Once changes have been applied, you will be able to proceed with Facebook WiFi configuration by clicking "GO TO FACEBOOK WIFI CONFIGURATION".

7. Clicking this field will direct you to Facebook's site to proceed with the configuration steps. You should see a page like this:

8. Next, under Facebook Page, select the Facebook Page that you'd like the Wi-Fi to be associated with.

9. Under Bypass Mode, select either:

"Skip check-in link" which permits users to get access to the Wi-Fi without having to check-in with social media.

"Require Wi-Fi code" which requires the user to use a pre-defined Wi-Fi code you can provide to your customers.

10. Select "Session Length" to determine how long users should have access to Wi-Fi before having to reauthenticate.

11. Under "Terms of Service", if enabled you can require users to first accept your own Terms and Services.

12. Once you have configured these settings to your liking, click "Save Settings". You will then be prompted to close the window.

13. After these settings have been applied, the only thing that is left to do is to apply Guest Policies to your Facebook Wi-Fi Guest Network, by going to Settings > Wireless Networks > Select the SSID you wish to use Facebook Authentication with, and clicking "Apply Guest Policies", then click "Save" at the bottom of the page.

14. You should now be able to test Facebook Wi-Fi.

Testing Facebook Wi-Fi

Let's take a look at what the process looks like from a user's perspective:

1. The user will connect via Wi-Fi to your Guest SSID. Once connected, they will be automatically prompted to complete additional steps as shown:

2. The user will then need to Login to Facebook to authenticate/associate the individual's Wi-Fi access with their Facebook account.

3. After signing in, the user will then be prompted with the ability to Check In, which is a nice way to increase traffic to your Facebook page, or alternatively skip Check-in or enter a Wi-Fi code depending on how you want to enforce this.

User Tip:By setting a Wi-Fi code you will likely direct more users to Check-In to your business page, helping generate more traffic on your Facebook business page.

Related Articles

Back to Top

UniFi - Wireless Guest Network Setup

Overview

In this article users can comparethe differentantenna radiationpatternsof a few of ourUniFi Access Points. For an explanationon how to read antenna radiation patterns see our UniFi - Introduction to Antenna Radiation Patterns article.

Table of Contents

1. Introduction

2. Radiation Plot Format

3. Comparison Table

4. Model Summary Plots

4.1 UAP-HD

4.2 UAP-SHD

4.3 UAP-AC-Lite

4.4 UAP-AC-LR

4.5 UAP-AC-PRO

4.6 UAP-AC-IW

4.7 UAP-AC-IW-PRO

4.8 UAP-IW-HD

4.9 UAP-AC-M

4.10 UAP-AC-M-PRO

4.11 UMA-D

4.12 UAP-nanoHD

4.13 UAP-XG

4.14 UWB-XG

4.15 UDM

4.16 UAP-FlexHD

4.17 UAP-BeaconHD

5. Antenna Files (.ant)

6. Related Articles

Introduction

Back to Top

The UniFi access pointshave a distinct hardware design to meet the varying needs of wireless deployments. A critical part of what differentiates each model is the number, arrangement, and orientation of the AP’s antennaswhich influences the shape and behavior of wireless signal (both on transmit and receive). Radiation patterns can be used to better understand how each UniFi access point model broadcasts wireless signa. These patterns are what antenna engineers call reciprocalin that the transmit-power (the capability of the AP to ‘speak’) will be highest at the peaks, and so will the receive-sensitivity (the capability of the AP to ‘hear’).

Please note that these radiation patterns are gathered in a fully anechoic environment. Their shape, peak gain/directivity and efficiency will change in installed environments. Every deployment will behave differently due to interference, materials, geometries of structures, and how these materials behave at 2.4GHz and 5GHz.

With that in mind, use these radiation plots as a "general guide" to identify where most of the energy (and receive sensitivity) of the UniFi APs is being directed; but keep present that the ultimate way to know how successful the coverage design isis to measure it. Measure signal strength and coverage before (with mock positioning), during (as you install), and after to guarantee that you have the coverage you wantand don’t have the coverage you don’t want (for example with self-interference: APs hearing each other or other AP stations on the same channel).

Radiation Plot Format

Back to Top

Radius represents ‘elevation’, with 0 representing antenna gain straight under the AP, and 90 representing antenna gain at horizon. The degrees on the circumference represent ‘Azimuth’. That is to say, left/right/front/back of the AP, when mounted overhead. For a more detailed explanation, please see our UniFi - Introduction to Antenna Radiation Patterns article.

Comparison Table

Back to Top

Use this table to compare the radiation patterns of each UAP. The first column shows where the respective colored dots found in each radiation plot is placed in the actual devices. Note that colored dots in the plots might be in the outer perimeter or closer to center.

UniFi - Introduction to Antenna Radiation Patterns

NOTE:Varying scales are represented in the graphs below. Consider each graph individually and take note of scale when comparing products.

Product Image

Directional Color Dots

5.20GHz

Frequency

5.50GHz

Frequency

5.80GHz

Frequency

2.45GHz

Frequency

UAP-HD

UAP-SHD

UAP-AC-Lite

UAP-AC-LR

UAP-AC-PRO

UAP-AC-IW

UAP-AC-IW-PRO

UAP-IW-HD

Coming soon.

UAP-AC-M

UAP-AC-M-PRO

UMA-D

UAP-nanoHD

UAP-XG

UWB-XG

(High Gain)

(High Gain)

(High Gain)

The UWB-XG models do not operate on the 2.4GHz band.

UDM

(5.15GHz)

(5.50GHz)

(5.85GHz)

(2.45GHz)

UAP-FlexHD

(5.15GHz)

(5.50GHz)

(5.85GHz)

(2.45GHz)

UAP-BeaconHD

(5.15GHz)

(5.50GHz)

(5.85GHz)

(2.45GHz)

Model Summary Plots

Back to Top

This section includes a graphic summary for eachUAP shownin thetable above, portrayingradiation plots for Azimuth, Elevation 0, Elevation 90 and Mapped 3D, for three different frequencies: 5.20GHz, 5.50GHz and 5.80GHz. Click on each one to expand and zoom.

UAP-HD

Back to Top

UAP-SHD

Back to Top

UAP-AC-Lite

Back to Top

UAP-AC-LR

Back to Top

UAP-AC-PRO

Back to Top

UAP-AC-IW

Back to Top

UAP-AC-IW-PRO

Back to Top

UAP-IW-HD

Back to Top

UAP-AC-M

Back to Top

UAP-AC-M-PRO

Back to Top

UMA-D

Back to Top

UAP-nanoHD

Back to Top

UAP-XG

Back to Top

UWB-XG

Back to Top

High Gain

Low Gain

UDM

Back to Top

UAP-FlexHD

Back to Top

UAP-BeaconHD

Back to Top

Antenna Files (.ant)

Back to Top

Please notethe data in the .ant files below was extracted from full model simulations. Clicking on the links in the following table will prompt the immediate download of the .ant file.

UniFi Access Point Model

Downloadable Antenna Files (.ant)

UAP-AC-IW-Pro

UAP-AC-IW-Pro.zip

UAP-AC-IW

UAP-AC-IW.zip

UAP-AC-Lite

UAP-AC-Lite.zip

UAP-AC-LR

UAP-AC-LR.zip

UAP-AC-Pro

UAP-AC-Pro.zip

UAP-AC-Mesh

UAP-AC-Mesh.zip

UAP-AC-Mesh-Pro

UAP-AC-Mesh-Pro.zip

UAP-HD

UAP-HD.zip

UAP-SHD

UAP-SHD.zip

UAP-nanoHD

UAP-nanoHD.zip

UAP-XG

UAP-XG.zip

UWB-XG

UWB-XG.zip

UMA-D

UMA-D.zip

UDM

UDM.zip

UAP-BeaconHD

UAP-BeaconHD.zip

UAP-FlexHD

UAP-FlexHD.zip

Related Articles

Back to Top

RMA form Ubiquiti devices will have aMAC ID number printed on a small sticker or on the device itself. This information can be found on the back panel or on the underside of devices. Some devices have silicon inserts to protect the Ethernet port areas, remove the insert to expose the MAC ID. MAC IDs can also be found on the outside of product boxes.

The first 5 characters which end with a letter are the device's Date Code. The following 12 characters, a mixture of numbers and letters, will be theMAC ID. The image points out the Date Code section in blue, and the MAC ID, in red. The barcode itself only contains the MAC ID, not the Date Code.

Components and parts of devices do not have MAC ID or Date Code information. In these cases, use the Serial Number (S/N) in the MAC Address space instead when using the official. Serial Number format and length will vary: some will be all numbers, others will have alphabetical and numerical characters. Identify a Serial Number by the S/N or SN in front of it. A few bundled itemswill not have an individual Serial Number, only the packaging box one. In these cases use the carton Serial Number for any of the items packaged within.

Overview

Click on the question that interests you to expand and collapse the answers. If you don't see the answer you are looking for, search in our other UniFi FAQ articles: UniFi - Getting Started FAQ,or let us know by clicking on theSend Feedback button at the bottom of this article.

Frequently Asked Questions

What are the current UniFi Controller software versions for the different release branches?

Release Branch

Definition

Current Release

EOL Product Support

Release that is maintained for products that do not support newer firmware versions.

5.6.42

Stable

General availability (GA) release.

5.12.35

Release Candidate

Release we think can go to Stable unchanged. Formerly called Stable Candidate.

-

Testing

Feature-frozen, going to Release Candidate and then Stable.

5.13.9

Unstable

Branch where new features are being added.

5.12.5

unifi.ui.com

NOTE:Some of these versions are in beta. To sign up for the early access program and be able to access these, follow this article.

Why do I see Release Candidate and Stable releases in the Official release section on the community?

Release Candidate versions are essentially what we are targeting for Stable. We find value in getting these out to a broader audience. If there are no known bugs and nothing discovered in testing, then this release may be promoted to Stable after one week from the initial time it was released to official. Sometimes this process is accelerated and other times it's delayed.

Why do I see Release Candidate and Stable releases in the Official release section on the community?

Release Candidate versions are essentially what we are targeting for Stable. We find value in getting these out to a broader audience. If there are no known bugs and nothing discovered in testing, then this release may be promoted to Stable after one week from the initial time it was released to official. Sometimes this process is accelerated and other times it's delayed.

The Beta section of Releases will hold versions in Unstable, Testing, and Release Candidate stages. The Official section, will only share Release Candidate and Stable stages.

Why can't I find the latest release in the repo for Debian/Ubuntu?

A release is initially only available via the Downloads page or release post on the Releases section of the Community. As a general rule, one week after a release goes Stable it will be made available on the repos. There will be some exceptions where the this period will be shorter or longer. There are also cases where a release goes Stable but we find a bug and decide not to push that out to the repo, and instead will work on a follow-up release which fixes the bug, promoting that release to stable instead. The follow-up release may follow an accelerated release plan or it may go through the regular one week intervals.

What are the recommended UniFi Network Controller versions for UniFi Hardware?

We recommend always running the latest UniFi Network Controller software version as well as the latest device firmware version provided in our Downloads page. Our developers are constantly updating and improving features, so for best functionality always upgrade. To know which is the latest recommended version for a specific device, go to the Downloads page, click on the model of choice in the left hand menu and look at the Software and Firmware sections. For example, notice that for the UAP-AC and the UAP-AC-Outdoor it is suggested to stay in the 5.6.42 software controller version.

If you wish to know what theminimum version you can use is to check your device's Quick Start Guide's Introduction section.Quick Start Guides can be found at the bottom of the product page, which can be accessed when navigating from the UI Products page. They can also be downloaded from UI Downloads.

Does the UniFi Controller have to run at all times? What happens with the Guest Portal when the Controller is offline?

UniFi devices retain their running configuration post-adoption. The controller is not required to be running for the devices to forward traffic. If the controller is restarted it will not restart your access points or other devices. All configurations, as well as your internet connectivity, will continue working as usual. However, you will lose anything running on the Controller directly instead of a device; for example: statistics, reporting, manually applied user groups, and most importantly, the Guest Portal.

When the Guest Portal feature is enabled, the controller is functioning asa captive portal.When a UniFi access point (UAP) cannot reach the controller, it goes into "SELFRUN" state. In this state, it will not redirect guests to the portal since it is not reachable, so the UAP will automatically allow guests to use the network without redirecting. Moreover:

The guest access policies willstill be effective, along with the restricted subnets feature.

The user group configuration associated with this WLAN will still be effective.

When the Controller comes back online (and the UAP goes into MANAGED state), the Guest Portal redirection feature will restore automatically.

If you wish to configure the "SELFRUN" state, please see this article. If you would like to know more about setting up Guest Networks (including the Portal), please see: UniFi - Guest Network, Guest Portal and Hotspot System.

Can I make the UniFi Controller update information more frequently? Where is the refresh button?

The controller's refresh button is hidden by default, but it can be added to the top toolbar, by enabling it in the Controller's Preferences. You'll beable to select between 15 seconds, 1 minute, 2 minute or 5 minutes update intervals. Or you could altogether eliminate automatic refreshing, by selecting "Never refresh" and only refreshing the controller manually with the button once it is enabled. To configure these two settings:

Classic Controller Mode:

Go to Settings > User Interface and scroll down to the Datasubsection.

To add the refresh button to your controller's top toolbar, switch on the Enable refresh button setting.

To adjust the frequency of automatic refreshing, or disable it completely, use the drop-down of the Refresh ratesetting.

New Settings (Beta) Mode:

Go toSettings > Preferences > Advanced to theData section.

To add the refresh button to your controller's top toolbar, switch on the Enable Refresh Button setting.

To adjust the frequency of automatic refreshing, or disable it completely, use the drop-down of the Refresh Ratesetting.

Can I change the language of the UniFi Controller?

Yes! The UniFi Controller translation, as well as most other translations in Ubiquiti are Community based. They're a team effort done by native speaking Community members who have volunteered to work on this project. If you are interested in collaborating with us, please sign up for beta access first by following this article: How To Sign Up for Early Access and then tag UI-AlexCaldas to volunteer. If you find mistakes in translations, please let us know in this dedicated Community thread. To change the language of your Controller follow these steps:

On the Classic Controller Mode:

Go to Settings > User Interface and the Localizationsubsection.

Select the language you prefer from theLanguage drop-down menu.

Read the warning before clickingSave and Close, now visible in your selected language. Sometimes you will need to refresh the page to see the translations reflected on your screen. You can toggle to another section and back to force this refresh.

On the New Controller Settings (Beta):

Go to Settings > Preferences > Formatting.

Select the language you prefer from theLanguage drop-down menu.

ATTENTION:All translations (other than English) are Community sourced, and should be considered to be in beta always. Before making any big changes, check the English translation first.Translations improve as they move forward; to get the best translations please upgrade to the newest Controller software version available.

I'm having trouble upgrading from an older UniFi Controller version, what can I do?

When upgrading, always read the Release Notes, there will be information on any considerations to keep in mind when migrating from previous versions.

Upgrading from v2 to current version: There is no direct upgrade path from v2 to v5 current releases. You first need to upgrade from v2 to v3 then from v3 to a newer version. There should be virtually no installs running v2 or earlier but if you fall into this category please reach out to support and we will happily provide you with a v3 release as an intermediary upgrade to help you get your site onto something current.

Migrating from v3 to current version: There are many changes to APIs and it's not backward compatible. You may need to update the shell library ( unifi_sh_api ) and/or your customized portal/external portal code.

What Java / JRE version should I be using?

UniFi 5.11.39 Stable Release: Java 8 must be installed on the system hosting the controller software. Java 9 and later are not yet supported.

UniFi 5.6.42 LTS Stable Release: Java 8 must be installed on the system hosting the controller software. Java 9 and later are not yet supported.

NOTE: Although Javais required on any machine that is actually hostingthe UniFi Controller, it is not required to navigate to(the UniFi Cloud Access portal) to access .

How can I trigger a provision?

Whenever a configuration is modified within the UniFi Controller UI, it will be automatically detected and a provision will be triggered. However, if you are changing configurations by modifying theconfig.properties file, the Controller will not detect the change and you will have to manually instruct it to begin a provision.

To trigger a provision via the controller follow these steps:

Launch the Controller and accesstheDevices section.

Click on the device you wish to provision, displaying the Properties panel.

Click on theConfigtab.

Click to expand the Manage Device section.

Scroll down to the Force Provision sectionand click on theProvision button.

If you need to trigger a provision for all access points, perform it using thegroup configfeature by doing the following:

Launch the Controller and accesstheDevices section.

In the top toolbar Allwill be selected by default. Click onAPS.

Click on the gear icon in the upper right hand corner and check the box for Enable group config. This will add a empty checkbox to AP row.

Check the top box to select all.

Clickthe button ofEdit Selected which appeared in the top toolbar. This expands a batch AP Properties panel.

Go toConfig> Manage Devices and click theProvision button.

Overview

Readers will learn how to configure a Policy-Based Site-to-Site IPsec VPN between an Edgerouter and a USG.

Intro to Networking - How to Establish a Connection Using SSH

NOTES & REQUIREMENTS:

Applicable to the latest EdgeOS firmware on all EdgeRouter models. Please see the Related Articles below for more information.

Devices used in this article:

EdgeRouter-4 (ER-4)

UniFi Security Gateway (USG-3)

Table of Contents

Frequently Asked Questions (FAQ)

Setting up a Policy-Based VPN

Related Articles

FAQ

Back to Top

1. What site-to-site IPsec VPN types can be configured on EdgeOS?

The following IPsec VPN types can be configured on EdgeOS:

Policy-Based

Route-Based (VTI)

GRE over IPsec

2. What are the available encryption and hashing options (Security Associations / SAs) for Phase 1 (IKE) and Phase 2 (ESP)?

Encryption

AES128

AES256

AES128GCM128

AES256GCM128

3DES

Hashing

MD5

SHA1

SHA2-256

SHA2-384

SHA2-512

Setting up a Policy-Based VPN

Back to Top

The 192.168.1.0/24 and 172.16.1.0/24 networks will be allowed to communicate with each other over the VPN.

GUI: Access the EdgeRouter Web UI.

1. Define the IPsec peer and hashing/encryption methods.

VPN > IPsec Site-to-Site > +Add Peer

Check: Show advanced options

Check: Automatically open firewall and exclude from NAT

Peer: 192.0.2.1

Description: ipsec

Local IP: 203.0.113.1

Encryption: AES-128

Hash: SHA1

DH Group: 14

Pre-shared Secret: <secret>

Local subnet: 192.168.1.0/24

Remote subnet: 172.16.1.0/24

2. Apply the changes.

GUI: Access the UniFi Controller Web Portal.

1. Navigate to the Settings to create a new IPsec network using a custom profile.

Settings > Networks > +Create New Network

Name: ipsec

Purpose: Site-to-Site VPN

VPN Type: Manual IPsec

Enabled: Enable this Site-to-Site VPN

Remote Subnets: 192.168.1.0/24

Peer IP: 203.0.113.1

Local WAN IP: 192.0.2.1

Pre-Shared Key: <secret>

IPsec Profile: Customized

Expand (+) Advanced Options

Key Exchange Version: IKEv1

Encryption: AES-128

HASH: SHA1

DH Group: 14

PFS: Enable Perfect Forward Secrecy / Check

Dynamic Routing: Disable / Uncheck

NOTE: The USG will use the all corporate networks as the local subnet(identifiers)for the IPsec connection.

2. Apply the changes.

Related Articles

Back to Top

EdgeRouter - Policy-Based Site-to-Site IPsec VPN

EdgeRouter - Route-Based Site-to-Site IPsec VPN

Overview

Users will learn how to test throughput using the CLI tool known as iPerf3. TheiPerf3tool generates and sends traffic from a server to a client, or from a client to a server. This is the best option for testing throughput when speedtest websites are showing poor results.

https://iperf.fr/iperf-download.php#windows

NOTES & REQUIREMENTS:This article requires a limited amount of CLI experience. Users should understand how to login via SSH and run commands via SSH.

Table of Contents

Introduction

How Does this Test Work?

Steps: How to Test Throughput

Introduction

Back to Top

Internet speedtests can fail for a variety of reasons including, but not limited to the following:

Server location

Server load

Server connection speed

Server networking issues

Simultaneous tests being run to the same server

This is why it is useful to rule out connection issues that are out of your control by testing from one end of a link to another.

How Does this Test Work?

Back to Top

iPerf3between two PCs plugged into either side of the link.

This is the best way to test your throughput. It will rule out any other networking equipment on your network and allow you to test only that wireless link.

This test will also be able to show any limiting factors on your LAN connections because it will test through the LAN interface on one radio, through the LAN interface of the other radio, without causing too much overhead on the radios themselves.

Steps: How to Perform the Test

Back to Top

ATTENTION: These instructions assume you are running Windows on both PCs.

1. Visitto download the current version ofiPerf3 for your Windows PCs.

2. Once you download the file, you will need to extract it. You may put the extracted contents on C:\.

3. Once you have downloadediPerf3 and extracted the files to C:\, you can open the command prompt and navigate to the directory that you savediPerf3 to.

cd C:\

4. Now run iperf3.exe as a server on one PC.

iperf3.exe -s

5. Runiperf3.exe as the client on the other PC.

iperf3.exe -c 203.0.113.26 -t 100 -P 5

NOTE:203.0.113.26 is the IP address of the exampleiPerf3 server running on the opposite PC. You will need to change the IP address to match that of the PC that you started the server on.

This will start aniPerf3 TCP throughput test and run for 100 seconds while showing the results every one second.