Why your UniFi LAN shouldn't be 192.168.1.0/24

There is no RFC that says a home router has to default to 192.168.1.0/24. There is no IEEE standard that mandates it. It is a convention — one that stuck so hard it became invisible. Every major consumer router vendor either defaults to 192.168.1.0/24 or to 192.168.0.0/24, with a handful of vendor- specific exceptions:

• 192.168.1.1 — Linksys, Netgear, ASUS, TP-Link, D-Link, Ubiquiti UniFi gateways out of box, and dozens of smaller vendors.
• 192.168.0.1 — D-Link (some models), TP-Link (some models), Belkin, some Tenda.
• 192.168.2.1 — SMC, some Belkin and US Robotics models.
• 192.168.86.1 — Google Nest Wifi / Google Wifi. Quietly one of the better-chosen defaults in the consumer market, because it landed somewhere almost no other vendor did.
• 10.0.0.1 — Xfinity / Comcast gateways, eero (some firmware), older Apple AirPort.

UniFi's default LAN, on a new UDR / UCG-Ultra / UDM-Pro / UDM-SE / Dream Machine, is 192.168.1.1/24. You can change it in five clicks at first-time setup — Settings → Networks → Default → Host Address — and most installers, on most installs, just click Next. Once a single device has been bound to an address inside that subnet, changing it stops being a five-click operation.

Wikipedia's article on private networks notes the same convergence on consumer hardware in general terms — most ISPs hand a residential customer one public IPv4 address, and the NAT-capable home router then runs a private LAN inside one of the RFC 1918 blocks behind it.³ It does not name a specific default — there is no standard to cite — but the empirical reality is consistent: a phone joining a residential Wi-Fi network is, the vast majority of the time, joining some flavour of 192.168.{0,1,2}.x.

The default subnet doesn't break the home network. That is the trap. It breaks something the home network wants to connect to or be connected from. There are three common shapes.

Failure 1 — Remote-access VPN home from a colliding Wi-Fi

The most common one. The homeowner sets up a UniFi WireGuard or OpenVPN server so they can reach their home NAS, control system, NVR, or RDP into a desktop while travelling. The home LAN is 192.168.1.0/24. The home NAS lives at 192.168.1.50. Everything works from a coffee shop on cellular data. It also works from a friend's house on a network that happens to be 10.0.0.0/24. Then the homeowner travels, checks into a hotel, and the hotel Wi-Fi is also 192.168.1.0/24. The VPN dials up. The tunnel is healthy. The NAS at 192.168.1.50 is unreachable.

The reason is in the WireGuard man page's definition of AllowedIPs:

“A comma-separated list of IP (v4 or v6) addresses with CIDR masks from which incoming traffic for this peer is allowed and to which outgoing traffic for this peer is directed.”⁴

AllowedIPsis a routing decision, not just a filter. When the laptop is sitting on a network that's already 192.168.1.0/24, the operating system already has a directly-connected route to that subnet — out the Wi-Fi interface. The VPN tunnel is offering the same route. The OS picks the directly-connected one. Packets for 192.168.1.50go out the Wi-Fi card, to the hotel's router, which has no idea what to do with them. The NAS at home is, from the laptop's perspective, every other hotel guest's laundry-room printer.

The same physics applies to OpenVPN, IKEv2, Tailscale subnet routes, and every other modern remote-access VPN. Tailscale's own documentation on subnet routers spells out the prerequisite that subnets be planned so that traffic can be deterministically routed:⁵ if both ends are 192.168.1.0/24, the routing table can't tell them apart.

Failure 2 — Corporate VPN that wants the same /24

The mirror image. The work laptop runs a corporate VPN — Cisco AnyConnect, GlobalProtect, FortiClient, Zscaler ZPA, or Tailscale-with-an-ACL. The corporate network has a sprawl of internal services on 192.168.1.0/24 (or, more often, several /24s in 10.0.0.0/8 plus a handful of 192.168.x oddities that grew out of mergers). The user works from home. The home network is 192.168.1.0/24. The VPN connects. The corporate intranet is unreachable.

Some corporate VPN clients handle this with split-DNS and per-app routing. Many do not — they push a single route table to the OS at connect time, and the already-installed directly-connected route to 192.168.1.0/24 wins for outbound packets. The corporate intranet might as well be on the moon. The remote-access ticket gets escalated to the corporate IT team. The corporate IT team blames the home router. The user changes carriers, switches laptops, reinstalls the VPN client — none of which fixes anything, because the problem is the subnet number.

Failure 3 — Site-to-site between two homes that both defaulted

