Category: Windows 11

How to Deploy a Domain Controller in Azure

In this guide, I will demonstrate how to deploy a domain controller in Azure.

Deploying a Domain Controller in Azure can be used to add additional Domain Controllers to your on-premises environment. It’s also an easy way to create an Active Directory test lab.

Note: The VM I create in this demo is for testing, the settings are not optimal for a production domain controller. If you want to deploy a Domain Controller in Azure for production you will need to determine the right settings for your organization, such as VM size (CPU, Mem), redundancy options, disks, and network settings, all of which will increase the cost.

Tip #1: For a production DC, DO NOT give it a public IP or allow public inbound ports.

Tip #2: To add an azure domain controller to your on-premises environment you will need a VPN tunnel from your network to Azure. I will go over this in a separate guide.

Tip #3: For production, the Azure virtual network must not overlap your on-premises network. For testing, it doesn’t matter (assuming you will not be connecting to your on-premises network).

Let’s get started.

Part 1: Create a Virtual Machine

If you don’t have an Azure account you can create one for free. Microsoft gives you a $200 Azure credit for 30 days. This is plenty of credits to create several VMs and use other Azure resources.

Step 1. Sign in to your azure portal, https://portal.azure.com

Step 2. Click on “Virtual machines”

select virtual machines

Step 3. Click on Create and select “Azure virtual machine”

Step 4. Enter basic information for the new VM

  • Subscription: Select the subscription you want to use for the VM.
  • Resource group: Select an existing or create a new resource group.
  • Virtual machine name: Give your VM a name.
  • Region: Choose your region, you typically want a region that is close to you.
  • Availability options: This is for redundancy and will ensure your VMs are still running if one Azure data center has a failure. You want this for production VMs. I’m just creating a test VM so I’ll choose “No infrastructure redundancy required.”
  • Security Type: I’ll choose Standard.
  • Image: Pick the OS you want to use, I’ll pick “Windows Server 2019 Datacenter”.
  • Size: You will need to determine the size of VM you need. For testing reasons, I’ll choose a small VM to keep costs low.
  • Username and password: This will be the administrator account for the VM.
  • Public inbound ports: For production, you want this set to “none”. For testing, I’ll leave RDP open.
  • Licensing: If you have an existing license you can use select the box, this can save money on each VM.

Here is a screenshot of the Basics settings for my VM.

virtual machine basic settings

Now click Next to go to the Disks page.

Step 5. Enter disk details for the VM.

Determine the disk type to use, for testing I use the standard HDD.

virtual machine disk settings

Click next to go to networking.

Step 6. Network settings

  • Virtual network: Select an existing or create a new virtual network.
  • Subnet: Select or create a subnet.

You create a virtual network and then use subnetting to segment the address space. For example, I’m using the 10.1.0.0/16 address space then I segment 10.1.10.0/24 (256 addresses) with subnetting. I’ll use the 10.1.10.0/24 subnet block for my servers.

virtual machine create virtual network
  • Public IP: A public IP will be added automatically. For testing, this is OK, for production set this to none.
  • NIC network security group: This is s stateful firewall for your virtual network. I’ll choose standard.
  • Public inbound ports: For production, you want to select none. For testing, you can use RDP to access the VM.
virtual machine network inbound ports

Click next to “Management”

Step 7: Management Settings

The only thing I want to point out on this page is the “Auto-shutdown” option. For testing with Azure, this is a great feature to help save costs. You get charged for the VM running even if you are not using it. I’m not going to be using this test domain controller 24/7 so I’ll have it auto shut down at 7:00 PM each night. Do not do this for a production domain controller.

virtual machine auto shutdown

Step 8: Click Review + create

Microsoft will validate your settings and show any warnings or settings that were missed. You will also get a cost estimate but keep in mind it is just an estimate.

virtual machine validation check

When ready click the “Create” button to create the VM.

You will get a progress page so you can watch the status of the deployment. It took about 5 minutes for my VM to be created.

virtual machine deployment completed

Part 2: Configure VM with Static IP Addresses

Domain controllers need a static IP address and the DNS pointing to itself. For on-premises DCs you would just go into the NIC settings and manually configure the IP settings. With Azure VMs it’s recommended to set this at the Virtual Network Interface.

