UniFi Home Network Review — Sample Report

Three port-forwarding rules on the UDM-Pro expose ports on the Crestron processor at 192.168.88.20 to the public internet: external 8443 → internal 443 (HTTPS), external 50001 → internal 50001 (Crestron Home App), and external 41796 → internal 41796 (Secure CIP, Crestron Home Setup app). The From field on all three rules is Any, meaning any source IP on the internet is permitted.

Crestron Home's official documentation now states the following about port mapping for remote access:¹

The current configuration is one generation behind Crestron's recommended deployment model. Automation controllers and embedded systems have historically been attractive targets when reachable directly from the internet, and a successful authentication here grants access onto the same flat LAN as personal devices and IP intercoms (see F-05).

Adjacent AV-control vendors have converged on the same architecture — outbound cloud relay for the homeowner app, VPN for installer config, no inbound port-forwarding required:

Retire all three port-forwards, in line with Crestron's current guidance:

1. Move the homeowner's mobile Crestron Home app to Crestron's cloud-based remote-access service. That removes the need for the 50001 port-forward entirely.
2. Provide AV-integrator technician access to the processor through a UniFi WireGuard VPN (F-02). That removes the need for the 8443 and 41796 port-forwards.
3. As an interim measure while the VPN is being set up, tighten each port-forward's From field from Any to the integrator's known public IP range.
4. After the cloud + VPN substitutes are verified end to end, remove the port-forwards entirely.

Low-to-medium. The retire-and-replace sequence above is staged, not flash-cut. The mobile app may need to be reauthorized once against the cloud relay.

Settings → VPN shows no VPN Server, VPN Client, or Site-to-Site VPN configured. UniFi cloud access to the controller itself is independent of this — the gap here is specifically that there is no VPN tunnel into the LAN.

Without a VPN, every remote-access requirement turns into another open port on the WAN. This is the direct cause of F-01's exposure, and it blocks any clean path to retiring the open Crestron rules. Crestron's own current guidance for installer config explicitly names VPN as the substitute.¹

Stand up a UniFi VPN server. WireGuard is the recommended choice on UDM-Pro — modern, fast, and supported by macOS / Windows / iOS / Android clients. Once the VPN is verified end-to-end (the AV-integrator technician successfully reaches the Crestron processor through the tunnel), proceed with the Phase 2 work in F-01.

One G4 Bullet (driveway-facing) was adopted and is reachable on the local management network, but the controller flags it with a 'Default Password In Use' advisory. The other seven cameras have rotated passwords managed through the Protect application.

Cameras retaining default credentials are widely abused by automated tools. Although the camera is not directly internet-exposed today, the flat LAN (F-05) means any compromised LAN device could attempt to reach it on the management network.

Rotate the camera password from the Protect application's device-management screen and verify the 'Default Password In Use' advisory clears.

All five SSIDs are set to Security Protocol = WPA2. Protected Management Frames (PMF) is set to Disabled on all five.

WPA2 without PMF is susceptible to deauthentication and beacon-spoofing techniques that can knock clients offline or push them onto a malicious AP. PMF support is defined in IEEE 802.11w and is standard on every modern client. All five APs in this deployment are WiFi 6 (U6-Pro / U6-LR), which support WPA2/WPA3 transition mode and PMF Optional natively.

Move each SSID to WPA2/WPA3 transition mode with PMF = Optional. Test one SSID first (the IoT SSID is the lowest-risk place to start since IoT clients are typically more rigid about Wi-Fi security than personal devices, so any compatibility issues will surface fastest there).

Only one logical network exists: 'Default' on 192.168.88.0/24. The 62 client devices include personal computers and phones, Crestron Home processor, Lutron HomeWorks processor, 2N IP intercoms, Sonos zones, UniFi Protect cameras, and a printer — all sharing the same broadcast domain.

If any one device on the LAN is compromised (an unpatched IoT device, a malicious app on a phone), it can directly reach every other device. IoT and home-automation devices in particular often ship with weak or hard-coded credentials. Camera systems and access-control intercoms should be on isolated management networks.

Introduce at least four logical networks:

• Trusted personal — laptops, phones, tablets
• Home automation — Crestron, Lutron, intercoms (allowed to reach the internet and their named cloud endpoints; cannot initiate connections into Trusted)
• IoT / smart-home — Sonos, lighting accessories, printer, etc.
• Camera management — Protect NVR + cameras (locked to that VLAN; outbound only to Ubiquiti cloud)

Multicast / mDNS reflection can be enabled selectively where Apple / Chromecast / Sonos discovery needs to cross zones.

The Owner role on the UniFi console is held by an AV-integrator email of the form service@<integrator>.example. The mailbox pattern (a role-named mailbox rather than a named individual) suggests it is a shared service account used by multiple technicians. Two further integrator accounts hold Custom roles tied to identifiable individuals; two homeowner accounts hold Super Admin.

