Simple Vlan setup: 2 access ports on same VLAN, one trunk

Thanks,

Good tip to go back to basics. Here’s how/what I investigated:

  • vlans have proper dhcp settings that gets allocated just fine over the trunk. Which lead me to believe that both the bridge/vlan association and the dhcp address pool/vlan are working fine
  • I indeed disabled my arp- thingy, with no better success
  • I checked over and over the port allocation to the vlan
  • I actually set an IP to the laptop connected to the access port (static IP) and tried to ping the mikrotik
    None of these brought results.

Thanks for the invite to have a look at the latest version.
I’ll dump and send

Cheers

Okay looking at it now.
(1) Please ensure for interface list members that you do identify all the vlans to the LAN interface as requested originally.
Dont care about all the other list member items you have but do include those.

add interface=“vlan4(private)” list=LAN
add interface=“vlan8(guest)” list=LAN
add interface=“vlan9(GTwork)” list=LAN
add interface=“vlan10(CLBwork)” list=LAN
add interface=“vlan11(flat231)” list=LAN

If I was to comment on the rest of them I would state…
You do not need to put etherports as interface list entries.
You should put your ovpn and IPSEC interface as list entries and the applicable vlans to identify the trusted interface list members…

Other than that dont see anything that stands out.

I’m sadly reporting no tangible progress: I am still unable to get the VLAN access port to work, while the trunk works fine.

I marked all these VLAN as lan, as recommended by your last post, ie:

/interface list member add interface="vlan4(private)" list=LAN-Interfaces

Following your advise to work on the fundamentals:

  • I have greenlighted some areas that work: VLANS through the trunk port work and DHCP uses the proper IP address pool per VLAN. Which leaves me to believe that the bridge, VLAN and DHCP pools are all OK.
  • when connecting to a physical interface and manually setting a static IP, I don’t get access
  • I even tried to reboot the device
  • Consequently, I think it narrows it down to the association of VLAN and physical port. This is where I focused my efforts.

Still not getting the access port to work and I’m confused on these specific items:

1- double/redundant setting in bridge of associating a VLAN ID with the physical port in Mikrotik’s logic
Indeed the config seems to require to set the VLAN ID for the access port in 2 areas:

  • at the /interface bridge port level with the command:
/interface bridge port add bridge=BridgeVlanToLan comment="Access port" frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ETH6-LAN pvid=8



  • then again at the /interface bridge vlan level with the command:
/interface bridge vlan add bridge=BridgeVlanToLan tagged=ETH7-LAN_Trunk,BridgeVlanToLan untagged=ETH6-LAN vlan-ids=8

Both these commands seems to state the same: get Vlan ID 8 on port ETH6-LAN

2- Disabling specific VLAN that goes through Trunk has no effect
I would have expected that disabling this command would result in the VLAN 9 to no longer be tagged on the tunk port … but disabling it does nothing: I still have this VLAN through the trunk

/interface bridge vlan add bridge=BridgeVlanToLan tagged=BridgeVlanToLan,ETH7-LAN_Trunk vlan-ids=9

For the sake of completeness in trial and errors, I need to point out that I tried disabling this command below, and I confirm that when disabled, then the whole trunk doesn’t work at all

/interface bridge port add bridge=BridgeVlanToLan comment="Trunk port" frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=ETH7-LAN_Trunk

So I’m puzzled: it seems Mikrotik uses the /interface bridge port command above to define the trunk and throw all VLAN IDs into it.
I was expecting the command /interface bridge vlan to be mandatory for the trunk to work by exhaustively listing the VLAN IDs that are to be passed through the trunk. It doesn’t seem the case: as written above, disabling this command has no impact, the trunk keeps working fine.


3- /interface bridge host print does not associate VID to hosts
I don’t know if this is normal, but when running the command

/interface bridge host print

I see the list of MAC-ADDRESS, one per line, but the column VID is empty.
Shouldn’t I see here the VLAN ID displayed in front of each mac access?
It might be minor, since each mac address does get allocated to the proper vlan through trunk (as it gets its IP address handed over from the DHCP server).

But the command

/ip arp print

Does show properly list the mac-addresses and associate them with the correct VLAN


Conclusion and next steps:
I have removed a bunch of previously-disabled items (ip pool, dhcp settings, bridge and interfaces).
@anav I have sent you an updated config file (smaller, because of the removal of the disabled items). We could work on this smaller file to further redact and publish here to get some further eyeballs at why I can’t get the vlan access port to work.
Should the bridge be activated for VLAN filtering, and if yes for what PVID, and should I set ingress-filtering to yes?

/interface bridge set BridgeVlanToLan vlan-filtering=yes

I have run out of things to try.

Yes, the bridge should be activated YES as you have posted it.
The default bridge vlan should be left as is.

