I have one router and 6 caps. I configured capsman and I have three SSID each of them goes to a bridge (Privada, Invitado and CCT). Each bridge has it’s own dhcp server. The problem is:
If I connect to any of the wifi, I can’t ping the gateway so I have no internet.
The device connected to wifi gets the ip. I’m posting my configuration. Any help will be welcome.
/interface bridge
add name="Bridge CCTV"
add name="Bridge Invitado"
add name="Bridge Oficina"
/ip dhcp-server
add address-pool=dhcp disabled=no interface="ether3 LAN" lease-time=1d name=dhcp1
# DHCP server can not run on slave interface!
add address-pool=dhcp disabled=no interface="ether6 - LAN" name=LAN
add address-pool=dhcp_pool_WOficina disabled=no interface="Bridge Oficina" name=dhcp2
add address-pool=dhcp_pool_WInvitado disabled=no interface="Bridge Invitado" name=dhcp3
So no DHCP server is attached to “Bridge CCTV”, so I wonder how devices in that network can receive IP addresses.
Next, mask length is missing at some local IP addresses: The value of “network” attribute does not substitute mask length.
/ip address
...
add address=192.168.10.1/24 comment="Direcciones Pool Oficina Oficina" interface="Bridge Oficina" network=192.168.10.0
add address=192.168.11.1 comment="Direcciones Pool Invitado" interface="Bridge Invitado" network=192.168.11.0
add address=192.168.12.1 comment="Direcciones Pool CCTV" interface="Bridge CCTV" network=192.168.12.0
Next, “ip dhcp server network” and “ip pool” are missing for 192.168.12.0/24 (for “Bridge CCTV”), so devices in that network can get no address (no pool) nor default gateway (no network)
Configuration for Officina seems least malformed to me, so the only thing which comes to my mind is that you should try to add “netmask=24” to its “/ip dhcp-server network” configuration and try with a client in that WLAN again. If it works, fix the mistakes in configuration of the remaining two networks.
CCTV it is not configured because I couldn’t make to work Invitado and Oficina so you will see it is half configured.
I fixed dhcp-server adding netmask but no luck. I can connect to Invitado, I get an ip but I can’t ping gateway.
If I choose client-to-client forwarding on datapath I can get Internet at invitado, so I guess I’m missing some route but I can’t find which. Any ideas?
It sounds like a bug to me because client to client forwarding should affect nothing except whether WLAN clients can talk to each other.
If you can get to internet using this magic, the routes must be set properly, the cause must be something else.
Please check that the dynamically created cAP interfaces are added as dynamic members to “Bridge Invitado” in both cases, i.e. with “datapath.client-to-client-forwarding=no” and with “datapath.client-to-client-forwarding=yes”, maybe post here the output of “/interface bridge port print” for both cases.
It would also be fine to see the output of “/ip dhcp-server lease print”.
# INTERFACE BRIDGE PRIORITY PATH-COST HORIZON
0 XI ether7 - WIFI Bridge Oficina 0x80 10 none
1 ether6 - LAN Bridge Oficina 0x80 10 none
2 ID cap40 Bridge Invitado 0x80 10 none
3 D cap41 Bridge Oficina 0x80 10 none
4 D cap42 Bridge CCTV 0x80 10 none
5 ID cap43 Bridge Invitado 0x80 10 none
6 ID cap44 Bridge Oficina 0x80 10 none
7 ID cap45 Bridge CCTV 0x80 10 none
8 ID cap46 Bridge Invitado 0x80 10 none
9 ID cap47 Bridge Oficina 0x80 10 none
10 ID cap48 Bridge CCTV 0x80 10 none
11 ID cap49 Bridge Invitado 0x80 10 none
12 ID cap50 Bridge Oficina 0x80 10 none
13 ID cap51 Bridge CCTV 0x80 10 none
14 ID cap52 Bridge Invitado 0x80 10 none
15 ID cap53 Bridge Oficina 0x80 10 none
16 ID cap54 Bridge CCTV 0x80 10 none
17 ID cap55 Bridge Invitado 0x80 10 none
18 ID cap56 Bridge Oficina 0x80 10 none
19 ID cap57 Bridge CCTV 0x80 10 none
/ip dhcp-server lease print
# ADDRESS MAC-ADDRESS HOS SERVER RAT
0 D 192.168.10.10 XX:XX:XX:XX:XX:XX dhcp2
1 192.168.10.127 XX:XX:XX:XX:XX:XX nes dhcp2
2 D 192.168.10.12 XX:XX:XX:XX:XX:XX DES dhcp2
3 D 192.168.11.251 XX:XX:XX:XX:XX:XX and dhcp3
I printed this, but now works with or without client-to-client forwarding. But now, from invitado, which is on bridge Invitado I can ping ips from bridge Oficina. Why is that?
PS: For reseting configurations, I drop all interfaces in capsman and provision again. Also, I leave client-to-client forwarding on oficina since I want to allow machines on wifi access to machines on LAN. Am I right?
But now, from invitado, which is on bridge Invitado I can ping ips from bridge Oficina. Why is that?
Surprisingly, a bit of normal behaviour in your spooky castle. It is a router, so it is routing between networks unless you tell it not to do so.
The datapath.client-to-client-forwarding=no can prevent the AP from forwarding frames from STA to STA as they pass through at L2. As soon as the two STAs are associated to different virtual APs, each of which uses a different bridge and IP subnet, the packets are routed between them, so from the perspective of the AP they flow between wireless and wired sides of it and the client-to-client-forwarding setting does not affect them.
So if you want to prevent devices associated to different SSIDs from being able to talk to each other, you have to add some firewall filter rules, such as
/interface list add name=my-lan-bridges
/interface list member add list=my-lan-bridges interface="Bridge Invitado"
/interface list member add list=my-lan-bridges interface="Bridge Oficina"
/interface list member add list=my-lan-bridges interface="Bridge CCTV"
/ip firewall filter add chain=forward in-interface-list=my-lan-bridges out-interface-list=my-lan-bridges action=drop
(a pair of rules for each pair of networks is necessary in this case).
The rules must be high enough in the chain, for a quick check make them the first two.
Consider an upgrade to 6.40.6 if you are not ready for the new bridge and switch configuration method used in 6.41 and above. Already 6.40.5 does support interface lists.
As for why you can ping - I don’t know where the device with that IP is connected. The rules above work between interfaces with associated IP addresses as these are a result of routing; member interfaces of bridges are not recognized as in-interfaces or out-interfaces (although this may have changed since 6.34.3) Plus your rule was only prohibiting one direction, so if you’ve initiated the ping in the opposite (not prohibited) direction and there is a rule which permits “established” connection state regardless any other properties of the packets, you could ping anyway.
6.41 and above changes the way how bridges and switches are configured. Your configuration already seems not to rely on “master ports” so you should have no serious issues. Nevertheless, make a backup of your configuration and download any files you have created (backups or anything else not created automatically by the router itself) to your PC before upgrading. After upgrading the application (which includes a reboot), first go to system → routerboard and upgrade the firmware, then wait about a minute, then reboot again.
Warning - a backup from one version cannot be used for restore in another version.
There is a small chance that your cAPs will stop working after the upgrade, I don’t know when the cAPsMANv1 has been replaced by cAPsMANv2, so you would then need to upgrade all your cAPs as well.
I have upgraded my router to 6.41.2 application and firmware.
And all is working as before.
If I’m connected to invitado, I get an Ip from DHCP Server Invitado 192.168.11.x can not ping other ip addresses like 192.168.10.127 from DHCP server on Oficina but I still can ping address bridge oficina 192.168.10.1 even if I add the filters
It is because ip firewall filter chain “forward” only handles packets travelling through the Mikrotik. To deal with incoming or outgoing traffic of the Mikrotik itself, ip firewall filter chains “input” and “output” are used.
It actually makes no difference at which of its several local IP addresses your Mikrotik is accessible. Either it is OK that the wireless clients connected into one of your WLANs have management access to the Mikrotik, and in such case, it is irrelevant via which of its addresses, or it is not OK, but in such case you have to restrict access to all of its addresses.
But besides services providing management access, there are also services like DHCP, DNS, and NTP, which need to be provided to the clients. So the best option is to restrict access to Mikrotik’s own ports to anything, with exceptions of DHCP, DNS, and NTP for everyone and with exceptions of management protocols for selected source IPs or for selected interfaces (e.g., anything associated to SSID Officina has management access, anything connected to other SSIDs has not).
BTW, the reason for upgrading was the absence of “/interface list”. Maybe you can use that method to block routing between the SSIDs?
I upgraded because I assume that having a new version it is better than the old one (less bugs, etc.).
I don’t use the address list because what I want is that SSID privada can access my local lan which is on ether6 and are on the same bridge (oficina). So I isolated SSID Invitado on bridge invitado filtering access from oficina to invitado and from invitado to oficina.
I’m not completely sure. If clients associated to SSIDs “privada” and “officina” share the same bridge and IP subnet, any filtering rule handling IP routing can not affect the traffic between them because it is not routed (L3) but bridged (L2). So whether you put that common bridge as in-interface in one rule and out-interface in another rule, or whether you make it a member of an interface list to which a single rule will refer to as in-interface-list and out-interface-list makes no difference, as the traffic will never leave that bridge. So the fact that the same list is set as both in and out in the same rule, and so packets which would come and leave through the same interface would be matched by that rule, is irrelevant except really complex scenarios involving multiple NAT.
When the CCTV SSID and bridge come into play, you’ll need 6 rules the way you do it now, or a single firewall rule and 4 other lines (one interface list and three member interfaces of it). Almost the same effort so the choice is yours.
eth6 and SSID Privada are in “bridge Oficina”.
SSID Invitado is in “bridge Invitado”.
What I did was to avoid routing between Bridge Oficina and Bridge Invitado with that filters, so I assume that because SSID oficina and SSID Invitado are in different bridges they can’t reach from each other. Is my assumption correct?
Yes. I just got a feeling from what you wrote that your reason not to use interface list was that privado and officina would stop seeing each other if done that way.
add action=drop chain=input comment="Drop all packets from public internet which should not exist in public network" in-interface=WAN src-address-list=NotPublic
add action=drop chain=forward comment="Drop all packets from public internet which should not exist in public network" in-interface=WAN src-address-list=NotPublic
add action=drop chain=forward comment="Drop all packets from local network to internet which should not exist in public network" dst-address-list=NotPublic in-interface=LAN
add action=drop chain=forward comment="Drop all packets in local network which does not have local network address" in-interface=LAN
Assume that my WAN is ether1 which is connected to other router which is given by my internet provider. I get a local IP from that router for dhcp on my interface eth1. Let’s say I configure DHCP on internet provider router that gives to my router on network 10.0.0.1/24. So then, my router gets for example 10.0.0.2 IP on eth1.
Rule 1 says drop all packages that does not come from the router that get in WAN interface. Doesn’t that rule drop all packages that comes to my router on that interface? An Rule 2, looks the same but packets thought router …
Rule 1 says drop all packets which come from “non-public” IP addresses to your router via its WAN interface - it does not say to drop packets which have traversed intermediate devices with such addresses on their way. The source IP address of a packet does not change during routing. So if the gateway on 10.0.0.1 sends anything to you, that will be dropped. If anything comes to you via that gateway, it will not be dropped (well, unless the gateway would src-nat it).
But as either the ISP’s gateway itself is the DHCP server for your WAN, or at least the DHCP server shares the subnet with the gateway, you have to provide an exception from that rule for DHCP packets in server->client direction (protocol=udp src-port=67 dst-port=68), because while DHCP discover from client to server uses a broadcast destination IP address, already the DHCP offer from the server to the client comes from the server’s unicast IP address (a broadcast address must not be used as source address). This exception is only necessary for the input chain as the gateway only sends the DHCP offers and responses to the Mikrotik itself.
Another exception you need to set up is for icmp, and that one must be present in both the “input” and “forward” chains. Otherwise not only traceroute but also path MTU discovery would break, maybe even something else.
In the other direction, you have to permit DHCP packets from client to server (i.e. swap the src and dst ports in the exception rule) and icmp as well.
Maybe connection tracking saves all that, but I’m not sure about it and even if it does, it is not always enabled.