Owner-on-integrator is a common pattern in professionally installed AV systems and is not in itself a problem — but it has two consequences. First, if the homeowner ever changes integrators, control of the network sits outside the household. Second, a shared service account makes MFA enforcement and offboarding harder (anyone with the credentials retains access), and makes audit attribution impossible.

Decide deliberately whether console Ownership should remain with the integrator or transfer to a homeowner-controlled account — there is no single right answer, but the decision should be made. Replace the shared service account with per-individual technician accounts under least-privilege Custom roles, so MFA and offboarding can actually be enforced.

Internet → WAN → UPnP is On. The current rule table shows two auto-opened mappings created via UPnP requests from internal devices.

UPnP lets any internal device punch holes in the firewall without administrator review. On a network that already exposes Crestron via static port-forwards (F-01) and lives on a flat LAN (F-05), additional dynamic port-openings widen the attack surface in ways the homeowner cannot see or audit.

Disable UPnP. Any service that genuinely needs an inbound port should be configured explicitly as a port-forward (and ideally moved behind the VPN per F-02 once that's in place).

All three Crestron port-forwards in F-01 are configured with Protocol = TCP/UDP. HTTPS (443) is TCP-only. The Crestron control ports (50001, 41796) are documented as TCP/TLS services² — UDP is not required.

Forwarding UDP on these ports needlessly broadens the exposed attack surface and adds amplification / scan opportunities for UDP-based probes.

Set each rule's Protocol explicitly to TCP. This change is reversible in seconds and has no functional impact on the documented Crestron services.

The five SSIDs ('House', 'House-Guest', 'House-IoT', 'House-AV', 'House-Service') are all bound to the same Native Network. The SSID names suggest segmentation, but the underlying network is shared — clients on each SSID land in the same 192.168.88.0/24 broadcast domain.

The intended segmentation is illusory. A compromised IoT device on House-IoT has the same network reach as a laptop on House.

This is a natural starting point for the VLAN work in F-05. Keep the SSID names, but bind each to its own VLAN with explicit allow/deny rules between them. Rotate the PSK on the Service SSID after each major integrator visit, since it is shared with technicians by design.

WAN and Default network DNS are set to Auto, which uses the ISP's DNS resolvers. Encrypted DNS is Off. No CyberSecure Content Filter is bound to the LAN.

ISP DNS may offer fewer privacy, security-filtering, and policy-control options than dedicated resolvers (e.g., Cloudflare 1.1.1.1, Quad9 9.9.9.9). DNS over TLS (RFC 7858)⁷ and DNS over HTTPS provide a meaningful confidentiality layer over plaintext DNS, particularly on a network that already lacks VLAN isolation.

Set Encrypted DNS to Cloudflare or Quad9 on the WAN, and apply the Basic Content Filter to the IoT VLAN once F-05 is in place. Quality-of-life and minor-security improvement; not urgent on its own.

The WAN IPv4 is obtained via DHCP from the ISP; the WAN IP field in port-forward rules carries the standard warning that the IP may change. No DDNS service is bound to WAN1.

If the public IP changes, any remote-access workflow that hard-codes it will silently break. For a VPN-based remote-access model (F-02), a stable hostname is operationally preferable.

When WireGuard is stood up per F-02, configure DDNS on WAN1 with a service the integrator already manages (No-IP, DynDNS, etc.) and reference the hostname in the VPN client config rather than a literal IP.

UDM-Pro and Network application are on the Official channel with auto-update enabled. All 16 UniFi infrastructure devices show as Up to date. Protect application is current.

Maintain. Keep the Official channel and auto-update enabled; consider scheduling auto-updates for low-impact hours.

Five APs total — three U6-Pro and two U6-LR, all on 802.11ax (WiFi 6). All five support WPA3 and PMF natively, which is why F-04 is recommended as a software-only change rather than a hardware refresh.

None at hardware level. At next AP refresh cycle, evaluate WiFi 6E / 7 APs (U7-Pro / U7-Pro Max) for 6 GHz support if client density rises significantly.

CyberSecure IPS is On, Detection Mode = Notify-and-Block, all categories selected. Region Blocking is enabled. Rogue DHCP Server Detection is On. Spanning Tree is RSTP. Single WAN is in Failover-Only mode. IPS signatures updated within the last 24 hours.

Maintain. These are appropriate defaults for this environment and represent meaningful active protection. Effectiveness improves further once F-01 / F-07 are addressed.

The controller's tracked-client list contains six locally-administered MAC addresses — the first hex digit's lower nibble indicates the U/L bit is set.⁶ All six are fingerprinted by the controller (DHCP option 55 / vendor class identifier / mDNS hostnames per RFC 2132⁸) as Apple devices.

None observed. The observed pattern is consistent with Apple's Private Wi-Fi Address feature, which generates a software-defined MAC for Wi-Fi networks; some configurations rotate it on a recurring basis, which produces 'new client' entries in the controller as the address changes.⁹

No action required for security. If the homeowner wants the client list to stop showing repeated 'new device' entries, the setting is per-network on each Apple device. See the companion article The mystery MACs on your UniFi network.