17 votes

Any Ubiquiti Unifi users? - Questions on zone firewall policies

Posted by JCPhoenix
Tags: ask.advice, ubiquiti.unifi, networking, vlan, firewalls

I'd normally post this on reddit...but I thought I'd give the Tildes Tech Support Team a try.

I have a Ubiquiti Unifi Cloud Gateway Ultra and I'm trying to better understand zone firewall management and VLANs and all that.

I'll start with a screenshot. I'm only changing the two settings highlighted in red.

I'm trying to understand the difference between two firewall policy settings:

  1. Action = Allow ONLY, AND Connection State = Return Traffic
  2. Action = Allow AND Auto Allow Return Traffic checked, AND Connection State = All

I have two VLANs -- "Internal" and "Lab." Each is in their own policy zone, also called "Internal" and "Lab." The "Internal" VLAN does not have the "Isolate Network" option checked, but "Lab" does.

What I want is devices in "Internal" able to initiate and maintain connections with devices in "Lab." But I don't want devices in "Lab" able to initiate connections to devices in "Internal."

With Policy 1, "Internal" can't reach "Lab" nor vice versa. Hmm.

With Policy 2, "Internal" can ping and SSH into devices in "Lab," but not the other way around. Perfect; that's what I want.

And now my question(s): What is the difference between these two policies? To me, they look the same. But clearly the end results say they're not. So what's actually going on here? Additionally, assuming I could get Policy 1 to do what I want, is Policy 2 more vulnerable from a cybersecurity perspective than Policy 1?

If it helps, here's a screenshot of my zone matrix, with focus on source "Internal" and destination "Lab."

Thanks!