Go to VM Networking settings.

In the right-hand menu for your VM under settings click on “Networking”.

configure vm static ip

Now click on the Network Interface for the VM (You will have a different name).

virtual network network interface

Next click on “IP Configurations” in the left menu under settings.

Next click on “ipconfig1” under IP configurations.

ip configuration

Change the IP from “Dynamic” to “Static” and enter the IP address you want the domain controller to have, it must be an IP from the subnet you assigned to your virtual network. I’ll give my DC the IP address 10.1.10.10.

set static ip address on vm

Click “Save”. The network interface will be restarted to set the IP address.

Go back to the Network Interface and click on “DNS servers”.

network interface dns settings

Set the DNS server to the IP address of the domain controller.

set dns servers for nic

Now on the VM, your server should be configured with the settings from above. Below I run ipconfig /all to verify my IP settings.

ipconfig for virtual machine

Part 3: Install Active Directory Domain Services

With a VM created and the IP settings configured we can move forward with installing Active Directory on the server. If you have installed ADDS before this is not new, it’s the same as installing it on an on-premises server.

Go to the server manager and click on “Add roles and features”

server manager add roles

Before you begin – click “Next”.

Installation type – select “role based” and click “Next”.

Server Selection – select the hostname of your server and click “Next”.

Server Roles – select “Active Directory Domain Services”.

You will get a pop-up to add additional features. Click “Add Features”.

install active directory domain services

Click “Next”.

Features – no features need to be added so click “Next”.

AD DS – Click “Next”.

Confirmation – Click “Install”.

The installation will start.

When finished click the yellow icon in the upper right corner and click on “Promote this server to a domain controller”.

promote to domain controller

Deployment Configuration

I’m creating a new domain so I’m going to pick “Add a new forest”. If you’re adding another DC to your existing domain you would pick the first option “Add a domain controller to an existing domain”.

domain controller deployment config

Domain Controller Options

For a new test domain, the default settings are good. Add a DSRM password and click next.

domain controller options

DNS Options

Click next on this screen.

Additional Options

Enter a NetBIOS name and click “Next”

netbios domain name

Paths

I always leave these as default settings

Review Options

Review your settings and click “Next”

Prerequisites Check

If the Prerequisites pass click on “Install”

deployment check

When done installing the server will reboot and will now be a domain controller.

domain controller install completed.

Nice work. If you followed along you should now have a domain controller running in the Azure cloud.

You can now deploy additional Azure VMs and connect them to this domain controller. You can also use this domain controller to add additional DCs to your on-premises environment.

Part 4: Additional Settings and Tips

Here are a few additional settings and tips I recommend.

  1. You will need to create a new site in Active Directory Sites & Services with the new subnet.
  2. You should adjust the domain controller DNS settings for redundancy.
  3. A VPN tunnel is required from your on-premises network to Azure.
  4. If you are testing and use a public IP with open ports (RDP 3389), then I recommend using fake/dummy data in Active Directory. Their server might get comprised due to the internet exposure so don’t use real data such as real usernames and passwords.
  5. You can use the Azure firewall to limit access to the VM from your IP address.
  6. Use Bastion for secure remote connectivity.
  7. Explore the many options that Azure has to offer, it’s very impressive everything it has to offer.

Do you plan to use domain controllers running in Azure? Let me know in the comments below.

Resources

Recommended Tool: Permissions Analyzer for Active Directory

This FREE tool lets you get instant visibility into user and group permissions and allows you to quickly check user or group permissions for files, network, and folder shares.

You can analyze user permissions based on an individual user or group membership.

This is a Free tool, download your copy here.

8 thoughts on “How to Deploy a Domain Controller in Azure”

Source :
https://activedirectorypro.com/deploy-domain-controller-azure/

Active Directory Ports Used Client to Server

Active Directory ports used

In this post, I will explore the TCP and UDP ports used by Active Directory from client to server.

I will use WireShark and a series of tests to determine what ports are used.

Tests I’ll be running:

  • Ports Used When a User Logs into a Computer
  • Ports used when running gpupdate
  • Ports used when joining a computer to the domain
  • Ports Used When Rebooting

