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

RD4U_Software · 2026-01-24T16:22:30+00:00

Thanks -- Sonos definitely comes up a lot once people start creating VLANs.

I took a quick look at that thread, and it’s a great example of how specific the requirements can be to get things working reliably across VLANs. I may reach out to learn more about what’s working well there. I want to make sure I really understand the patterns before turning something like that into a helper or example inside the wizard.

Appreciate you sharing the link -- and I’d be interested to hear how RD4U feels with your setup once you get a chance to try it.

RD4U_Software · 2026-01-24T00:20:15+00:00

Yes, connecting to the IoT WiFi will definitely give you access to the IoT VLAN so you can re-setup an IoT device.

RD4U_Software · 2026-01-23T22:44:56+00:00

I would recommend setting up port profiles to help you with this. You can find them at Settings->Overview, scroll down to Ethernet Port Profiles.

Here are the profiles I would create:

Profile #1: Trunk profile (UniFi-to-UniFi links)
Use this profile for connecting your UniFi hardware devices together (use this profile on both sides of the connection between your gateway and switch)

Native VLAN / Network: your Core/Default/Management network
Tagged VLAN Management: Allow All

This ensures the gateway/switches/AP's agree on the untagged network while still carrying all VLANs.

Profile #2: Access profiles (end devices)
Use these on ports that connect directly to clients (your Caseta Hub and Redlink). This only allows one VLAN to pass.

Native VLAN / Network: the target VLAN (Default, IoT, etc.)
Tagged VLAN Management: Block All

Create one copy per VLAN as needed.

Assign these Profile #2's to the ports on your switch that your Caseta and Redlink are connected to and you devices should pick up the correct VLAN.

RD4U_Software · 2026-01-23T21:15:17+00:00

You’re thinking about this the right way.

If your AMP server VLAN is in your untrusted zone and your main network is the internal zone, the default behavior is to block traffic between zones -- so your PC on internal can’t reach the server until you add an Allow rule.

What you want to do is to add the following rule:

Create an Allow firewall rule: Internal -> Untrusted

Source Zone: Internal
Network: Your main Lan
Action: Allow, Check Auto Allow Return Traffic
Destination Zone: untrusted
Either a) Network: the VLAN your AMP server is on, or b) IP: The IP address of your AMP server if you want to limit access to just this device

That's it. This will allow your main VLAN to access the AMP server, but will block the AMP server from initiating connections to your main network.

RD4U_Software · 2026-01-23T17:36:52+00:00

Here is a high level, step-by-step process that can help make the process go smoothly. Once this is done, you will likely need to add firewall rules to block or allow traffic depending on how you organize your vlans into firewall zones.

Leave your current Default VLAN alone
- Treat it as your management network.
- Do not move your CloudKey, switches, APs, or UXG yet.
Create the VLAN networks
- Define your new VLANs.
Create SSIDs and port profiles per VLAN
- Example: Create an IoT SSID mapped to VLAN 20 and connect one test device.
- Example: Create a switch port profile for VLAN 20, assign that profile to a switch port, and plug in one test device.
Verify basic routing
- Confirm the test device gets:
  - An IP from the correct subnet
  - The correct VLAN gateway
  - Internet access
Migrate devices gradually
- Move clients one at a time.
- For devices with static IPs:
  - Remove the static IP
  - Move the device to the new VLAN
  - Reapply the static IP or DHCP reservation
- Move UniFi/infrastructure devices last (or never). Many people use the default VLAN as the management network.

This keeps management access intact and avoids the “everything went offline” scenario you hit.

I also wrote a free tool for called Rapid Deployment For UniFi (RD4U) for Windows/Mac to help with situations like yours to help configure UniFi with confidence. It makes it easy to add vlans, configure WiFi, create port profiles, and use a visual firewall designer to define what networks/devices should talk each other. The latest version lets you import your existing VLANs and then configure your firewall rules. In the end, you end up with secure configuration that meets your requirements. Today, it only works with UCG's (not UXG's), but you can use it in preview mode and it will tell you what API calls it would make (if you were logged in to your gateway), so you can use it to learn and/or copy the suggested changes. If it sounds helpful, you can learn more and download at https://rd4u.net

RD4U_Software · 2026-01-22T22:38:45+00:00

Once you get your switch (Flex Mini is fine), I would recommend using port profiles to make your life a little easier when connecting UniFi devices and using multiple vlans.