10 comments

  1. [4]
    0x29A
    (edited )
    Link
    This is my distant, and possibly wrong, understanding of the potential difference based on what I've been able to find online (unifi forums, etc) mixed with some of my existing knowledge: Isolated...

    This is my distant, and possibly wrong, understanding of the potential difference based on what I've been able to find online (unifi forums, etc) mixed with some of my existing knowledge:

    • Isolated network is probably setting some of its own rules that might be conflicting with zone rules, and by default automatically blocks outgoing from the isolated network (Lab) (but not incoming)
    • With policy 1, you're telling or "narrowing" the application of the "allow" rule to only apply to specifically traffic considered "return traffic" from Lab. However, Lab is also set as isolated, and that itself might be taking precedent over this, and because this policy isn't allowing new traffic from Internal -> Lab, only return traffic from Lab, you don't get access either direction
    • With policy 2, you're telling the allow rule to apply to all traffic, including return traffic, and I think the "Auto Allow Return Traffic", rather than simply looking, within this rule, to filter the policy to apply to traffic in a certain state - is actually maybe setting up its own source Lab -> destination Internal rules instead. So with policy 2 - all traffic is affected Internal -> Lab so you get access that direction, and while its being told to also allow return traffic or set those rules up- "Isolated Network" is again probably preventing that return, so you still only get it one direction regardless of potentially having rules in place that would otherwise facilitate Lab -> Internal traffic flow
    • Think of "connection state" as limiting/narrowing "the type of traffic/packets/initiated connections this rule will apply to", and that it's having to determine the state of particular traffic to be "return" traffic to apply the rule to it, which apparently might be a crapshoot. Apparently this use of the word "return" is weird, because it used to be called related/established and might be completely different from the "auto allow return traffic" which is, instead of checking for a type of connection state, simply creating an identical rule in the reverse direction (swaps destination and source) see more here

    IMO (unless I'm way off base) the way these settings are designed and worded (as "return" seems to denote two different things) seems to be a bit poor, leading to really confusing conflicting states like this

    Also appears that bugs with rule ordering and such have caused weird behavior: https://community.ui.com/questions/Network-Isolation-Traffic-Rule/4405252c-8883-4549-8df3-0ab5882759c1?page=2

    I seem to have found a solution. Because the auto created "YOUR RULE (return)" rule is placed under the isolated networks rule, it blocks the return traffic, but by creating your own return traffic rule identical to the auto created return rule, you can place it above the isolated networks rule allowing it to work. Then disable the Auto Allow Return Traffic option in the main rule.

    5 votes
    1. [3]
      JCPhoenix
      Link Parent
      Huh, the person in that reddit thread seemed to have the opposite issue of me. Auto Allow Return Traffic checked didn't work, but using the Connection State = Return Traffic, did for them....

      Huh, the person in that reddit thread seemed to have the opposite issue of me. Auto Allow Return Traffic checked didn't work, but using the Connection State = Return Traffic, did for them. Interesting. Maybe that was just a bug in the system. It must've been fixed since.

      Anyway, both links were very informative and helped me understand what's going on here. I think.

      I'm not sure the has anything to do with Network Isolation. That's because, generally speaking, new zones -- Such as Lab -- are by default blocked from communication with other zones. I did try turning off Network Isolation on Lab and nothing changed and running both Policies 1 and 2, and nothing changed

      What was key to all this was this comment from u/powerstream:

      Rules are only one way, source to destination. LAN being source and IoT being destination. Once the packet reaches a device on IoT, that device will send a response (return traffic). Now IoT is the source and LAN is the destination. But there is a rule for IoT to block all.[...]

      As such, that means that the "Connection States" are only ever applied to traffic originating from a source. You're right that Return Traffic is a bit of a misnomer. At least in this case where Internal is the originating zone. The tooltip for that option says it's the same as selecting Custom and then checking both Established and Related.

      Starting with Policy 1, I created a rule in Lab -> Internal that's Action = Allow and Connection State = Return Traffic. That only affects (in this case, allows) traffic originating outside of Lab.

      Then in the Internal -> Lab zone, I started playing with the original rule, particularly the Connection State. And then I started pinging from my local computer in Internal to my VM in Lab.

      With Connection State = New, only the first ping in the sequence was successful, because that was a new connection. All other pings in the sequence are now Established but those aren't explicitly allowed.

      With Connection State = New && Established, now the full ping sequence happens. The first ping is New but the rest of the pings are via an Established connection. I can let the pings go on forever.

      With Connection State = Established, provided I didn't stop the previous ping, the ping will go on forever. But if I stop the ping and start a new ping, then it won't work. Because now the first ping is New and blocked and the connection is never Established.

      Related is the only one I don't understand (Well, Invalid, sorta, but I don't know its use case).

      All that to say, thanks for pointing me in the right direction! Your explanation plus others' on Reddit and the official Unifi forums helped to explain how this works.

      1 vote
      1. 0x29A
        Link Parent
        Sure! Also thanks for replying with these findings after the fact! This stuff always gets mega confusing haha :)

        Sure! Also thanks for replying with these findings after the fact! This stuff always gets mega confusing haha :)

        1 vote
      2. 0x29A
        Link Parent
        Another note: for related/invalid, Unifi lists it like this: I believe, in practice, related, means if it can tell the "new" connection is somehow related to an established connection. As a crude...

        Another note: for related/invalid, Unifi lists it like this:

        Related: The incoming packets are new, but associated with an already existing connection.
        Invalid: The incoming packets do not match any of the other states.

        I believe, in practice, related, means if it can tell the "new" connection is somehow related to an established connection. As a crude example: you start an FTP connection to a server, and a "new" connection happens for the data transfer after authorizing/establishing the FTP connection- this new connection for the transfer itself is related to the existing open FTP connection.

        Someone online described invalid as being packets caught in a weird state, whether odd / malformed / stale / associated with now-closed connections- basically traffic that doesn't match any of the other states, and can both be malicious and non-malicious:

        It’s not just malformed/odd packets that the firewall will consider invalid. It’ll also treat any packet that’s not associated to a new/established session as invalid. For example, if you were downloading a file and the transfer completed, the TCP session would be torn down. Now if the server sends more packets for some reason, they’d be considered invalid because there’s no live session still. FWIW, I think it’s a good idea to keep these rules to prevent an odd intrusions from a compromised node

        1 vote
  2. [2]
    Positive
    Link
    The youtuber SpaceRex put out a video on the new Zone Firewall rules. Maybe it will help: https://www.youtube.com/watch?v=oetH1_0LSmo Disclaimer: I haven't watched it.

    The youtuber SpaceRex put out a video on the new Zone Firewall rules. Maybe it will help:
    https://www.youtube.com/watch?v=oetH1_0LSmo

    Disclaimer: I haven't watched it.

    3 votes
    1. JCPhoenix
      Link Parent
      Thanks for sharing. I watched the whole thing, but unfortunately he doesn't go into great depth with the various options. But it was good foundational info nonetheless. Good timing, too!

      Thanks for sharing. I watched the whole thing, but unfortunately he doesn't go into great depth with the various options. But it was good foundational info nonetheless. Good timing, too!

      1 vote
  3. vord
    Link
    As an aside, I've noticed Tildes has a surprisingly incredible breadth for advice given our fairly small population. Thanks everyone!

    As an aside, I've noticed Tildes has a surprisingly incredible breadth for advice given our fairly small population.

    Thanks everyone!

    2 votes
  4. [3]
    ShroudedScribe
    Link
    More of a question than an answer... Admittedly, I'm not a networking professional, but know enough to poke through pfSense / OPNsense and set up basic rules. I didn't realize that such a setup...

    More of a question than an answer...

    Admittedly, I'm not a networking professional, but know enough to poke through pfSense / OPNsense and set up basic rules. I didn't realize that such a setup would be possible. In order to establish a two-way connection (which SSH would be, right?), wouldn't both zones have to allow bidirectional traffic?

    If the above is true, does the "Auto Allow Return Traffic" create some sort of dynamic exception? Kind of like how UPnP can open ports dynamically?

    2 votes
    1. [2]
      JCPhoenix
      (edited )
      Link Parent
      Correct, both zones need to allow traffic in either direction, but with only one side able to initiate that connection. Each rule in Unifi handles direction in one way (see my other comments in...

      Correct, both zones need to allow traffic in either direction, but with only one side able to initiate that connection.

      Each rule in Unifi handles direction in one way (see my other comments in this thread). So that's why the "Auto Allow Return Traffic" has to be checked, which automatically creates the allow return traffic rule in the corresponding zone. Or if not checked, then a rule in the "reverse" zone has to be manually created to allow that return traffic.

      I can't really answer the UPnP portion, since I don't know enough about UPnP. But it seems like Yes? I can restrict the ports and protocols if I want. I can even say specific devices that I want connections from and/or to. But provided whatever combination of devices and type of service I'm trying to run matches with a rule (or doesn't match a rule), then a connection can be made and return traffic will flow.

      In my example, I was using SSH and just pings (ICMP). But I could've run FTP. Or port 80 web traffic. Or whatever, because I didn't set specific ports/protocols to allow or exempt. In that sense, I guess it is dynamic.

      2 votes
      1. ShroudedScribe
        Link Parent
        I re-read your other comment and can see you were able to accomplish this with "connection states." To append to what you shared, I found an article on connection states in pfsense. These...

        I re-read your other comment and can see you were able to accomplish this with "connection states." To append to what you shared, I found an article on connection states in pfsense. These paragraphs seem to relate to what you're doing (but again, is related to how it's handled in pfsense, not necessarily in UniFi):

        pfSense software is a stateful firewall, which means it remembers information about connections flowing through the firewall so that it can automatically allow reply traffic. This data is retained in the State Table. The connection information in the state table includes the source, destination, protocol, ports, and more: Enough to uniquely identify a specific connection.

        Using this mechanism, traffic need only be permitted on the interface where it enters the firewall. When a connection matches a pass rule the firewall creates an entry in the state table. Reply traffic to connections is automatically allowed back through the firewall by matching it against the state table rather than having to check it against rules in both directions. This includes any related traffic using a different protocol, such as ICMP control messages that may be provided in response to a TCP, UDP, or other connection.

        I'm sure the implementation details for how the firewall software establishes this state is quite complex, but it's interesting how they call out protocol as an identifier, then say that it's smart enough to group "related traffic."

        1 vote