You do not need to post the /interface bridge vlan rules for the untagged components as the router will dynamically create them based on the bridge port settings.
I prefer to set them manually anyway for two reasons… one when looking at my config I like to map my bridge port settings to my bridge vlan settings to see my logic.
two… an export and also viewing in winbox will not show the untagged relationship in vlans unless the vlan is in use (invisible) and I prefer the visible 100% of the time.
In any case will not do any harm… and you confirm that the other untagged vlans work fine right ???
you didnt disable the ether7 trunk interface list member…

Thanks anav,

in my setup, I had not enabled the filtering on the bridge - this was something I found googling around, incl. in the post from your first response.
I will try activating this and see if it makes a difference.
Also, I have removed the ETH7 port as lan, thanks for spotting this.

I understand your response on the first item that confused me about having to double-config this association between an eth-port and the vlan.

I’m not sure I follow your question on “you confirm that the other untagged vlans work fine right ???”
On the mikrotik router, I can’t plug into an ethernet port and get an access port (ie: untagged vlan). BUT the tagged one (on the trunk port) does work well: the switch and access points connected to that trunk do manage to associate to the proper VLAN.
So I’m not in a setup where I have one port that enables me to have untagged VLAN associate to a vlan of my choice

Yeah I did a face palm when I realized you had not set bridge vlan filtering to YES, yet.
Its one of the explicit instructions on the link.
http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1

I facepalmed too…

With that setting enabled, it now works as intended!
All these hours, while being one checkbox away from the desired outcome…

Many thanks for sticking with me through this process. I learned a lot.

Well as Sob would say, the config looks much better now that it has been “anavIZED” :wink:
Personally I would get rid of all the xtra firewal rules for anything other than the defaults plus what is essential for a working network
(drop all icmp crap, raw crap, ddos crap, port scanning crap etc…)

I would invest in MOAB (couple of cups of coffee a month) https://itexpertoncall.com/ and put that on the device and with solid fundamentals in the firewall rules, should be worry free.
The biggest problem is shitty admins, that a. dont keep firmware up to date, b. let every LAN user have full access to the router, c. Even worse allow unencrypted remote access to the router. d. dont change default user names and passwords, think nothing of running insecure servers, and servers without a defined source-address list, etc…

The anavIZED brought tremendous value, I’m sure sob was well aware of this way before me!


… but … but this is my crap. Hard to let go :slight_smile:
I actually build it from other forum’s veteran discussion around this forum

I know and I read them all the time.

I would consider only one of them relevant for real…do the bogon one but differently no firewall rules just in IP Routes.
The rest toss like garbage. Unless you are using an edge router just for the firewall to do these things… good luck stopping DDOS for example…
As for Port scans… they are going to keep scanning day in and day out because they are bot driven and automated, so they rotate public IPs, probe frequency and ports.
Its not like your stopping any individual, who would waste their time in this day and age. So your attempting to stop an unrelenting army of bots with scan rules… GLuck with that.
I simply drop all at the end of the forward and input chains… (have not had any issues - but I am not a major institution LOL)

LIke I said I would just us the service I noted above, the standard firewall rules, the bogons via IP routes and get on with life.
ver6
/ip route
add dst-address=10.0.0.0/8 type=unreachable
add dst-address=172.16.0.0/12 type=unreachable
add dst-address=192.168.0.0/16 type=unreachable
ver7
/ip route
add dst-address=10.0.0.0/8 checkbox blackhole
add dst-address=172.16.0.0/12 checkbox blackhole
add dst-address=192.168.0.0/16 checkbox blackhole

Fill your boots if you want to address the rest of them…
0.0.0.0/8
127.0.0.0/16
169.254.0.0/16
192.0.2.0/24
192.88.99.0/24
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
224.0.0.0/4

Even the first config you posted didn’t have vlan-filtering enabled, you should have noticed it back then! Greetings from Captain Hindsight. :smiley: But I’ll be honest, I missed it too.

And bogons in firewall is not wrong. The way with routes is simple, but it deals only with outgoing traffic (which may be enough, but it’s less than you can do with firewall). Main advantage is that you can’t easily mess it up when playing with firewall. Too bad there’s no unreachable in v7 anymore.

Thanks anav to share

to be fair, I indeed copied these flood scanner rules and others, but you’ll see they were disabled.
Your comments drive me to do what I pushed back “for later”, which is to delete these rules that were disabled since a while now.

It’s an interesting approach to use the bogons in routing and not firewall
At first, I thought you essentially orient/prevent the traffic from going out of the mikrotik; while firewall prevents the traffic from coming in.
But with RP-filter in loose (or strict), the packet is checked and discarded if no route exist; acting as an inbound filter too.
That’s an interesting perspective!

@sad: Hi cap’ :slight_smile: I’ll beat myself on this filtering option, a “small missing stuff that acts as a wrench in my wheels”
I wasn’t aware this feature got discarded in v7. Thanks for the insight

FYI, I’m still going through the router to check the conf.

For closure (and if this can help other post readers in the future).
With the VLAN filtering now activated in the bridge, now the command

/interface bridge host print

indeed displays the proper VID in front of the mac address.
A different behavior than what I wrote earlier today where the VID field was left blank.