Connecting the bridge to a Vlan

[mikrodoog]

Hello, first a diagram:

Things I was able to do:

• Create 3 vlans on the port that goes to the AP
  Assign each SSID to each vlan
  Got the IoT vlan (98) to have dhcp service and internet connection
  Got the Guest vlan (108) to have dhcp service and internet connection
  The Aruba AP to obtain IP via DHCP, but seems to be over vlan 1 from the bridge

Things that I’m still not able to do:

• Make the bridge talk to the Home Vlan (88), meaning, I want the same dhcp to serve both bridge and Home Vlan. Also, that Home Vlan will be part of the LAN group. Think of the Home wifi Vlan as an extension of whatever is on the bridge. I could easily just assing Vlan 1 to the SSID in the AP and call it a day , but I don’t want to. I want to make it tidy and nice.

Also, from my NAS I want to be able to connect to the IoT Vlan, but the NAS is part of the bridge.

My config:
myconfig.rsc (12.5 KB)

[anav]

Simplify: One bridge 3 vlans ( home, iot, guest )

Internet access - guest, home, iot
guest/iot access - only the admin on home vlan.

/interface vlan
add interface=bridge name=Guest_vl vlan-id=108
add interface=bridge name=Home_vl vlan-id=88
add interface=bridge name=IoT_vl vlan-id=98

The aruba should get an IP address on the home subnet.
We know aruba is vlan capable, what we dont know is if it can accept all vlans tagged or if it needs the trusted vlan coming in untagged ???

/ip dhcp-server
add address-pool=default-dhcp allow-dual-stack-queue=no disabled=no
interface=Home_vl bridge lease-time=1d name=defconf
add address-pool=Guest_pool allow-dual-stack-queue=no bootp-support=none
disabled=no interface=Guest_vl name=Guest_dhcp
add address-pool=IoT_pool allow-dual-stack-queue=no bootp-support=none
disabled=no interface=IoT_vl lease-time=1d name=IoT_dhcp

/interface list member
add comment=defconf interface=sfp1 list=WAN
add interface=Home_vl list=LAN
add interface=Guest_vl list=LAN
add interface=IoT_vl list=LAN

/ip address
add address=192.168.88.1/26 comment=defconf interface=Home_vl network=
192.168.88.0
add address=192.168.108.1/27 interface=Guest_vl network=192.168.108.0
add address=192.168.98.1/29 interface=IoT_vl network=192.168.98.0
add address=192.168.78.1/24 comment=“Dedicated MGMT Port” interface=ether1
network=192.168.78.0
( no idea what this is ??? is it the static Ip assigned to the router ?? )
Okay now I know! It looks like you are trying to set an Admin access port which is fine, but just remove ether1 from the bridge
This is actually recommended so that you can configure the router especially to any part of the bridge while safely off the bridge.

/interface bridge port
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=88
add bridge=bridge ingress-fitering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=88
add bridge=bridge ingress-fitering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=88
add bridge=bridge fast-leave=yes ingress-filtering=yes frame-types=admit-only-tagged-vlans interface=ether 5 trusted=yes

/interfac bridge vlans
add bridge=bridge tagged=bridge,ether5 vlan-ids=98,108
add bridge=bridge tagged=bridge,ether5 untagged=ether2,ether3,ether4 vlan-ids=88

Whats at 192.168.88.7 ???
Why these????
/ip dns static
add address=192.168.88.1 comment=defconf disabled=yes name=router.lan
add address=192.168.88.1 comment=defconf name=router.home.arpa
add address=192.168.88.4 disabled=yes name=ix2.local

How do you expect IoT devices to find their cloud homes if you block port 53?
I imagine your simply using them locally on NAS etc and dont want them to connect to the internet and thus part of that is block DNS access?
Probably a more efficient way to handle that.

I dont get your allowing ICMP by firewall address list. Its unecessary. Simply use the following default rule.
add action=accept chain=input protocol=icmp

In fact your input chain is not consistent with your intent.
You allow all from LAN, why should all user have access to the router?? Certainly not wifi guests or iot and probably nobody that is not the admin.
How to handle that properly is the following. FIXED, cleaner, for your needs.
…