Test Environment:

  • Server 2022 with IP 192.168.100.10 (Active Directory Server)
  • Windows 10 Pro with IP 192.168.100.20
  • Wireshark is installed on the Active Directory server
  • The Active Directory server is a default install

Ports Used by Active Directory Between Client and Server

This section is a summary of the ports used in all the tests.

TCP 135 Microsoft RPC Mapper

TCP 135 Microsoft RPC Mapper
  • Description: Port 135 is a critical client/server port. This port is used by many Microsoft services and should not be blocked by a firewall. First the client connects to the RPC mapper service (port 135) and asks the mapper what port a given service is listening on (which will be a dynamic port range… see below). The RPC mapper responds to the client with the port and then the client connects to that port. You can see this in the above screenshot.
  • Firewall: Allow between client and server. Port 135 should not be exposed to the internet.

TCP/UDP 49152 – 65535 RPC Dynamic Ports

rpc dynamic port range
  • Description: The dynamic port range is used by various server applications. RPC dynamic port allocation instructs the RPC program to use a particular random port in the range configured for TCP and UDP, based on the implementation of the operating system used. The RPC mapper (port 135) is used to connect clients to services running on these dynamic ports.
  • Firewall: Allow between client and server. This port range should not be exposed to the internet.

we recommend that you reconfigure the firewalls to allow traffic between servers in the dynamic port range of 49152 through 65535. This range is in addition to well-known ports that are used by services and applications.

https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/default-dynamic-port-range-tcpip-chang

TCP 88 Kerberos

tcp 88 kerberos ports
  • Description: Kerberos is an authentication protocol that authenticates requests between a client and server in a secure manner. This is Microsoft Window’s default authentication method for domain-joined devices.
  • Firewall: Allow between client and server. Port should not be exposed to the internet.

TCP 389 LDAP

tcp 389 ldap ports
  • Description: LDAP is a directory access protocol. This protocol is used to search, add/delete, authenticate and modify data in a Directory Server such as Active Directory.
  • Firewall: Allow between client and server. Port should not be exposed to the internet.

UDP 53 DNS

udp 53 dns ports
  • Description: DNS is a critical service used to map IP addresses to host names. This is a critical service used by clients to locate resource records in the domain and lookup external domain names.
  • Firewall: Allow between client and server. If DNS is running on your Active Directory server I do not recommend exposing it to the internet.

TCP 445 SMB

tcp 445 server message blocks
  • Description: Server message blocks (SMB protocol) is a client-to-server communication protocol used for accessing files, printers, and data on a network. This port is used during startup to get GPO information, it is also used when running the gpupdate command.
  • Firewall: Allow between client and server. Do not expose this port to the internet.

Ports Used When a User Logs into a Domain-Joined Computer

In this example, I will log into computer PC1 (192.168.100.20) and capture the network packets from the domain controller.

Here is a conversation view of the TCP/UDP ports used. This is traffic sent from the client to the domain controller and destination ports.

ports used when logging in

Here is a summary of the destination ports used by the client.

  • TCP 88 (Kerberos)
  • TCP 135 (Microsoft RPC)
  • TCP 389 (LDAP)
  • TCP 445 (Microsoft DS)
  • TCP 49668 (RPC for LSA, SAM, NetLogon) – This starts with a request to port 135
  • UDP 53 (DNS)
  • UDP 389 (LDAP)

Ports Used When Running Gpupdate

While logged into the client PC I will run the gpupdate command to see what ports are used.

Results below. It Looks like TCP port 445 is used the most when running a gpupdate.

ports used running gpupdate

Ports Used When Joining a Computer to The Domain

This looked similar to the other packet captures.

TCP 88 (Kerberos)
TCP 135 (Microsoft RPC)
TCP 389 (LDAP)
TCP 445 (Microsoft DS)
TCP 49668 (RPC for LSA, SAM, NetLogon) – This starts with a request to port 135
UDP 53 (DNS)

Ports Used When Rebooting

Nothing new, I see the same ports used when compared to the other packet captures.

Hopefully, this guide helps you to understand the ports used between a client and an Active Directory server. Keep in mind this test was a default domain controller install with no additional services running, the more services you install the more ports that may be used.

Resources:

Recommended Tool: Permissions Analyzer for Active Directory

This FREE tool lets you get instant visibility into user and group permissions and allows you to quickly check user or group permissions for files, network, and folder shares.

