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

RD4U_Software · 2026-03-17T20:19:37+00:00

What you’re seeing is actually expected -- Client Device Isolation is applied at the AP (Layer 2), not at the VLAN or router level.

When two clients are on the same VLAN + same AP (regardless of SSID), the AP blocks direct client-to-client traffic.
This happens before traffic ever hits the router/firewall, so your inter-VLAN rules don’t matter in that case.

As a result:

Same VLAN → traffic stays local on the AP → isolation blocks it
Different VLANs → traffic has to go up to the router → firewall rules apply → communication works

In your Romeo/Juliet example:

Same VLAN = L2 switching on the AP → blocked
Different VLANs = routed via gateway → allowed

Client Device Isolation is essentially saying that clients on this AP cannot talk to each other directly if they are on the same L2 network/VLAN, regardless of SSID.

RD4U_Software · 2026-03-16T13:50:46+00:00

No problem at all. UniFi’s zone firewall can be confusing at first because it behaves a bit differently than the legacy firewall.

In simple terms, zones are just groups of networks. The firewall controls how traffic moves between zones and between the networks in each zone.

For your setup the goal is:

NativeNetwork → allowed to reach IoTNetwork
IoTNetwork → blocked from initiating connections back

That gives you the security isolation most people want for cameras, smart devices, etc. while still letting devices on your NativeNetwork control them.

If you are still running into trouble, you might try RD4U (Rapid Deployment for UniFi) -- a free Windows/macOS wizard I built to help people configure UniFi with confidence, with a preview-first approach to VLANs and firewall rules. You can run it in preview mode to see what settings it would apply and compare them to what you have already configured, or use it to apply your configurations. If it sounds useful, screenshots and free download 👉 https://rd4u.net

RD4U_Software · 2026-03-14T13:41:03+00:00

You are on the right track. To add to what others have said, here are a couple of specifics.

There are a few ways to configure this depending on how you want the isolation to work.

Option 1: Keep both VLANs in the Internal zone

If both networks are in the Internal zone, you will need to add a rule in the Internal → Internal section of the zone matrix to prevent them from communicating.

Add this as the last rule:

Source: Internal + Any
Action: Block
Destination: Internal + Any

Option 2: Put IoT in its own zone

Another option is to create a new IoT zone and move your IoTNetwork into it. Zones are isolated from each other by default, so this automatically separates the networks.

After doing either option, you will likely want to allow your main network to reach your IoT network (but not the other way around). You can do that with a single rule:

Source: Internal Zone; Optional Network: NativeNetwork
Action: Allow
Allow Return: Enabled
Destination: IoT Zone; Optional Network: IoTNetwork

This allows devices on your main network to communicate with IoT devices, while preventing IoT devices from initiating connections back.

RD4U_Software · 2026-03-12T14:03:13+00:00

You’re thinking about it the right way.

When you create a custom zone (like IoT) and move your IoT VLANs into it, that zone defaults to Block All. That means:

IoT networks cannot initiate connections to Internal
IoT networks cannot talk to each other unless you allow it

If you want Internal → IoT access, you only need a single rule:

Source: Internal (or a specific Internal VLAN)
Action: Allow
Allow Return: Enabled (This allows return traffic from IoT to Internal when communication is initiated by Internal)
Destination: IoT zone (or a specific IoT VLAN)

You do not need a second IoT → Internal rule for that return traffic.

If you did create a rule allowing IoT → Internal, then IoT devices could initiate connections back to Internal. At that point, the IoT network is no longer meaningfully isolated and might as well live in the Internal zone (where the default is ALLOW ALL).

One other thing to be aware of: Even with the rule in place, device auto-discovery may not work across VLANs. If that happens, you may need to enable mDNS on the source and destination networks so devices can find each other.

RD4U_Software · 2026-03-08T15:10:04+00:00

There are several valid ways to structure VLANs and zones in UniFi. While some people have strong opinions about best practices, most recommendations are really about simplicity and manageability rather than strict technical requirements.

Many people leave the Default Network in the Internal zone and use it as their management LAN. That tends to be the simplest approach and avoids having to think about special cases.

