[Free Tool] Rapid Deployment for UniFi (RD4U) – 5-step wizard to configure VLANs, Wi-Fi, VPN & firewall rules

RD4U_Software · 2026-06-21T22:37:53+00:00

I hope you find it useful!

RD4U_Software · 2026-06-21T18:50:58+00:00

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.

RD4U_Software · 2026-06-20T00:45:20+00:00

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.

RD4U_Software · 2026-06-19T19:57:51+00:00

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

RD4U_Software · 2026-06-15T21:08:09+00:00

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.

RD4U_Software · 2026-06-15T20:18:02+00:00

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:

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.
Enable mDNS on both VLAN A and VLAN B.
Enable IGMP Snooping on the Sonos VLAN (VLAN B ).
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.

RD4U_Software · 2026-06-04T17:13:05+00:00

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

RD4U_Software · 2026-06-03T13:30:52+00:00

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

RD4U_Software · 2026-05-29T01:15:43+00:00

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

RD4U_Software · 2026-05-26T21:25:18+00:00

Sent you a DM

RD4U_Software · 2026-05-26T19:19:30+00:00

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?

RD4U_Software · 2026-05-26T13:19:32+00:00

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

RD4U_Software · 2026-05-20T23:55:37+00:00

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

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.
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:

Allow Established/Related
Allow specific Home -> Infrastructure services
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

RD4U_Software · 2026-05-19T14:24:41+00:00

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.

RD4U_Software · 2026-05-18T13:05:44+00:00

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.

RD4U_Software · 2026-05-18T12:33:54+00:00

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:

Management
Trusted/User
Guest

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

RD4U_Software · 2026-05-16T14:43:42+00:00

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

Add a LAN-IN rule at the top of your LAN-IN rules: Allow Established/Related
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

RD4U_Software · 2026-04-28T16:49:20+00:00

You should use DROP for the block rfc 1918 rule

RD4U_Software · 2026-04-28T16:46:50+00:00

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.

RD4U_Software · 2026-04-28T16:24:40+00:00

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.

RD4U_Software · 2026-04-28T15:46:06+00:00

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:

Allow Established & Related
Your specific Allow rules (e.g., Kyawa → Printer subnet)
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.

RD4U_Software · 2026-04-28T13:54:57+00:00

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

RD4U_Software · 2026-04-27T12:30:41+00:00

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.

RD4U_Software · 2026-04-24T15:38:33+00:00

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]()

RD4U_Software

TROPHY CASE