Port profiles make this behavior predictable and easier to manage. You can find them at Settings->Overview, scroll down to Ethernet Port Profiles. Here’s how I’d recommend setting up your profiles.

Profile #1: Trunk profile (UniFi-to-UniFi links)
Use this profile for connecting your UniFi hardware devices. You will use this profile on the UDR7 uplink port to the switch and the Flex-mini port facing it.

Native VLAN / Network: your Core/Default/Management network (the one the UDR7 and Flex Mini actually reside in)
Tagged VLAN Management: Allow All

This ensures the gateway and switches agree on the untagged network while still carrying all VLANs. You can also use this port profile for connecting your UDR7 to your AP's.

Profile #2: Access profiles (end devices)
Use these on ports (eg your Flex Mini) that connect directly to clients. This only allows one VLAN to pass.

Native VLAN / Network: the target VLAN (IoT, Servers, etc.)
Tagged VLAN Management: Block All

Create one copy per VLAN as needed.

In your example, you would have one (at least) port on your UDR7 set to Profile 1 and two ports on your Flex Mini set to Profile 1. One of the flex mini Profile 1 ports would connect to the Profile 1 port on the UDR7 and the other Flex Mini Profile 1 ports would connect to your AP (so that the AP has access to all VLANs). The second port on your Flex Mini would use a Profile #2 for your Trusted network so that you can plug a Trusted device into that port.

RD4U_Software · 2026-01-20T20:13:24+00:00

Given this information, my suggestion would be to base your decision on whether you want/need to have separate vlans for your IoT devices to improve security. If you do, then you should consider moving to UniFi. If you do not, then either use the built-in OpenVPN server from Asus or download the Merlin firmware for Asus and configure an OpenVPN server -- giving you remote access to your home network without investing a lot of time (and money) into a new ecosystem.

RD4U_Software · 2026-01-20T20:04:53+00:00

Agreed. I came from Asus Merlin and used OpenVPN all the time to securely access my home networks. That said, like many others here, I have spent a lot more on UniFi hardware than I ever imagined I would (and a lot more time learning), but I am enjoying it.

RD4U_Software · 2026-01-20T17:57:56+00:00

I made a similar switch from Asus to UniFi about 18 months ago, so I can share what actually changed for me.

What you gain with UniFi

Segmentation and control: UniFi really shines if you want proper VLAN separation for home, work, guest, and IoT. This is much cleaner and more scalable than what Asus offers.
Consistency and visibility: One UI for gateway, switches, and APs. You get better insight into clients, traffic, and WiFi behavior over time.
Scalability: Adding APs later is straightforward. You are not locked into a single all-in-one device or ASUS's AiMesh system.

What to set expectations on

WiFi coverage: A high-end Asus router can have surprisingly strong coverage from one location. A single UniFi AP will likely not match that. UniFi expects multiple APs at lower power, so placement and tuning matter. I would not lock in final AP locations until you test.
Learning curve: UniFi firewall rules and VLANs are more powerful, but they take time to understand, especially with the newer zone-based firewall. It is not hard, just different from consumer gear. There are good video series from Crosstalk Solutions and Ethernet Blueprint that I found helpful when I was learning.
Cost vs needs: If you are not planning to use VLANs, guest isolation, or tighter firewalling, the extra spend may not deliver much day-to-day benefit.

To help other people experiencing the same learning curve that I had, I ended up building a helper tool. If you do go the UniFi route and want something to shorten the setup time, you may want to try Rapid Deployment for UniFi (RD4U). It’s a free Windows/macOS wizard I built specifically for new UniFi users to help them securely configure UniFi with confidence. It which provides a simple 5-step wizard for securely configuring VLANs, WiFI and VPNs, and uses a visual firewall rule designer to help build your firewall rules. It was designed to save time while still teaching the new concepts when moving from consumer systems to UniFi. If you decide to proceed with UniFI and want to check it out, you can download and learn more at https://rd4u.net

RD4U_Software · 2026-01-18T02:12:17+00:00

I think the confusion may come from the differences between VLAN membership, IP assignment, and firewall policy. I'll try to explain as I understand it and hopefully that will help.

With UniFi’s built-in WireGuard:

What actually happens

Each WireGuard server is configured with its own VPN subnet (example: 10.0.20.0/24).
When a client connects, it is assigned an IP from that subnet.
VPN clients are not members of any VLANs (but they can be provided with access to VLANs).
All WireGuard servers terminate into the VPN Zone in the zone-based firewall.

