Setting up a management VLAN on a bridged AP

I want to use a management VLAN on my bridged AP and ensure that only that network has access to the administration of that device. Here's the current situation:

I referred to one of our older threads regarding carrying vlans. I mimicked that config for vlan10 and vlan30.

I mimicked the current good-known-config for vlan10 to vlan30 on the switch vlans.

I am able to connect to vlan10 via SSID. I am getting connected, no internet. It is not pulling a 10.x address
I am pulling a 192.168.30.x IP from eth4 on the router but unable to ssh to the AP when vlan30 is selected as the ssh interface.

current config:

AP


config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd91:4cfb:b589::/48'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan'

config interface 'lan'
        option device 'br-lan.1'
        option proto 'static'
        option ipaddr '192.168.1.2'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option gateway '192.168.1.1'

config bridge-vlan
        option device 'br-lan'
        option vlan '1'
        list ports 'lan:u*'

config bridge-vlan
        option device 'br-lan'
        option vlan '10'
        list ports 'lan:t'

config interface 'vlan10'
        option device 'br-lan.10'
        option proto 'none'
        option type 'bridge'

config bridge-vlan
        option device 'br-lan'
        option vlan '30'
        list ports 'lan:t'

config interface 'vlan30'
        option device 'br-lan.30'
        option proto 'none'

router

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1'
        list ports 'eth2'
        list ports 'eth3'
        list ports 'eth4'

config bridge-vlan
        option device 'br-lan'
        option vlan '10'
        list ports 'eth1:t'
        list ports 'eth2:u*'

config bridge-vlan
        option device 'br-lan'
        option vlan '1'
        list ports 'eth1:u*'

config bridge-vlan
        option device 'br-lan'
        option vlan '20'
        list ports 'eth1:t'
        list ports 'eth3:u*'

config bridge-vlan
        option device 'br-lan'
        option vlan '30'
        list ports 'eth1:t'
        list ports 'eth4:u*'

config interface 'lan'
        option device 'br-lan.1'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option delegate '0'
        option ipv6 '0'
       

config interface 'GST'
        option proto 'static'
        option device 'br-lan.10'
        option ipaddr '192.168.10.1'
        option netmask '255.255.255.0'

config interface 'cams'
        option proto 'static'
        option device 'br-lan.20'
        option ipaddr '192.168.20.1'
        option netmask '255.255.255.0'

config interface 'mgmt'
        option proto 'static'
        option device 'br-lan.30'
        option ipaddr '192.168.30.1'
        option netmask '255.255.255.0'

fw


config defaults
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'vlan_1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'vlan_10'
        option output 'ACCEPT'
        option forward 'REJECT'
        option input 'ACCEPT'
        list network 'GST'             

config zone
        option name 'cams'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        list network 'cams'

config zone
        option name 'mgmt'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        list network 'mgmt'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list network 'wan'

config forwarding
        option src 'vlan_1'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Allow-vlan10-DNS'
        option src 'vlan_10'
        option dest_port '53'
        option target 'ACCEPT'
        list proto 'tcp'
        list proto 'udp'

config rule
        option name 'Allow-vlan10-DHCP'
        list proto 'udp'
        option src 'vlan_10'
        option dest_port '67-68'
        option target 'ACCEPT'

config forwarding
        option src 'vlan_10'
        option dest 'wan'

From the AP network config, remove the last line here (option type 'bridge') as it will break the interface:

Then restart the AP and test again.

Also, based on the configuration, VLANs 1 (LAN) and VLAN 10 (guest) are expected to reach the internet, but the other two (VLAN 20/cams, and VLAN 30/mgmt) will not be able to do so.

Can you please explain why they don't reach the internet? Is it firewall rules or otherwise?

Can you help me be able to only reach the AP via ssh when i'm on vlan30? I.E wired to eth4? I have read the luci.secure documentation and wrote an openssh wrapper that allows me to easily connect to a local-port-forwarded luci session and bring it up as needed. So my goal is to restrict ssh to vlan 30, disable luci when not in use, and tunnel it over ssh when it is active.

Thanks, I will modify the AP config and test without the bridge options

Firewall rules.

Specifically, you don't allow forwarding from these networks/zones to the wan. An example where this is allowed is here (VLAN 10):

In the absence of this forwarding or any other similar rules, routing will not be allowed between the network in question and the wan/internet.

This is not expected. In fact, currently your AP has an address only on VLAN 1:

So you should only be able to reach the AP at the address: 192.168.1.2. And I would only expect that to be an option when you are connected to that network (i.e. with an address in the 192.168.1.0/24 network).

