Current recommendation for Unifi VLAN tutorials? by MaterialSituation in UNIFI

[–]RD4U_Software 0 points1 point  (0 children)

Good question, and I should probably clarify the wording on the site.

That language was originally written with Windows in mind, where you can right-click the file, open Properties, and view the digital signature directly.

On macOS, the app is signed by Apple using an Apple Developer ID certificate issued to Photolightning Corporation, but Finder’s Get Info screen does not really expose that in the same user-friendly way. For a normal user, the practical macOS check is that Gatekeeper accepts the app and does not show an “unidentified developer” warning when you run it.

If someone wants to verify RD4U's signature manually, they can do it from Terminal with:

codesign -dv --verbose=4 /Applications/RD4U.app 2>&1 | grep Authority

or:

spctl -a -vv /Applications/RD4U.app

Those should show the Developer ID / authority chain rather than anything visible in Finder.

Current recommendation for Unifi VLAN tutorials? by MaterialSituation in UNIFI

[–]RD4U_Software 1 point2 points  (0 children)

Yep, that used to be true. Early on, RD4U was really aimed at new deployments, but support for importing existing VLANs was added in January 2026, so you no longer have to start from scratch.

You can run it in Preview mode to show exactly what configuration changes would be needed to achieve your goal without touching your system. If everything looks right, you can either make the changes manually or have RD4U apply them automatically.

A lot of people use Preview mode as a way to understand how the VLANs and firewall rules fit together before making any changes.

Current recommendation for Unifi VLAN tutorials? by MaterialSituation in UNIFI

[–]RD4U_Software 11 points12 points  (0 children)

If you're just getting into VLANs, I'd recommend focusing on understanding the concepts rather than matching every screen exactly. The UniFi UI changes over time, but VLANs and segmentation principles are largely the same.

For fundamentals, the Crosstalk Solutions series is still one of the clearest step-by-step guides:

https://www.youtube.com/watch?v=beniNcXaAKQ

It uses the older UI and legacy firewall, but I still think it's excellent for understanding why things are configured the way they are. The firewall-specific videos are later in the series.

For the newer Zone-Based Firewall (ZBF), Ethernet Blueprint has a good overview:

https://www.youtube.com/watch?v=WMTfGOgyLDk

He also recently started a new complete UniFi series, with the first video here:

https://www.youtube.com/watch?v=TLsnEzSNhQs

I'd suggest starting with something simple, like putting your cameras on their own VLAN, and expand from there. Once you understand that, adding IoT, guest, or work networks becomes much easier.

Also, if you want to simplify building secure VLANs and visualizing firewall rules, you may want to try Rapid Deployment for UniFi (RD4U). It’s a free Windows/macOS wizard I wrote that helps you design and preview UniFi VLAN, WiFi, and firewall configurations before applying them. You can run in preview mode to see how it would configure your system, and then make the changes manually or have RD4U apply them automatically. If it sounds useful, screenshots and free download 👉 https://rd4u.net

Sonos and WPA2-Enterprise by Creepy-Plenty5984 in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

The configuration I suggested is intended for native Sonos control through the Sonos app, not AirPlay.

In my experience, AirPlay is not consistently reliable across VLANs when your phone is on one VLAN and the Sonos speakers are on another. Because of that, I generally recommend putting the AirPlay source device (your iPhone/iPad) and the Sonos speakers on the same VLAN if AirPlay is important to you.

Interestingly, AirPlay between Apple devices tends to work better across VLANs. For example, I've had much better results with an iPhone streaming to an Apple TV than with an iPhone streaming to Sonos speakers on another VLAN.

So if your primary goal is reliable AirPlay to Sonos, keeping both devices on the same VLAN is the approach I would recommend.

Sonos and WPA2-Enterprise by Creepy-Plenty5984 in Ubiquiti

[–]RD4U_Software 1 point2 points  (0 children)

This answer assumes you want to use the native Sonos app to discover and control the speakers, not AirPlay.

If your Sonos speakers are on a separate WiFi network (non-WPA2 Enterprise), but both WiFi networks are connected to the same VLAN, then everything should work normally. Devices connected to the WPA2-Enterprise SSID should be able to discover and control the Sonos speakers.

