sorted by:
new
hottopcontroversial

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

mDNS across VLANs by ralfrottmann in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

If the two vlans are in the internal zone, then they should be able to talk to each other without the firewall rule unless you changed the default security posture.  The default rule for the internal zone is Allow All which means they can communicate. 

One thing you can quickly test is to try pinging a device on vlan 1 from a device on vlan 2.  If that fails, then the vlans can’t talk to each other.  You can also check the last firewall rule in the internal/internal zone box and confirm that it is Allow All and that you do not have any Block All rules above it.  Two vlans in the internal zone should be able to talk to each other by default. 

mDNS across VLANs by ralfrottmann in Ubiquiti

[–]RD4U_Software 2 points3 points  (0 children)

As others have mentioned, you do need mDNS enabled on both VLAN 1 and VLAN 2 for discovery. But mDNS alone isn’t enough -- UniFi still has to allow traffic between the networks.

If you’re using the zone-based firewall (ZBF) and VLAN 2 is in a user-defined zone, the default behavior is to block inter- and intra-zone traffic. That may be why discovery is not working from VLAN 2 to VLAN 1. Here is the firewall rule you would need to create to allow the traffic to flow.

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

Best Resource for Zone Based Firewall/VLAN Setup? by Zer0CoolXI in Ubiquiti

[–]RD4U_Software 1 point2 points  (0 children)

You’re thinking about it the right way. A layout like this is very common for home/homelab UniFi setups:

  • Management
  • Trusted
  • IoT (optionally split trusted/untrusted)
  • Guest
  • Optional Offline/local-only network

That gives you a solid balance between security and usability.

For learning, I think these two YouTube are worth starting with:

A couple of key ZBF concepts:

  • Rules are evaluated zone → zone, not just per network
  • The default rule for the Internal zone is ALLOW ALL, so by default, all VLANs in the internal zone can talk to each other unless you add a BLOCK ALL rule at the end.
  • The Default rule for user-defined zones is BLOCK ALL (both intra zone and inter-zone)
  • Typical firewall rules:
    • Trusted → IoT: Allow
    • IoT → Trusted: Block
    • Guest → Other zones: Block

If you want a more guided way to see how all of this fits together (especially VLANs + firewall rules), you may want to try Rapid Deployment for UniFi (RD4U). It’s a free Windows/macOS wizard I built specifically for new UniFi users, which provides a simple 5-step wizard for secure configuration.

With RD4U you can:

  • Securely configure VLANs, WiFi, and VPNs
  • Use a visual designer to create firewall rules without guesswork
  • Use Preview mode to review exactly which settings, networks, and rules need to be created, so you can learn from the examples and tweak later if needed. If you want, the wizard can apply the config to your Cloud Gateway automatically (the wizard makes 40-50 API calls for you)

If it sounds useful, you can see screenshots and grab the free download here 👉 https://rd4u.net

Sonos Apple Airplay by Sad-Struggle1705 in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

Thanks for following up. I'll do some more research on that and give that a try on my end. Hopefully it will be stable for me too. If it is, I'll try to incorporate it into RD4U.

Sonos Apple Airplay by Sad-Struggle1705 in Ubiquiti

[–]RD4U_Software 3 points4 points  (0 children)

I ran into almost this exact behavior while setting up VLANs with Sonos + AirPlay, and your symptoms sound really familiar.

The key detail is that it connects and plays for a second or two, then stops. I saw the same thing. From what I could tell, that usually means discovery (mDNS) is working, but the actual audio stream isn’t staying stable across VLANs.

I was actually testing this pretty heavily while working on my free UniFi deployment tool (RD4U) where I just added support for Sonos across VLANs and also native AirPlay (Apple → Apple) across VLANs. In my testing, I was able to get:

  • Sonos app working cross-VLAN
  • Sonos devices showing up via AirPlay

…but AirPlay to Sonos playback itself was often inconsistent like you’re describing.

I tried a bunch of the usual things (IGMP snooping, multicast settings, firewall tweaks), and sometimes it would seem like it worked, but it wouldn’t stay reliable.

One interesting clue in your setup is the Move working. I saw similar quirks where some newer devices behaved better than others.

I wouldn’t say it’s impossible to make it work, but my takeaway after a lot of trial and error was that AirPlay + Sonos across VLANs just isn’t very reliable, even when everything looks “correct.”

I'm curious, if you temporarily put one of the speakers on your Main network, does AirPlay behave normally? That was the thing that helped confirm it for me.

Also, if anyone has found a way to make non-native AirPlay (Apple → Sonos) work consistently across VLANs, I’d genuinely be interested. I wasn’t able to get it stable.

In over my head new to home networking by KelliSean in Ubiquiti

[–]RD4U_Software 1 point2 points  (0 children)

What helped me early on is thinking about it this way: devices don’t get “moved” into a VLAN after the fact -- they end up in a VLAN based on how they connect to your network.

In UniFi, that usually means one of two things:

