Reply
New Member
Posts: 14
Registered: ‎03-09-2018

ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

[ Edited ]

Setup:  ER-X with 192.168.2.0/24 on VLAN20 that's being used by the UniFi WAP on eth2 for a guest wifi--it's set to corporate--it also hosts the native LAN (192.168.1.0/24) on separate antennas, also set to corporate. PC directly wired to eth1, native LAN.

Purpose: I'm studying. It's already doing what I want it to do which is to filter traffic between LANs, but allow communication within its respective LAN. The issue is that I'm not understanding some things.

1. Shouldn't this configuration be be blocking intraLAN communcation? For example 192.168.2.2 pinging 192.168.2.4 shouldn't respond, right? Yet, it does reach. I mean, it's doing what I want it to do which is to prevent VLAN 20 to native LAN communication, but it reads (to me) as though it would block any communication from 192.168.2.0/24 to 192.168.0.0/16 which is including itself.

 

firewall {
    all-ping enable
    broadcast-ping disable
    group {
        network-group LAN_NETWORKS {
            description "LAN Networks"
            network 192.168.0.0/16
        }        
    }    
    name PROTECT_IN {
        default-action accept        
        rule 10 {
            action drop
            description "Drop LAN_NETWORKS"
            destination {
                group {
                    network-group LAN_NETWORKS
                }
            }
            protocol all
        }
    }
}
interfaces {
    switch switch0 {
        address 192.168.1.1/24
        description Local
        mtu 1500
        switch-port {
            interface eth1 {
            }
            interface eth2 {
            }
            interface eth3 {
            }
            interface eth4 {
            }
            vlan-aware disable
        }
        vif 20 {
            address 192.168.2.1/24
            description Guest
            firewall {
                in {
                    name PROTECT_IN                
            }
            mtu 1500
        }
    }
}

2. Does this mean that firewall settings only filter between interLAN communication and not intraLAN?
(b)What about if I put a wired device on eth3 and set eth3 to VLAN20 and then tried to ping from a wireless device on the WAP to the wired device off the router?

 

3. (side question) I have a UniFi WAP on eth2. Does all traffic that enters the WAP go to the router/switch inlcuding intraLAN communication such as 192.168.2.2 <-> 192.168.2.4 or is wireless to wireless traffic connected by the WAP contained in the WAP, never travelling to the router?

Emerging Member
Posts: 199
Registered: ‎09-13-2018
Kudos: 35
Solutions: 12

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

[ Edited ]

@Harman20 wrote:

1. Shouldn't this configuration be be blocking intraLAN communcation? For example 192.168.2.2 pinging 192.168.2.4 shouldn't respond, right? Yet, it does reach. I mean, it's doing what I want it to do which is to prevent VLAN 2 to native LAN communication, but it reads (to me) as though it would block any communication from 192.168.2.0 to 192.168.0.0 (including itself).

 

2. Does this mean that firewall settings only filter between interLAN communication and not intraLAN?

 

3. (side question) I have a UniFi WAP on eth2. Does all traffic that enters the WAP go to the router/switch inlcuding intraLAN communication such as 192.168.2.2 <-> 192.168.2.4


  1. In general intra LAN traffic works independently of the router.  As long as the ip address of the destination is known, a router is not required at all.  host 192.168.2.2 wants to send to host 192.168.2.4.  To send a message it has to know 192.168.2.4's ethernet address (the layer 2 MAC address).  Assume it does not know what it is.   FIrst it looks at the network mask (/24 meaning "if the first 24 bits of the address (the first three octets 192.168.2) are the same, then we are on the same network, and I don't need to ask the router to send this off LAN".  They are the same.  But now 192.168.2.2 looks in its ARP table to see if it can find 192.168.2.4, but it isn't there.  How does it get it?   It sends an ARP request via ethernet broadcast (destination all bits set), with the message.  "Who has 192.168.2.4?  Tell 192.168.2.2" sent with 192.168.2.2's mac address as the source address  This is like someone using a Paging system to annouce "If you lost your keys, call x4523".  Every PC on the LAN gets that message (like the presidential alert), but every PC but the one with ip address 192.168.2.4, after grumbling "why do they keep interrupting me?", just ignores the "page". The one PC with that IP address (192.168.2.4) responds back to  PC with the MAC address that just sent the broadcast.  So now in the future, as long as these "ip address to mac address mappings" remain in the ARP table of the two pcs (you can see these with > arp -a in a cmd prompt on windows), the pcs can send messages back and forth with out sending any more arp requests or with the involvement of the router.
  2. yes
  3. It depends how the AP is set up, and whether guest client isolation is in effect.  The Unifi AP has a ability to limit communication between wifi clients. I am not an expert with Unifi APs, so I don't know if this is done at layer 2 (mac address level) or at layer 3 (ip address level).

Probably more detail than you wanted.

New Member
Posts: 14
Registered: ‎03-09-2018

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

I appreciate the response and detail so much!

I should've mentioned that I wasn't using a separate switch, just the ER-X, PC1 on eth1 and Unifi AP on eth2. I thought since it was all connecting to the router that it would still be filtered.

I really should've mentioned that because I have a basic understanding of the OSI model such as you described with ARP messages and Ethernet frames only traveling across a switch and not through the router.

The only isolation is at the firewall level as described in the settings. Both LANs are set to 'Corporate'
Emerging Member
Posts: 199
Registered: ‎09-13-2018
Kudos: 35
Solutions: 12

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

[ Edited ]

@Harman20 wrote:
I should've mentioned that I wasn't using a separate switch, just the ER-X, PC1 on eth1 and Unifi AP on eth2. I thought since it was all connecting to the router that it would still be filtered.

The ERX has an integrated switch chip.  So depending on how it is configured, the 5 ports can all act as independent ports (but all traffic between ports is then limited by the 1 Gb link to the CPU).

 

If you use the standard wizard config, eth0 will be connected only to the CPU (in hidden vlan 4088), and eth1-eth4 will be in  switch0.  So traffic between eth1 and eth2 will be switched at layer 2, just as if they were connected to a switch.  So unicast frames never makes it to the cpu.  If the ports are bridged, and hwnat is not enabled, then the CPU will have to be involved with every ethernet frame.

 

There is some info you can get from the command line with 

$ /sbin/switch vlan dump

and 

$ /sbin/switch dump

or just

$ /sbin/switch

for a list of commands this unsupported utility can do.

New Member
Posts: 14
Registered: ‎03-09-2018

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

[ Edited ]

I figured that since the ACL has options for MAC address filtering that the router/switch filtered at L2 as well, but I guess not (?)

I ought to test to see if I set that group filter the native lan and ping my phone from native LAN on the WAP on eth2 to the native lan with my PC on eth1 if it'll filter it or let it through--that way I know for sure that the traffic is going through the WAP and the ER-X to compare to see if the WAP is switching VLAN2 without passing it on to the router is why the ACL isn't kicking in.

Senior Member
Posts: 2,969
Registered: ‎08-06-2015
Kudos: 1253
Solutions: 174

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

If you do not have your WLAN on your UAP set to 'guest' then the UAP will not do any filtering.  If you do enable guest controls on your WLAN on your UAP then yes the UAP will apply filtering itself.

 

If guest controls are enabled

  • The driver in the UAP will enforce L2 isolation between its own associated guests on that WLAN.
  • 'ebtables' rules will be created on the UAP to further restrict traffic to/from those associated wireless guests based on your 'Pre-Authorization Access' and 'Post-Authorization Restrictions'

'ebtables' is a layer-2 filter (with basic higher-layer inspection) since an AP is really just a layer-2 device.

 

What exacty are you trying to accomplish?  There may be some other way to achieve your goal, but it almost sounds like you want the ports on your ER-X to themselves be isolated which isn't specifically possible here with just a single L2 and L3.

 

An edgerouter operates at layer-3, and uses netfilter (iptables with ipset) for layer-3 filtering with some basic lower-layer inspection. If traffic is not routed (L3), the ER-X won't be able to restrict that traffic.

New Member
Posts: 14
Registered: ‎03-09-2018

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

[ Edited ]

The goal is to learn and understand the flow of traffic and where the ACL applies (and some bits on vlan trunking with vlan aware enabled/disabled, see (7) below)--it's confusing because it has options for MAC address filtering.

4(a). I want to know where the path of traffic on the WAP goes if it's within the same SSID/subnet/VLAN--does the WAP always pass on all traffic to the ER-X that it's connected to or (b) does it bridge ((c)?correct wording?) it across other hosts under the same SSID/subnet/VLAN by itself?

I turned on vlan-aware on the ER-X, and set the interface with the WAP with vid 20 set.

It appears that devices on the ER-X native/administrative/switch0 LAN are incapable of communicating across all other VLANs (with the exception to and from the ER-X itself/local/(192.168.1.1)) even when all firewall rules are turned off on all related interfaces. This means that my wired PC on 192.168.1.0/24 (eth2) can't ping a wireless printer on 192.168.2.0/24.  I know this because if I set VLAN30 (192.168.3.0/24) on eth3, and connect my wired PC on it, I can ping the wireless printer which goes through the ER-X and through the WAP. However, if I set the firewall rules to block 192.168.0.0/16 traffic on VLAN20 again, it'll get blocked from responding to VLAN30/192.168.3.0.

I did learn that the ACL doesn't apply to ER-X traffic from within the same VLAN/subnet despite definitely going through the ER-X. I learned this by leaving on the drop 192.168.0.0/16 filter setting on VLAN20 (192.168.2.0), setting eth3 to VLAN20 and connecting my wired PC to it and then successfully pinging to the wireless printer that's on the same VLAN/subnet.

5. Now I wonder if the ER-X has way to apply an ACL at the L2 level--I mean, it can definitely read MAC addresses. I know this because if I set a permit rule for my wireless printer's MAC address above the drop rule for traffic to 192.168.0.0/16 on the VLAN20 interface, I can ping it from VLAN30--not if I remove the permit rule while leaving the drop rule on. (a) Is there such a thing as ACL on the L2 in general? (b) What about for the ER-X? (c) What's up with the ACL having options to filter source by MAC then?

6. I'm still curious about how come other devices such as my PC on eth2/switch0/192.168.1.0/24/administrative LAN is unreachable when vlan-aware is on, but not if it's off. Is this a feature?

7. I wonder how come VLAN tagging seemed to work fine before I turned on vlan-aware on the ER-X where instead I had to then set the interface for the WAP to vid 20 to allow the guest WLAN connected devices to pick up the DHCP and get IPs. What is it about 'vlan-aware enable' that changed this?

The main purpose it to learn, so the rest is just kind of unrelated but inspired me: I want the guest wifi to allow intraLAN communication, just not to be able to connect to my PCs subnet.  I also want to harden access to the printer which I have just now put on VLAN10 (now the new 192.168.1.0/24), but I want it accessible to the guest wifi so that guests can connect and print freely (the guest wifi does have a password). I had the printer on the guest wifi for a time, but I since put it on the VLAN10 (now 192.168.1.1/24), and I set up the ACL to VLAN10 IN/OUT to block all access to it except for certain ports it needs IN to its MAC+port-group.

Please excuse me if the '(blank)'s seem silly. I'm probably being over-cautious but whatever, right? Below is a redacted config that I'm currently using. It's here for reference and criticism, but I'm really here to have the numbered questions answered and to learn more in theory and practice to become a IT network professional.

 

Spoiler



firewall {
    all-ping enable
    broadcast-ping disable
    group {
        network-group LAN_NETWORKS {
            description "LAN Networks"
            network 192.168.0.0/16
        }
        port-group printerport {
            description "Printer Port Group"
            port 137
            port 161
            port 54925
            port 515
        }
    }
    ipv6-receive-redirects disable
    ipv6-src-route disable
    ip-src-route disable
    log-martians enable
    name PROTECT_IN {
        default-action accept
        rule 10 {
            action accept
            description "Printer allow internal network access on printer ports"
            destination {
                address 192.168.1.50
                group {
                    port-group printerport
                }
            }
            log disable
            protocol tcp_udp
            source {
                group {
                }
            }
        }
        rule 20 {
            action accept
            description "Printer allow printer to respond to pings from internal network"
            destination {
                address 192.168.1.50
                group {
                }
            }
            log disable
            protocol icmp
            source {
                group {
                }
            }
        }
        rule 40 {
            action drop
            description "Drop LAN_NETWORKS"
            destination {
                group {
                    network-group LAN_NETWORKS
                }
            }
            protocol all
        }
    }
    name PROTECT_LOCAL {
        default-action drop
        rule 10 {
            action accept
            description "Accept DNS"
            destination {
                port 53
            }
            protocol tcp_udp
        }
        rule 20 {
            action accept
            description "Accept DHCP"
            destination {
                port 67
            }
            protocol udp
        }
    }    
    name VLAN10_PrinterProtect_IN {
        default-action accept
        rule 10 {
            action accept
            description "Printer allow internal network access on printer ports"
            destination {
                group {
                    network-group LAN_NETWORKS
                }
            }
            log disable
            protocol tcp_udp
            source {
                group {
                    port-group printerport
                }
                mac-address (blank)
            }
        }
        rule 20 {
            action accept
            description "Printer allow printer to respond to pings from internal network"
            destination {
                group {
                    network-group LAN_NETWORKS
                }
            }
            log disable
            protocol icmp
            source {
                group {
                }
                mac-address (blank)
            }
        }
        rule 30 {
            action drop
            description "Printer Internet and Catchall Block"
            destination {
                address 0.0.0.0/0
            }
            log disable
            protocol all
            source {
                mac-address (blank)
            }
        }
    }
    name VLAN10_PrinterProtect_OUT {
        default-action accept
        description "Block Internet Access to Printer"
        rule 10 {
            action accept
            description "allow specific ports to printer from internal network"
            destination {
                address 192.168.1.50
            }
            log disable
            protocol tcp_udp
            source {
                group {
                    network-group LAN_NETWORKS
                    port-group printerport
                }
            }
        }
        rule 20 {
            action accept
            description "allow ping to printer from internal network"
            destination {
                address 192.168.1.50
            }
            log disable
            protocol icmp
            source {
                group {
                    network-group LAN_NETWORKS
                }
            }
        }
        rule 40 {
            action drop
            description "Internet and internal network catchall block to printer"
            destination {
                address 192.168.1.50
            }
            log disable
            protocol all
            source {
                address 0.0.0.0/0
            }
        }
    }
    name WAN_IN {
        default-action drop
        description "WAN to internal"
        rule 10 {
            action accept
            description "Allow established/related"
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
    }
    name WAN_LOCAL {
        default-action drop
        description "WAN to router"
        rule 10 {
            action accept
            description "Allow established/related"
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
    }
    receive-redirects disable
    send-redirects enable
    source-validation disable
    syn-cookies enable
}
interfaces {
    ethernet eth0 {
        address dhcp
        description Internet
        duplex auto
        firewall {
            in {
                name WAN_IN
            }
            local {
                name WAN_LOCAL
            }
        }
        speed auto
    }
    ethernet eth1 {
        description Local
        duplex auto
        speed auto
    }
    ethernet eth2 {
        description Local
        duplex auto
        speed auto
    }
    ethernet eth3 {
        description Local
        duplex auto
        speed auto
    }
    ethernet eth4 {
        description Local
        duplex auto
        speed auto
    }
    loopback lo {
    }
    switch switch0 {
        description Local
        mtu 1500
        switch-port {
            interface eth1 {
                vlan {
                    pvid 10
                }
            }
            interface eth2 {
                vlan {
                    pvid 10
                    vid 20
                }
            }
            interface eth3 {
                vlan {
                    pvid 30
                }
            }
            interface eth4 {
            }
            vlan-aware enable
        }
        vif 10 {
            address 192.168.1.1/24
            description "VLAN10 Admin"
            firewall {
                in {
                    name VLAN10_PrinterProtect_IN
                }                
                out {
                    name VLAN10_PrinterProtect_OUT
                }
            }
        }
        vif 20 {
            address 192.168.2.1/24
            description "VLAN20 Guest"
            firewall {
                in {
                    name PROTECT_IN
                }
                local {
                    name PROTECT_LOCAL
                }
                out {
                }
            }
        }
        vif 30 {
            address 192.168.3.1/24
            description "VLAN30 Backup VLAN"
        }
    }
}
protocols {
    static {
    }
}
service {
    dhcp-server {
        disabled false
        hostfile-update disable
        shared-network-name Guest {
            authoritative disable
            subnet 192.168.2.0/24 {
                default-router 192.168.2.1
                dns-server (blank)
                dns-server (blank)
                lease 86400
                start 192.168.2.2 {
                    stop 192.168.2.254
                }                
            }
        }
        shared-network-name LAN {
            authoritative enable
            subnet 192.168.1.0/24 {
                default-router 192.168.1.1
                dns-server (blank)
                dns-server (blank)
                lease 86400
                start 192.168.1.2 {
                    stop 192.168.1.254
                }
                static-mapping PRINTER {
                    ip-address 192.168.1.50
                    mac-address (blank)
                }                
            }
        }
        shared-network-name VLAN30 {
            authoritative disable
            subnet 192.168.3.0/24 {
                default-router 192.168.3.1
                dns-server (blank)
                dns-server (blank)
                lease 86400
                start 192.168.3.2 {
                    stop 192.168.3.254
                }
            }
        }
        static-arp disable
        use-dnsmasq disable
    }


I understand that my writing may be hard to read as I'm coming from a place of learning and I'm a novice, so I appreciate the efforts to tough through it and answer my questions.

 

Senior Member
Posts: 2,969
Registered: ‎08-06-2015
Kudos: 1253
Solutions: 174

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

@Harman20 wrote:

The goal is to learn and understand the flow of traffic and where the ACL applies (and some bits on vlan trunking with vlan aware enabled/disabled, see (7) below)--it's confusing because it has options for MAC address filtering.

This is why I noted above that an AP is a layer-2 device (only) and the ER is a layer-3 device.  The UAP will forward traffic at layer-2 only.  Any layer-3 forwarding must happen at a router.

 

The basic understanding of layer-2 vs layer-3 is required for this type of question.

 

Devices that are trying to communicate with each other (very simplified and summarized):

  1. If both devices are on the same subnet, as determined by the locally-configured netmask (network size), they will attempt to communicate directly at layer-2.  A layer-3 device never enters the picture and would not be able to filter/control this traffic in any way.
  2. If the two devices are on a different subnet, as determined by the locally-configured netmasks, they will attempt to communicate at layer-3 by communicating directly at layer-2 with their default gateway(s).  Here, the router (a layer-3 device) is a key part of the communication and is able to filter/control this traffic.

A UAP, being a layer-2 device, can only filter at layer-2.  It has limited layer-3 inspection to help determine what gets filtered, but the filtering is done at layer-2.  Every wireless client uses their associated AP as their layer-2 peer for all traffic, so this works well.

 

An edgerouter, even an ER-X, is a layer-3 device and can only filter at layer-3.  Even though an ER-X has an integrated switch (layer-2) it does not have any filtering capabilities at layer-2.  All firewall policies and rules will always apply at layer 3, including any MAC-based rules.

 

4(a). I want to know where the path of traffic on the WAP goes if it's within the same SSID/subnet/VLAN--does the WAP always pass on all traffic to the ER-X that it's connected to or (b) does it bridge ((c)?correct wording?) it across other hosts under the same SSID/subnet/VLAN by itself?

See above.  A wireless AP is strictly a layer-2 device.  It has no concept of subnets or IPs.  If forwards strictly based on layer-2 information.  

 

Two wireless clients associated to the same AP on the same WLAN (SSID) will be part of the same layer-2 and will attempt to communicate directly at layer-2, so the AP will forward traffic between them directly (that traffic will never hit the upstream).

 

A wireless client and a wired client on the same VLAN will themselves attempt to communicate at layer-2, and again the AP will happily forward traffic between them.  This traffic would pass to the upstream layer-2 peer of the UAP (wireless or wired uplink) but would never touch a layer-3 device.  In other words this traffic would get sent to the ER-X, but would never leave the builtin switch and would never reach switch0 interface itself.

 

Two wireless clients associated to different APs but on the same WLAN (SSID) would be similar to the case directly above.

 

A wireless client and a wired client on different VLANs would attempt to communicate through their default gateway(s).  Their layer-2 communication would be directly with those gateways with the expectation that the gateways would forward traffic appropriately.  Here the AP will again happily forward traffic between its wireless client and the default gateway, completely unaware that the traffic is ultimately destined elsewhere.  Here, the traffic would again pass to the upstream layer-2 peer UAP (wireless or wired uplink) and would continue until it reached the layer-3 device, which would be the actual switch0 interface of your ER-X.

 


It appears that devices on the ER-X native/administrative/switch0 LAN are incapable of communicating across all other VLANs (with the exception to and from the ER-X itself/local/(192.168.1.1)) even when all firewall rules are turned off on all related interfaces.

I don't understand this question/statement.  VLANs are a layer-2 concept.  Traffic between VLANs will pass through switch0 on an ER-X, but traffic within the same vlan will stay within with switch and never reach switch0.

 

Again - understanding layer-2 vs layer-3 is important for this type of question.  On an ER-X 'swich0' is the layer-3 interface.  Only traffic reaching that interface can be filtered.  Any ports that are part of that switch0 are layer-2 and no filtering by the ER-X would occur.  Any ports that are not part of switch0 become layer-3 ports themselves, separate from switch0, and would be able to filter traffic.

  

I did learn that the ACL doesn't apply to ER-X traffic from within the same VLAN/subnet despite definitely going through the ER-X. I learned this by leaving on the drop 192.168.0.0/16 filter setting on VLAN20 (192.168.2.0), setting eth3 to VLAN20 and connecting my wired PC to it and then successfully pinging to the wireless printer that's on the same VLAN/subnet.

Traffic within a VLAN is layer-2 only.  The ER-X can not filter at layer-2.  Please see above.  I tried to summarize (ok maybe a little longer than a simple summary) what happens where but the key factor is indeed this.  An ER's firewall policies only apply to layer-3 (routing).  Period.  An ER (any model) has no ability to limit or otherwise restrict layer-2 traffic, such as traffic between devices on the same VLAN.


5. Now I wonder if the ER-X has way to apply an ACL at the L2 level--I mean, it can definitely read MAC addresses.

I know I am sounding like a broken record, but as I noted in my previous post an ER is a layer-3 device and can only filter on layer-3.  An ER-X may have an integrated switch (layer-2) but it has no layer-2 filtering capabilities.

 

Being able to inspect layer-2 does not mean a device can filter at layer-2.  Only traffic that passes through a routed (L3) interface may be filtered on an ER (any model).  Ports that are members of switch0 are not layer-3 interfaces - switch0 is their layer-3 interface.  Only ports that are not members of switch0 are themselves layer-3.

 


The main purpose it to learn, so the rest is just kind of unrelated but inspired me: I want the guest wifi to allow intraLAN communication, just not to be able to connect to my PCs subnet. 

If you want your "guest" devices to be able to communicate amongst themselves you would not configure the WLAN as a 'guest'.  IE: you would not enable 'Guest Policy' on the WLAN configuration page in the UniFi controller for that WLAN.  You would want to make this its own VLAN with its own subnet, but you would not enable it as a guest.  Then you would use firewall polices on your ER-X to manage traffic to/from that subnet just as you would with any other subnet.

 

SImilar would apply to your printer.  If all devices on the same subnet as the printer should be able to access the printer you can leave it on the same subnet, and use more granular firewall rules to specifically control access to the printer.  However if other devices on that would be on the same subnet should not all have access to the printer then using only an ER-X you would indeed want to put the printer on its own VLAN with its own subnet.

 

For firewall policies it is best to not to try to overthink or get too clever, especially at first.  All ERs leverage netfilter (iptables/ipset) for their firewall which is a stateful firewall.  This has many benefits and unless you understand what that means and have a reason to not track state (stateless) it is best to stay with the standard stateful configurations such as those created by the wizards.

 

Most traffic is bi-directional, and if you are not using a standard (stateful) configuration you need to specifically be sure to accommodate traffic in both directions.  Your configurations are stateless and less secure than a stateful configuration.

 

Your configuration is not actually very complex and should be easy to recreate.  You might be best off by first resetting to factory default then using one of the wizards to create the initial configuration with firewall.  Then you can look at what is done, add your additional subnets and policies/rules.

 

Looking at what the wizards configure is actually a good way to get started, even if you don't ever plan to use a GUI again.

 

There are some KB articles and threads that may also be of some help.  If you haven't found it there is a growing help-center found by clicking on SUPPORT at the top of the page.  From there you can find sections for UniFi for your UAP and for EdgeMAX for your ER-X.  In particular:

EdgeRouter - Beginners Guide to EdgeRouter

EdgeRouter - How to Create a WAN Firewall Rule

EdgeRouter - How to Create a Guest\LAN Firewall Rule

EdgeRouter - VLAN-Aware Switch

 

There is also a section often missed that has perhaps several helpful KB articles:  Intro to Networking

 

New Member
Posts: 14
Registered: ‎03-09-2018

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?


@waterside wrote:

I don't understand this question/statement. VLANs are a layer-2 concept. Traffic between VLANs will pass through switch0 on an ER-X, but traffic within the same vlan will stay within with switch and never reach switch0.


I meant that despite all interfaces and subnets/VLANS being on the routing table, that while 'vlan-aware enabled' was set that I wouldn't be able to ping devices from other hosts on the switch0 interface to any other host on any other VLAN (switch0.xx) except for the router IP that's on the switch0 interface (which isn't going 'through' it), so devices behind switch0.xx VLANS could always ping the switch0/192.168.1.1 interface, just not through it to the hosts behind switch0 interface and vice versa. Of note is that devices on the same switch0/LAN could ping each other such as that while the pid for eth2/UAP & its admin SSID/LAN were set blank--effectively setting them behind switch0--I could ping from wired PC1 to my cellphone (that is using the admin SSID).

However, while 'vlan-aware disabled' was set, devices across switch0 and switch.xx could communicate.

For example, say I set 'vlan-aware enabled', set 192.168.1.1/24 on switch0, and PC1 on 192.168.1.2/24 on eth2 with no pid/vid (effectively setting it on switch0 interface, right?); even with no firewall/ACL rules, any other host on the switch0.xx interface(s) wouldn't be able to reach PC1 and vice versa; this only happened with 'vlan-aware enabled', and when it was disabled, hosts on switch0 and switch.20 would be able to contact each other. However, all devices could always ping switch0/192.168.1.1--just not to any other device on the switch0/192.168.1.0 subnet while 'vlan-aware enabled' was set, but they could reach hosts on the switch0 subnet while 'vlan-aware disabled' was set.

8. How come the setting 'vlan-aware enabled' made it so that hosts behind switch0 wouldn't be able to ping switch0.xx hosts despite all being connected on the routing table, but they were allowed to ping each other when 'vlan-aware disabled' was set?

9. (a) How was the ER-X respecting tagging with 'vlan-aware' enabled and disabled? (b) Was it passing the dot1q tags/trunking along all of its switch0 interfaces when it was disabled? The UAP SSID set to VLAN20 worked fine to get the 192.168.2.1/24 DHCP server IPs of the 192.168.2.0/24 subnet as well as respect its ACL either way the 'vlan-aware' was set--it just can't reach the switch0 subnet regardless of ACL being disabled while 'vlan-aware enable' was set.

 

Again, much thanks for your patience and participation @waterside.

Highlighted
Senior Member
Posts: 3,909
Registered: ‎05-15-2014
Kudos: 1398
Solutions: 267

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

@Harman20 In addition to mentioned resources, reading Layman's firewall explanation may help understanding the firewall basics.

Senior Member
Posts: 3,909
Registered: ‎05-15-2014
Kudos: 1398
Solutions: 267

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

@Harman20 See issue #10 mentioned in Known Issues of EdgeMax Series

 

 

10 SWITCH VLAN

EdgeRouter X Inter-VLAN routing issues

When using switch in vlan-aware mode, routing between switch0 and other vif interface isn't possible.

current workaround:  put switch0 config under switch0.1  (=vif1)

 

New Member
Posts: 14
Registered: ‎03-09-2018

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

[ Edited ]

@BranoB wrote:

@Harman20 See issue #10 mentioned in Known Issues of EdgeMax Series

 

 

10 SWITCH VLAN

EdgeRouter X Inter-VLAN routing issues

When using switch in vlan-aware mode, routing between switch0 and other vif interface isn't possible.

current workaround:  put switch0 config under switch0.1  (=vif1)


Ah, I was wondering if it were documented anywhere. I didn't see mentions of it in the VLAN guides.

Senior Member
Posts: 3,909
Registered: ‎05-15-2014
Kudos: 1398
Solutions: 267

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

I believe, the issue is HW limitation combined with the internal VLAN config on the switch, see from CLI

$ sudo /sbin/switch vlan dump
  vid  fid  portmap    s-tag
    1    0  invalid
    2    0  invalid
    3    0  invalid
    4    0  invalid
    5    0  invalid
    6    0  invalid
    7    0  invalid
    8    0  invalid
    9    0  invalid
   10    0  invalid
   11    0  invalid
   12    0  invalid
   13    0  invalid
   14    0  invalid
   15    0  invalid
   16    0  invalid
 4088    0  1-----1-       0
 4089    0  -1----1-       0
 4090    0  --1---1-       0
 4091    0  ---1--1-       0
 4092    0  ----1-1-       0
 4093    0  -----111       0
 4094    0  ---11-1-       0

 

New Member
Posts: 14
Registered: ‎03-09-2018

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

[ Edited ]

@BranoB

Spoiler

@BranoB wrote:

I believe, the issue is HW limitation combined with the internal VLAN config on the switch, see from CLI

$ sudo /sbin/switch vlan dump
  vid  fid  portmap    s-tag
    1    0  invalid
    2    0  invalid
    3    0  invalid
    4    0  invalid
    5    0  invalid
    6    0  invalid
    7    0  invalid
    8    0  invalid
    9    0  invalid
   10    0  invalid
   11    0  invalid
   12    0  invalid
   13    0  invalid
   14    0  invalid
   15    0  invalid
   16    0  invalid
 4088    0  1-----1-       0
 4089    0  -1----1-       0
 4090    0  --1---1-       0
 4091    0  ---1--1-       0
 4092    0  ----1-1-       0
 4093    0  -----111       0
 4094    0  ---11-1-       0

 


 

I barely understand what I'm looking at. I get that it's a Linux command (over ssh or telnet, probably), I get the file structure '/sbin/switch' with sbin being where critical files/executables are at and switch being the file executed with options 'vlan dump', but I don't get the output under 'fid', 'portmap' and 's-tag'.

 

I don't understand how this code limits switch0 from communicating with switch0.xx while 'vlan-aware enable' is set though.

 

I appreciate the high(er) level talk btw. I figure that it's better to talk at a professional level and just have the novice (me) ask questions to fill the gap(s).

 

 

Senior Member
Posts: 2,969
Registered: ‎08-06-2015
Kudos: 1253
Solutions: 174

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?


@BranoB wrote:

@Harman20 In addition to mentioned resources, reading Layman's firewall explanation may help understanding the firewall basics.

I had meant to include this too - completely forgot!  Perhaps you could work this up and submit as a KB article, begin the original author?  It does get referenced quite a bit.

 

@Harman20 wrote:



9. (a) How was the ER-X respecting tagging with 'vlan-aware' enabled and disabled? (b) Was it passing the dot1q tags/trunking along all of its switch0 interfaces when it was disabled? The UAP SSID set to VLAN20 worked fine to get the 192.168.2.1/24 DHCP server IPs of the 192.168.2.0/24 subnet as well as respect its ACL either way the 'vlan-aware' was set--it just can't reach the switch0 subnet regardless of ACL being disabled while 'vlan-aware enable' was set.

You may very well have been hitting the known issue referenced above when dealing with VID 1 as the default when vlan-aware is enabled.

 

When vlan-aware is enabled, the integrated switch will follow typical behavior through each of the physical ports with respect to tags, but with vlan-aware disabled the ER-X will completely ignore the 802.1Q headers and will keep them intact/untouched.

 

 

Emerging Member
Posts: 199
Registered: ‎09-13-2018
Kudos: 35
Solutions: 12

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

[ Edited ]

@BranoB wrote:

@Harman20 In addition to mentioned resources, reading Layman's firewall explanation may help understanding the firewall basics.


I agree that the Layman's firewall explanation is a great reference.

 

However, it was written for the ERLite3 (ERL), which has no ethernet switch.  And looking at it makes it appear there is no path between ethernet ports, except through the layer 3 router/cpu.   And that is true for the ERL.  To forward ethernet frames at layer 2 on the ERL requires bridge devices, and bridging (at least on devices without switch chips) is a software function that requires CPU involment, and that is why bridging has lower performance and is more processor intensive than switching.

 

Because the ERX has a L2 vlan aware switch integrated on its MediaTek MT7621 SOC, it can forward ethernet frames received on one port and forward them to another port in the same vlan.  However, the switch chip will not forward frames from one vlan to another, that has to be done by the router/cpu.  The integrated switch can also add/remove 802.1Q vlan tags, all without the involvement of the CPU.  The only way the CPU knows how many ethernet frames have been received or sent on a port is by asking the integrated switch controller.  

 

The devices you see when you type the cli $ show interfaces command, are "connections to the router/CPU".  vif (virtual interfaces e.g. switch0.23) are the "connection" to the CPU when in vlan-aware mode.  When not in vlan aware mode the switch0 device is the connection, and no ethernet frames are ever tagged with 802.1Q vlan tags.  For more info about 802.1Q vlans, you may want to look at the references in my post in https://community.ubnt.com/t5/EdgeRouter/ER-X-into-nested-Netgear-switches-VLAN-Can-t-get-an-IP-adre...

 

The firewall functionality is done by the CPU.  If you look at the output of /sbin/switch there are hints that the ERX's switching controller may have the ability to do layer 2 "filtering" with ACLs at the MAC level, but that functionality is not supported by EdgeOs.

 

See Re-visit the Switch in Edgerouter X for more accurate technical architectural details of the ERX and ERX SFP routers.

 

Here is my poor attempt at drawing a conceptual view of the ERX with paint, on this pc without visio.  For visual thinkers like me, pictures make understanding much easier.

 

ERX conceptual view.png

 

 

Senior Member
Posts: 2,969
Registered: ‎08-06-2015
Kudos: 1253
Solutions: 174

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?


@BuckeyeNet wrote:

Because the ERX has a L2 vlan aware switch chip, it can forward packets received on one port and forward them to another port in the same vlan.  However, the switch chip will not forward frames from one vlan to another, that has to be done by the router/cpu.  The switch chip can also add/remove 802.1Q vlan tags, all without the involvement of the CPU.  The only way the CPU knows how many ethernet frames have been received or sent on a port is by asking the switch chip.  

 

 


In an ER-X, there is not actually any separate "switch chip".  There is a single SoC (one "chip") that implements functionality at both layer-2 and layer-3, and is able to configure any of its five ports as either a layer-2 or layer-3 interface.  This same SoC includes the CPU, I/O controllers, memory controller, and offloading engine as well.

 

This really has nothing to do with whether or not there is a "switch".  The ER-X is a layer-3 device that can only filter at layer-3.  It does not provide layer-2 filtering.  It can forward traffic at layer-2 but that is largely the extent of the layer-2 support.

 

When vlan-aware is enabled, the switch will manage 802.1Q tags, and will present traffic to be forwarded at layer-3 via the appropriate layer-3 VIF (switch0.X).  When vlan-aware is not enabled, the switch will not manage 802.1Q tags but will still present traffic to be forwarded at layer-3 via switch0 (again, the layer-3 interface).

 

EdgeOS firewalls, based on iptables, only apply to layer-3.  It has nothing to do whether this is done by the CPU or by the switch.

 

I don't know if ebtables is (could be?) supported on an ER-X, but that would be not be supported as part of any EdgeOS configuration regardless.  Such underlying support would depend entirely upon the MTK SDK.  ebtables provides layer-2 filtering, while iptables provides layer-3 filtering.

 

Emerging Member
Posts: 199
Registered: ‎09-13-2018
Kudos: 35
Solutions: 12

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?

[ Edited ]

Yes, that is technically correct.  One of the reasons I had the link to Re-visit the Switch in Edgerouter X

 

I have edited my previous post  to replace "switch chip" with either a reference to MediaTek MT7621 or "integrated switch".

 

And yes, I am aware that the CPU is part the same SOC.

 

I thought what I wrote agreed with what you restated.

New Member
Posts: 14
Registered: ‎03-09-2018

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?


@BranoB wrote:

I believe, the issue is HW limitation combined with the internal VLAN config on the switch, see from CLI

Spoiler

 

$ sudo /sbin/switch vlan dump
  vid  fid  portmap    s-tag
    1    0  invalid
    2    0  invalid
    3    0  invalid
    4    0  invalid
    5    0  invalid
    6    0  invalid
    7    0  invalid
    8    0  invalid
    9    0  invalid
   10    0  invalid
   11    0  invalid
   12    0  invalid
   13    0  invalid
   14    0  invalid
   15    0  invalid
   16    0  invalid
 4088    0  1-----1-       0
 4089    0  -1----1-       0
 4090    0  --1---1-       0
 4091    0  ---1--1-       0
 4092    0  ----1-1-       0
 4093    0  -----111       0
 4094    0  ---11-1-       0

 

 


I partially understand what's shown. I recognize that it's a Linux command. I understand sudo as a program for running logged superuser commands from another user login, /sbin/ as the directory with executables for root, switch as one of those executables, and 'vlan' & 'dump' as options to the program switch. I also figure that vid is the VLAN IDs, right?

 

I don't know what fid, portmap or s-tag are or how the code-snippet suggests that switch0 can't talk to other VLANs.

 

I appreciate the high level talk. I figure it's better for all to try and talk at a professional level and let a novice (me) ask questions to have the gaps filled.

Senior Member
Posts: 2,969
Registered: ‎08-06-2015
Kudos: 1253
Solutions: 174

Re: ER-X: Firewall LAN_NETWORKS: Doesn't apply to intraLAN communication?


@Harman20 wrote:

I appreciate the high level talk. I figure it's better for all to try and talk at a professional level and let a novice (me) ask questions to have the gaps filled.

 

You are starting to delve into a bit of a deeper technical dive.  The short answer is that you are possibly hitting a known limitation (I don't know if it would be a 'bug') of this specific implementation.

 

A rough description to help understand:

Any vlan-aware switch will inspect incoming ethernet frames to look for an 802.1Q header.  If there is no such header present the switch will internally track that frame belonging to the PVID ("native" vlan).  If the PVID has not been explicitly configured for that port, the switch will use '1' as the PVID.  If there is an 802.1Q header, the switch will compare the value with the list of allowed VIDs for that port.  If none match, the frame is dropped.  If there is a match, the switch will strip the 802.1Q header and track that frame as belonging to the indicated VID.

 

Upon forwarding that frame, any vlan-aware switch will then compare the tracked VID with the PVID of the outbound port.  If they match, the frame is forwarded without any 802.1Q header added.  If they do not match, the switch will add the proper 802.1Q header to the frame and forward.  If the PVID has not been explicitly configured a value of '1' is used by the switch as the PVID.

 

There may be specific efficiencies and optimizations on any given implementation that vary from above, but the higher-level behavior is still the same.  There may also be some nuances with respect to traffic tagged with the PVID that are not specifically relevant here.   From above you can see why VLAN1 is somewhat "unique", and is part of why good practices also often suggest that VID 1 should be avoided from use when VLANs are configured.  There are security-related concerns to go with this but it gets into a bit of a deeper discussion.

 

You'll note that the concept of the "native" VLAN is specific to the local device.  In other words you could have two devices connected with one using PVID 3 and the other using PVID 5.  Because there would be no actual 802.1Q header the traffic entering/exiting the first switch would be on vlan 3 while the very same traffic entering/exiting the second switch would be on vlan 5.  This would not be a recommended configuration, to say the least Man Wink

 

With ERs, being based on a linux kernel, any given base interface (eth0, eth1, etc) sees all traffic, both tagged and untagged.  However only untagged traffic will be delivered to any given application using that interface.  VIFs (eth0.X, eth1.X, etc) are used for directing tagged traffic to/from the base interface.  Upon receipt of a tagged frame on the base interface, the kernel will look for a VIF with a matching VID.  if one does not exist, the frame is dropped.  If there is a match, the header is stripped and the traffic is passed to the application using the interface.  In reverse, traffic received from an application on a VIF has an 802.1Q header added by the kernel matching the noted VID.  In the case of a router such as an ER, the "application" is actually the kernel itself in performing its routing functions as well as any filtering (firewalling), etc.

 

You'll note that 'swtich0' is somewhat unique in that it is treated as a layer-2 interface by the switching implementation and a layer-3 interface by the routing implementation, both at the same time.  All other ports (ethX) are exclusively one or the other.  You will also notice there is no method to define a 'PVID' for the switch0 interface (there would actually be no need).  This perhaps is where the observed issue arises and why the noted workaround may be required.  This implementation is specific to the SoC and vendor-provided SDK.  Yes it can be confusing.

 

You can try defining a PVID on each switchport that is other than '1', and only use VIFs in your router configuration matching those VIDs (in other words you wouldn't configure an address/network on the base 'swtich0' itself and would only configure switch0 vifs with addresses/networks)

 

 

Reply