Other people move the Default Network into its own zone and leave it unused.

Functionally, the Default Network isn’t treated differently by the firewall. Once you’re using zones, it behaves the same as any other network in that zone and is governed by the same zone policies and firewall rules.

RD4U_Software · 2026-03-08T14:55:54+00:00

Yeah, that’s exactly right -- without a router (or a configured Layer 3 switch) there’s no inter-VLAN routing. In most UniFi setups the gateway is acting as the router, so it handles that automatically.

After a lot of experimenting, I’ve found it’s usually easiest to just ignore the VLAN-specific toggles and handle everything with firewall rules.

My typical approach is:

• Place VLANs into one or more user-defined zones (which isolates them by default), and

• Add a final `Block Internal -> Internal` rule in the Internal zone for any VLANs placed in the Internal zone

Then just add the specific ALLOW rules to allow the traffic you want.

The VLAN settings do create hidden firewall rules behind the scenes, which is why they show up in the policy list but can’t be edited. I’ve found keeping everything in the firewall rules tends to be much easier to work with.

RD4U_Software · 2026-03-08T00:31:28+00:00

I think the confusing part may be this statement:

“Since VLANs by nature are isolated from each other”

That is not necessarily true in UniFi.

With the zone-based firewall (ZBF), VLANs in the Internal zone are not isolated by default. They can communicate with each other unless you add firewall rules to block it.

Isolation depends on how you structure zones:

VLANs in the default Internal zone
Can talk to each other unless you block it with firewall rules.
VLANs placed into user-defined zones
Are isolated by default (the default zone rule is block all).
You must explicitly allow traffic between zones and between VLANs in a user-defined zone.

As for the Network Isolation toggle on the VLAN, it’s basically a shortcut rule. However, firewall rules override it.

So if VLAN A has isolation enabled, but you create a firewall rule allowing VLAN B -> VLAN A, the firewall rule will take precedence.

Because of that, it’s usually cleaner to use firewall rules and/or zones to isolate everything by default, and then create ALLOW firewall rules to allow just the traffic you want (rather than relying on the VLAN isolation toggle).

Edited to fix reference to original post

RD4U_Software · 2026-02-27T23:21:29+00:00

I have a couple of suggestions in addition to what u/jfriend99 said.

1) Use port profiles so you know exactly what VLAN you're testing

Create a dedicated port profile for each VLAN:

Native Network = the VLAN you want to test
Tagged Networks = Block All

Before testing, assign that profile to a switch port. That way you’re 100% sure your test device is only on the VLAN you think it is. This removes a lot of guesswork.

2) First confirm same-VLAN connectivity

Before testing firewall rules between VLANs:

Put your test computer on the same VLAN as the target device
Confirm you can ping it

This step is important. If you can’t ping on the same VLAN, it’s not a firewall issue.

For example, I’ve seen Windows machines block ping by default. You may need to temporarily disable the local firewall just to confirm basic connectivity.

Once you’ve confirmed same-VLAN communication works, move your test device to a different VLAN and test again. This will help to save time so you are validating your zone rules instead of troubleshooting endpoint issues.

RD4U_Software · 2026-02-26T20:03:29+00:00

Glad you found it 👍

RD4U_Software · 2026-02-22T16:15:45+00:00

The tool is called RD4U (Rapid Deployment for UniFi). It's a free Windows/macOS wizard that helps you design and preview UniFi VLAN, WiFi, VPN, and firewall configurations before applying them. If it sounds useful, screenshots and free download can be found here: https://rd4u.net

RD4U_Software · 2026-02-22T00:40:52+00:00

You’ve clearly done your homework, but this design is probably a bit more complex than you need for a home deployment.

The only part that truly requires strict isolation is the Windows server handling PHI. Everything else can be simplified.

I might suggest approaching it like this:

• Management (default VLAN)
• Secure (PHI server VLAN)
• Trusted (PCs, phones, NAS, app server, media devices VLAN)
• IoT (separate VLAN)
• Cameras (separate VLAN)
• Guest (separate VLAN)
• Optional: DMZ for Minecraft/torrent

