Firewall lists

install adds the veth to an interface list and the container’s /30 to an address list, so that the raw drop rules of a MikroTik firewall let the agent’s replies through. Name the lists your rules use with --iface-list and --addr-list, or none when no rule needs them. Without --expose, install writes no firewall rule.

Raw drop rules

MikroTik’s Building Advanced Firewall guide adds raw rules commented defconf:. Two of them silently drop every packet a new container sends:

Rule	Drops a packet that	A new container is dropped because	What lets it through
drop the rest, in-interface-list=!LAN	enters on an interface outside the LAN list	its veth is in no interface list	the veth in LAN: --iface-list
drop local if not from default IP range, src-address-list=!LANs	comes from an address outside the LANs address list	its /30 is in no address list	the /30 in LANs: --addr-list
the same rule written src-address=!192.168.88.0/24	comes from an address outside that range	its /30 is outside the range	no list: add an accept rule for in-interface=<veth> before it, or pick a --subnet inside the range

The drop is silent. From your host the agent does not answer, which looks the same as a container that is not running, so the probe after install asks the router whether the container runs before it suggests anything else (Network access).

Other drop rules in raw, input or forward can drop the container’s traffic elsewhere. install adds nothing for them beyond the two memberships; doctor’s trap check reads them and names the rule.

List memberships

With the default lists, install writes these two entries:

Step	Command	Left out with
interface-list membership	/interface/list/member/add list="LAN" interface="veth-mikroscope" comment="mikroscope:mikroscope (managed by mikroscope)"	--iface-list none
address-list membership	/ip/firewall/address-list/add list="LANs" address=172.30.10.0/30 comment="mikroscope:mikroscope (managed by mikroscope)"	--addr-list none

• Both carry the tag. uninstall removes each by the tag, the list and the member.
• The interface list must exist. The address list need not: its first entry creates it, and uninstall removes the entry.
• With both memberships, a host on the LAN reaches the agent directly through the router (verified).

A membership is not scoped to mikroscope. Any other rule of your router that matches the LAN interface list or the LANs address list matches the container’s traffic too, for as long as it is installed. Read your own rules with that in mind.

Custom list names

Pass the lists your drop rules use:

Flag	Variable	Default	Accepted	Names
--iface-list	MIKROSCOPE_IFACE_LIST	LAN	^[A-Za-z0-9][A-Za-z0-9_.-]{0,63}$ or none; not RouterOS’s built-in all, dynamic or static	the list your in-interface-list=!… drop rule uses
--addr-list	MIKROSCOPE_ADDR_LIST	LANs	^[A-Za-z0-9][A-Za-z0-9_.-]{0,63}$ or none	the list your drop local if not from default IP range rule uses

mikroscope install --iface-list MYLAN --addr-list MYNETS

A built-in interface list takes no member, so --iface-list static stops before the first connect:

mikroscope: iface-list "static" is a RouterOS built-in list, which takes no member: name the list your firewall's in-interface-list=!… drop rule uses, or none to join no list

status, upgrade and uninstall read the lists from the install on the router, so they need no list flag. A list flag that contradicts the install is refused, naming both values (Install shape).

No membership

A router with no rule that drops by list needs neither membership. Leave both out:

mikroscope install --iface-list none --addr-list none

doctor tells you when that is the case: its trap check ends with they would pass with no list membership as well, and a missing interface list is reported with --iface-list none as the first fix:

  MISSING interface list LAN exists (found=0)
          fix: --iface-list none: no firewall rule here needs the veth in an interface list. Or create it: `/interface/list/add name=LAN`

Trap check

doctor, run alone or by install, checks the lists and then follows the agent’s replies through your firewall:

The checks doctor runs

Check, as printed	Passes when	The fix it names
interface list <list> exists	the --iface-list list (default LAN) exists. With --iface-list none doctor prints interface list the veth joins and passes: no membership is written	--iface-list none when no firewall rule needs the veth in a list (doctor offers it first then); otherwise /interface/list/add name=…, or pass the list your in-interface-list=!… drop rule uses
address list <list>	always: install adds the /30 to the --addr-list list (default LANs), which creates it when it is missing, and uninstall removes the entry. With --addr-list none doctor prints address list the /30 joins. Whether a rule needs the membership is the next row's question	none
no firewall rule drops the agent's replies	doctor reads every enabled rule of the chains the agent's replies meet, /ip/firewall/raw prerouting and /ip/firewall/filter forward and input, and walks each one as RouterOS does, first match wins, with the replies in the lists the plan joins: no rule drops them. A warning when a rule might, because it matches on something doctor does not judge (a destination, a mark, a rate), and when the replies to a LAN host pass but a rule may drop the ones to the router itself (filter input), which the relay transport needs	the --iface-list and --addr-list that let the replies through; when no list does (a src-address=!<range> rule, say), add an accept rule for in-interface=<veth> before that rule, or pick a --subnet inside the range

