Create Port Forwarding rules within UniFi Network in the Settings > Firewall & Security section. Refer to the troubleshooting steps below if your Port Forwarding or custom Destination NAT rule is not working.
Your UniFi Gateway does not have a public IP address (Double NAT). This happens if your UniFi Gateway is located behind another router/modem that uses NAT. You are likely affected by this if your UniFi Gateway has a WAN IP address in one of the following ranges:
10.0.0.0/8 (10.0.0.0 – 10.255.255.255)
172.16.0.0/12 (172.16.0.0 – 172.31.255.255)
192.168.0.0/16 (192.168.0.0 – 192.168.255.255)
100.64.0.0/10 (100.64.0.0 – 100.127.255.255)
To fix this issue, try to re-configure your ISP modem/router into bridge mode so that your UniFi Gateway can obtain a public IP address on the WAN interface.
If that is not supported, you will need to first forward the port(s) on the upstream router/modem to the WAN address of your UniFi Gateway in addition to forwarding them from your UniFi Gateway to the desired location. You may wish to contact your ISP to assist with port forwarding or providing a DMZ option that allows you to automatically forward the ports.
Your UniFi Gateway is already forwarding the port to another device or has UPnP enabled. A given WAN port can only be forwarded to a single device within your network. For example, TCP port 443 can only be forwarded to one LAN port.
Note: It is possible to forward multiple WAN ports to the same LAN port.
Another possible cause is that UPnP is enabled and is already using the port. Try disabling UPnP in your UniFi Network Application’s Internet Settings.
Incoming traffic is not reaching the WAN interface of your UniFi Gateway. In this case, the traffic is most likely blocked somewhere upstream, such as at the ISP modem/router, or a third party firewall. We recommend disabling any upstream firewalls for testing, and then contacting your ISP for more details.
The LAN host is blocking the port with a local firewall, or does not have the correct route configured. In this case, the host/server on the LAN is not allowing outside connections to access the port. On Windows computers, this may be a result of the Windows Firewall rules. On Linux machines, this could be a result of the connection not being allowed in the iptables firewall. We recommend consulting with the particular client’s manufacturer for more information.
There is an incorrect route configured on the LAN host. It is possible that the LAN host does not know how to reach the IP address of the Internet client. This can result if the default gateway is not configured correctly. You should verify your routing settings on the local host to resolve this situation.
We strongly recommend Teleport VPN for most users seeking to remotely access their UniFi OS Console’s network. It’s faster, more secure, and requires zero configuration.
VPN server configuration requires a UniFi gatewayanda public IP address. We recommend obtaining a static public IP address from your ISP to avoid having to reconfigure all of your clients every time your IP changes. Your UniFi gateway will automatically update server-side settings.
Note: Dynamic DNS can be used to avoid reconfiguring your clients’ VPN when IP changes occur, but this process is not outlined here.
To set up a VPN server, you must create a Pre-shared Key (UniFi generates a secure one automatically) and user credentials (Username and Password) that are entered on clients to authenticate their remote network access.
Note: Users are linked to the UniFi gateway’s internal RADIUS server. Although UniFi supports third-party RADIUS server integration, we recommend contacting the third-party server provider if you have troubleshooting questions.
Configuring Clients
You can connect any L2TP VPN client, including those provided by Microsoft Windows or macOS. We recommend using your operating system’s native VPN client.
Although we outline OS-specific client configuration processes below, we still recommend consulting your device’s manufacturer on how to use their platform’s VPN client.
Microsoft Windows 11
Go to Settings > Network & internet > VPN > VPN connections > Add VPN and select L2TP/IPsec with pre-shared key as your VPN type.
Note: Your username, password, and pre-shared key are the same as those in your UniFi Network settings.
Go to Settings > Network & internet > Advanced network settings > More network adapter options > L2TP Adapter properties
Click the Security tab, then set your authentication method to MS-CHAP v2.
macOS
Go to System Preferences > Network > +.
Select VPN in the Interface field.
Select L2TP over IPsec in the VPN Type field.
Enter l2tp as the Service Name.
Note: Your username, password, and pre-shared key are the same as those in your UniFi Network settings.
Route all traffic through the VPN by going to Options > Session Options and selecting Send all traffic over VPN connection.
Troubleshooting
If your client cannot connect to the VPN server, or is unable to route traffic through the VPN, you may receive error messages stating that the server is not responding, the client disconnected, or that a processing error occurred. Your VPN connection may also fail. These events are likely related to one of the following:
Your UniFi Gateway Does Not Have a Public IP Address (Double NAT)
This typically occurs if your UniFi gateway is located behind another router/modem that uses Network Address Translation (NAT). You are likely affected if your UniFi gateway has a WAN IP address in one of the following ranges:
10.0.0.0/8 (10.0.0.0 – 10.255.255.255)
172.16.0.0/12 (172.16.0.0 – 172.31.255.255)
192.168.0.0/16 (192.168.0.0 – 192.168.255.255)
100.64.0.0/10 (100.64.0.0 – 100.127.255.255)
To resolve this, set your upstream router to Bridge Mode. If this is not possible, try forwarding UDP Ports 500 and 4500 from the upstream router/modem to your UniFi gateway. Please note that this will not work if your upstream router doesn’t have a public IP address.
Note: By default, Windows computers cannot establish L2TP VPN connections with servers behind NAT. To get around this restriction, you will need to manually change the AssumeUDPEncapsulationContextOnSendRule registry value from 0 to 2. For more details, please refer to Microsoft’s support page.
For help configuring your device to bridge mode or port forwarding, we recommend contacting your ISP for further assistance. Please note that IP addresses in the 100.64.0.0/10 subnet range always require ISP assistance in order to establish a VPN connection.
Required Ports Are Blocked by an Upstream Device or Forwarded by Your UniFi Gateway to Another Device on Your Local Network
Make sure that no third-party routers, firewalls, or ISP modems are blocking UDP Ports 500 or 4500 from reaching your UniFi gateway. You may need to contact your ISP to verify that your network traffic is being routed correctly.
Once you confirm that your traffic is not being blocked, please ensure that your UniFi gateway is not forwarding these ports to another device on your local network. You can remove existing port forwarding rules in the Firewall & Security section of your UniFi Network application.
Authentication Failures Due to Incorrect Configuration
This occurs when the VPN server and client have mismatching pre-shared keys, authentication methods, or login credentials. Please ensure that all of these match what is configured in your UniFi Network application. Also, ensure that client devices are using the MS-CHAP v2 authentication method, and that the VPN type is set to L2TP. Lastly, verify that you are authenticating with a pre-shared key and not a certificate.
Re-enter the pre-shared key, username, and password and check for typos.
Your Client Cannot Establish an L2TP Connection
Try using a different client or operating system to verify if this is a client-specific issue. If so, check for any device updates or contact the manufacturer for further assistance.
Note: Most Android clients require you to enable Weak Ciphers in your UniFi Network’s VPN server configuration.
Your Client Is Routing Over the VPN, but Its Traffic is Prohibited
In this scenario, the client can connect to the VPN but cannot communicate with any other devices on the local network.
To resolve this, please ensure that there are no traffic or firewall rules preventing VPN clients from communicating with your local network. Alternatively, individual clients on the local network could be dropping incoming traffic at their local firewalls. The Windows firewall, for example, drops all ICMPv4 (ping) traffic by default.
If you are testing with ping, then you will need to allow this traffic through the Windows firewall. For more details, please refer to the Microsoft support page.
The Client and VPN Server Use the Same Local IP Range
In this scenario, the client can connect to the VPN but cannot communicate with any devices on the local network. This could be because the client has an IP address that overlaps with the subnet of the network it is attempting to connect to.
For example, if your client has a 192.168.3.21 address on its local network, and it is trying to connect to the UniFi VPN server configured on the 192.168.3.0/24 subnet, the client will always utilize its local network connection instead of the VPN. To resolve this, either change the client’s local IP or adjust your UniFi Network subnet range.
Your Client Has Split Tunneling
This will prevent clients from communicating with certain VPN-connected devices despite being connected to the network itself. To resolve this, we recommend routing all traffic through your VPN:
For Windows clients, enable Use default gateway on remote network in the Advanced TCP/IP Settings.
For Mac clients, enable Send all traffic over VPN connection in your VPN network preferences.
For more OS-specific guidance, please contact your device’s manufacturer.
Expedite Your Support Request
If you’re submitting a support request, please include answers to the following to ensure that our Support Engineers are fully apprised of your unique situation and can deliver the best, most personalized support experience possible.
What is the model and operating system of each affected client?
What error message(s) are you receiving?
How are your client(s) configured? (Please provide screenshot(s), if possible.)
Have you tested this on a different client?
How is each client attempting to connect to the VPN? Is it using LTE data, or is it connected to a different WiFi network?
What is the IP address of each affected client, and what is your UniFi gateway’s VPN server subnet range?
Also, please provide a copy of your support file, along with a timestamp of when you last attempted to connect to the VPN server. More detailed instructions can be found here.
UniFi OS Console users can obtain their support file from their UniFi OS Settings (*.tgz extension).
Self-hosted Network users can obtain their support file from their Network application settings (*.supp extension).
A UniFi device with an Offline state has lost communication with its application host meaning that you will be unable to manage its configuration. This does not necessarily mean it has stopped working. As long as it is powered on with connectivity to the rest of your network it will continue operating in a “Self-Run” state using the last known UniFi configuration.
A UniFi device can go offline for a number of reasons, but this is most common for those with third-party equipment, or those that choose to self-host the Network Application instead of using a UniFi OS Console.
Here are the most common reasons why UniFi devices go offline:
Physical Connection Issues
Device connection can be disrupted by faulty cabling, power supply issues, or other problems with your physical networking hardware. First, ensure that your device is being powered by Power-over-Ethernet (PoE). Then, replace its cabling, confirm that both ends are securely connected, and try a new port to rule out physical damage.
Device Cannot Obtain an IP Address from Your DHCP server
This is most common for users with a third-party DHCP server. To fix this, start by verifying that the device has been assigned a correct IP and gateway. You can do this by reviewing your server’s DHCP leases, or you can scan your network with the WiFiman mobile app (Android / iOS).
Note: 192.168.1.20 is used as a fallback IP address, so its usage may indicate that your device cannot obtain another IP from your DHCP server.
Please also verify that your DHCP server’s network is added as a member of all your switch port profiles. Additionally, ensure that UDP Ports 67 and 68 are open on any firewalls on your network. Otherwise, none of your devices will be able to obtain an IP address and connect to your network.
Your Wirelessly Adopted Devices Have Poor Connectivity
This is the most common for users self-hosting the Network Application, especially on Windows hosts. For troubleshooting purposes, we recommend temporarily disabling your firewalls to verify if they are preventing your UniFi devices from coming online.
Please also note that some Windows updates can reconfigure your firewall settings. As such, please ensure that your firewall is set to Private.
Next, verify that TCP Port 8080 and UDP Port 10001 are both open. For instructions on how to verify other required port configurations, see our Required Ports Reference.
If you have any Layer 3-adopted APs, please disable any custom firewall rules blocking traffic across VLANs between your UniFi device and the Network Application.
Your Network Application Host Moved or Its IP Address Changed
If you change the location of your UniFi Network host, your devices could still be attempting to communicate with its old IP address. If the old and new IPs are on the same Layer 2 network (i.e,. same subnet and VLAN), your devices will be able to re-discover and reconnect to your host.
If you moved the Network host to a new VLAN, however, you must use Layer 3 Adoption to re-establish connectivity. This should only be done by advanced users. Otherwise, we recommend reconfiguring your setup so that your Network Application and UniFi devices are on the same Layer 2 network.
Those who have performed a Layer 3 adoption should also verify if their public IP address has changed. This happens if your ISP provides IP addresses via DHCP. An IP address change will leave your L3-adopted devices still trying to communicate with the old IP address. We recommend using a Dynamic DNS (DDNS) service to avoid this.
The Management VLAN Is Not a Member of Your Switch Port Profile
Your UniFi device’s Management VLAN must be a member of all switch ports. The Management VLAN configuration is found in the Settings tab of the device’s properties panel, which can be accessed by selecting it on the UniFi Device page.
Packet Loss and High Latency Between the UniFi Network Application and Device
The UniFi Network Application has a 60-second disconnection threshold, meaning that it will wait one minute for a response from the device before declaring it disconnected. Packet loss and increased network latency can occasionally trigger device disconnections.
Expedite Your Support Request
Prior to reaching out to support, we recommend gathering/verifying the following information. Including these details in your request will expedite your support experience.
How are you hosting your UniFi Network Application (i.e., UniFi OS Console vs. self-hosted)?
What is your UniFi Network Application version? Please refer to our Software Releases page to confirm if you have the latest version.
What is the model and firmware version of your device? Please refer to our Software Releases page to confirm if you have the latest version.
Does your device frequently change statuses, or is it stuck in an Offline state?
When did this issue begin? Did you make any notable changes prior to it occurring?
Also, please provide a copy of your support file, along with the MAC address(es) of all affected device(s). More detailed instructions can be found here.
UniFi OS Console users can obtain their support file from their UniFi OS settings (*.tgz extension).
Self-hosted Network users can obtain their support file from their Network application settings (*.supp extension).
Site-to-site VPNs are primarily used by businesses looking to connect numerous remote locations. If you are a home user, we strongly recommend Teleport VPN—our fast, secure, one-click remote access solution that requires no configuration.
UniFi gateways support two site-to-site VPN protocols: IPsec and OpenVPN. Depending on the one you select, you will need to ensure that the following settings are the same for all gateways used to create site-to-site connections:
We recommend using UniFi gateways at all of your sites to maximize connection compatibility and performance. Additionally, some third-party gateways allow you to configure settings that are unavailable in the UniFi Network application. Troubleshooting these types of settings lies outside of Ubiquiti Support’s scope, but you can check out our Considerations for Third-Party Equipment: Site-to-Site VPNs for more information.
IPsec
Pre-Shared Key: This is used to authenticate VPN connections.
UniFi Gateway IP: This is your UniFi gateway’s public IP address.
Shared Remote Subnets: This is the list of networks shared by the remote gateway. Please note that UniFi gateways share all local networks. You must ensure that there are no overlaps within your sites’ local subnets.
Remote IP: This is the remote gateway’s WAN IP address.
Additional Notes:
There are also Advanced settings that should match across all gateways. We recommend using the default settings unless you are proficient with VPN security.
Your UniFi gateway will automatically create the static routes required to direct traffic through the VPN. Do not try to create new ones for this purpose.
OpenVPN
The OpenVPN Site-to-site VPN uses a 512-character pre-shared key for authentication. The key should be the same for both gateways and shouldn’t contain line breaks. You can either create this key yourself or generate it on your UniFi gateway. To do this:
Generate your key by using the following command: openvpn –genkey secret /tmp/ovpn
You can now view/copy the key by running the command: cat /tmp/ovpn Note: Be sure to remove any line breaks when copying the key.
Note: USGs must use generate vpn openvpn-key /tmp/ovpn to generate the key, then sudo cat /tmp/ovpn to view/copy the key.
Additionally, the following information is required:
Local Tunnel IP Address: This is the IP used for your local “tunnel”. Traffic sent to the remote gateway will be routed through this IP address. This address should be available on the local and remote site. We recommend selecting a private IP from a subnet that is unused on both gateways.
Local Port: By default, UDP Port 1194 is used for OvenVPN. This port must not be used by other services or other OpenVPN connections. If you’re using multiple OpenVPN tunnels, each one must be assigned to its own port. The local and remote ports do not need to be the same.
Shared Remote Subnets: This is the list of networks shared by the remote gateway. Please note that UniFi gateways share all local networks. You must ensure that there are no overlaps within your sites’ local subnets.
Remote IP Address: This is the remote gateway’s WAN IP address.
Remote Tunnel IP Address: This is the IP address of the remote gateway’s tunnel. Do not enter the gateway’s WAN IP.
Remote Port: This is the remote gateway’s OpenVPN port. The local and remote ports do not need to be the same.
Note: Your UniFI gateway will automatically create the static routes required to direct traffic through the VPN. Do not try to create new ones for this purpose.
Troubleshooting
If you’re unable to establish a VPN tunnel between your sites, or your connection drops periodically, you likely have at least one site with an incorrect VPN or network configuration. Please refer to the common mistakes below.
Your UniFi Gateway Does Not Have a Public IP address (Double NAT)
This typically occurs if your UniFi Gateway is located behind another router/modem that uses Network Address Translation (NAT). You are likely affected if your UniFi Gateway has a WAN IP address in one of the following ranges:
10.0.0.0/8 (10.0.0.0 – 10.255.255.255)
172.16.0.0/12 (172.16.0.0 – 172.31.255.255)
192.168.0.0/16 (192.168.0.0 – 192.168.255.255)
100.64.0.0/10 (100.64.0.0 – 100.127.255.255)
To resolve this, set your upstream router to Bridge Mode. If this is not possible, try forwarding the necessary ports from the upstream router/modem to your UniFi gateway. IPsec uses UDP Port 500 and 4500. By default, OpenVPN uses UDP Port 1194, but this can be changed. Please note that this will not work if your upstream router doesn’t have a public IP address.
If this doesn’t work, we recommend contacting your ISP. Please note that IP addresses in the 100.64.0.0/10 subnet range always require ISP assistance in order to establish a VPN connection.
Required Ports are Blocked by an Upstream Device or Forwarded by Your UniFi Gateway to Another Device on Your Local Network
Make sure that no third-party routers, firewalls, or ISP modems are blocking the required ports from reaching any of the gateways supporting your site-to-site VPN. IPsec uses UDP Port 500 and 4500. By default, OpenVPN uses UDP Port 1194, but this can be changed. Please note that if you reconfigure a port for one gateway, you must also reconfigure the same port for all other site-to-site VPN gateways.
Once you confirm that your traffic is not being blocked, please ensure that your UniFi gateway is not forwarding these ports to another device on your local network. You can remove existing port forwarding rules in the Firewall & Security section of your UniFi Network application.
Authentication Failures Due to Mismatched Gateway Configurations
Every gateway supporting your site-to-site VPN must have the same configuration, including Advanced settings. Failure to do so will prevent you from establishing a VPN connection or sustaining one for a long period of time.
We recommend using UniFi gateways at all of your sites to maximize connection compatibility and performance. This is because some third-party gateways allow you to configure settings that are not available in the UniFi Network application, but rather automatically set in the background. A mismatch in these configurations can still result in a connection failure. Troubleshooting these types of settings lies outside of Ubiquiti Support’s scope, but you can check out our Considerations for Third-Party Equipment: Site-to-Site VPNs for more information.
Also, please note that UniFi gateways are configured to share all local networks. Ensure these are configured in the paired gateway’s Shared Remote Subnets list.
Your Client Is Routing Over the VPN, but Its Traffic is Prohibited
In this scenario, the client can connect to the VPN but cannot communicate with any other devices on the local network.
To resolve this, please ensure that there are no traffic or firewall rules preventing VPN clients from communicating with your local network. Alternatively, individual clients on the local network could be dropping incoming traffic at their local firewalls. The Windows firewall, for example, drops all ICMPv4 (ping) traffic by default.
If you are testing with ping, then you will need to allow the traffic through the Windows firewall. For more details, please refer to Microsoft’s support page.
Your Sites Have Overlapping IP Ranges
Overlapping IPs can prevent a VPN from establishing. Even if the VPN tunnel is established, it may prevent proper communication across the VPN. This is because a client will always prioritize IP addresses on a local network connection rather than those on the opposite end of a VPN. The only way to prevent overlapping is to review each gateway’s local networks and, if necessary, adjust their IP address ranges. For example, if one gateway has a local network configured to 192.168.0.0/24, its IP addresses range from 192.168.0.1 – 192.168.0.255. Your remote gateway should not use any addresses within that range.
Overlapping IPs ranges may prevent proper communication across your VPN, or it can prevent the connection from establishing altogether. Assuming the VPN establishes,
Your Client Has Split Tunneling
This will prevent clients from communicating with certain VPN-connected devices despite being connected to the network itself. To resolve this, we recommend routing all traffic through your VPN:
For Windows clients, enable Use default gateway on remote network in the Advanced TCP/IP Settings.
For Mac clients, enable Send all traffic over VPN connection in your VPN network preferences.
For more OS-specific guidance, please contact your device’s manufacturer.
Make sure your cables are undamaged and securely connected to their respective ports. If your speeds are slower than you expect, swap out your cables for new ones. We recommend using SFP/SFP+ modules or DAC cables, when possible, to maximize speeds. Otherwise, use CAT6 RJ45 cables.
All UniFi devices automatically negotiate their speeds. Some clients, however, may be incapable of doing so. For these devices, we recommend manually setting their link speed in the Port Management section, found in the UniFi Devices tab of the Network Application.
Please be sure to check each client’s specifications. Not all clients have a Network Interface Card (NIC) capable of negotiating at faster rates, such as 1 Gbps.
Note: Clients with speed negotiation issues often result in dropped connectivity. This is a telltale sign to look for if you suspect a client-specific issue.
Disable Resource-intensive Software Features
Resource-intensive features such as Threat Management and Smart Queues may reduce throughput by up to 30%. Please consider this when prioritizing network speed, performance, and security.
Note: Smart Queues are only recommended if you have expected Internet speeds of 250 Mbps or less and you consistently have more internet traffic than your bandwidth can support.
Other features that may impact throughput include:
Device and Traffic Identification (Deep Packet Inspection)
Note: These features will only affect traffic routed through your gateway or to the internet. It should not affect LAN traffic between devices on the same network.
Minimize Network Congestion
A high number of concurrent clients routing traffic through a local network device, like a single switch, may reduce throughput. To resolve this, we recommend separating network traffic or adopting an additional Layer 3 switch.
Be Aware of Protocol and Client Limitations
Certain protocols offer lower performance. For example, L2TP VPNs are relatively slower compared to Wireguard or Teleport. Another example of a traditionally slow protocol is SMB file transfers.
Similarly, some clients may be limited by the resource intensity of the applications they run, independently of your network.
Use DHCP or Static WAN (Internet) Connection When Possible
PPPoE is a very CPU-intensive protocol that may reduce throughput compared to DHCP or Static IP configurations.
Remove Traffic Rules and Bandwidth Profiles That Limit Client Traffic
We always recommend taking a moment to verify that there are no active Traffic Rules or Bandwidth Profiles reducing client throughput.
Expedite Your Support Request
Please include answers to the following in your request to expedite your support experience:
What are your expected speeds?
How are you hosting your UniFi Network Application (i.e., UniFi OS Console vs. self-hosted)?
What version of UniFi Network are you running? What firmware versions are your network devices running (e.g., switches, APs, gateway, etc.)? Please refer to our Software Releases directory to verify everything is up-to-date.
If you are using a UniFi OS Console, what version of UniFi OS are you running? Please refer to our Software Releases directory to verify if you are running the most up-to-date UniFi OS.
How widespread is your throughput issue? Does it affect wired clients, wireless ones, both, or just certain devices?
There are a few simple principles that can help achieve optimal wireless client connectivity:
Ensure all firmware and software is up to date. You can refer to UniFi Updates for more information on automatic update management. Please refer to community.ui.com/releases for our latest release notes.
Use a full stack of Ubiquiti equipment, including a gateway (including DHCP server), APs, and switches for maximum compatibility.
Use the default settings when creating a new WiFi SSID. These settings have been selected to achieve maximum compatibility, as supported by continuous quality testing.
Maintain sufficient signal strength on all of your client devices. We recommend at least -65dBm. You may need to increase AP TX Power, move client devices closer to an AP, or install more APs to increase your coverage area.
If you are experiencing client disconnections, please note that connectivity can be affected by your settings, client specifications, and any interference related to utilization or RF environment congestion.
Consider the suggestions below:
Disable Protected Management Frames (PMF) for Improved Compatibility We recommend disabling PMF to maximize compatibility. Many devices, especially legacy ones, are incompatible with PMF and experience resulting connectivity issues..
Use a Basic WPA2 Security Mode WPA3 requires PMF which, as mentioned, may create client connectivity issues.
Furthermore, we recommend testing with a non-enterprise security mode. Enterprise modes use RADIUS servers to authenticate clients. This adds an additional layer of complexity in order to verify clear communication between clients and their server, as well as whether or not the server is properly configured.
Reduce the Minimum Data Rate to Improve Legacy Device Compatibility The default minimum data rate for the 2.4 GHz channel is set at 1 Mbps to maximize compatibility. This is because some clients, particularly legacy devices (802.11b), require a low data rate in order to connect. If you have changed this value and noticed issues specific to legacy clients, we recommend setting it back to 1 Mbps.
Properly Configure the DTIM Period The DTIM Period is a WiFi SSID setting that tells clients when to “wake”. Having a period that is too high may result in the device disconnections. We recommend:
2.4GHz = 1
5GHz = 3
Select Non-Overlapping and Low-Interference Channels We recommend enabling Nightly Channel Optimization to ensure you are on the least-crowded, non-overlapping channels. Your network will continue to work during nightly scans.
Wireless clients use a shared airspace for communication. This is true for all devices in a given area, even if they are not connected to your network (e.g., your neighbor has a lot of IoT devices). This is why having high-density deployments may contribute to speed or connectivity issues.
If you prefer to manually assign channels, here are a couple of rules to keep in mind:
If you must use 2.4 GHz, you should only ever use Channel 1, 6, or 11. These will optimize connectivity since they are the only non-overlapping channels.
Nearby APs should use different channels. If you have three APs, you can set one each to Channel 1, 6, and 11 on the 2.4 GHz band. This concept applies to 5 GHz as well.
You can perform an RF Scan in the UniFi Network Application to identify channels with the lowest interference. Unlike Nightly Channel Optimization, this scan may interrupt client connectivity while in progress..
Decrease Channel Width UniFi Network supports the following channel widths:
Although larger channel widths enable faster speeds, they result in more interference and decreased range. If you have a high-density deployment or high utilization, we recommend reducing your channel widths.
Use Band Steering to Move Compatible Clients to 5 GHz The 2.4 GHz band is generally much more congested than 5 GHz. This congestion can result in dropped packets and device disconnections. We recommend enabling Band Steering in your WiFi SSID settings to prioritize the movement of all compatibility clients to the 5 GHz band.
Increase Your Minimum Data Rate to Reduce Network Congestion As mentioned, some clients require you to reduce the Minimum Data Rate to maximize their compatibility. However, there are instances where increasing it may be more beneficial for high-density deployments in a congested RF environment.
Increasing this rate will ensure more efficient airtime utilization, which may resolve client connectivity and packet dropping issues. Please exercise caution when modifying this rate as it can also negatively impact client connectivity if incorrectly tuned.
Enable Multicast and Broadcast Control to Reduce Network Congestion Multicast and broadcast traffic drastically increase utilization, which may create more interference in crowded environments. Multicast and Broadcast Control is a WiFi SSID setting that will block all multicast and broadcast traffic, thus drastically reducing congestion.
You should add exceptions for any devices that require multicast or broadcast traffic. For example, failing to add exceptions for your gateway and/or DHCP server will prevent clients from obtaining IP addresses, and thus being unable to connect to your network.
Reduce TX Power to Reduce Network Congestion We recommend keeping TX Power set to High or Auto to maximize signal strength for clients. However, if you can reduce the signal strength and still maintain full coverage, this may reduce interference.
Please use our Design Center or the Signal Mapper in the WiFiman mobile app (iOS / Android) to assess your deployment’s WiFi coverage needs.
Dynamic Frequency Selection (DFS) consists of 5 GHz channels that are normally reserved for things like radar, military, weather, or satellite communication. Although these channels offer increased availability and less interference, wireless clients will disconnect if radar events are detected. This is a compliance requirement that varies by country, often ranging from 1 minute to 10 minutes. These channels are only recommended in areas that do not encounter these external radar events.
Disable Minimum RSSI Minimum RSSI sets a signal strength threshold. All devices that fall below it are automatically disconnected from your network. The purpose of this setting is to facilitate roaming within deployments with tightly-packed APs. If it is set incorrectly, though, you may experience client instability.
Expedite Your Support Request
Prior to reaching out to support, we recommend gathering/verifying the following information. Including these details in your request will expedite your support experience.
Is the issue affecting all of your clients, or just specific ones? What is the make and model of the affected device(s)?
Is the issue affecting all of your APs, or just specific ones? What is the model and firmware version of the AP(s)? You can refer to community.ui.com/releases for the latest available versions.
Is your issue related to establishing connectivity or keeping it?
What is the maximum number of concurrent wireless clients connected at a given time?
Does rebooting your AP improve connectivity?
Did this issue start after an AP firmware or UniFi Network update?
Does this issue occur frequently, randomly, during specific times, in certain locations, or at particular proximities from your AP?
In addition to the information above, it is beneficial to share the appropriate support logs after the issue occurs. To obtain these:
1. Enable Syslog and Syslog & Netconsole in the System settings of your Network Application.
2. Once the issue occurs, download the appropriate support file. Users with a UniFi OS Console should obtain the logs from the UniFi OS settings (*.tgz extension), whereas users who downloaded a self-hosted copy of the Network Application can obtain their support file from the Network Application settings (*.supp extension). More details can be found here.
3. You should provide the MAC Address(es) of the client(s) experiencing the issue, along with the timestamp of when this issue occurred. This will help us identify the relevant information from the files you provide.
Check out our UniFi Expert’s Corner video for a quick overview of wireless speeds. Follow these guidelines, and those in Optimizing Wired Network Speeds, to maximize your total network throughput.
Introduction
Wireless throughput is affected by more than just how you configure your network and UniFi Access Points (APs). This article will explore the most common causes of slow speeds and provide suggestions for improving them.
Before you continue, please note that maximized speeds are not the ultimate benchmark of a high-performance network. For context, streaming Ultra HD content on Netflix only requires 25 Mbps of bandwidth. Achieving the highest rate possible isn’t required to ensure quality connectivity. As such, your most pressing concern should be achieving stable speed and bandwidth rates that reliably support all connected devices.
Setting Realistic Expectations
Unlike wired connections that support full-duplex communication, wireless communication is half-duplex. This means that a 1 Gbps wireless connection can only support a simultaneous upload/download speed of 500 Mbps.
Furthermore, wireless protocol overheads typically result in 25-40% speed reduction compared to the theoretical maximum. This applies to all vendors and wireless access points.
In general, it is safe to assume that you are in good shape if you are achieving ~50% of your theoretical maximum speeds.
Recommendations
Increase Your Channel Width
Larger channel widths allow for faster speeds. Doubling your channel width will nearly double your wireless speed. Increase widths cautiously, though, as this will decrease your WiFi range and could increase channel interference. High-density or crowded RF environments with a large channel width can decrease network performance and cause more device disconnections.
UniFi Network supports the following channel widths:
Larger channel widths result in more interference. If you have a high-density deployment or high utilization, we recommend reducing your channel widths.
Use Band Steering to Move Compatible Clients to 5 GHz
UniFi APs currently only support the 2.4 and 5 GHz bands. Soon, we will launch the U6-Enterprise which will support the upcoming 6 GHz standard and deliver the fastest possible WiFi speeds. Here’s a simple breakdown of the two currently supported bands:
2.4 GHz: Delivers slower speeds and more interference, but broadcasts further due to better signal penetration through solid surfaces.
5 GHz: Delivers faster speeds and offers less-crowded channels. However, some legacy clients are incompatible with the band.
Enable Band Steering to automatically move compatible clients to the 5 GHz band.
Improve Client Signal Strength
To maximize your speeds, we recommend maintaining signal strengths between -50dbm and-60dbm. Numbers closer to zero indicate higher signal strength and throughput.
You can improve your signal strength by:
Moving clients closer to your AP.
Adding more APs to your network.
Setting your TX power to Auto or High.
Note: Increasing the transmit power of your devices can negatively impact their performance, especially in a very high density environment.
Select Non-Overlapping and Low-Interference Channels
We recommend enabling Nightly Channel Optimization to ensure you are on the least-crowded, non-overlapping channels. Your network will continue to work during nightly scans.
Wireless clients use a shared airspace for communication. This is true for all devices in a given area, even if they are not connected to your network (e.g., your neighbor has a lot of IoT devices). This is why having high-density deployments may contribute to speed or connectivity issues.
If you prefer to manually assign channels, here are a couple of rules to keep in mind:
If you must use 2.4 GHz, you should only ever use Channel 1, 6, or 11. These will optimize connectivity since they are the only non-overlapping channels.
Nearby APs should use different channels. If you have three APs, you can set one each to Channel 1, 6, and 11 on the 2.4 GHz band. This concept applies to 5 GHz as well.
You can perform an RF Scan in the UniFi Network Application to identify channels with the lowest interference. Unlike Nightly Channel Optimization, this scan may interrupt client connectivity while in progress.
Use APs That Support the Latest WiFi Standards and Technology
Each AP has its own specifications (such as WiFi standard or supported MIMO streams) that affect its maximum speeds. For optimal performance, we recommend our WiFi 6 access points.
For more details about U6 APs, please visit the UI Store, or review their respective datasheets.
Ensure That Your Clients Support the Latest WiFi Technology
Client specifications are just as important as your AP’s. A legacy client connected to the 2.4 GHz band using the WiFi 1 (802.11b) standard with 1×1 MIMO support will never be able to experience the benefits of your U6 Pro (e.g., 5 GHz WiFi 6 connectivity, 4×4 MU-MIMO and OFDMA functionality, etc.).
Remove Upstream Bottlenecks from Your Network
It is important to identify any bottlenecks throttling your speeds. For example, a wireless client will never achieve a 25 Mbps Netflix stream if it is limited by a 10 Mbps Internet connection or switch port / Ethernet connection upstream.
Minimize Meshed Network Usage
It is always preferable to hardwire APs to your network. Wirelessly meshing APs typically results in a ~50% throughput reduction per hop. If you prefer a meshed network, we recommend no more than two hops between a downstream AP and its first hardwired uplink.
Expedite Your Support Request
Prior to reaching out to support, we recommend gathering/verifying the following information. Including these details in your request will expedite your support experience.
What are your expected speeds?
How widespread is your throughput issue? Does it affect wired clients, wireless ones, both, or just certain devices?
What is your channel width? You can find this in your Global AP Settings, or by opening the device details panel of a specific AP.
Also, please include the following information, which can be found by selecting the affected device(s) on the Client Device page in your Network application.
Make and model
Band utilization (2.4 or 5GHz)
MIMO support (e.g., 1×1, 2×2)
WiFi standard (e.g., WiFi 5, WiFi 6)
Signal strength while experiencing reduced throughput
A mesh network consists of APs that are wirelessly connected to each other, as opposed to everything being hardwired to your network. This enables you to minimize dead-zones and create a continuous wireless network when it is difficult to run a cable to certain locations.
Note: Wireless Meshing must be enabled in your Network Application settings.
Mesh networks should only be used to supplement a wired network.
It is always preferable to hardwire your equipment to your central router/gateway for optimal performance and stability. This is because meshed networks are heavily impacted by the RF environment. Too much noise may result in client disconnections, or even your AP becoming disconnected from its uplink.
Minimize the number of wireless “hops”.
Although you can uplink one wireless AP to another wireless AP, this is not recommended. Each “hop” will reduce stability, and will also result in nearly 50% performance decrease.
Make sure there is a strong signal between your wirelessly meshed APs.
We recommend having a signal strength of at least -60 dBm between your wireless AP and its wired uplink. Lesser signal strengths may result in both performance and stability issues.
We recommend most users to stick with our default settings.
UniFi will automatically pick the best AP to uplink to, as well as the channel on which the APs are wirelessly connected. Although you can set these parameters manually, we advise most users to remain on the default settings because an incorrect configuration has the potential to completely break your meshed network.
Note: Both APs must use the same channel or else you risk breaking your meshed connection.
A virtual private network (VPN) allows a client to join a network remotely via an encrypted connection. VPNs offer many benefits:
Securely share resources between multiple office branches, or grant access to network resources from a remote location.
Moderate activity and impose network-specific traffic and routing policies for remote connections.
Mask IP addresses when accessing the internet.
UniFi supports several types of VPNs. This article will outline their specific benefits and use cases.
Note: A UniFi gateway is required to use the VPNs profiled below.
VPN Types
Teleport
Teleport is a one-click VPN that allows clients to remotely connect to networks hosted by a UniFi gateway via the WiFiman mobile app (iOS / Android). With WiFiman, you can remotely access local network resources, like connected storage drives. Utilizing Wireguard VPN technology, Teleport delivers reliable, high-speed connectivity and requires zero configuration. We recommend Teleport for most users seeking to set up a VPN.
VPN Server
A VPN server also allows clients to remotely connect to a network hosted by a UniFi gateway. Unlike Teleport, you must configure your UniFi gateway and the clients that will be using the VPN. We only recommend setting up a VPN server if you need to connect remote clients that cannot use the WiFiman mobile app. Otherwise, Teleport is likely a more suitable option because of its streamlined configuration and reliably high performance.
Site-to-site VPNs connect multiple sites with an encrypted “VPN tunnel” to create a single secure connection between all ‘local’ networks. This is perfect for two-way resource sharing across multiple locations. As such, site-to-site VPNs are primarily used by larger organizations that span multiple locations. They are not recommended for most home users.
This VPN sends some, or all, of your network traffic through a third-party VPN server. This is useful for those that prefer to mask their public IP addresses while they access the internet.
VPN Client also allows devices that don’t natively support VPN usage to connect to one. For example, when configuring a UniFi VPN server, we mentioned that each connected client must be configured individually. This isn’t a problem for most smartphones, laptops, or PCs, but some clients, like IoT devices or smart TVs, are not designed to remotely connect to other networks. VPN Client circumvents this by allowing your UniFi gateway to send their traffic through the VPN, instead of the devices themselves.
VPN Comparison
Teleport
VPN Server
Site-to-Site
VPN Client
Purpose
Allow users to remotely connect to a local network and access network resources (e.g., a local storage drive).
Allow users to remotely connect to a local network and access network resources (e.g., a local storage drive).
Combine multiple sites to create a single, secure connection allowing two-way resource sharing.
Direct local network client traffic through a third-party VPN server to mask their IP addresses and/or locations.
Recommended Users
Users connecting to their home network from a different location.
Remote employees connecting to their company’s network from home.
Office employees connecting to other branch networks.
Network administrators sending specific network traffic through a third-party VPN server.
Setup Requirements
One-click VPN that requires zero-configuration.
Set up on a UniFi gateway. Each connected client must be individually configured.
A gateway at each connected site must be configured.
UniFi gateways must be loaded with a configuration file provided by the third-party VPN provider.
How Users Connect
Each client has its own connection with the UniFi gateway.
Each client has its own connection with the UniFi gateway.
Users share the same connection that tethers multiple sites.
The UniFi gateway establishes a single connection with the third-party VPN.
Number of attacks targeting users of Kaspersky mobile solutions, Q1 2020 — Q2 2022 (download)
As in the previous quarter, fraudulent apps occupied seven out of twenty leading positions in the malware rankings. That said, the total number of attacks by these apps started to decrease.
Interestingly enough, some fraudulent app creators were targeting users from several countries at once. For instance, J-Lightning Application purported to help users to invest into a Polish oil refinery, a Russian energy company, a Chinese cryptocurrency exchange and an American investment fund.
On the contrary, the number of attacks by the RiskTool.AndroidOS.SpyLoan riskware family (loan apps that request access to users’ text messages, contact list and photos) more than quadrupled from the first quarter. The majority of users whose devices were found to be infected with this riskware were based in Mexico: a third of the total number of those attacked. This was followed by India and Colombia. The ten most-affected countries include Kenya, Brazil, Peru, Pakistan, Nigeria, Uganda and the Philippines.
The second quarter was also noteworthy for Europol taking down the infrastructure of the FluBot mobile botnet, also known as Polph and Cabassous. This aggressively spreading banking Trojan attacked mainly users in Europe and Australia.
Mobile threat statistics
In Q2 2022, Kaspersky detected 405,684 malicious installation packages, a reduction of 110,933 from the previous quarter and a year-on-year decline of 480,421.
Distribution of newly detected mobile malware by type, Q1 and Q2 2022 (download)
Adware ranked first among all threats detected in Q2 2022 with 25.28%, exceeding the previous quarter’s figure by 8.36 percentage points. A third of all detected threats of that class were objects of the AdWare.AndroidOS.Ewind family (33.21%). This was followed by the AdWare.AndroidOS.Adlo (22.54%) and AdWare.AndroidOS.HiddenAd (8.88%) families.
The previous leader, the RiskTool riskware, moved to second place with 20.81% of all detected threats, a decline of 27.94 p.p. from the previous quarter. More than half (60.16%) of the discovered apps of that type belonged to the Robtes family.
Various Trojans came close behind with 20.49%, a rise of 5.81 p.p. on the previous quarter. The largest contribution was made by objects belonging to the Mobtes (38.75%), Boogr (21.12%) and Agent (18.98%) families.
Top 20 mobile malware programs
Note that the malware rankings below exclude riskware or PUAs, such as RiskTool or adware.
Verdict
%*
1
DangerousObject.Multi.Generic
21.90
2
Trojan-SMS.AndroidOS.Fakeapp.d
10.71
3
Trojan.AndroidOS.Generic
10.55
4
Trojan.AndroidOS.GriftHorse.ah
6.07
5
Trojan-Spy.AndroidOS.Agent.aas
5.40
6
Trojan.AndroidOS.GriftHorse.l
3.43
7
DangerousObject.AndroidOS.GenericML
3.21
8
Trojan-Dropper.AndroidOS.Agent.sl
2.82
9
Trojan.AndroidOS.Fakemoney.d
2.33
10
Trojan.AndroidOS.Fakeapp.ed
1.82
11
Trojan.AndroidOS.Fakeapp.dw
1.68
12
Trojan.AndroidOS.Fakemoney.i
1.62
13
Trojan.AndroidOS.Soceng.f
1.59
14
Trojan-Ransom.AndroidOS.Pigetrl.a
1.59
15
Trojan.AndroidOS.Boogr.gsh
1.56
16
Trojan-Downloader.AndroidOS.Necro.d
1.56
17
Trojan-SMS.AndroidOS.Agent.ado
1.54
18
Trojan-Dropper.AndroidOS.Hqwar.gen
1.54
19
Trojan.AndroidOS.Fakemoney.n
1.52
20
Trojan-Downloader.AndroidOS.Agent.kx
1.45
* Unique users attacked by this malware as a percentage of all attacked users of Kaspersky mobile solutions.
First and third places went to DangerousObject.Multi.Generic (21.90%) and Trojan.AndroidOS.Generic (10.55%), respectively, which are verdicts we use for malware detected with cloud technology. Cloud technology is triggered whenever the antivirus databases lack data for detecting a piece of malware, but the antivirus company’s cloud already contains information about the object. This is essentially how the latest malware types are detected.
Trojan-SMS.AndroidOS.Fakeapp.d rose from third to second place with 10.71%. This malware is capable of sending text messages and calling predefined numbers, displaying ads and hiding its icon.
Members of the Trojan.AndroidOS.GriftHorse family took fourth and sixth places with 6.07% and 3.43%, respectively. This family includes fraudulent apps that purchase paid subscriptions on the user’s behalf.
Trojan-Spy.AndroidOS.Agent.aas (5.40%), an evil twin of WhatsApp with a spy module built in, retained fifth position.
The verdict of DangerousObject.AndroidOS.GenericML (3.21%) came seventh. These verdicts are assigned to files recognized as malicious by our machine-learning systems.
Trojan-Dropper.AndroidOS.Agent.sl (2.82%), a dropper that unpacks and runs a banking Trojan on devices, remained in eighth place. Most of the attacked users were based in Russia or Germany.
Trojan.AndroidOS.Fakemoney.d slid from second to ninth place with 2.33%. Other members of the family occupied twelfth and nineteenth places in the rankings. These are fraudulent apps that offer users to fill out fake welfare applications.
Trojan.AndroidOS.Fakeapp.ed dropped to tenth place from sixth with 1.82%; this verdict covers fraudulent apps purporting to help with investing in gas utilities and mostly targeting Russian users.
Trojan.AndroidOS.Fakeapp.dw dropped from tenth place to eleventh with 1.68%. This verdict is assigned to various scammer apps, for example, those offering to make extra income.
Trojan.AndroidOS.Soceng.f (1.59%) dropped from twelfth to thirteenth place. This Trojan sends text messages to people in your contacts list, deletes files on the user’s SD card, and overlays the interfaces of popular apps with its own window.
Trojan-Ransom.AndroidOS.Pigetrl.a dropped from eleventh to fourteenth place with 1.59%. This malware locks the screen, asking to enter an unlock code. The Trojan provides no instructions on how to obtain this code, which is embedded in the body of the malware.
The verdict of Trojan.AndroidOS.Boogr.gsh occupied fifteenth place with 1.56%. Like DangerousObject.AndroidOS.GenericML, this verdict is produced by a machine learning system.
Trojan-Downloader.AndroidOS.Necro.d (1.56%), designed for downloading and running other malware on infected devices, climbed to sixteenth place from seventeenth.
Trojan-SMS.AndroidOS.Agent.ado dropped from fifteenth to seventeenth place with 1.54%. This malware sends text messages to short codes.
Trojan-Dropper.AndroidOS.Hqwar.gen, which unpacks and runs various banking Trojans on a device, kept eighteenth place with 1.54%.
Trojan-Downloader.AndroidOS.Agent.kx (1.45%), which loads adware, dropped to the bottom of the rankings.
Map of attempts to infect mobiles with malware, Q2 2022 (download)
TOP 10 countries and territories by share of users attacked by mobile malware
Countries and territories*
%**
1
Iran
26,91
2
Yemen
17,97
3
Saudi Arabia
12,63
4
Oman
12,01
5
Algeria
11,49
6
Egypt
10,48
7
Morocco
7,88
8
Kenya
7,58
9
Ecuador
7,19
10
Indonesia
6,91
* Excluded from the rankings are countries and territories with relatively few (under 10,000) Kaspersky mobile security users. ** Unique users attacked as a percentage of all users of Kaspersky mobile security solutions in the country.
Iran remained the leader in terms of the share of infected devices in Q2 2022 with 26.91%; the most widespread threats there as before were the annoying AdWare.AndroidOS.Notifyer and AdWare.AndroidOS.Fyben families. Yemen rose to second place with 17.97%; the Trojan-Spy.AndroidOS.Agent.aas spyware was the threat most often encountered by users in that country. Saudi Arabia came third with 12.63%, the most common malware apps in the country being the AdWare.AndroidOS.Adlo and AdWare.AndroidOS.Fyben adware families.
Mobile banking Trojans
The number of detected mobile banking Trojan installation packages increased slightly compared to the previous quarter: during the reporting period, we found 55,614 of these, an increase of 1,667 on Q1 2022 and a year-on-year increase of 31,010.
Almost half (49.28%) of the detected installation packages belonged to the Trojan-Banker.AndroidOS.Bray family. The Trojan-Banker.AndroidOS.Wroba was second with 5.54%, and Trojan-Banker.AndroidOS.Fakecalls third with 4.83%.
Geography of mobile banking threats, Q2 2022 (download)
TOP 10 countries and territories by shares of users attacked by mobile banking Trojans
Countries and territories*
%**
1
Spain
1.04
2
Turkey
0.71
3
Australia
0.67
4
Saudi Arabia
0.64
5
Switzerland
0.38
6
UAE
0.23
7
Japan
0.14
8
Colombia
0.14
9
Italy
0.10
10
Portugal
0.09
* Countries and territories with relatively few users of Kaspersky mobile security solutions (under 10,000) have been excluded from the ranking. ** Unique users attacked by mobile banking Trojans as a percentage of all Kaspersky mobile security solution users in the country.
In Q2 2022, Spain still had the largest share of unique users attacked by mobile financial threats: 1.04%. Trojan-Banker.AndroidOS.Bian.h accounted for 89.95% of attacks on Spanish users. Turkey had the second-largest share (0.71%), with attacks on Turkish users dominated by Trojan-Banker.AndroidOS.Ermak.a (41.38%). Australia was third with 0.67%; most attacks in this country were attributed to Trojan-Banker.AndroidOS.Gustuff.d (96,55%).
Mobile ransomware Trojans
The number of mobile ransomware Trojan installation packages we detected in Q2 2022 (3,821) almost doubled from Q1 2022, increasing by 1,879; the figure represented a year-on-year increase of 198.
Geography of mobile ransomware Trojans, Q2 2022 (download)
TOP 10 countries and territories by share of users attacked by mobile ransomware Trojans
Countries and territories*
%**
1
Yemen
0,30
2
Kazakhstan
0,19
3
Azerbaijan
0,06
4
Kyrgyzstan
0,04
5
Switzerland
0,04
6
Egypt
0,03
7
Saudi Arabia
0,03
8
Uzbekistan
0,02
9
Russian Federation
0,02
10
Morocco
0,02
* Excluded from the rankings are countries and territories with relatively few (under 10,000) Kaspersky mobile security users. ** Unique users attacked by ransomware Trojans as a percentage of all Kaspersky mobile security solution users in the country or territory.
Countries leading by number of users attacked by mobile ransomware Trojans were Yemen (0.30%), Kazakhstan (0.19%) and Azerbaijan (0.06%). Users in Yemen most often encountered Trojan-Ransom.AndroidOS.Pigetrl.a, while users in Kazakhstan and Azerbaijan were attacked mainly by members of the Trojan-Ransom.AndroidOS.Rkor family.
