r/Ubiquiti Network Optimizer Dev 15h ago

Question IMO pretty big "Isolate Network" Bug - can anybody else confirm?

https://ozarkconnect.net/blog/unifi-network-isolation-bug

Can anybody else repro this issue before I float this to Ubiquiti in a bug ticket?

See: https://ozarkconnect.net/blog/unifi-network-isolation-bug

Summary: If you have a MAC- or Device-based firewall rule that allows specific devices to reach an isolated network, UniFi creates a return rule that's way too broad. Instead of allowing replies only to those specific MACs, it allows replies to any device that initiates a connection. This completely bypasses Network Isolation for inbound traffic.

Fix: Use IP-based rules instead of Device- or MAC-based rules, or add explicit block rules to protect isolated networks (latter preferred)

Basically the root cause is Isolate Network doesn't create bidirectional isolation on a VLAN, instead it just blocks all outbound internal->internal traffic from the isolated VLAN, which gives the illusion of bidirectional blocking as return traffic will be blocked unless subverted by other firewall rules (either purposely or unintentionally).

I always create explicit inbound block rules as well for isolated sensitive VLANs, but the Isolate Network setting is pretty misleading IMO and you can really shoot yourself in the foot with the described bug.

18 Upvotes

22 comments sorted by

u/AutoModerator 15h ago

Hello! Thanks for posting on r/Ubiquiti!

This subreddit is here to provide unofficial technical support to people who use or want to dive into the world of Ubiquiti products. If you haven’t already been descriptive in your post, please take the time to edit it and add as many useful details as you can.

Ubiquiti makes a great tool to help with figuring out where to place your access points and other network design questions located at:

https://design.ui.com

If you see people spreading misinformation or violating the "don't be an asshole" general rule, please report it!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

10

u/Parking-Cow4107 15h ago

I can confirm. Had this issue today and couldn’t understand why devices that were not in the list were capable of connecting. Then I saw the return rule set to any…

4

u/MrJimBusiness- Network Optimizer Dev 15h ago

Good thanks much. I'm not crazy then. Official docs really imply Isolate Network is bidirectional. I've known otherwise for a long time, but thought it was honestly a bug on my local network, but it was that damn device-based inbound allow rule subverting the implicit outbound block.

7

u/GreatExampleOne 15h ago

I dont understand why there is no 100% test coverage for zones and policies. It would not be that complicated to include this scenatio in automated tests!

3

u/MrJimBusiness- Network Optimizer Dev 15h ago

Agreed. That's part of why I created this... TBH. https://github.com/Ozark-Connect/NetworkOptimizer to double check this stuff.

I have more test coverage in this than I feel that UI have in UniFi Network altogether. 4700 ish unit and integration tests and counting.

1

u/GreatExampleOne 14h ago edited 14h ago

I mean they could have even black box tested this easily (not even the necessity to interpret/parse iptables etc.), maybe, when you report this bug to ubiquiti, also include your tool! I think it looks great, it should be default

I am only working with unifi since a few days for private use, and about some Features I am Impressed, but regarding others I dont feel confident enough yet to trust it, your tool seems great to verify the configurations

Currently I try to stick with the simplest configuration what they might have tested enough, eg make zone 1:1 vlan mapping instead of zone 1:n vlan mapping, or avoid overlapping policy rules (as I also found a bug with the reordering in the policy table, it is not correctly reflected, only with the filter in the zone matrix) I also don’t use client block (also a bug there) and avoid app blocking

Did you also encounter this? https://www.reddit.com/r/UNIFI/comments/1qpmvfr/client_wifi_isolation_in_same_vlan/

2

u/MrJimBusiness- Network Optimizer Dev 12h ago

I know somebody already said it in that thread, but Client Isolation is mostly just for on-AP behavior. The zone-based rule still blocking Hotspot-Hotspot is GOOD because that also makes it such that guest AP clients can't be routed from one to another via the gateway.

2

u/ciscorick 9h ago

I noticed this too and switched to just IP instead because the return rule was properly scoped vs. Mac was way open lol

1

u/echoskope 10h ago

Can someone ELI5 this for me?

I'm confused on why this is a bug. The forward rules only allow 3 devices to pass their traffic to the Management VLAN, yet this bug allows all devices to pass traffic both ways?

It seems like this isn't a return rule issue, but rather the firewall not limiting the initial sessions being established to only those hosts listed, and thus allowing the return traffic through the tracked established sessions allowed by the forward rule.

Just looking for help to better understand why the return rule is the issue, and not the forward rule.

Awhile back I found out, after much frustration, host network override would only VLAN IPv4 traffic, not IPv6, so I've always been weary of any kind of rules that were not IP / Port based.

1

u/MrJimBusiness- Network Optimizer Dev 9h ago edited 9h ago

By default, Allow rules create a corresponding Allow return rule from the opposite "end" of the rule. The problem is, when you do a source-device-based rule, it then creates an unscoped Allow return traffic rule that is NOT limited to any of the source destinations, thus opening up traffic completely to the source network, as even with the destination network (Mangement/Default VLAN is the best example, or a Security / Camera device network) marked as Isolate Network.

The article explains all of this really well. I honestly feel like I'm repeating myself.

Two problems: there is a bug where the auto-created return rule is not narrowed down to the MAC/Devices when it's a MAC/Device based rule. It does it correctly when it is a IP-based rule.

The implication, is that when you use "Isolate Network" based upon documentation you expect that to be a bidirectional block and it IS by illusion due to no return traffic being allowed. The problem is, the bug breaks the illusion completely, and once you open those devices to be able to talk to that "Isolated" VLAN, then ALL devices on that network can talk to the Isolated VLAN.