You can analyze user permissions based on an individual user or group membership.

This is a Free tool, download your copy here.

1 thought on “Active Directory Ports Used Client to Server”

Source :
https://activedirectorypro.com/active-directory-ports-used-client-to-server/

Change IP Address on Domain Controller

In this post, I will demonstrate how to change the IP address on a domain controller.

Before you change the IP address it is very important to run through a checklist. Any changes to a domain controller can disrupt services and impact business operations. See my checklist below.

For this demonstration, I have the following settings.

  • DC1, IP Address 192.168.100.10
  • DC2, IP Address 192.168.100.11
  • DC3, IP Address 192.168.100.12

I’m going to change the IP on DC2 to 192.168.100.15. If you are changing to a different subnet there are additional things to consider that I go over in the checklist.

Pre-Change Checklist

I recommend reviewing each item on this checklist before making changes. I’ve migrated many domain controllers from small to large networks and these steps have been a lifesaver. If you do this often you will probably come up with your own checklist.

Do You Have Multiple Domain Controllers?

It is best practice to have multiple domain controllers and backup Active Directory for disaster recovery reasons. I do not recommend making major changes to domain controllers if you have a single domain controller. If you have multiple DCs and the change breaks the server you can still operate from a secondary DC.

You can get a list of all domain controllers in your domain with this command:

Get-ADDomainController -filter * | select hostname, domain, forest

Check FSMO Roles

Does the DC hold any FSMO roles? Easily check with this command:

netdom query fsmo

Below you can see all my FSMO roles are on DC1.

To help avoid disruption to authentication services you could move the FSMO roles to another domain controller that is on the same site. Keep in mind you would need to move any services that are manually configured to the server.

I’m making changes to DC2 which has no FSMO roles running on it.

Check Installed Roles and Features

I recommend checking what services are running on the server, you don’t want to change the IP and then have something break because you didn’t know it was a DHCP server or a web server.

  • Check the control panel for installed software
  • Check the installed roles and features

You can quickly check the installed roles and features with this command:

Get-WindowsFeature | Where-Object {$_. installstate -eq "installed"}

Below you can see my DC2 server has some critical services running on it including DHCP and DNS. I’ll need to consider this when changing IP addresses.

Find Devices Pointing to the Domain Controller with Wireshark

Wireshark can help you identify what systems are pointing to your domain controller for various services like DNS, DHCP, and so on. This might be the most important pre-change step.

Useful Wireshark filters:

  • dns
  • dhcp
  • ldap
  • DCERPC

Here is an example:

The packet capture shows that system 192.168.100.22 is using DC2 for DNS. I’ve done a large migration of domain controllers before and used Wireshark to help identify systems that are still pointing to old domain controllers. From experience, you will probably be surprised at how many systems are hardcoded to your DCS.

Check Domain Controller Health

You need to check that your domain controller is healthy before making the change. Any issues could result in replication issues, DNS issues, and so on. I’ve got a complete guide on how to use dcdiag its actually very easy to use. Just open the command prompt on your server and run the command.

dcdiag

Check The Health of DNS

By default, dcdiag does not test DNS. Use this command to run a complete test on DNS.

dcdiag /test:dns /v

Make sure the server passes all tests and the name resolution SRV record is registered.

Run Best Practice Analyzer

The best practice analyzer can find configuration issues according to Microsoft best practices. The BPA tool is not always accurate so you need to double check its findings. Also, any errors or warnings do not mean your migration will fail. It can just help you find any major misconfigurations according to Microsoft best practices.

Here is a scan from my DC2.

I’ve got a warning that the loopback address is not included on the ethernet adapter settings. The best practice is to point the preferred DNS server to another DNS server (not itself).

Here is an example of how it should be configured:

My DC2 IP address is 192.168.100.11. You can see I set the preferred DNS to another domain controller (DC1) and the alternate is set to the loopback address. This is Microsoft’s best practice.

Again any warnings or errors the best practice analyzer finds doesn’t mean your migration will fail. But to help avoid any potential migration issues I recommend running this tool and reviewing the scan results. It might even fix some issues you weren’t aware of.

Are You Changing Subnets?