Are you seeing something different? Please be specific about how you're accessing it (the IP address of the source device, the IP address used as the target/AP's connection address), wifi vs wired connectivity).

Ok, the forwarding rules make a lot of sense now. I can easily distinguish between input/output and the forwarding rules in terms of functionality.

Nope, this is the current behavior i'm able to access it via wired switch connections and WiFi connections on the vlan1 ssid. Here is my goal behavior if it is possible:

Keep the AP on the vlan1 lan 192.168.1.x
within luci/administration/ssh set the listening interface to the bridged vlan30, which can only be accessed via eth4 on the router. When on eth4/vlan30, I plan to tunnel luci through ssh. This got me thinking... Couldn't I assign two IP addresses to one interface, I.E assign a 192.168.30.x IP to the interface side-by-side the 192.168.1.x IP? Is this possible in openwrt? Do you have any suggestions otherwise to accomplish this goal?

This is the cause of a lot of confusion... just to make sure it is clear:

  • input controls the ability to connect to the router itself. It is the router's input from a given source/zone. If it is set to reject/drop, hosts will not be able to access the router itself (which is why you need to allow DHCP and DNS for guest networks where this is often set to REJECT, for example).
  • output controls the traffic egressing from the firewall towards the target zone/network. This should almost always be ACCEPT.
  • forward controls the intra-zone forwarding between networks. Specifically, if you have two or more networks assigned to the same zone, this will allow or prohibit them from connecting to each other. It doesn't affect inter-zone forwarding.

Ok... sounds consistent with the way the configuration currently sits.

I think you'll want to change this to unmanaged, but that can be done later.

In this case, you want to setup a static IP on VLAN 30 on the AP:

config interface 'vlan30'
        option device 'br-lan.30'
        option proto 'static'
        option ipaddr '192.168.30.2'
        option netmask '255.255.255.0'

You will also need to add vlan30 to the lan firewall zone on the AP (or create a new zone for it that has input = ACCEPT).

Why? There's no real value here.

Not with the VLANs as they are. It would only mess things up. In general, it is bad practice to have multiple addresses on a single interface, although there maybe certain narrow use cases for that scenario. This is not one of them, though.

so drop will be overridden by explicit-allow rules then it sounds like, this makes sense. Then shouldn't we set drop by default and set explicit allow for robust security? Also, how can clients reach http 80/443 without these explicit rules in a drop scenario?

Difficult to wrap my head around. Example: vlan1 and vlan10 are in the same firewall zone. All my brain sees within luci is Vlan1 and vlan10 stacked in a zone with the forwarding box empty. How can I better understand what's going on here? Are configs easier to read than luci?

What do you mean by inter-zone forwarding?

    option ipaddr '192.168.30.2'

This needs to be 192.168.30.2 because 192.168.30.1 is taken on the root device/vlan (router) and is the router's vlan interface IP correct?

Got it.

luci/uhttpd can still be accessed via vlan1 by virtue of the interface IP 192.168.1.1 is reachable. This is true from all vlans correct? Even theoretically if someone got onto my vlan10 ssid, they could also reach 192.168.10.1 and meet luci. I think firewall rules would work here... but saving the uhttpd resources seems OK too.

very good to know.

The only zone that is default input 'ACCEPT' is the lan zone. This is considered the trusted zone. You can change this, of course, but it is a reasonable assumption for most environments. And you want the router to respond to pings, web and ssh services without needing to add any additional rules, especially for the default sitaution.

They cannot. But don't forget, we're talking about the router's own web interface here, not the internet. That's why the default lan zone uses ACCEPT. It's also why guest networks are typically recommended to be REJECT because guests do not need to access the router's admin features.

I'm referring to the zone Forward rule that is next to the Input and Output rules (not the forwarding boxes). I know it's a bit confusing, though. There will always be one of three options defined: ACCEPT, REJECT, or DROP.

I would say so, but this is in part that I am very used to it, and also in part because you can see the whole picture in just a few files rather than possibly dozens of screenshots.

  • Intra-zone forwarding: forwarding of packets between two or more networks in the same zone
  • Inter-zone forwarding: forwarding of packets between two or more networks that are in different zones.

correct.

Yes. More complete: it is because the router has an address on that network, that network is assigned to a firewall zone, and that firewall zone has the input rule set to ACCEPT.

No, but there are slightly different reasons for the router and the AP.