The trap check reads every enabled rule of /ip/firewall/raw prerouting and /ip/firewall/filter forward and input, and walks each chain as RouterOS does, first match first. The replies it follows come in on the veth, from the agent’s address and port, in the lists the plan joins.

Prints	Means	Do
ok … no rule drops them	the replies pass with the plan’s memberships	nothing
ok … they would pass with no list membership as well	no rule needs a membership	--iface-list none --addr-list none, if you want no membership
MISSING … drops them, fix install with --iface-list … --addr-list …	a rule drops the replies, and other lists the rules name let them through	install with the lists the fix names
MISSING … drops them, fix … add an accept rule for in-interface=<veth> before it	no list the rules name lets the replies through, as with a src-address=!<range> rule	add that accept rule, or pick a --subnet inside the range the fix names
WARN … may drop them	the rule matches on something doctor does not judge: a destination, a mark, a rate	if the agent does not answer after install, look at that rule first
WARN … may drop the ones to the router itself	replies to a LAN host pass, and a filter input rule may drop replies to the router	use the direct transport; the relay may not reach the agent

doctor names a rule by its table, chain and number, its matchers and its comment, as in /ip/firewall/raw rule 0 (chain=prerouting action=drop, …) "…". It never proposes a list the router’s uplink is in, and it takes an address list other than the plan’s to hold no entry for the /30.

It walks a rule the way RouterOS applies it, which is not always the way it reads. RouterOS passes over a rule it marks invalid, and a rule that names an interface list that was removed stays valid with the list’s id in place of its name and matches as if the list were empty (Router exposure).

Router exposure

Two warnings are about the router rather than the install. They change neither doctor’s exit status nor whether install goes ahead, but a router whose firewall does not do what it reads as doing carries traffic it was never meant to, and every panel then measures that traffic:

The checks doctor runs

Check, as printed	Passes when	The fix it names
no firewall rule doctor reads is invalid or names a deleted list	a warning: no rule of raw prerouting or filter forward and input is marked invalid, which RouterOS passes over as if it were not there (it names an interface that was removed or is not ready, and about says which), and none names an interface list that was removed, which RouterOS keeps as the list's id (in-interface-list=!*2000010) and matches as an empty list. A rule changed a moment before reads invalid with no reason until RouterOS has applied it	fix or remove what an invalid rule names; set a deleted list again by name, since creating a list of the same name does not repair the rule. With no reason given, run doctor again
the router does not answer DNS from its uplink	a warning: /ip/dns allow-remote-requests is off, or a rule of raw prerouting or filter input drops a UDP query to port 53 that comes in on the interface of the active default route, walked as for the trap check, first match wins. A warning that the queries may pass when a rule matches on something doctor does not judge, a source address list say. IPv6 is not read	a drop rule for UDP and TCP port 53 on the uplink before any accept that takes it, or /ip/dns/set allow-remote-requests=no if no LAN host uses the router as its resolver

• A rule that does nothing, or does too much. An invalid rule, one that names an interface that was removed or is not ready, is passed over: an invalid drop drops nothing. A rule whose interface list was removed reads in-interface-list=!*2000010 and matches as if the list were empty, so a !LAN drop left that way drops every packet that reaches the input chain, the router’s own SSH and Winbox from the LAN included. Creating a list of the same name does not repair it: set the rule’s list again by name.
• An open resolver. With /ip/dns allow-remote-requests=yes, the router answers DNS on every interface its firewall lets queries in on. doctor follows a UDP query to port 53 that comes in on the interface of the active default route through raw prerouting and filter input; when no rule drops it, the router answers DNS for the Internet, and reflection attacks that find it fill its connection table and its CPU. The default configuration’s in-interface-list=!LAN drop on the input chain stops them.

Both were checked against RouterOS in the lab (Tested on).

Existing memberships

If the veth is already in the interface list, or the /30 already in the address list, and that entry does not carry mikroscope’s tag, install stops at that step and names it: the effect exists, but mikroscope did not create it and will not remove it. Pick another --veth or --subnet, or remove your entry by hand if it is yours. uninstall never touches it.

Expose rules

Only --expose writes firewall rules: a dst-nat on the router’s LAN address and a forward accept placed before the first forward drop, both tagged. uninstall removes them with the rest of the install, because it reads from the router that the install was exposed. Expose on the LAN has both rules and who reaches the agent through them.

See also

• Network access: the three ways to reach the agent, and what to do when the memberships are not enough.
• Requirements: every doctor check.
• Expose on the LAN: the two rules --expose adds.
• Tested on: the firewalls these memberships ran against.