If you will be changing to a new subnet then consider the following:

  • If the server also runs DHCP you will need to update the helper address on your switch or firewall.
  • Add the new subnet to Active Directory sites and services.

Check Firewall Rules

Are there any firewall rules that will need to be updated? This could be your network firewall and windows based firewalls. I typically have rules on the network firewall that limit network access for critical servers like domain controllers. I would need to update the firewall rules to permit traffic to the new DC IP.

Plan & Schedule the IP Change

I recommend making this type of change during your maintenance window. No matter how much you prepare for changes there is always a potential for something going wrong. You need to have a maintenance window to allow time to resolve any issues. Don’t forget to communicate these changes with your team ahead of time.

How to Change the IP Address of a Domain Controller:

Here are the steps to changing the IP Address on a domain controller.

  1. Log on locally to the server (console access, don’t RDP or use remote access).
  2. Change NIC TCP/IP settings
    1. Change IP Address
    2. Change subnet mask (if required)
    3. Change Default gateway (if required)
    4. Preferred DNS server (should point to another DC in the same site)
    5. Alternate DNS server (should be the loopback address 127.0.0.1)
  3. After changing the IP run ipconfig /flushdns to remove local cache
  4. Run ipconfig /registerdns to ensure the new IP is registered by the DNS server
  5. Run dcdiag /fix to ensure service records are registered.

Video Tutorial

https://youtube.com/watch?v=4R942B54cEE%3Ffeature%3Doembed

Done. Nice work!

Post Change Checklist:

  • Update DHCP settings if DC server is also DNS server
  • If subnet address changed then make sure AD Sites and services is updated
  • Update clients that use static ip address
  • Update other DCs nic settings (if needed)
  • Run commands dcdiag and dcdiag /test:dns /v to check for issues.
  • Verify DNS is working, you can do this with nslookup.
  • Test authenticating to the DC. You can do this by manually settings a client IP DNS settings to the IP of the DC or using PowerShell and specify the authentication server.
  • Continue to monitor old IP with wireshark – This can be done by a span port or assign the DCs old IP to a computer with wireshark installed. This is useful to help find systems that are still using the old IP of the DC.
  • Update firewall rules if needed.
  • If a client system is having issues try to flush the local dns cache with ipconfig /flushdns command
  • Changing the IP address on the DC should not effect any shares on the server as long as DNS is updated.

Summary

In this post, I showed you how to change the IP address on a domain controller. I also showed you a checklist I go through before changing the IP address. Authentication, DNS, and DHCP services are critical so it’s very important to plan and review as much as you can before making changes to these critical services. Also, all organizations and networks are different so over time you may have a different checklist than mine.

Recommended Tool: Permissions Analyzer for Active Directory

This FREE tool lets you get instant visibility into user and group permissions and allows you to quickly check user or group permissions for files, network, and folder shares.

You can analyze user permissions based on an individual user or group membership.

This is a Free tool, download your copy here.

2 thoughts on “Change IP Address on Domain Controller”

Source :
https://activedirectorypro.com/change-ip-address-on-domain-controller/

Automatic Virtual Machine Activation in Windows Server

Automatic Virtual Machine Activation (AVMA) acts as a proof-of-purchase mechanism, helping to ensure that Windows products are used in accordance with the Product Use Rights and Microsoft Software License Terms.

AVMA lets you activate Windows Server virtual machines (VMs) on Windows Server Hyper-V host that is properly activated, even in disconnected environments. AVMA binds the virtual machine activation to the licensed virtualization host and activates the virtual machine when it starts up. You can get real-time reporting on usage and historical data on the license state of the virtual machine when using AVMA. Reporting and tracking data is available on the virtualization host.

Practical applications

On virtualization hosts, AVMA offers several benefits.

Server data center managers can use AVMA to do the following:

  • Activate virtual machines in remote locations
  • Activate virtual machines with or without an internet connection
  • Track virtual machine usage and licenses from the virtualization host, without requiring any access rights on the virtualized systems

Service Provider License Agreement (SPLA) partners and other hosting providers do not have to share product keys with tenants or access a tenant’s virtual machine to activate it. Virtual machine activation is transparent to the tenant when AVMA is used. Hosting providers can use the server logs to verify license compliance and to track client usage history.

System requirements