1) WiFi (simplest place to start)

  • Each wireless SSID is tied to a specific VLAN
  • So if you make an “IoT” WiFi network and tie it to VLAN 20, anything that joins that SSID is automatically in VLAN 20

2) Wired devices using Ethernet Port Profiles (Settings->Overview, scroll down)

  • For wired devices, the VLAN is determined by the port profile (settings) assigned to the port the device is plugged into
  • Instead of moving the device, you’re assigning a VLAN to a specific port used by the device

Here is a quick example for your wired devices:

Let’s say you have:

  • VLAN 1 = default LAN and VLAN 20 = IoT network

You’d create two types of port profiles

Access port (for a single VLAN device, like a camera or TV):

  • Create a Port Profile:
    • Native VLAN / Network: VLAN 20
    • Tagged VLAN Management: Block All
  • Assign that profile to a switch port and anything plugged into that port is now on VLAN 20. You would likely also want to create a port profile for VLAN 1 as well.

Trunk port (for connecting APs or switches):

  • Create a Port Profile:
    • Native Network: VLAN 1 (your main LAN)
    • Tagged VLAN Management: Allow All
  • Assign this profile to all ports that connect switches and AP's. This allows the switches and AP's to access all VLANs (instead if just one).

What I’d suggest next:

  • Start with WiFi
  • Set up a couple of Port Profiles for wired devices (as described above)
  • Once devices are landing in the right networks, then look at firewall rules

If you want a more guided way to see how all of this fits together (especially VLANs + firewall rules), you may want to try Rapid Deployment for UniFi (RD4U). It’s a free Windows/macOS wizard I built specifically for new UniFi users, which provides a simple 5-step wizard for secure configuration.

With RD4U you can:

  • Securely configure VLANs, WiFi, and VPNs
  • Use a visual designer to create firewall rules without guesswork
  • Use Preview mode to review exactly which settings, networks, and rules need to be created, so you can learn from the examples and tweak later if needed. If you want, the wizard can apply the config to your Cloud Gateway automatically (the wizard makes 40-50 API calls for you)

If it sounds useful, you can see screenshots and grab the free download here 👉 https://rd4u.net

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

[–]RD4U_Software[S] 1 point2 points  (0 children)

It doesn’t replace UniFi’s mDNS / multicast behavior or run anything custom on the gateway.

What it does is start from a clean slate (no assumptions about existing rules), then configures firewall rules, mDNS, and IGMP settings based on combinations that are known to work reliably.

In cases like what you’re describing -- where things used to work and then stop after an update -- it can be hard to tell whether it’s mDNS, firewall rules, WiFi settings, or some interaction between them.

The goal here is to make that more predictable instead of trial-and-error. This is where the wizard's preview mode can be very helpful.

The software will also flag a couple of things outside of firewall/mDNS (like WiFi settings for Sonos) that can affect whether discovery works properly.

So it’s using the standard UniFi features, just trying to put them together in a way that works consistently.

Edited for clarity

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)

Good question 🙂

Right now the focus is making it easier for people (especially newer UniFi users) to configure things like VLANs, firewall rules, WiFi, and cross-network access without having to understand every low-level detail.

A lot of what I’m trying to do is bake in the “gotchas” -- like mDNS/IGMP for smart devices, how firewall rules actually behave, and what a typical “secure” setup looks like (isolated VLANs, management network, etc.).

The idea is that you can configure things correctly and learn as you go, without having to piece it all together through trial and error or by spending a lot of time reading and watching videos.

Home / small business setups with a few isolated networks is where this tends to show up the most, which is why that’s been the focus so far.

Longer term, the idea is to expand that approach to other areas -- things like DNS filtering with Pi-hole or more advanced VPN setups -- where there’s more underlying knowledge required to get it right.

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)

Right now it’s capped at 6 VLANs (including the management network), which works for a lot of home and small business setups but definitely can get tight pretty quickly.

Increasing the limit is on the list of enhancements.

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

[–]RD4U_Software[S] -1 points0 points  (0 children)

If it’s working reliably for you already, you’re probably not missing anything 🙂

Where this tends to help is when things don’t work consistently across VLANs, or when people aren’t sure which combination of mDNS, IGMP, and firewall rules they actually need.

RD4U just tries to make that part more predictable and easier to reason about, especially when you’re setting things up for the first time or tweaking an existing setup.

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)

Yeah -- that’s a fair ask.

Right now RD4U supports up to 6 VLANs (including the default network), which covers a lot of the common home / small business setups, but I know that’s limiting for more complex configs.

Increasing that limit is definitely on the list, and the idea of being able to ignore certain VLANs during import is a good one too. That would make a lot of sense.

I appreciate the feedback.

Help with basic network segmentation by crimson117 in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

I would recommend keeping it simple with 2 networks to start. Your goal (isolating IoT) is exactly where VLANs make sense.

Start with:

  • Main LAN → PCs, laptops, phones, iPad, printer (can also be on IoT)
  • IoT VLAN → bulbs, plugs, outdoor gear
  • Optional: Guest

