MikroTik

Hi! I had to disable "defconf: drop all not coming from LAN" otherwise my local CAPs Manager would not work. Am I missing something? I actually don't quite understand the need for this rule. Isn't it best hinged on WAN?
https://wiki.mikrotik.com/wiki/Manual:I ... all/Filter didn't really help me (search for "drop all not coming"). You would expect to see some mapping to the RouterOS's defconf wouldn't you? Be nice if there was a function to double check WAN input is sane. I've had a compromise before when I accidentally allowed access to a default admin/nopasswd routerboard.

Full config https://s.natalian.org/2018-09-22/uptown.txt

I actually don't quite understand the need for this rule. Isn't it best hinged on WAN?

Great question! Yes, it is theoretically best hinged on WAN instead of not-LAN -- *however* -- the main reason this was not done is that many RouterOS novices who configure PPPoE (very commonly needed as a method to connect to the Internet, accomplished by adding a new PPPoE client interface) are completely unaware that they also need to manually add their PPPoE interface to the "WAN" interface list to secure their router properly. If they failed to add the PPPoE interface to the WAN interface list, and the rule that you refer to was blocking admin login from WAN instead of not-LAN, then hackers on the Internet would easily be able to get into their router if it had a weak password or a security vulnerability. By using not-LAN instead of WAN as the matching criteria for this rule, MikroTik ensures that, even if the user doesn't know (or forgets) to add the pppoe-out1 interface to the "WAN" interface list, their router will not be wide open for hackers to take control of.

Don't disable the rule, otherwise you are allowing login to your device from any IP anywhere for admin purposes (unless of course this device is completely protected by a firewall on a different device, in which case you don't really need any firewall rules). Either reconfigure the rule for WAN instead of not-LAN (and if you have a PPPoE interface, make sure that you add it to the "WAN" interface list), *or* add whatever interface your CAPSMAN/CAPS communication takes place on to the "LAN" interface list, in which case it will not be blocked.