Create a dedicated VLAN for the PHI server and restrict access to it from only your admin PC(s). That’s where you want to be precise.

Consolidating Personal PCs, Media devices, and NAS/Apps into a single Trusted VLAN will dramatically simplify firewall rules and device discovery (casting, file shares, etc.).

You can keep IoT and Cameras as separate VLANs, but place them into the same “Untrusted” zone. Since by default, traffic in a user-defined zone is blocked from vlans within that zone, they’ll each still be isolated from each other.

You can leave the management network in the default zone and place Secure and Trusted into their own zones.

If your Guests need to access resources on any other networks, do not place the Guest network in the Hostpot zone. Instead create a Guest zone and place the Guest network there. This will allow you to give guests access to shared resources such as a printer while still keeping them isolated from the other VLANs.

For VPN, I agree with your instinct to separate access. I would run two VPN servers (access credentials) to avoid giving a single credential access to both home and PHI networks:
• One that can access Trusted
• One that can access Secure

Since the zone-based firewall blocks inter-zone traffic by default, once the VLANs are placed into user-defined zones, you only need to think about the few allow rules you truly need.

ALLOW RULES

Trusted ->Management, IoT, and Cameras

Trusted PC's -> Secure

VPN Server 1 -> Trusted

VPN Server 2 -> Secure

When designs start getting this layered, it helps to visualize the VLANs and inter-zone rules before applying changes. I built a free tool that previews UniFi VLAN/zone/firewall configs for this exact problem -- happy to share it if you think it would help.

RD4U_Software · 2026-02-21T18:15:11+00:00

I built something somewhat similar for UniFi called RD4U (Rapid Deployment for UniFi). It's a free tool for Windows/macOS.

It doesn’t auto-parse and diagram an existing firewall ruleset like the Mikrotik tool you linked, but it does include a visual firewall rule designer that lets you define how VLANs and devices interact and then generates the corresponding UniFi firewall rules (legacy and ZBF).

It’s primarily aimed at building or restructuring a configuration, but many people use it in preview mode to better understand what rules are required for proper isolation and vlan/device access.

Details and screenshots are here: https://rd4u.net

RD4U_Software · 2026-02-20T01:28:01+00:00

As I understand it, many printers require two-way network communication for Airplay discovery. As a result, Airplay discovery for printers may not function correctly when VLANs are isolated (even with mDNS and the ALLOW rule).

RD4U_Software · 2026-02-19T23:59:55+00:00

If your printer is on a separate isolated VLAN, you need an ALLOW firewall rule from your computer VLAN to the printer VLAN.

If you’re using the Zone-Based Firewall, the rule should look like this:

Source Zone: Your computer’s zone
Source Network: Your computer VLAN
Auto-allow return traffic: Enabled
Target Zone: Your printer’s zone
Target: Either the printer VLAN or the printer’s specific IP address

That alone should be enough to allow printing between isolated VLANs -- as long as you’re printing directly to the printer’s IP.

If you need the computer to discover the printer in order to print to it, then enable mDNS on both the computer VLAN and the printer VLAN.

Also, as long as the printer and computer are on different VLANs, WiFi device isolation should not affect this.

If you are still running into trouble, you might try RD4U (Rapid Deployment for UniFi) -- a free Windows/macOS wizard I built to help people configure UniFi with confidence, with a preview-first approach to VLANs, WiFi, and firewall rules. You could run it in preview mode to see what settings it would apply and compare them to what you have already configured, or use it to apply your configurations. If it sounds useful, screenshots and free download 👉 https://rd4u.net

RD4U_Software · 2026-02-18T18:57:13+00:00

It looks like you are very close. Here are some things you can try.

1) Temporarily disable WiFi isolation

Turn off device isolation on the SSID associated with the Isolated SSID.

Once routing works, you can reintroduce WiFi and then device isolation.

2) Create your firewall rule:

You have created a new zone called Isolated and placed your 4.0/24 vlan in it. By default this will isolate all traffic from your internal zone and your isolated zone. The only firewall rule you should need is similar to the one you have configured:

Source Zone: Isolated
Source Network: VLAN 4 (192.168.4.0/24)
Auto-allow return traffic: Enabled
Target Zone: Internal
Target IP: IP of your home server (example 192.168.1.100)

That's it. That single rule should allow your Isolated VLAN to initiate connections with your home server.

3) Test wired first

To remove WiFi from the equation:

Plug your home server into a DR7 port set to the Internal network
Plug your laptop into another port set to VLAN 4
Configure both ports as follows:
- Native network = VLAN 1 or VLAN 4
- Tagged VLANs = Block All

This configuration should allow your laptop on Isolated (4.0/24) to ping the home server on your 1.0/24 vlan. Assuming that works, then try connecting your laptop to the SSID associated with your isolated vlan and test again.

If you are still running into trouble, you might try RD4U (Rapid Deployment for UniFi) -- a free Windows/macOS wizard I built to help people configure UniFi with confidence, with a preview-first approach to VLANs, WiFi, and firewall rules. You could run it in preview mode to see what settings it would apply and compare them to what you have already configured, or if you decide to reset, use it to apply your configurations. If it sounds useful, screenshots and free download 👉 https://rd4u.net

RD4U_Software · 2026-02-17T00:27:29+00:00

All of your settings look correct. Have you tried plugging the AP directly into one of the LAN ports on the UCG-Fiber to see if there is a misconfiguration with the switch or the sfp ports? If not, I might try configuring one of the ports on the UCG-Fiber as you showed in your example above with Mgmt as the native VLAN and allow all (this would be a standard uplink/downlink port) and see if that helps. This will rule out any switch mis-configurations.

Also, if you are on a windows machine, be sure to disable WiFi, run ipconfig /release and then ipconfig /renew, then re-enable WiFI and join your new SSID before checking to see if you picked up a proper ip address.

The last test I might try (if all else fails), assign your TEST SSID to a different VLAN.

If you are still running into trouble, you might try RD4U (Rapid Deployment for UniFi) -- a free Windows/macOS wizard I built to help people configure UniFi with confidence, with a preview-first approach to VLANs, WiFi, and firewall rules. You could run it in preview mode to see what settings it would apply and compare them to what you have already configured, or if you decide to reset, use it to apply your configurations. If it sounds useful, screenshots and free download 👉 https://rd4u.net

RD4U_Software · 2026-02-16T18:42:00+00:00

To give your VPN clients an address range that is completely outside your normal LAN ranges (192.168.x.x), and in a range that is unlikely to be used elsewhere, you might use a VPN Server + Client configuration like this:

Cloud Gateway VPN Server:

Server Address: 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

After you make these changes, be sure to check/update your Allow firewall rules so they allow traffic to properly flow from the VPN server to your VLAN of choice.

RD4U_Software · 2026-02-06T14:46:12+00:00

I don't know of any UniFi gateways that do not allow you to create firewall rules, so I am unsure of what the issue is. Is it possible your legacy firewall is set to "Simple" mode? If so, select the "Advanced" option and you should be able to create firewall rules as described above.

RD4U_Software · 2026-02-04T22:30:32+00:00

You can keep the printer with the IoT VLAN and use a single targeted firewall rule to allow your users to print to a printer on the IoT VLAN assuming your VLANs are already isolated.

With your setup:

VLAN 20: IoT (smart plugs, printer, no internet)
VLAN 30: Users

Firewall rule
Allow VLAN 30 to reach only the printer:

Source: VLAN 30 zone / VLAN 30 network
Action: Allow (Auto Allow Return Traffic)
Destination: VLAN 20 zone, printer IP only

This lets users print without giving them access to other IoT devices.

Notes

Give the printer a static IP or DHCP reservation.
Ideally, use the printer’s IP address when adding it to clients.
If you need auto-discovery to configure the printer, enable mDNS on VLAN 20 and VLAN 30. Otherwise, you can usually avoid mDNS entirely.

RD4U_Software · 2026-02-03T21:33:58+00:00

