My understanding right now is that the AP should respond to Mikrotik request.

My understanding right now is that the AP should respond to Mikrotik request.

Except that the very point of arp=reply-only is that no request ever comes :) This setting is a poor man's substitution of 802.1x. It prevents RouterOS from sending ARP requests on that interface and thus from dynamically populating the ARP table (IP->MAC address translation) on demand; instead, the ARP record is created when a DHCP lease is given to the client (and removed when the lease expires), so devices which manually set the IP from the proper subnet cannot receive any traffic from the Mikrotik. But this must be explicitly enabled in the DHCP server configuration. Or you can create the ARP records manually (using the ones added dynamically while arp=enabled as a base) and then set arp=reply-only if the APs do not obtain their addresses from the Mikrotik.

An eventual attacker may beat arp=reply-only if he first sniffs both the MAC addresses and the IP addresses related to them from live traffic (which is quite simple) and then spoofs them. Only the real 802.1x is secure as the MAC address alone is not enough for authentication, the device must know the proper secret.

So are there any workaround in this?

• use separate VLANs for the wireless interfaces and for the management,
• use CAPsMAN to let the APs transport the wireless traffic encapsulated into UDP to the hotspot router and land it on a separate bridge there,
• set arp=enabled for a while, ping all the APs' addresses in 192.168.5.0/24 to obtain the ARP records, and then set arp back to reply-only - this means you have to add the ARP record for each newly added or replaced AP manually,
• connect the APs to a bridge at the hotspot router side and use /interface bridge filter rules to block ARP requests sent by the Mikrotik to the APs for IP addresses in the 10.0.0.0/24 range (which would selectively substitute the arp=reply-only setting on the bridge so you could put back arp=enabled - but this last option leaves the attacker the possibility to choose an address from 192.168.5.0/24 and bypass the protection.

So are there any workaround in this?

In our culture, mentalism has no real tradition, so I can't see your network setup clearly. So what I assume is that you run the 192.168.5.0/24 and the 10.0.0.0/24 in the same (V)LAN, and you want to keep the arp=reply-only behavior in place for the hotspot clients. So depending on what type of APs you use, you may

• use separate VLANs for the wireless interfaces and for the management,
• use CAPsMAN to let the APs transport the wireless traffic encapsulated into UDP to the hotspot router and land it on a separate bridge there,
• set arp=enabled for a while, ping all the APs' addresses in 192.168.5.0/24 to obtain the ARP records, and then set arp back to reply-only - this means you have to add the ARP record for each newly added or replaced AP manually,
• connect the APs to a bridge at the hotspot router side and use /interface bridge filter rules to block ARP requests sent by the Mikrotik to the APs for IP addresses in the 10.0.0.0/24 range (which would selectively substitute the arp=reply-only setting on the bridge so you could put back arp=enabled - but this last option leaves the attacker the possibility to choose an address from 192.168.5.0/24 and bypass the protection.

This way, the clients can access the management interface of the APs if they manually assign themselves addresses from 192.168.5.0/24.

What was the question you forgot to add to you delaration?

What was the question you forgot to add to you delaration?

What do you mean?

What was the question you forgot to add to you delaration?

What do you mean?

In the post to which I've replied this, you've provided the information about the current topology, but you wrote nothing that would require any reaction. So I was assuming that, once you've shown the topology, there was some related question - otherwise, what would be the purpose of posting it?

This way, the clients can access the management interface of the APs if they manually assign themselves addresses from 192.168.5.0/24, and the arp=reply-only cannot prevent that, as ARP is only used when routing is necessary to deliver a packet, which is not the case to a client associated to one of the APs if he uses a 192.168.5.x address.

I am very confused about with vlan rn... and still trying to understand it.

I am very confused about with vlan rn... and still trying to understand it.

VLAN implementation on Mikrotik or VLAN as a concept? Have you seen the @pcunite's textbook on that already?

Also i am confused why there are so many vlan in RouterOS. It must be that the vlan in the switch is hardware related while the bridge vlan is the Software and in the interface vlan idk.

Also i am confused why there are so many vlan in RouterOS. It must be that the vlan in the switch is hardware related while the bridge vlan is the Software and in the interface vlan idk.

Correct. The switch chip is quite a separate entity, and if you don't need hardware forwarding between its ports, you may deactivate it let the sowftare bridge do everything on its own. Another point is that the VLANs exist independently on each bridge, so you can have VLAN 27 at bridge A and VLAN 27 on bridge B and they don't leak to each other (this is not the case on the switch chip if hardware forwarding is enabled). That's a huge advantage in complex topologies. And VLAN interfaces attached directly to physical interfaces are also completely independent.

If you simplify that a small bit, you can look at the VLAN ID as just an extension of the MAC address, or as a logical address of a sub-interface on a physical interface, whichever is more illustrative for you. So what you would normally attach to ether1 (like IP address or dhcp client), you can attach to /interface vlan name=ether1.27 vlan-id=27 interface=ether1 instead; the /interface vlan is a stupid pipe which adds VLAN tags to those L2 frames carrying L3 packets which it receives from the system on its tagless end (referred to as the pipe's name), and removes VLAN tags from frames which it can see at the underlying interface if the VID in the tag matches the vlan-id, and outputs only these frames after untagging from its name end.

So if you just need to separate traffic on a single cable, you can attach as many /interface vlan as you need to the Ethernet interfaces at each end; if the Ethernet port is a member port of a bridge, you must attach the /interface vlan(s) to that bridge instead.