(BTW, as an aside I am sorry for your bad experience on the unofficial MikroTik IRC chat room. Not all advanced users have equal patience with novices. I frequent the IRC chat that you visited before and youtube'd about, but was not around when you were trying to figure things out.)

Ah, so https://s.natalian.org/2018-09-22/uptown.txt had WAN as
Which wasn't on the PPPoE interface "unifi". I've since updated it to.
I didn't understand what you said by "add whatever interface your CAPSMAN/CAPS communication takes place on to the "LAN" interface list, in which case it will not be blocked". Surely CAPsMAN communication should be on LAN by default? I can't tell what interface it's on looking at https://s.natalian.org/2018-09-22/uptown.txt

I do `nmap` my IP, and I didn't notice any ports open. So there must be some other rule that makes my firewall work? I guess it's the

Thanks for your welcome.

Note that because “WAN” is an interface list, you can have multiple wan interfaces if you like (for instance, both ether1 and your pppoe interface). You don’t have to remove ether1 from WAN in order to add the pppoe interface.

Surely CAPsMAN communication should be on LAN by default? I can't tell what interface it's on looking at

Is the device using itself as a capsman? If so, you might need to create an input chain rule allowing all from source address 127.0.0.1 and place it above that drop rule.

I do `nmap` my IP, and I didn't notice any ports open. So there must be some other rule that makes my firewall work? I guess it's the

Code: Select all

add action=drop chain=input comment="default configuration" in-interface=unifi

That rule is not part of the normal config and must have been added manually. It shouldn’t be necessary with the default “drop all from not LAN” rule.

If you have in mind the setup where a local CAPsMAN controls local wireless interfaces (alone or along with wireless interfaces on other machines), it is true that the default configuration's firewall rules do not cover that setup. The thing is that the cAP process (controlling the wireless interfaces in slave mode) talks to the CAPsMAN process via UDP, and if both these processes run on the same machine, their communication doesn't pass through any interface at all, regardless what IP addresses are used.

So one of the possible rules you have to add to an appropriate position in chain=input of /ip firewall filter to resolve this situation is chain=input action=accept in-interface-list=!all out-interface-list=!all. It permits locally originated packets to be locally received.

Other than that, if you want to connect remote cAPs to a local CAPsMAN, you have to provide necessary firewall rules just like for any other service. So into chain=input of /ip firewall filter, you have to add permissive rules for access to UDP ports 5246 and 5247 for source addresses (src-address, src-address-list) and/or interfaces (in-interface, in-interface-list) from which the cAPs will be connecting to the CAPsMAN. The opposite direction is handled by the common rule action=accept connection-state=established,related.

When thinking about connection of remote cAPs to the WAN side of the CAPsMAN, bear in mind that only the control communication is encrypted, so you may want to set up a secure tunnel. Other than that, a recovery from loss of control communication between cAP and CAPsMAN causes a noticeably longer gap in wireless user connectivity than the control communication loss causing it. So e.g. having a cAP and a CAPsMAN at two ends of a wireless link suffering from heavy interference is not a good idea.

So one of the possible rules you have to add to an appropriate position in chain=input of /ip firewall filter to resolve this situation is chain=input action=accept in-interface-list=!all out-interface-list=!all. It permits locally originated packets to be locally received.

That rule is really unnecessarily confusing. I would not do that with in-interface-list=!all, even though it may work, because there is a clearer solution that has the same effect:

/ip firewall filter add action=accept chain=input dst-address-type=local src-address-type=local

That will do the same thing as your rule above, but is much more readable and easier to understand.

That will do the same thing as your rule above, but is much more readable and easier to understand.

Well... given how many people here have proven to believe that address-type=local matches any address from a connected subnet, or, probably worse, to blindly copy it without understanding from a wrong example given in some other topic, I'm a bit sceptical regarding your rule being much more comprehensible than mine. But we've both done our best

Also, it's not really the same, src/dst-address-type=local only checks if given address matches any address assigned to router. But it doesn't care from where the packet came. If I send it from somewhere else (with source address set to something that's also on target router), it will match too.

And in-interface-list=!all is sort of a hack too, which depends on the fact that RouterOS has "lo" interface hidden from user. IMHO it would be best if they exposed it, even though it's not usually needed. It's not like we don't know that it's there.

Also, it's not really the same, src/dst-address-type=local only checks if given address matches any address assigned to router. But it doesn't care from where the packet came. If I send it from somewhere else (with source address set to something that's also on target router), it will match too.

Good point - I hadn't realized that.

sindy's !all might then be the safest method at the moment - the only problem is that if MikroTik did decide to add the lo interface so that it wasn't hidden (as you suggest), the rule would stop working.

Trying to summarize here for my sanity. Isn't the real issue is that 127.0.0.1 from which CAPs Manager is run, is not considered from LAN? That would make the defconf firewall work... right?

How do other services like dhcpd work, but CAPsMAN doesn't?

Btw CAPsMAN is NOT on the WAN side. Heavens knows why you would have that sort of setup. I run it on the Mikrotik next to the ONU that does the PPPoE part too.

I am just trying to keep things simple here for future reference for a CAPsMAN setup here in Malaysia .

Thanks guys!

Trying to summarize here for my sanity. Isn't the real issue is that 127.0.0.1 from which CAPs Manager is run, is not considered from LAN? That would make the defconf firewall work... right?

Correct, it is not considered from LAN because, as Sob explained, the lo interface (which has the IP 127.0.0.1) is invisible in RouterOS and therefore can't be added to the LAN interface list.

Before CAPsMAN existed, there were essentially no services that would have been affected by this limitation, and that is undoubtedly why the lo interface was never added.

How do other services like dhcpd work, but CAPsMAN doesn't?

Because there are two services involved here - the CAP service and the CAPsMAN service. Because the CAP service is usually run on different routers than CAPsMAN, it communicates with CAPsMAN over a network. As a result, when the CAP service talks to CAPsMAN on the same device, it has to go through the networking stack, sending UDP packets like it would to a remote router. These packets are then processed by the firewall and can be blocked by the firewall.

On the other hand, communication between CAPsMAN on that router and a remote CAP on a different AP device that is connected to an interface in the LAN interface list will not be blocked, because all communication is allowed by default if the source interface for the traffic is in the LAN interface list.

This would not happen with DHCPD because it is just a single daemon running on the router that the computers get IPs from, and the computers are on an interface in the LAN list, so it is allowed in the firewall. You might run into such an issue if, say, you made the router a DHCP server, and you also added a DHCP client on the same router to get an IP from the DHCP server on the same router. However, I don't see why you would need to do such a strange setup to begin with, so it is unlikely you would run into this issue with the other RouterOS services.

Hello, maybe this rule in firewall will help in solving the problem: As far as I understand this will allow local traffic on the router itself.
You should put it above "defconf: drop all not coming from LAN".

ps: Not sure if this is the right decision, but it works.
pps: Oops! This solution was suggested above. Sorry...

I actually don't quite understand the need for this rule. Isn't it best hinged on WAN?

...the main reason this was not done is that many RouterOS novices who configure PPPoE (very commonly needed as a method to connect to the Internet, accomplished by adding a new PPPoE client interface) are completely unaware that they also need to manually add their PPPoE interface to the "WAN" interface list to secure their router properly. If they failed to add the PPPoE interface to the WAN interface list, and the rule that you refer to was blocking admin login from WAN instead of not-LAN, then hackers on the Internet would easily be able to get into their router if it had a weak password or a security vulnerability. By using not-LAN instead of WAN as the matching criteria for this rule, MikroTik ensures that, even if the user doesn't know (or forgets) to add the pppoe-out1 interface to the "WAN" interface list, their router will not be wide open for hackers to take control of.

I did (or didn't do) exactly this when I first set up my 2 x ROS devices! Even after realising my mistake, I think at the time I lacked enough knowledge to fix it properly without breaking certain things (not knowing I needed some extra accept rules before the revised drop rule - in particular IPSec comes to mind, I'd allowed UDP/500 but not 50/ESP or 51/AH)! So to this day on those original devices, I think I am more open than I should be on the WAN side.

New devices going in to swap them out with a config done from fresh on the latest software. I've added the PPPoE interface to the WAN interface list this time , but welcome this rule too!