Control Inter-VLAN Communication with the UniFi USG Firewall

You have a UniFi Security Gateway (USG). You want to allow your LAN to talk to all VLANs, but VLANs cannot talk to the LAN or to other VLANs. How do you configure the USG firewall?

First:  define your networks as Corporate. I tried adding firewall exceptions to a Guest network and never got it to work.

This article and this thread contain helpful tips, especially the bits about allowing established/related traffic.

All rules are defined on LAN IN.

1. Add a LAN IN rule to “Allow all Established/Related Traffic”:

Action: Accept
Protocol: All
States checked: Establish, Related <—don’t miss this step!
Source: leave blank
Destination: leave blank

As UBNT-jaffe says here, “Adding this rule at the top will allow all established and related stateful firewall traffic to be able to pass (basically all ‘reply’ traffic).”

2. Add a group “All_private_IPs_RFC1918”:

USG Firewall 1

This allows us to target all private subnets (those that do not route to the Internet).

3. Add a LAN IN rule to “Allow main LAN to access all VLANs”:

Action: Accept
Protocol: All
States checked: none (applies to all states)
Source: Network – LAN (NETv4)
Destination: Address/Port Group “All_private_IPs_RFC1918”

This serves as the exception to the next rule.

4. Add a LAN IN rule to “Block all inter-VLAN communication”:

Action: Drop
Protocol: All
States checked: none (applies to all states)
Source: Network – Address/Port Group “All_private_IPs_RFC1918”
Destination: Address/Port Group “All_private_IPs_RFC1918”

Note At first glance, you might think that this rule would block communication within each subnet as well, for example blocking 10.5.2.15 from talking to 10.5.2.72. However, that “Layer 2” traffic is handled in your switch(es) and never touches the USG, so the rule has no effect there. Only inter-subnet traffic comes back up to the “Layer 3” routing in the USG.

At this point, your rules will look like this:

USG Firewall 2

Bonus Tip

Now, what if you have one device on a VLAN that needs access to one device on the LAN, maybe a laptop that must send backups to a server?

a. Create “Device1” and “Device2” groups. Even though they are “groups,” put just one IP address in each group.

b. Add this rule then move it above the “Block all inter-VLAN communication” rule created in step 4 above:

Action: Accept
Protocol: All
States checked: none (applies to all states)
Source: Network – Address/Port Group “Device1”
Destination: Network – Address/Port Group “Device2”