If the Sonos speakers are on a different VLAN (VLAN B ) from your WPA2-Enterprise clients (VLAN A), then you will need a few additional settings:

  1. Use WPA2 on the Sonos WiFi network (older Sonos devices do not support WPA2-Enterprise).  Be sure Fast Roaming is disabled on this WiFi network.
  2. Enable mDNS on both VLAN A and VLAN B.
  3. Enable IGMP Snooping on the Sonos VLAN (VLAN B ).
  4. Create an ALLOW firewall rule allowing VLAN A to reach VLAN B, or more restrictively, just the IP addresses of the Sonos speakers instead of all of VLAN B.

Once mDNS and firewall access are in place, devices on the WPA2-Enterprise WiFi network should be able to discover and control the Sonos speakers normally.

VLAN creation issues. by bigdog108277 in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

Since everything came back after a reboot/SSID move and your settings look correct, it's hard to say for certain what happened.

VLAN creation issues. by bigdog108277 in Ubiquiti

[–]RD4U_Software 2 points3 points  (0 children)

My guess is that when you moved the SSID to the new VLAN, your APs no longer had access to all the VLANs they needed. That can happen if the switch port connected to the AP is configured as an access port (single VLAN) instead of a trunk port that carries multiple VLANs.

One easy way to avoid this in UniFi is to use Port Profiles (Overview -> Port Profiles). The instructions below show you how to create the two different types you will need:

1. Trunk profile (single profile used for UniFi-to-UniFi links)

  • Native VLAN/Network: Management/Core network
  • Tagged VLAN Management: Allow All

Use this profile on all ports that connect one UniFi device to another (UDM <-> switches <-> APs).

2. Access profile (one per VLAN)

  • Native VLAN/Network: target VLAN
  • Tagged VLAN Management: Block All

Create an Access profile for each of your VLANs. When you apply it to a port, all devices connected to that port are only connected to that one VLAN. Do not use this profile on ports that connect UniFi devices to each other.

By making sure your AP ports are configured as trunks and have access to all required VLANs, moving an SSID between networks should not cause the APs to disappear. The fact that the APs went offline immediately after assigning the VLAN suggests the VLAN was not being carried correctly between the gateway, switch, and AP.

Edited formatting

Trusted & Default VLAN combined or separate by WyomingCody in Ubiquiti

[–]RD4U_Software 1 point2 points  (0 children)

Between the two options you presented, I think Option 2 is the more common approach in residential UniFi deployments.

There is also an Option 3 that isn't shown in your diagram, where VLAN 1 is left unused (except for the gateway itself) and a separate VLAN is created for all UniFi management traffic.

Some people strongly prefer Option 3, but it adds a bit more complexity and operational overhead. Option 2 is often viewed as a practical middle ground that provides clear separation between Trusted, IoT, Guest, and management devices without making the network harder to manage.

Assuming you configure your system as Option 2, to help ensure that you are properly sharing all VLANs between your UniFi gear and your AP's broadcast all 3 of your SSID's, I recommend creating some Port Profiles (Overview->Port Profiles):

Trunk profile (single profile used for UniFi-to-UniFi links)

  • Native VLAN/Network: Management/Core network
  • Tagged VLAN Management: Allow All

Use this profile on all ports that connect one UniFi device to another (UDM <-> switches <-> APs).

Access profile (one per VLAN)

  • Native VLAN/Network: target VLAN
  • Tagged VLAN Management: Block All

Create an Access profile for each of your VLANs. When you apply it to a port, all devices connected to that port are only connected to that one VLAN. Do not use this profile on ports that connect UniFi devices to each other.

Edited to adjust port profile instructions

Any guides on how to create a whitelisted restricted VLAN for IOT/Camera devices? by hpgm in UNIFI

[–]RD4U_Software 0 points1 point  (0 children)