The virtualization host that will run virtual machines needs to be activated. Keys can be obtained through the Volume Licensing Service Center or your OEM provider.

 Note

In a failover cluster, each virtualization host in the cluster must be activated for VMs to stay activated regardless of which server they run on.

AVMA requires Windows Server Datacenter edition with the Hyper-V host role installed. The operating system version of the Hyper-V host determines which versions of operating system can be activated in a virtual machine. Here are the guests that the different version hosts can activate:

Server host versionWindows Server 2022 guest VMWindows Server 2019 guest VMWindows Server 2016 guest VMWindows Server 2012 R2 guest VM
Windows Server 2022XXXX
Windows Server 2019XXX
Windows Server 2016XX
Windows Server 2012 R2X

 Note

The table above applies all editions (Datacenter, Standard, or Essentials).

AVMA does not work with other server virtualization technologies.

How to implement AVMA

To activate VMs with AVMA, you use a generic AVMA key (detailed in the AVMA keys section below) that corresponds to the version of Windows Server that you want to activate. To create a VM and activate it with an AVMA key, do the following:

  1. On the server that will host virtual machines, install and configure the Microsoft Hyper-V Server role. For more information, see Install Hyper-V Server. Ensure that the server is successfully activated.
  2. Create a virtual machine and install a supported Windows Server operating system on it. ImportantThe Data Exchange integration service (also known as Key-Value Pair Exchange) must be enabled in the VM settings for AVMA to work. It is enabled by default for new VMs.
  3. Once Windows Server is installed on the VM, you install the AVMA key in the VM. From PowerShell or an elevated Command Prompt, run the following command:Copyslmgr /ipk <AVMA_key>

The virtual machine will automatically activate, providing the virtualization host itself is activated.

 Tip

You can also add the AVMA keys in any Unattend setup file.

AVMA keys

The following AVMA keys can be used for Windows Server 2022:

EditionAVMA key
DatacenterW3GNR-8DDXR-2TFRP-H8P33-DV9BG
StandardYDFWN-MJ9JR-3DYRK-FXXRW-78VHK

The following AVMA keys can be used for Windows Server 2019:

EditionAVMA key
DatacenterH3RNG-8C32Q-Q8FRX-6TDXV-WMBMW
StandardTNK62-RXVTB-4P47B-2D623-4GF74
Essentials2CTP7-NHT64-BP62M-FV6GG-HFV28

The following AVMA keys can be used for Windows Server, versions 1909, 1903, and 1809:

EditionAVMA key
DatacenterH3RNG-8C32Q-Q8FRX-6TDXV-WMBMW
StandardTNK62-RXVTB-4P47B-2D623-4GF74

The following AVMA keys can be used for Windows Server, version 1803 and 1709:

EditionAVMA key
DatacenterTMJ3Y-NTRTM-FJYXT-T22BY-CWG3J
StandardC3RCX-M6NRP-6CXC9-TW2F2-4RHYD

The following AVMA keys can be used for Windows Server 2016:

EditionAVMA key
DatacenterTMJ3Y-NTRTM-FJYXT-T22BY-CWG3J
StandardC3RCX-M6NRP-6CXC9-TW2F2-4RHYD
EssentialsB4YNW-62DX9-W8V6M-82649-MHBKQ

The following AVMA keys can be used for Windows Server 2012 R2:

EditionAVMA key
DatacenterY4TGP-NPTV9-HTC2H-7MGQ3-DV4TW
StandardDBGBW-NPF86-BJVTX-K3WKJ-MTB6V
EssentialsK2XGM-NMBT3-2R6Q8-WF2FK-P36R2

Reporting and tracking

The Key-Value Pair (KVP) exchange between the virtualization host and the VM provides real-time tracking data for the guest operating systems, including activation information. This activation information is stored in the Windows registry of the virtual machine. Historical data about AVMA requests is logged in Event Viewer on the virtualization host.

See Data Exchange: Using key-value pairs to share information between the host and guest on Hyper-V for more information about KVP.

 Note

KVP data is not secured. It can be modified and is not monitored for changes.

 Important

KVP data should be removed if the AVMA key is replaced with another product key (retail, OEM, or volume licensing key).