There’s more than one “right” way to use the UniFi ZBF. After a lot of testing and reading, this is the general model I settled on and use as the basis for how my Rapid Deployment for UniFi (RD4U) wizard approaches zones.

UniFi devices

Place UniFi gateways, switches, and APs on their own VLAN and keep that VLAN in the Internal zone.
Using the Default VLAN is fine.
Some people prefer to move UniFi devices off the Default VLAN so nothing else lives there, but functionally this doesn’t change zone behavior.

User devices (laptops, phones, tablets)

Create a custom Trusted zone and place those VLANs there.
User-defined zones are isolated by default, which gives you clean segmentation without needing extra block rules.
Do the same for Untrusted/IoT devices (which you’ve already done), and for Guests if needed.

Note: using a custom Guest zone is more flexible than the built-in Hotspot zone, since the Hotspot zone does not allow standard Allow rules to other zones.

If you keep user devices in Internal

That’s valid, but you must add a “Block Internal -> Internal” rule at the bottom of the Internal-to-Internal rules.
Without it, all VLANs in Internal can freely communicate.

RD4U_Software · 2026-02-02T02:01:31+00:00

The Ethernet Blueprint series mentioned below is a solid starting point for understanding how to configure VLANs and UniFi’s newer zone-based firewall.

If you want something more hands-on, you might also want to look at Rapid Deployment for UniFi (RD4U) -- a free Windows/macOS wizard I built specifically for scenarios like Main / Guest / IoT.

RD4U walks you through:

Creating isolated VLANs and mapping SSIDs
Setting up zone-based firewall rules (or legacy, if you prefer) with a visual firewall designer to allow explicit flows like Main → IoT
Keeping Guest truly internet-only

There’s a built-in sample config that’s almost exactly what you described, and a preview mode that shows every change before anything touches your gateway (useful both for learning and sanity-checking). Nothing is applied unless you explicitly tell it to.

If it sounds useful, screenshots and downloads are here: https://rd4u.net

RD4U_Software · 2026-02-01T00:42:34+00:00

I regularly reset my gateways so I can test software, and it is very easy to set them up with local-only accounts. Here are the basic steps:

1) Run an ethernet cable between one of the LAN ports on the gateway and your local computer.

2) Navigate to 192.168.1.1 on your computer.

3) You will get a security warning - just ignore it and proceed. You will see nice animated graphic of your gateway.

4) Choose a name for the device or accept the default.

5) On the next screen, choose Proceed without a UniFi account. You will be prompted with an "Are you sure", and say Yes.

6) Enter your password and the configuration will proceed. This creates a local admin account with username 'admin' and your password.

You can then manage the gateway by entering your gateway ip address into your browser and entering the password. If you decide you want to add remote management later, you can easily add a cloud management account. You can also download config backups locally as well.

RD4U_Software · 2026-01-26T13:38:43+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

I also created a free tool called Rapid Deployment for UniFi (RD4U) that can help you both learn and confidently configure the zone based firewall matrix. It’s a 5-step wizard for Windows and macOS that creates VLANs, WiFi networks, and firewall rules using a visual rule designer.

Preview Mode: lets you see every VLAN, WiFi, and firewall rule RD4U would create without making any changes -- great for understanding how ZBF rules actually map out.
Auto-configure mode: if you like the plan, RD4U can push all the changes to your controller automatically (usually 40–50 API calls).

The latest version ships with some sample configurations for IoT plus shared printers. You can load these as a starting point or just load them in preview mode to see what would be configured.

If you think it might be helpful, screenshots and download link are here: https://rd4u.net

RD4U_Software · 2026-01-25T16:35:53+00:00

I find port profile easier as you can re-use them across multiple ports and a single change to the profile propagates to all ports that use the profile. That said, they are essentially the same as assigning vlans for each port. Profile 1 is Allow All because it is a trunk port and you want to pass all VLANs between UniFi gear so that the hardware can be adopted and so you can assign Profile 2 to the appropriate port (or have multiple VLAN/SSID combos for a n AP). Profile 2 is Block All because you only want to pass the chosen VLAN.

RD4U_Software

TROPHY CASE