21 thoughts on “Control Inter-VLAN Communication with the UniFi USG Firewall

  1. Eric

    This is helpful! Thanks for posting this. This opens my eyes to a better way of organizing my firewall rules for VLAN communication instead of a blanket block, or a blanket allow.

    I think I have a pretty good handle on the different settings in the firewall, except for the connection type. I really don’t know the difference between established, new, related, etc. That part confuses me, and I’m sure I would make better rules if I understood them fully.

    I’ve also seen a lot of questions on the nets about WAN In, LAN In, WAN out, LAN out and Local…. I found a few places on the interwebs that helped me break it down, and understand it, but that took hours of research to piece it all together. It may help to describe this as well.

  2. Jorge

    Finally! Thanks for the help in getting my LAN to talk to my VLAN. New to using Unifi gear and this was my only issue thus far.

  3. Gene Montgomery

    This could be the “holy grail” of UniFi firewall posts. Thanks for this!

  4. JC

    Mark,

    Thanks for this. I followed your guide and added a rule to allow all private IPs access my Airplay speaker. It seems to only work when I allow the airplay speaker “new” access rather than only established/related. Any idea why I have to give it “new” access?

  5. Mark Berry Post author

    JC – I don’t know your topology but my understanding is that “established/related” allows _reply_ traffic whereas “new” would be for traffic that is _initiated_ at the specified Source. In step 3 of the article, I say to leave all States unchecked, which should mean allow all states.

  6. BM NINADA

    I would NEVER put this rule below. This is because, in case of being compromised, the 1st. network which will be compromised will be the gateway network from WAN – which in this case is LAN. Effectively, by having this rule, it allows the attacker to subsequently compromise the entire system. Defeating the very purpose of having managed switches / VLAN tagging.

    In fact, the standard practice is NOT to have ANY device in LAN or default network.

    Add a LAN IN rule to “Allow main LAN to access all VLANs”:

    Action: Accept
    Protocol: All
    States checked: none (applies to all states)
    Source: Network – LAN (NETv4)
    Destination: Address/Port Group “All_private_IPs_RFC1918”

  7. Mark Berry Post author

    @BM, thanks for that perspective. My main reason for VLAN tagging is to keep the phones, cameras, and especially the guest computers on Wi-Fi away from the main LAN. I see the threat from rogue devices inside the network as greater than the threat from outside. If an attacker can compromise the firewall from outside and get access to the LAN, I’ve got bigger things to worry about than whether they can also access a phone or camera.

    “In fact, the standard practice is NOT to have ANY device in LAN or default network.” I assume you mean that everything is on a VLAN? I’d be interested to see an article explaining this “standard practice”–it’s not something I’ve encountered in the small-business space.

  8. cybersandwich

    This was a great straight-forward tutorial with perfect explanations of the steps. I followed a few other guides and was getting some weird unexplainable (at least to me) behavior when I tested it.

    This worked perfectly and I understand whats happening.

  9. Dave

    I thought I’d drop by the comments here to express my gratitude.

    Everything else I’d found online suggested that I should be able to route from a UniFi Corporate LAN to my Guest VLAN hosted IoT devices (eg. AV Receiver/Spotify Connect, Apple TV etc).

    I wasted an untold number of hours trying to get things to work; messing with mDNS and IGMP and various firewall settings. I finally found and followed your advice by changing the IoT VLAN to a corporate network with appropriate firewall rules. Now everything’s golden.

    You’re a star.

  10. Mark Berry Post author

    Dave, glad it helped. I feel your pain. So frustrating when what seems obvious (putting guest devices on a Guest network) doesn’t work! Maybe there’s a way, but at least the communication among Corporate VLANs is comprehensible.

  11. Extermini

    Hi.
    I have read several guides for setting firewall rules in the Unifi USG.
    And i Source/Destination. Some say to use Groups as you have used, but some use
    And some say to use Groups as you do, and some say to use “Network”.
    What is the main differance between using groups and network in the source/destination?

    Regards
    Extermini

  12. Mark Berry Post author

    Extermini, as you can see, I use both:

    Source: Network – LAN (NETv4)
    Destination: Address/Port Group “All_private_IPs_RFC1918”

    The Network is one specific network as defined in the router (one subnet).
    The group covers multiple subnets.

    So maybe if you are targeting one subnet, use the name of that network. If you want to target multiple subnets in the same rule, use a group.

  13. Extermini

    Hi.
    Thanks for the quick explantion.
    In the newer version of Unifi controller. The Source: “Network” you can choose between IPV4 subnet and USG ip adress. What is the differance and what to use?

    Regards
    Extermini

  14. Mark Berry Post author

    Extermini – I’ve only used “IPv4 Subnet”. If it had to guess, I would assume that “USG IP Address” refers specifically to the single IP address of the USG itself. I guess that could be used if you want to allow some traffic (like ICMP for ping) to reach the USG but not go anywhere else.

  15. Gilles

    Hey Mark, great and to the point information without any BS surrounding it. I like it. One question; i also have this page in my bookmarks: https://www.missingremote.com/guide/2018/08/configure-unifi-to-block-access-from-one-iot-vlan-to-all-vlans

    I think 1 and 2 over there correspond with 1 and 2+3 over here; then the only difference is that the other site blocks IoT to main VLAN where you block all inter-VLAN communication by default, right?

    Additional question regarding getting Sonos on my IoT VLAN:
    Do you perhaps also know if I still have to do stuff for accessing Sonos on my IoT network from my main LAN if i follow this guide: https://help.ubnt.com/hc/en-us/articles/360001004034-UniFi-Best-Practices-for-Managing-Chromecast-Google-Home-on-UniFi-Network

    I haven’t set that part up but i read some contradicting blogs;
    https://blog.awelswynol.co.uk/2017/11/unifi-sonos-and-vlans
    https://blog.awelswynol.co.uk/2018/04/sonos-unifi-vlan-and-firewalls
    https://durdle.com/2018/12/09/unifi-vlans-sonos-and-igmp-proxy/

  16. Mark Berry Post author

    Hi Gilles, that’s a bit too detailed to discuss in a blog comment. In most cases, once you understand the principles of opening ports and the hierarchy of rules, with a little trial and error, you’ll get the setup you need. You might want to temporarily put a laptop (with its local firewalls off) on your IoT VLAN so you can test pinging to and from it.

  17. CM

    Thanks for this post, Mark! Very insightful

    I’m curious – do you still consider the above good practice?

    In particular, I’m wondering how the firewall rules you’ve described work with / against features (from more recent Unifi updates) like Port Isolation and “Block LAN to WLAN Multicast and Broadcast Data”.

    C

  18. Mark Berry Post author

    CM – This is not a “best practice” article. It’s about how to address a specific need: let the main VLAN initiate communication with other VLANs but not vice-versa. And yes, I still use it.

    I’m not using either of the features you mention. From their names, they serve other purposes. One is about blocking communication _within_ a VLAN; the other about LAN to WLAN.

    So, it depends on what you need to do.

  19. Robert

    Mark,

    I’ve followed your guide and it works perfectly. I’ve gotten stuck on setting up a follow up rule however. I have a DNS host on LAN Pi-Hole. Lets say 192.168.1.3 and I have a IoT Vlan 192.168.2.0/24 with some devices on it. I have blocked inter-vlan traffic per your blog but how do I allow IoT device to hit DNS on LAN? I’d really like any of those VLANs to be allowed to hit my dns host on 53.

    The IoT vlan gets DNS handed to it via dhcp just fine.

    I’ve got a rule in LAN-IN just above the drop all rule.

    Something like:

    Action: Accept
    Protocol: TCP and UDP
    States checked: none (applies to all states)
    Source: Any
    Destination: Address/Port Group > 192.168.1.3/53

    In any other firewall I’d already have this sorted out but I’m stumped. Am I doing this right? Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.

This site uses Akismet to reduce spam. Learn how your comment data is processed.