Since the AVMA activation process is transparent, error messages are not displayed. However, AVMA requests are also logged on the virtualization host in Event Viewer in the Application log with Event ID 12310, and on the virtual machine with Event ID 12309. The following events are captured on the virtual machines:

NotificationDescription
AVMA SuccessThe virtual machine was activated.
Invalid HostThe virtualization host is unresponsive. This can happen when the server is not running a supported version of Windows.
Invalid DataThis usually results from a failure in communication between the virtualization host and the virtual machine, often caused by corruption, encryption, or data mismatch.
Activation DeniedThe virtualization host could not activate the guest operating system because the AVMA ID did not match.

Recommended content

Source :
https://learn.microsoft.com/en-us/windows-server/get-started/automatic-vm-activation

UniFi Network – WAN Failover and Load Balancing

What is WAN Failover?
Failover enables you to connect a second Internet connection to your UniFi Gateway which will serve as a “backup”. If your primary Internet service goes down, you will begin utilizing your secondary Internet connection.

How does UniFi determine if my Internet goes down?
The UniFi Network Application checks for connectivity and latency to an “echo server”. By default, this is set to ping.ui.com which leverages responses from various locations to ensure maximum accuracy. 

Note: Some advanced network administrators may choose to manually select their own echo server depending on their specific requirements.

What is WAN Load Balancing?
Unlike WAN Failover which only uses a single Internet source at a given time, WAN Load Balancing will split Internet traffic between both of your sources. This will be supported by UniFi Gateways beginning in version 1.13 (UDM Pro / UXG Pro) and 2.5 (UDM SE).

How many Internet connections are my UniFi Gateways capable of?
In addition to the two WAN connections, UniFi Gateways also support the use of our UniFi LTE Backup which is connected to a LAN port. This is only capable of being used as a failover option.

Source :
https://help.ui.com/hc/en-us/articles/360052548713-UniFi-Network-WAN-Failover-and-Load-Balancing

UniFi Network – Configuring Port Forwarding

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.

Source :
https://help.ui.com/hc/en-us/articles/235723207-UniFi-Network-Configuring-Port-Forwarding

UniFi Network – Configuring Remote Access VPNs (VPN Server)

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. 

For more information about Teleport and other VPN options, see our Introduction to UniFi VPNs.

Setup

VPN server configuration requires a UniFi gateway and a 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

  1. 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.
  2. Go to Settings > Network & internet > Advanced network settings > More network adapter options > L2TP Adapter properties
  3. Click the Security tab, then set your authentication method to MS-CHAP v2.

macOS

  1. Go to System Preferences > Network > +. 
  2. Select VPN in the Interface field.
  3. Select L2TP over IPsec in the VPN Type field.
  4. Enter l2tp as the Service Name.

    Note: Your username, password, and pre-shared key are the same as those in your UniFi Network settings.
  5. 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 – Maintaining Connectivity with your UniFi Devices

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

A wirelessly adopted device is like any other wireless client. See Optimizing Wireless Client Connectivity for more details.

Firewall Blockages

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 Network – Configuring Site-to-Site VPNs

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. 

To learn more about Teleport and other UniFi VPN options, check out our Introduction to UniFi VPNs.

Setup

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:

  1. SSH into your UniFi gateway.
  2. Generate your key by using the following command: openvpn –genkey secret /tmp/ovpn
  3. 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.

Source :
https://help.ui.com/hc/en-us/articles/360002426234-UniFi-Network-Configuring-Site-to-Site-VPNs

UniFi Network – Optimizing Wired Network Speeds

The main factors that contribute to wired speeds are:

  • Physical (Layer 1) connections between your networking devices
  • Available device resources (e.g., CPU and Memory)
  • Protocol limitations
  • Software or configuration limitations

Follow these guidelines, and those in Optimizing Wireless Network Speeds, to maximize your total network throughput.

Recommendations 

Check Your Cabling

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. 

Check out our Beginner’s Guide to Network Cabling for more information. 

Ensure That All Ports Negotiate Proper Speeds

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)
  • Firewall Rules
  • Content Filters
  • VPNs 

To approximate your deployment’s resource usage, try our UniFi OS Console Resource Calculator. 

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?
  • When did this issue start?

    Source :
    https://help.ui.com/hc/en-us/articles/6949005136919-UniFi-Network-Optimizing-Wired-Network-Speeds