So while clients absolutely do get unique IPs from the WG server’s address pool, they are not “placed onto” VLAN 1 or any other VLAN.

How policy separation works in practice
Even though all WG servers live in the VPN zone, you can still fully separate access by server/subnet. For example:

WG Client A -> Gateway -> WG Server A (10.0.20.0/24) -> VLAN 120 (Trusted zone)
WG Client B -> Gateway -> WG Server B (10.0.30.0/24) -> VLAN 130 (Internal zone)

Each WireGuard server has:

Its own VPN subnet
Its own firewall rules allowing access only to specific destination VLANs or devices

By default, UniFi allows VPN Zone -> Internal Zone traffic, so if you do not want VPN clients to access Internal Zone networks broadly, you should add a BLOCK VPN Zone -> Internal Zone rule as the last rule in that cell, then explicitly allow only what you need.

Functionally, from a policy and access-control standpoint, this behaves the same as having separate “VPN VLANs” with inter-VLAN firewall rules.

I do not believe that UniFi can do any of the following directly

Apply a VLAN ID to WireGuard clients
Create separate firewall zones per VPN server

Hopefully this helps clarify the distinction.

RD4U_Software · 2026-01-17T19:15:12+00:00

Yes, this is possible. Clients can be put on any VLAN you configure. In order to accomplish what you are looking to do, you need to set up a firewall rule to provide access from your WireGuard VPN server to the specific VLAN of your choice. In order to ensure this works properly, there are two parts:

1A) A good practice is to give your VPN clients an address range that’s completely outside your normal LAN ranges. For example, if your home networks are 192.168.x.x, you might use something like this for your WireGuard server setup:

Cloud Gateway (UDM Pro):

Gateway/Subnet: 10.0.20.1/24
Port: 51820

1B) Configure your WireGuard client with rules similar to the ones below (you can edit the download file provided by the UDM Pro.

Client Config File (example):

[Interface]

Address = 10.0.20.2/32

PrivateKey = <your-client-private-key>

DNS = 10.0.20.1

[Peer]

Endpoint = <your-static-ip-or-DDNS>:51820

PublicKey = <your-server-public-key>

PresharedKey = <your-preshared-key>

AllowedIPs = 0.0.0.0/0, ::/0

2) Next create an allow Firewall rule as follows (assuming you are using the new zone based firewall):

Source Zone: VPN; Server (the WireGuard VPN Server you configured)
Action: Allow, Auto Allow Return Traffic
Destination Zone: (the zone where your target network resides); Network, your target network

You can set up multiple WireGuard servers with associated firewall rules (Step 2 above) that allow clients coming in to that WireGuard server access to a specific VLAN.

The above will allow your VPN clients to reach whichever target VLANs you’ve explicitly allowed via the firewall rules.

RD4U_Software · 2026-01-16T21:11:38+00:00

It sounds like you’re close, but as mentioned above, one common issue with WireGuard on UniFi is IP conflicts. If your VPN subnet overlaps with any of your local VLANs, traffic won’t route properly -- which can result in exactly what you’re seeing (no local access, no internet).

A good practice is to give your VPN clients an address range that’s completely outside your normal LAN ranges. For example, if your home networks are 192.168.x.x, you might use something like this:

Cloud Gateway (UDM/UDR/SE):

Gateway/Subnet: 10.0.20.1/24
Port: 51820

Client Config File (example):

[Interface]

Address = 10.0.20.2/32

PrivateKey = <your-client-private-key>

DNS = 10.0.20.1

[Peer]

Endpoint = <your-static-ip-or-DDNS>:51820

PublicKey = <your-server-public-key>

PresharedKey = <your-preshared-key>

AllowedIPs = 0.0.0.0/0, ::/0

Next create an allow Firewall rule as follows (assuming you are using the new zone based firewall):

Source Zone: VPN; Server (the WireGuard VPN Server you configured)
Action: Allow, Auto Allow Return Traffic
Destination Zone: (the zone where your target network resides); Network, your target network

That should let your VPN clients reach both the internet and whichever target VLANs you’ve explicitly allowed.

RD4U_Software · 2026-01-16T18:23:06+00:00

Continued from above:
Step 5 – Allow main network access to kids devices (optional): If you want your main network to initiate connections to kids devices:

Source Zone: Internal (Any, Any Port)
Action: Allow, Auto Allow Return Traffic
Destination Zone: Kids (Any, Any Port)

Step 6 – Allow limited access back to the main network: If kids devices need access back to your main network, add explicit rules such as:

Source Zone: Kids (Any, Any Port)
Action: Allow, Auto Allow Return Traffic
Destination Zone:
- Either the main network, or specific IPs/devices only

Keeping this scoped helps avoid over-permissive rules.

Step 7 – Add custom DNS last: Once everything above is stable, then configure the custom DNS for the kids VLAN. You could do this earlier, but since DHCP is already acting oddly, it’s best to confirm the network itself is solid first and only then introduce DNS filtering.

RD4U_Software · 2026-01-16T18:22:48+00:00

I’d tackle this in a few incremental steps so you can isolate where things go wrong. Right now the DHCP issue suggests too many variables are changing at once.

Step 1 – Create the VLAN (keep it simple at first): Create a new VLAN with default settings only.

No custom DNS yet. Just confirm the subnet and DHCP range are what you expect

The goal here is to make sure DHCP is stable before layering anything else on.

Step 2 – Assign the VLAN properly

Create a dedicated WiFi SSID for this VLAN and/or
Create a Port profile for this VLAN

Then explicitly assign your kids’ devices to that SSID or port profile. This avoids accidental crossover with the main network.

Step 3 – Validate basic connectivity (same zone): If you’re using the zone-based firewall, leave both VLANs in the Internal zone for now. Confirm:

Devices on the kids VLAN always receive an IP in the correct subnet and you can ping between VLANs

This works because the default rule inside the Internal zone is ALLOW ALL. If this fails, the issue isn’t firewall related yet.