On the AP, only the lan interface currently has an address, the others are unmanaged (so there's no address on those other networks, see the previous point about the trifecta of conditions required). And the other VLANs cannot reach the AP (at address 192.168.1.2) because router's firewall doesn't allow it.

For the router, you have set the input rule to REJECT for the cams and guest network. The lan and mgmt networks do allow input. So the router will be reachable only when connecting from the latter two networks. Don't be confused, though -- the router will responds to any of it's addresses (including the cams and guest addresses), but it will only be reachable from the networks that allow access to the router (mgmt, lan).

Nope, they cannot. Try it.

It's not adding any additional overhead. The firewall rules are correct in the current state, except for the fact that your longer term goal is to make the management of the devices only possible via the mgmt network (and not the lan).

Ah, I'm looking now and see the Forward: Reject.
I was thinking input needed to be reject, but now I understand that is only for accessing the router itself. The router is hosting DNS and DHCP, so the explicit rules will allow that if configured correctly (for vlan10 ---- vlan 20/cams and vlan30/mgmt don't need it for now)

But, even if I set Forward to Accept. What is it forwarding to? WAN by default just through the underlying config/code? My brain is saying... no it's intra-zone forwarding, but my other brain has not understood that entirely. I see these rules and they make clear sense. We are allowing this firewall zone to forward to lan. I feel like i'm close to getting this 'picture'

config forwarding                     
        option src 'vlan_1'           
        option dest 'wan' 

I have added this static IP

config interface 'vlan30'        
        option device 'br-lan.30'     
        option proto 'static'         
        option ipaddr '192.168.30.2'  
        option netmask '255.255.255.0'

what are the implications of having firewall rules for the AP's lan interface? I just noticed it has all of those crazy default rules. since masq is off, this can't be a threat because it's NAT'd right?

here's my AP firewall:

config defaults
        option syn_flood '1'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

I really only NEED lan, right? I dumped the other rules assuming the router's firewall is the only necessary edge.

what would the syntax look like for this the interface name?

config interface 'vlan10'     
        list network 'lan'
        list network 'vlan30'

?

This is only relevant if you have two or more networks within the same firewall zone. In that case, it would allow forwarding between those networks.

It depends what the rules do and what your goal is. The question you've asked is a little like "how long is a piece of string?"

If you do not want the lan network to have access to the AP, you can make it an unmanaged network on that device because you've now got the management network defined (wait, though, until you ensure it works properly).

In truth, for the AP itself, you only need management in the firewall... you could delete the lan or edit it:

Yes, basically...

So... there are a few ways to do this -- chose one, and only one:

  • option 1 - keep the lan zone as it is, but add the vlan30 network:
config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'
        list network 'vlan30'
  • Option 2: keep the lan zone, add vlan30 and remove the lan network:
config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'vlan30'
  • Option 3: delete the lan zone or edit it to look like this:
config zone
        option name 'mgmt'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'vlan30'

BANG. I get it now.

This seems ideal. Just assume I live with a lot of non-technical people who want it to 'just work'. I have Comptia Net+ and Comptia Sec+, but obviously not a genius in networking. I usually just played with Fortinet GUI's at work. Now i'm really diving into open source networking and security.

I like this schema most. Can we do this?

Yup... go for it.

Now all that's left is to set the AP to unmanaged. How should I think about this? The device is unmanaged, just the one network, the interface?

Now that I have no firewall rules for lan, how exactly is my vlan1/nativeVLAN from the router communicating and bridging the networks? Strictly through the /etc/network configs? I'm in the weeds now...

Before you do this, let's just review the AP's current network and firewall files.

Cool, I just organized them a bit. It was bothering me...

/etc/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd91:4cfb:b589::/48'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan'

config interface 'lan'
        option device 'br-lan.1'
        option proto 'static'
        option ipaddr '192.168.1.2'
        option netmask '255.255.255.0'
        option gateway '192.168.1.1'

config interface 'vlan10'
        option device 'br-lan.10'
        option proto 'none'

config interface 'vlan30'
        option device 'br-lan.30'
        option proto 'static'
        option ipaddr '192.168.30.2'
        option netmask '255.255.255.0'

config bridge-vlan
        option device 'br-lan'
        option vlan '1'
        list ports 'lan:u*'

config bridge-vlan
        option device 'br-lan'
        option vlan '10'
        list ports 'lan:t'

config bridge-vlan
        option device 'br-lan'
        option vlan '30'
        list ports 'lan:t'

/etc/firwall

config zone
        option name 'mgmt'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'vlan30'

Ok... so the change should be simple... edit the lan so that it looks like this:

config interface 'lan'
        option device 'br-lan.1'
        option proto 'none'

DOH. It's an unmanaged interface. Just like vlan10, by virtue of having no IP address assigned, correct?

Cool. I will test this tonight when I won't get something thrown at me if it goes down, need to reboot too. :smiley:

Yup... that's the whole thing.

You should have your goals met by this change.