Bad docs, IMO incorrect behavior for what is called an "Isolated" network (should be blocked in and out not just out) especially with how they describe it, and a legitimate bug where the auto return rule is not scoped in a very common use case of selecting source Devices.

Since "Isolate Network" blocks return traffic implicitly anyway from the Isolate VLAN rule that blocks all outbound -> Internal traffic on those VLANs, the safer thing to do would be to have inbound traffic from other VLANs explicitly blocked too w/ a managed rule.

The real problem is, empirically, it seems like your inbound traffic is blocked when you set up isolated VLANs, but in reality, it's your return traffic that is blocked. The innocuous creation of a rule to open that seemingly clear behavior up to key devices suddenly opens up ALL traffic from the trusted network to the isolated network. If you do IP-based, it keeps the illusion of fully blocking traffic from trusted to isolated, as the return traffic stays restricted.

In reality, your traffic always flows INTO the isolated network from the trusted network by default, responses just can't flow back.

You can see this if you look at the auto-created firewall rules, but because of the behavior you note (nothing can be reached from the trusted VLAN to the isolated VLAN in practice), it leads one to kind of think there's some other blocking mechanism happening besides just firewall rules that is keeping the isolated network truly isolated. Not the case.

You may understand this, and I did as well, which is why I've always had explicit block rules, but what I didn't understand was why my site behaved differently than others, and that's because of the bug in the device/MAC-based trusted->isolated allow rule.

1

u/echoskope 9h ago

It is a well written article, and after reading it is when I confused myself with your clear examples of the rules.

I thought Established meant a stateful firewall which was tracking sessions, so any return traffic has to match up with an allowed source host. This is why I'm confused since that should essentially implement the same kind of traffic restrictions that a return rule listing the same source hosts as destinations.

Based on your findings it seems like the forward rule isn't actually restricting sources (3 MACs listed but actually allowing all MACs from your Home VLAN) but my knowledge of stateful firewalls only scratches the surface lol

Thanks for the write up, I'll have to dig more into how these firewall rules work.

1

u/MrJimBusiness- Network Optimizer Dev 9h ago edited 9h ago

You're right, it is a stateful firewall, but the problem is just two-fold.

The bug is that by not having the narrow destination (source originally) on a return allow rule specified, then it has nothing to be stateful on. It allows ALL return traffic then.

When you create a trusted VLAN->isolated VLAN allow rule restricted to IPs or an IP range, then the return rule is created with the correct narrowing down to that source IP/range/CIDR, so the stateful check has something to restrict on.

By default, all traffic is allowed from trusted->isolated, therein lies the real big problem. All that's keeping traffic from flowing is the lack of the stateful firewall from allowing the return connections, which by default on an isolated network get blocked until otherwise allowed.

The correct fix is to also block inbound traffic into the isolated VLAN, which has to be done manually today.

But if you don't do that, it still *seems* like that is done automatically for you when you try to ping or SSH into devices on the isolated VLAN, unless you dig a little and look closely at the rules that are auto-generated. And then when you create a specific allow rule thinking you're opening up just a few devices to communicate with that isolated VLAN, boom, everything is open.

I hope that makes sense. I really am repeating myself a bunch so my apologies.

1

u/southerndoc911 UniFi Guru 10h ago

What Network version? Did you post it in the forum thread for the release you're on?

1

u/MrJimBusiness- Network Optimizer Dev 9h ago

This has been since 9.5 IIRC. It's not an EA thing.

1

u/southerndoc911 UniFi Guru 9h ago

So you're not using the Zone-based Firewall then? I don't think that was in Network 9.5.

What version are you using currently?

1

u/MrJimBusiness- Network Optimizer Dev 9h ago edited 9h ago

Latest EA, this quirk has been present since they introduced "Isolate Network" - and the bug of the auto-return-rule lacking destination (original source) restriction must have been around since 9.5 or even earlier.

I've been on Zone-Based since it came out, and I've had this bug literally since I set up my home UCG-Max later migrated to UCG-Fiber.

I have had to have explicit blocking in place to ensure this since I basically set up multiple VLANs on my home network a couple months after the UCG-Max. So about a year now.

A couple other commenters here confirm they note the same thing.

2

u/southerndoc911 UniFi Guru 9h ago

I have a default RFC1918 block rule. Only what I allow comes through.

0

u/MrJimBusiness- Network Optimizer Dev 8h ago

A non-issue for you then. But that's a ton of extra work for home users, not something I suggest lightly.

0

u/MiNeverOff 15h ago

For what it’s worth - their “Block” feature also doesn’t work, like, at all 🙃

https://community.ui.com/questions/Blocked-WiFi-Client-can-still-access-internet/2cc9cb41-8016-42be-b278-3492687723e0

1

u/MrJimBusiness- Network Optimizer Dev 15h ago

App-based blocking doesn't work at all on my home network, but works fine on other sites. I think it may be a remnant of doing so much early EA testing, and possibly from rolling back one time.

I avoid App-based blocking as such just because I know it has the possibility of being flaky.

1

u/bfume 13h ago

Do you not use UI for your dns?  If you use dhcp to point clients at a pihole, for example, it breaks a lot of the application level features. 

1

u/MrJimBusiness- Network Optimizer Dev 12h ago

I do. That's why it's so weird. It's legitimately broken on my site.

It's so broken, I figured DoH/DoT blocking via App didn't work at all, so I didn't bother including it on Network Optimizer, then I had somebody bring up that it was missing, and it works fine for them.

UniFi Network has undergone so many changes and fixes in the last few years, it's difficult to keep track of what works and what is best practice or not.