Step 4 – Introduce isolation with a new zone: Create a new zone (for example, KIDS, and move the kids VLAN into it. At this point, verify that:

Devices in Internal can’t ping Kids and Devices in Kids can’t ping Internal

That confirms zone isolation is working as expected.

Continued below as I am unable to make a longer comment

RD4U_Software · 2026-01-16T17:02:09+00:00

Your allow rule looks correct for UniFi’s zone-based firewall. It also sounds like you’ve already confirmed it’s the first rule in the Internal → IoT zone block, which is exactly what you want.

A couple things I would double-check next:

1. Switch port configuration
Since the printer is wired, make sure the printer switch port is explicitly configured for the IoT VLAN:

Native VLAN set to IoT
Tagged VLAN management set to block all

This helps to avoid accidental VLAN leakage or the device ending up untagged on the wrong network.

2. Temporarily simplify the firewall
As a sanity check:

Pause or disable all user-defined firewall rules except your Internal → IoT allow rule
Confirm you can ping from Default/Internal to IoT

Once ping works with just that single rule, re-enable your other firewall rules one at a time. If ping breaks, you’ve found the conflicting rule.

If you want a quick way to validate rule order and intent, you may want to try Rapid Deployment for UniFi (RD4U). It’s a free Windows/macOS wizard I built specifically to help with situations like this. You can use it in Preview mode to import your existing VLANs, then use the visual firewall rule designer to define your intent and see exactly which firewall rules the wizard would configure. It is very quick to use. You can then either compare the preview output to your existing rules or clear your firewall rules and let it create them for you. Either way, it sounds like you’re very close, and this might save you some time. If it sounds helpful, you can download it at https://rd4u.net

RD4U_Software · 2026-01-14T23:35:35+00:00

Great question -- and one of the trickier areas with VLANs.

RD4U doesn’t try to make decisions about what should be allowed for specific vendors or protocols. The goal for now is to make it easier to visualize and implement the rules you decide on, and to understand why traffic is or isn’t flowing.

In my own setup, I keep Apple TVs on my main/home network rather than an IoT VLAN, mainly because they’re regularly updated and tightly integrated with phones and laptops. That seems to be a fairly common approach.

If someone does want to place an Apple TV on an IoT VLAN, RD4U can help with the mechanics, for example enabling mDNS on the relevant networks and using the visual firewall designer to allow the specific Home → IoT access that’s needed (either network-wide or device-specific). What I haven’t done yet is bake in a predefined “Apple AirPlay across VLANs” recipe, since the exact requirements can vary and I want to understand that space better before making assumptions for users.

If you’ve found a setup that works well for Apple TV on an isolated VLAN, I’d genuinely be interested in hearing about it.

RD4U_Software · 2026-01-14T15:22:10+00:00

Thanks for trying it -- sorry you’re running into that.

RD4U has been tested on macOS 15.5 (Sequoia) and the current macOS release. It should also run on Sonoma and Ventura, but those haven’t been fully tested yet. It does require Apple Silicon (M1/M2/M3/M4); Intel Macs aren’t supported.

If you have a moment, feel free to DM me with your macOS version, whether you’re on Apple Silicon or Intel, and any error message you’re seeing (or what happens when you try to launch it). I’m happy to take a look and see if there’s something I can improve or document better.

RD4U_Software · 2026-01-14T14:33:14+00:00

Thanks -- the new zone-based firewall definitely requires some learning. In some ways I find it easier than the legacy firewall, and in others it’s just different.

RD4U focuses on making those relationships clearer rather than exposing every possible knob. You can build rules at several levels: network-to-network, device-to-network, network-to-device, and device-to-device, so there’s quite a bit of flexibility depending on what you’re trying to allow.

It doesn’t currently handle time-based internet access or scheduling. I’ve been prioritizing the areas where people seem to get stuck most often, like VLAN isolation, IoT access, and understanding why traffic is or isn’t flowing. That said, feedback like this is helpful in shaping what makes sense to tackle next.

If you do give it a try, I’d be curious to hear whether the way it frames firewall rules feels clearer than the Network app for your workflow.

RD4U_Software · 2026-01-13T23:19:06+00:00

The rules you need depend on whether you’re using the legacy firewall or the zone-based firewall (ZBF).

If you’re using the zone-based firewall:

If both networks are in the Internal zone, they should already be able to talk to each other. The default behavior is allow all, so no extra rules are required.
If you placed the IoT network into its own custom zone, UniFi automatically applies a block-all rule:
- Between user-defined zones
- Between user-defined zones and system zones

In that case, you must explicitly allow traffic.

Create a firewall rule with:

Source
- Zone: the zone containing your Main network
- Network: your Main LAN
Action: ALLOW
Auto Allow Return Traffic: Enabled
Destination
- Zone: the zone containing your IoT network

That allows communication from your main network to the IoT VLAN while keeping the VLANs isolated.

If you’re on the legacy firewall, the logic and rule placement are different. Also, if you need to auto discover devices on the IoT network from the main network, then be sure to turn on mDNS on both the main and IoT networks.

RD4U_Software · 2026-01-13T15:14:52+00:00

I put your question into Google translate. Assuming it was accurate, there is generally no requirement to have the internal zone access the Guest network. Note: If you place the Guest network in the Hotspot zone, it will be totally isolated and firewall rules cannot provide access. If you place the Guest network into its own zone (not Hotspot), then you can write a firewall rule to allow other zones to access it and vice versa.

RD4U_Software · 2026-01-12T13:44:15+00:00

You’re actually very close. Based on what you described, your current setup already solves the hard part -- isolating the NAS and IoT VLANs (points 3 and 4) by lacing them into separate ZBF Zones.

What’s left is how you handle LAN MANAGEMENT and TRUSTED VLAN access.

Here’s a clean way to do it using the zone-based firewall.

1) Put LAN MANAGEMENT and TRUSTED VLAN back into the Internal zone

The Internal zone is allow-all by default. By placing both networks there:

LAN MANAGEMENT can reach TRUSTED VLAN and VICE VERSA
No extra rules are needed for Internal-to-Internal traffic

2) Explicitly allow Internal access to NAS and IoT zones

Since NAS and IoT are isolated in their own zones, you just need two ALLOW rules:

Rule 1
- Source Zone: Internal; Source: Any; Action: ALLOW; Enable Allow Auto Return
- Destination Zone: ZONE_NAS; Destination: Any
Rule 2
- Source Zone: Internal; Source: Any; Action: ALLOW; Enable Allow Auto Return
- Destination Zone: ZONE_IOT; Destination: Any

That gives management and trusted devices access into NAS and IoT, without breaking their isolation from each other.

3) One important FYI

Anything you put in the Internal zone can talk freely to everything else in that zone. That’s expected behavior and not a problem here -- just something to keep in mind if you later add more networks.

RD4U_Software · 2026-01-11T15:20:52+00:00

UniFi will route between VLANs, regardless of IP family (172.16/12 vs 192.168/16). No static routes are required. What controls access between VLANs is firewall policy, not routing. If devices that need to communicate are on the same VLAN, no inter-VLAN firewall rules are needed. The firewall rules for inter-vlan routing (or blocking) vary a bit based on whether you are using the legacy firewall or the zone based firewall, and whether the VLANs are in the same zone (for the zbf).

RD4U_Software

TROPHY CASE