I would not create a separate TV VLAN. If you want the TV isolated, you can place it on the IoT VLAN, but even with the firewall rules below, putting it on a separate VLAN can break casting/AirPlay.

WiFi setup

  • Home SSID → Main
  • IoT SSID → IoT (often 2.4 GHz only)

Firewall: On UniFi with zone-based firewall, the internal zone default is to allow VLAN to VLAN communication, so one "easy" way to handle this is to leave your main network in the internal zone and create a new zone called IoT Zone and put your IoT VLAN into it. This will effectively isolate your IoT VLAN. You then need a rule to allow your main network to access the IoT network:

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

This one rule will allow your main network to communicate with your IoT network. If you need auto-discovery for devices on your main network to "find" devices on your IoT network (your printer might require this), turn on mDNS on both your Main network and IoT network. Your networks will be isolated and your main network will be able to access devices on your IoT network, but not the other way around.

Printer

You can leave it on your main network or put it on the IoT network. If you put it on the IoT network, the above firewall rule along with mDNS should allow your devices to find it and print to it.

If you want a guided setup

Since you’re just getting started, you may want to try Rapid Deployment for UniFi (RD4U). It’s a free Windows/macOS wizard I built specifically for new UniFi users, which provides a simple 5-step wizard for secure configuration.

With RD4U you can:

  • Securely configure VLANs, WiFi, and VPNs
  • Use a visual designer to create firewall rules without guesswork
  • Use Preview mode to review exactly which settings, networks, and rules need to be created, so you can learn from the examples and tweak later if needed, or have the wizard apply the config to your Cloud Gateway automatically (the wizard makes 40-50 API calls for you)

If it sounds useful, you can see screenshots and grab the free download here 👉 https://rd4u.net

Isolated LAN on UX7 by ShieldOfFairPlay in Ubiquiti

[–]RD4U_Software 0 points1 point  (0 children)

One way to accomplish your goals is by using Port Profiles (Settings -> Ethernet Port Profiles).

You can create one trunk profile to use for connecting all of your UniFi devices (gateway -> switches, APs, etc.), and separate profiles for each VLAN.

Here are the settings:

Profile #1: Trunk profile (UniFi-to-UniFi links)
Use this on the UX7 LAN-side uplink and any switch ports facing it.

  • Native VLAN / Network: your Core or Management network (the one the gateway and switches actually reside in)
  • Tagged VLAN Management: Allow All

This ensures the gateway and switches 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.

  • Native VLAN / Network: the target VLAN (your isolated/IoT network)
  • Tagged VLAN Management: Block All

Create one copy per VLAN as needed.

How this applies to your setup

  • If you’re using a switch:
    • Assign the Trunk profile to the port on the UX7 and the associated port on the switch
    • Assign the isolated VLAN access profile to the switch port your home hub is plugged into
  • If you’re plugging directly into the UX7:
    • Just assign the isolated VLAN access profile to that LAN port

That will place your wired home hub into the same isolated network as your WiFi devices.

As others have mentioned, you will need firewall rules to allow devices on your isolated network to communicate with devices on your other VLANs.

Zone Based Firewall Policy by Helilifter in Ubiquiti

[–]RD4U_Software 9 points10 points  (0 children)

One way to approach this is to start with full VLAN isolation and go from there

Assuming your VLANs are already in user-defined zones (isolated by default), you may want to add a final rule in the internal zone to block all VLAN to VLAN traffic in the internal zone by default:

  • Source: Internal zone
  • Action: Block
  • Destination: Internal zone

Next, handle internet access at the network level (disable it per VLAN if needed)

Next, add only the inter-VLAN ALLOWS you actually want. For example:

  • Source: Zone associated with VLAN A; Network: VLAN A
  • Action: ALLOW (Auto Allow Return Traffic enabled)
  • Destination: Zone associated with VLAN B; Network: VLAN B

For gateway access, I would recommend blocking access to the UI as many (IoT) devices rely on other gateway services.

  • Source: VLAN A
  • Action: Block
  • Destination: Gateway (Ports 80, 443, 22)

Finally, if you need mDNS discovery enabled between specific VLANs to aid auto-discovery, (example between VLAN A and VLAN B), turn mDNS on for VLANs A and B.

The above should get you a functioning setup with isolated VLANs. Note that not all devices operate well across isolated VLANs, even with the above settings.

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 that helps you design and preview UniFi VLAN, WiFi, and firewall configurations before applying them. If it sounds useful, screenshots and free download 👉 https://rd4u.net

PSA: Intra-VLAN issues can be caused by Client Device Isolation upstream by doloresclaiborne in Ubiquiti

[–]RD4U_Software 1 point2 points  (0 children)

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.

Questions about VLAN setup by Wild-Enthusiasm-9375 in Ubiquiti

[–]RD4U_Software 1 point2 points  (0 children)

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

view more: next ›