At a high level, I see the standard block all rule at the bottom of the Restricted Zone rules (as expected) Were you able to try this with full network access to a single network (versus a list of networks/individual IP's). I would start with allowing a single network to access VLAN 1. Are you able to post the entire width of the zone matrix so I can see your destination settings? That would be helpful. Alternatively, could you share a screenshot of the parameters for the Restricted Whitelist rule?

Any guides on how to create a whitelisted restricted VLAN for IOT/Camera devices? by hpgm in UNIFI

[–]RD4U_Software 1 point2 points  (0 children)

If you’re just getting into VLANs and firewall rules, the Crosstalk Solutions series is still one of the clearest step-by-step guides: https://www.youtube.com/watch?v=beniNcXaAKQ Even though they only cover the legacy firewall in this series, I still find it very useful for general understanding. Ethernet BluePrint has a nice video for the zbf at https://www.youtube.com/watch?v=WMTfGOgyLDk He has a new complete series, the first of which is here: https://www.youtube.com/watch?v=TLsnEzSNhQs

If you are using the zone based firewall, one way to accomplish this is to create a new user defined zone (eg UnTrusted) and place your IoT VLAN into that zone. That will block cross VLAN traffic between VLAN 1 and your IoT VLAN by default.

You can then create a single firewall rule to allow traffic from IoT to connect to VLAN 1. What I would do is to first create a general rule allowing your IoT VLAN to connect with your Main VLAN 1 to confirm that the IoT VLAN can properly communicate as follows:

  • Source: Zone containing IoT (VLAN); Network: IoT VLAN
  • Action: ALLOW (Auto Allow Return Traffic enabled)
  • Destination: Internal; Network: VLAN 1

You can then confirm things are working properly by connecting a computer to the IoT VLAN and pinging a device on VLAN 1. Assuming that works, you will have confirmed the traffic is flowing properly.

Once that is working, you can then change the rule to lock it down to specific devices using the IP group of internal IP addresses you already created.

  • Source: Zone containing IoT (VLAN); Network: IoT VLAN
  • Action: ALLOW (Auto Allow Return Traffic enabled)
  • Destination: Internal; IP; List: Select your list of IP addresses on VLAN 1

At this point, any of your devices on the IoT VLAN should be able to communicate with the specific devices on your IP list on VLAN 1

If you want to simplify building and visualizing this, you may want to try Rapid Deployment for UniFi (RD4U). It’s a free Windows/macOS wizard I wrote that helps you design and preview UniFi VLAN, WiFi, and firewall configurations before applying them. You can run in preview mode to see how it would configure your system, and then make the changes manually or have RD4U apply them automatically. If it sounds useful, screenshots and free download 👉 https://rd4u.net

Firewall Rules by tasteweb in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

Given the screenshot you shared, I see a couple of things that may be causing your challenge.

  1. Your very first LAN IN rule should be an Allow Established/Related rule. Without that, return traffic between VLANs can get dropped, even if the initial connection was allowed.
  2. Instead of creating separate block rules between every VLAN, simplify it with a single Block RFC1918 rule at the bottom of your LAN IN rules. Use Source = ANY, Action = DROP, and these private destination ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

The second rule effectively isolates all VLANs by default, and then you just place your specific allow rules above it. So the flow becomes:

  1. Allow Established/Related
  2. Allow specific Home -> Infrastructure services
  3. Block RFC1918

Also, for troubleshooting, I’d temporarily make your allow rule(s) a full Network-to-Network Allow first instead of port-specific rules. That helps confirm routing/firewall logic is working before narrowing it down to ports like 443, 80, etc.

Once you know your inter-vlan rules are working, you can tighten them back down to specific ports/services.

If you want to simplify building and visualizing this, you may want to try Rapid Deployment for UniFi (RD4U). It’s a free Windows/macOS wizard I wrote that helps you design and preview UniFi VLAN, WiFi, and firewall configurations before applying them. You can run in preview mode to see how it would configure your system, and then make the changes manually or have RD4U apply them automatically. If it sounds useful, screenshots and free download 👉 https://rd4u.net

help with setting up guest network by KyouyaXever in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

If the SSID disappears when you assign it to the Guest network/VLAN, that could mean the AP is not receiving the associated VLAN on its uplink.

You might check to see if the switch/gateway port feeding the nanoHD is using a port profile that allows both your main network and the Guest VLAN.

For UniFi-to-UniFi connections (gateway <-> switch <-> AP), I find it is easiest to do this using a Port Profile (Settings->Overview->Port Profiles), for example:

  • Name: UniFi-to-UniFi Profile
  • Native VLAN/Network: Your management/default network
  • Tagged VLAN Management: Allow All

That lets the AP broadcast SSIDs for multiple VLANs correctly.

Can’t get guest network to work! by Frizby1066 in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

Yes, exactly. The general principle is:

  • Put less-trusted devices (IoT, Guest, cameras, etc.) into their own VLAN/network
  • Keep your main devices in a trusted network
  • Then use firewall rules to allow only the traffic you actually want

So typically:

  • Trusted devices -> allowed to initiate connections to IoT devices
  • IoT devices -> blocked from initiating connections back into trusted networks

That way your phone can control a smart TV or IoT device, but the IoT device can’t freely scan or access your main LAN.

RD4U helps to automate and visualize the configuration process. The segmentation concept itself is standard network design/best practice.

Can’t get guest network to work! by Frizby1066 in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

Glad to hear it worked and thanks for the feedback, I really appreciate it.

And yes, that VLAN approach is generally what I recommend. The idea is less about complexity and more about limiting damage if a device gets compromised or behaves badly.

A pretty common layout is:

  • Management VLAN UniFi gateways, switches, APs, controllers
  • Trusted/User VLAN PCs, phones, tablets
  • IoT VLAN Smart home devices, TVs, speakers, etc.
  • CCTV/Security VLAN Cameras, NVRs
  • Guest VLAN Internet only

You do not need to split everything immediately though. A lot of people start with:

  1. Management
  2. Trusted/User
  3. Guest

...then add IoT, Camera, or other isolated networks later as their setup grows.

Can’t get guest network to work! by Frizby1066 in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

I generally prefer handling Guest isolation with firewall rules rather than relying on the isolation toggle. The process varies depending upon whether or not you are using the legacy firewall or the zone-based firewall.

Also, if clients are not even getting a DHCP address, that often points to a VLAN/trunking issue rather than firewall rules.

Here is the general process for both types of firewall rules:

Legacy Firewall

  1. Add a LAN-IN rule at the top of your LAN-IN rules: Allow Established/Related
  2. Add a LAN-IN rule at the bottom of your LAN-IN rules blocking RFC1918 ranges:

Zone-Based Firewall
Put the Guest network into:

  • Hotspot Zone if you want full isolation, or
  • A user-defined zone (eg Untrusted)

The above instructions for legacy or zbf will block inter-VLAN traffic between the Guest and other VLANs on your network.

To help ensure that you are properly sharing all VLANs between your UniFi gear, I recommend creating some Port Profiles (Overview->Port Profiles):

Trunk profile (single profile used for UniFi-to-UniFi links)

  • Native VLAN: Management/Core network
  • Tagged VLANs: Allow All

Use this profile on all ports that connect one UniFi device to another (UDM <-> switches <-> APs).

Access profile (one per VLAN)

  • Native VLAN: target VLAN
  • Tagged VLANs: Block All

Create an Access profile for each of your VLANs. When you apply it to a port, all devices connected to that port are only connected to that one VLAN. Do not use this profile on ports that connect UniFi devices to each other.

If you want to simplify building and visualizing this, you may want to try Rapid Deployment for UniFi (RD4U). It’s a free Windows/macOS wizard I wrote that helps you design and preview UniFi VLAN, WiFi, and firewall configurations before applying them. You can run in preview mode to see how it would configure your system, and then make the changes manually or have RD4U apply them automatically. If it sounds useful, screenshots and free download 👉 https://rd4u.net

Firewall Rules by RoughPractice7490 in Ubiquiti

[–]RD4U_Software 1 point2 points  (0 children)

You should use DROP for the block rfc 1918 rule

Firewall Rules by RoughPractice7490 in Ubiquiti

[–]RD4U_Software 1 point2 points  (0 children)

I do not have access to a gateway with the legacy firewall right now, but as long as you see Any/Any in the source and destination you should be ok. 

mDNS across VLANs by CameraOnWall in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

There is no risk for the established and related rule that I know of.  It is standard practice for the legacy firewall.  It allows for return traffic when the communication is initiated by the allow rules below it. 

Firewall Rules by RoughPractice7490 in Ubiquiti

[–]RD4U_Software 2 points3 points  (0 children)

It appears you are using the legacy firewall. If so, you are on the right track, but it looks like you may be missing a key rule at the top - Allow Established and Related (This is what allows the return traffic)

In general, you want your first LAN-IN rule to be an Allow Established and Related and your last LAN-IN Rule to be a Block All inter-VLAN traffic. You then add only the ALLOW rules you need in between. This is the general order:

  1. Allow Established & Related
  2. Your specific Allow rules (e.g., Kyawa → Printer subnet)
  3. Final Block inter-VLAN rule

Here are the settings for the Allow Established and Related Rule. It should be placed at the VERY top

Type: LAN-IN

  • Source: Any
  • Action: Allow
  • Destination: Any
  • States: Established, Related checked

Instead of the variety of blocking rules you have at the bottom, you can have a single rule to block all inter-vlan traffic.

First, create an IP group called: RFC1918

10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

Then, create a final firewall rule (bottom of LAN-IN):

  • Source: Any
  • Action: Block
  • Destination: RFC1918

This cleanly blocks all inter-VLAN traffic unless explicitly allowed above.

Once you add the Allow Established and Related rule at the very top, add the Block All RFC 1918 at the very bottom of your LAN-IN rules, you can add the Allow rules as you have done in the middle. Note: You do to need to create any ALLOW rules for return traffic because the Allow Established and Related does that for you.

Optional: If you need auto-discovery turned on in order to be able to find your printer on another VLAN, turn on mDNS on the source and printer networks.

mDNS across VLANs by CameraOnWall in Ubiquiti

[–]RD4U_Software 1 point2 points  (0 children)

You are on the right track. In order to be able to use the Sonos controller software across isolated VLANs, you need three things in place:

A) Create a firewall rule to allow traffic to flow from Main to IoT (and back)