UniFi's Site Magic feature pairs two UniFi consoles into an automatic site-to-site WireGuard tunnel. It is one of the things the platform sells itself on. It also has a hard prerequisite that the two LANs being linked have non-overlapping IP ranges, because the underlying tunnel — and every other site-to-site VPN technology, going back to IPsec — is a routing tunnel. Two sites with identical subnets cannot be routed between, period. The Site Magic wizard refuses to complete the link if it detects an overlap.

The collision is depressingly common in residential installs: a homeowner who has a beach house wants to link it to their primary residence. Both UDMs are on 192.168.1.0/24because both came out of the box that way. Either one site has to renumber, or the link doesn't happen.

The bar is low. Any /24 inside RFC 1918 space that isn't one of the famous defaults will dramatically reduce the collision rate. Three workable strategies, in order of community preference:

Strategy A — A less-trafficked corner of 192.168.x/24

Pick a value for the third octet that consumer routers effectively never default to. Avoid: 0, 1, 2, 4, 10, 50, 100, 254. Avoid 86 (Google Wifi's default). Avoid 88 (a common WireGuard tutorial value). Reasonable picks: 192.168.42.0/24, 192.168.77.0/24, 192.168.137.0/24, 192.168.213.0/24. Any value chosen roughly at random in the third octet, outside the short list of vendor defaults, is fine. This is the gentlest change for a household full of devices that might have hard-coded a 192.168.xassumption somewhere — the upper three octets still look like home Wi-Fi.

Strategy B — A random /24 inside 10.0.0.0/8

More headroom. Pick two octets between 0 and 255 and land somewhere like 10.83.21.0/24, 10.207.42.0/24, or 10.144.7.0/24. Statistically almost certain to be unique against any random Wi-Fi network you ever connect to. Easy to expand later if the home grows into multiple VLANs — pick the prefix once, vary the third octet per VLAN (10.83.21.0/24 trusted, 10.83.22.0/24 IoT, 10.83.23.0/24 guest, etc.).

Strategy C — Anywhere in 172.16.0.0/12

The forgotten middle block. Spans 172.16.x.x through 172.31.x.x. Workable, occasionally clashes with corporate enterprise networks that picked it because consumer vendors didn't. Less common in homes than either of the other two; pick this if you specifically like that it isn't the obvious answer.

One trap to avoid in all three strategies: do not use 100.64.0.0/10. That range is reserved by RFC 6598 for Carrier-Grade NAT between an ISP and its customer-premises equipment. Using it inside a home will produce strange routing failures the day the upstream ISP migrates to or deepens CGNAT. The three RFC 1918 blocks are the safe choices.

Before any device has joined the home network, the only place the chosen subnet exists is the gateway's own configuration. Change it; reboot the gateway; you're done. Every device that subsequently connects gets a DHCP lease inside the new range. There is nothing to migrate, because nothing has been bound.

Five minutes of forethought at first-time setup — pick a third octet, type it into the LAN field, click save — removes an entire class of problems from the rest of the network's life. The home will never collide with a hotel Wi-Fi. Site Magic will work the first time. A corporate VPN's overlap is no longer the home's problem.

The Hostbor write-up of common UniFi misconfigurations states the case bluntly:

“When you first set up your UniFi Dream Machine setup or any UniFi controller setup, it defaults to using 192.168.1.x as your network subnet.”⁶ — and proceeds to recommend renumbering into 10.x.x.xwith site-distinct subnets explicitly so that VPN routing doesn't collide.

The Smart Home Hookup's long-running UniFi tutorial series happens to use 192.168.86.0/24as its example trusted network — borrowing from Google Wifi's default — for exactly this reason: it isn't the same number as anyone else's home Wi-Fi.⁷

The other direction is the painful one. A home that has been on 192.168.1.0/24 for two years has accumulated dozens of places where that subnet is hard-coded. Renumbering touches every one of them. The inventory tends to look like this:

• Static IP reservations in the DHCP scope. Every device with a reserved address — the NAS, the NVR, the printer, the AV-control processor, the home automation hub — has to be re-reserved inside the new subnet. UniFi's Clients view shows the list.
• Devices configured with static IPs at the device side (not via DHCP reservation). Older printers, some IP cameras, NAS units configured before DHCP-reservations were the norm, smart-home hubs that insist on a fixed address. Each of these has to be logged into and reconfigured. Some require a factory reset because their web UI is only reachable from the old subnet.
• Port-forwarding rules. Every rule on the UniFi gateway that maps an external port to an internal host has the internal address baked in. They all need to be updated.
• Firewall rules with explicit source or destination IPs. Any custom firewall rule that names a specific host inside the LAN.
• DNS records — local or upstream. Anything pointing nas.home.lan at 192.168.1.50 needs to point at the new address. Pi-hole / AdGuard Home / NextDNS / a local DNS server, any of them; check them all.
• AV-control system bindings. Crestron, Control4, Savant, Lutron, Sonos, integrator-installed audio matrices, video switchers — most of them are configured by IP, not by hostname. Renumbering means the AV system needs an integrator visit. Cost it in.
• Smart-home hubs and IoT controllers. Hubitat, Home Assistant, Homey, SmartThings stations, Lutron Caseta bridges, Hue bridges, Sonos controllers, Aqara hubs. Some auto-discover; many cache the old address and need to be re-paired.
• VPN clients. The AllowedIPs (WireGuard), push route (OpenVPN), or split-tunnel routes (IKEv2) on every remote client all reference the old subnet. They all need to be reissued.
• Cloud-side device pairings that cached the internal IP. Ring, Nest, Arlo, Eufy, and some AV-control cloud bridges occasionally pin an internal IP. Most recover on power-cycle; a handful need to be removed and re-added in their cloud account.

A residential renumber on a mature network is usually a half-day of careful work plus a follow-up week of discovering the IoT device that nobody remembered. Doing it before any device joins costs five minutes. The asymmetry is the entire reason this article exists.

In the UniFi Network application, the default LAN is edited at Settings → Networks → Default. The relevant fields:

• Host Address.The gateway's own IP on this LAN, in CIDR form. Typing 10.83.21.1/24 replaces the default 192.168.1.1/24 and sets both the gateway address and the subnet in one field.
• DHCP Mode. Leave as DHCP Server. The controller automatically derives a default DHCP range from the new subnet (typically x.x.x.6 – x.x.x.254); adjust the range to leave room for static reservations at the low end.
• DHCP DNS. Leave on Auto unless a local resolver is in play.
• Apply. The gateway re-IPs its LAN interface and triggers DHCP renewals on every connected client. Wired clients reconnect within seconds; wireless clients within a minute or two; a handful of stubborn IoT devices need a power-cycle.

If the LAN is brand-new — no devices yet — the change is instantaneous. If devices are already on the LAN, the controller does the renumber on the gateway side cleanly, but it cannot reach into static-IP devices that disagree with the new subnet. Those will have to be visited individually.

Site Magic overlap detection

When linking two UniFi consoles via Site Magic, the wizard inspects each site's configured LANs and refuses to complete the pairing if any /24 overlaps. That refusal is the diagnostic — if Site Magic won't finish, the most common reason is that both ends are 192.168.1.0/24. The remediation is to renumber one of them, on the side that has fewer bound devices, then retry. Ubiquiti documents the requirement in their Site Magic and Site-to-Site VPN articles in the help center (those URLs are not directly fetchable for citation purposes; the requirement is the same as for every other site-to-site VPN technology).

VLANs inherit the trap

If the default LAN is at 192.168.1.0/24 and a second LAN gets added at 192.168.2.0/24, both stay inside the most-collided-with /16. The collision risk is per-/24, not per-/16, so this only partially helps. Picking the prefix once at the parent level — e.g. 10.83.x.0/24 for every VLAN, varying just the third octet — gives every VLAN the same collision-free upper bytes.

• If the network will never serve a remote- access VPN — and never participate in a site-to-site VPN — the default is harmless. Plenty of households use a UniFi gateway purely as a fast local router and never set up either feature. The collision risk is purely a function of inbound remote access and inter-site routing.
• Some IoT devices misbehave on subnets they don't recognise. A small but real list of older smart-home gear was developed against 192.168.1.xas an implicit assumption and behaves erratically off it — failing to discover a controller, refusing to bind to a printer, or producing unhelpful error codes. Most modern gear doesn't care; legacy gear sometimes does. If one specific device starts misbehaving after a renumber, that's usually why.
• Some corporate VPNs handle subnet overlaps with subnet-translation NAT or per-app DNS-based routing. Zscaler ZPA, Cloudflare Access, Tailscale with subnet relays, and Cisco AnyConnect with a particular ASA configuration can all hide the overlap from the OS-level routing table. A network in 192.168.1.0/24isn't guaranteed to break every corporate VPN — but the failure mode is common enough that picking a different /24 costs nothing and removes the variable.
• Renumbering inside RFC 1918 doesn't affect external reachability.Public IP, WAN routing, ISP NAT, port-forwards (after they're re-pointed), and Cloudflare Tunnels all behave the same regardless of which private /24 the LAN uses. The change is purely cosmetic from the internet's point of view.
• This is a one-time decision.Pick a subnet at install. Document it. Don't change it again unless you have to. The cost of the second change is similar to the cost of the first after-the-fact change — it is the bindings, not the router config, that hurt.

None of these caveats changes the headline recommendation. On a new UniFi install, before any device has joined, change the LAN subnet to something other than 192.168.1.0/24 or 192.168.0.0/24. The cost is a minute. The payoff is a network that will route correctly the first time you try to VPN into it from somewhere else's default home Wi-Fi.