/ip firewall filter
{Input Chain}
[add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input in-interface-list=LAN  src-address-list=Authorized comment="admin only"
add action=accept chain=input comment="VPN TGE" dst-port=1723 protocol=tcp src-address-list=LATAM
add action=accept chain=input comment="Allow LAN DNS queries-UDP/NTP dst-port=53,123 in-interface-list=LAN protocol=udp 
add action=accept chain=input comment="Allow LAN DNS queries - TCP" dst-port=53 in-interface-list=LAN protocol=tcp
add action=drop chain=input comment="drop all else"
{forward chain}
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward comment="allow internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
add action=drop chain=forward comment="drop all else"

NOTE1: IF you want to exclude the iot subnet from access to DNS services in the INPUT CHAIN, and also from wan access in the FORWARD CHAIN, then modify the rules as follows:

add action=accept chain=input comment="Allow LAN DNS queries-UDP/NTP dst-port=53,123 in-interface-list=LAN protocol=udp src-address=!192.168.98.0/29
add action=accept chain=input comment=“Allow LAN DNS queries - TCP” dst-port=53 in-interface-list=LAN protocol=tcp src-address=!192.168.98.0/29
add action=accept chain=forward add action=accept chain=forward comment=“allow internet traffic” in-interface-list=LAN out-interface-list=WAN src-address=!192.168.98.0/29

NOTE2: You will need to make a firewall address list for admin IPs. ( static leases set in dhcp )

add address=adminDesktop list=Authorized
add address=adminLaptop list=Authorized
add address=adminIpad/Iphone list=Authorized
add address=admin VPN remote IP list=Authorized
add address=192.168.78.X list=Authorized. whatever IP you will use for ether1 access.

What is the purpose of this routing rule?? It is not required as its local to the router and thus the router is already aware and in fact already has DAC routes for all local subnets.
/ip route
add check-gateway=arp distance=1 dst-address=192.168.0.0/23 gateway=bridge


Set this to NONE as [mac server by itself] its not a secure access method to the router.
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

[mikrodoog]

add address=192.168.78.1/24 comment=“Dedicated MGMT Port” interface=ether1
network=192.168.78.0
( no idea what this is ??? is it the static Ip assigned to the router ?? )
Okay now I know! It looks like you are trying to set an Admin access port which is fine, but just remove ether1 from the bridge
This is actually recommended so that you can configure the router especially to any part of the bridge while safely off the bridge.

-Exactly, kinda like a “last resort” access in case I mess up the config.

Whats at 192.168.88.7 ???

-That’s the pihole dns server. For my Home lan, is my internal dns server.

I dont get your allowing ICMP by firewall address list. Its unecessary. Simply use the following default rule.
add action=accept chain=input protocol=icmp

-That is to get only icmp from specific places (in detail, is only the latam region), like work and my family’s router or network. The rest don’t need to know if I’m alive

In fact your input chain is not consistent with your intent.
You allow all from LAN, why should all user have access to the router?? Certainly not wifi guests or iot and probably nobody that is not the admin.

-The rules were not finished yet, sorry about that. I was still trying to figure out the communication thing.

What is the purpose of this routing rule?? It is not required as its local to the router and thus the router is already aware and in fact already has DAC routes for all local subnets.
/ip route
add check-gateway=arp distance=1 dst-address=192.168.0.0/23 gateway=bridge

-That is for the IPSEC I got from work. I can access the servers from my PC


Now, let me re-read all the corrections you made and try to understand, to them apply them.

[anav]

(1) It doesnt have to be access of last resort, I acctually prefer it as the config access of first resort!

(2) Okay you have a pihole server, who is supposed to use it, who is not supposed to use it?
Okay home vlan, but what about iot vland and guest vlan??

(3) There is no harm in ICMP access, other than the threat of your paranoia . and actually is useful for troubleshooting but okay if you want to limit it…
Thus skip all the fancy rules just modify the rule provided.
make one source-address-list
and change rule to
add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp src-address-list=COMPLETE-LIST

Just ensure on the complete list you include, besides the external folks,
add address=192.168.88.0/24 list=COMPLETE-LIST comment=“able to ping from home lan”
add address=192.168.78.0/24 list=COMPLETE-LIST comment=“able to ping from offbridge access”

(4) Ref the route. Still not clear.
Remember your router can already route traffic to any of your LAN subnets, you dont need to create another.
this includes: 192.168.78.0/24, 192.168.98.0/24, 192.168.108.0/24 and 192.168.88.0/24

Perhaps you mean you wish to connect via ispec to remote Subnets?
If so you need to be specific which ones, and the gateway to ipsec is NOT the bridge.

[mikrodoog]

You know? for some reason, I still don’t have access to the nas and the servers on ports 2,3,4.
Cannot find what am i missing.
myconf.rsc (13 KB)
I haven’t touched the firewall rules yet.

As for the ipsec, I will resolve it later then.

Edit: for some reason this does not seem right. The part that says Current tagged and untagged is empty.

Edit2: nevermind, I got it, I forgot to enable VLAN filtering on the bridge. But stil, I’m unable to access the servers on ports 2,3,4.

Edi3: I figure it out.

I moved the Home_vl from the ether5 to the bridge, and then I had access to the ports

Before I had it on ether5, and I was unable to reach ports 2,3,4. .

Then I moved it back to the bridge, then I had access to the port 2,3.4

[anav]

As per the config I gave you they should all have interface of bridge, not just home_vl

[mikrodoog]

Perhaps you mean you wish to connect via ispec to remote Subnets?
If so you need to be specific which ones, and the gateway to ipsec is NOT the bridge.

Well, the remote subnet is 192.168.0.0/23 and my is 192.168.88.0/26.
There is something odd.
While restoring everything, all worked except the ipsec. The tunnel was UP, but I could not get a route to the remote network.
I went to Routes and something told me: change the gateway from bridge to Home_vl like you did before. After that, I could get connection back to the remote network over the ipsec.

So, I know you will say that the gateway is not the bridge, but seems that the software attached the bridge or whatever interface is OVER the bridge (in this case, the vlan now) and acts as a gateway.
Why? I don’t know.

Btu after all that, I’m officially on vlan88 and with the rest of the vlans working.
Tomorrow I will sit down and work out the firewall rules.

Thanks for the help.

[mikrodoog]

As per the config I gave you they should all have interface of bridge, not just home_vl

OOOOOH, that explains it all.
Sorry, I was configuring all manually over my current config. That explains a lot hehe.

Again, thanks for all the help. I will make the corrections.

[mikrodoog]

As for final thoughts:

Regarding the guest vlan, if you do all the config, but leave that vlan attached to the ether5 interface. It doesn’t matter what you do in regards of routing, you will NOT be able to access the devices on the ports 2,3&4. Because the vlan is just attached to the ether5 and not the bridge.
Thus, isolating perfectly the guest vlan from the rest of the network, no need of firewall rules or anything.
That also means, for some odd reason, I cannot ping the default gateway that I have assigned for that vlan (I don’t mind actually), but I can ping the internet and get dns resolution.
How is this functioning? I don’t know, but it is kinda what i wanted. So, there you go.

Now, someone will more knowledge will explain why, because I don’t know. But what I do know is that the vlan has dhcp services, dns and it can access the internet. And that’s all I need. YAY.

[anav]

Many ways to do things, I prefer simplicity and consistency.