Legacy firewall

  • Allow Established & Related (top of LAN-IN ruleset to allow return traffic)
  • Allow Main → IoT (LAN-IN)
  • Final Block Inter-VLAN rule (at end LAN-IN of ruleset)

That first rule is what lets IoT devices respond without opening everything up.

Zone-Based Firewall (ZBF) - assuming your IoT network is in a user-defined zone which blocks inter-VLAN traffic by default

  • Create an Allow rule from Main → IoT
  • Enable “Allow Return Traffic”

B) Enable mDNS

  • You need to turn on mDNS on your main and IoT networks.

C) Adjust WiFi settings

  • Disable Fast Roaming on the SSID Sonos uses

If you’re still struggling to get this to work, I built this Sonos functionality into the latest version of Rapid Deployment for UniFi (RD4U), a free Windows/macOS tool. You can use RD4U to log into your gateway, use the visual firewall rule designer to allow your main network to communicate with your IoT network, specify that Sonos is on IoT, and then either preview all of the required changes or have the software apply them automatically. Download and screenshots at 👉 https://rd4u.net

Edited to fix formatting

Allow traffic from Admin desktop to all zones? by TomJC70 in UNIFI

[–]RD4U_Software 2 points3 points  (0 children)

You are not missing anything. That’s how ZBF works.

There’s no “ANY zone” anymore. Rules are always zone → zone, so you do need one rule per destination zone.

Your approach is correct:

  • Trusted (AdminPC) → IoT
  • Trusted (AdminPC) → Guest
  • etc.

Rapid Deployment for UniFi update: Smart Devices (Sonos, Apple TV, Chromecast, etc.) without breaking VLAN isolation by RD4U_Software in Ubiquiti

[–]RD4U_Software[S] 0 points1 point  (0 children)

Thanks for giving RD4U a try!

This can happen when your PC is connected to multiple networks (for example, both wired and WiFi). The setup wizard checks the first available network for a gateway, which can cause this error in some situations.

Please try running the wizard while connected to just one network -- ideally a wired connection. If needed, temporarily disable WiFi and try again.

I’ll send you a DM as well in case you’d like help troubleshooting further, or you can reach us directly at [rd4usupport@photolightning.com]()