I have found this filter rule suggested on the wiki. Can someone explain what type of local router applications this rule is designed to match?
/ip firewall filter
add action=accept chain=input comment=\
"Allow Local Traffic Between Router Applications" disabled=no \
dst-address-type=local in-interface=ether2-local-master src-address-type=\
local
/ip firewall filter
add action=accept chain=input comment=
“Allow Local Traffic Between Router Applications” disabled=no
dst-address-type=local in-interface=ether2-local-master src-address-type=
local
action = what to do with the packets
chain = can’t really explain, but “input” is incomming packets, “output” outgoing packets, forward I don’t know
dst-address-type = type of destination address, public IP or local IP
in-interface = which interface the traffic comes in at.
Incomming: packet ----> |router|
Outgoing: |router|---->
src-address-type= same as dst-address-type only it looks at the source address instead of destination address.
“ether2-local-master” is just the name of the interface. It might as well just be ether2.
Actually “dst-address-type=local” means that it is an IP address that is assigned directly to the router itself.
The “input” chain is for packets destined for the router itself regardless of the interface. I am not sure if any packets not destined for the router itself could ever wind up in the input chain (maybe some broadcast packets).
What the rule above seems to be saying is that some internal router application that outputs data that is intended to go right back to an internal router application must first pass through the output chain, then arrive at the local ethernet interface, then return via the input chain. The rule also implies that this data could be lost if you don’t specifically allow it after building a firewall rule set.
Is this true? Why wouldn’t internal router applications talk directly? Why give the user the ability to control or interfere with any internal router application communication? Any examples?
Does anyone have any info on this subject? Maybe just a good guess?
My guess is that it’s supposed to be the equivalent to “pass all on loopback” that you do when writing host firewall rules on Linux/BSD systems. Quite a few apps actually talk to one another via TCP/IP on localhost addresses on the loopback interface.
Since it doesn’t show up anywhere in the official documentation I would also guess that the iptables configuration generated from the rules you add to “/ip firewall” automatically includes a pass on all loopback traffic. If you want an opinion on that I’d guess you’d have to talk to support via email.
Thanks fewi,
Your answer makes a lot of sense, including the part about letting support have the last word.
Good firewall practice on one platform may not always transfer perfectly to another. I have decided to dig in and improve my understanding of the MikroTik firewall and the TCP/IP protocol at the same time. I am now stumbling over internal packet flow and protocol for DHCP Relay and for clients renewing leases prior to expiry. But, I will save that for another thread if I don’t figure it out 
Thanks again.
Maybe these help.
Packet flow: http://wiki.mikrotik.com/wiki/Manual:Packet_Flow
DHCP relay: the local agent receives the broadcast DHCP discovery message from the client, wraps it into a unicast discovery packet and sends it on to the central DHCP server. All traffic received back from the server is sent to the client as if the DHCP relay agent was a DHCP sever.
Lease renewal: most implementations renew at half the lease time. DHCP basically consists of four packets for a brand new lease: DHCP discovery for any lease from the client, then a DHCP offer for a specific lease from the server, then a DHCP request for the specifically offered lease from the client, and a DHCP ACK from the server confirming the DHCP request. At half time the client sends another DHCP request for the lease it already has, and the server increases the lease time in its database and ACKs. That’s a simplified view that assumes the server responds, it gets a little more convoluted when it doesn’t. The RFC for DHCP has all the details in fairly readable language.
I have seen that info, but I am wondering things like do the DHCP packets ever go through the forward chain and how is it different for lease renewal for local DHCP vs. DHCP Relay. I plan on running some tests to follow the packets but it might take a couple of days, it’s getting busy 
Actually that’s a simple answer: the DHCP server implementation on RouterOS uses raw sockets, and grabs packets destined for it before NetFilter ever sees them. DHCP packets are never seen by the firewall, they’re already processed before the firewall comes into play.
but it’s possible to catch those packets: if you create bridge and add your interface to it, you will see all packets in bridge filter
Now that is interesting information but it still leaves me with questions.
If the DHCP packets are unicast, and just passing through the router (DHCP Relay), when renewing a lease, does that still apply?
I am not using a bridge, so now it is harder to explain why this rule is working??
add action=drop chain=input comment=\
"Drop Rogue DHCP Detection from Neighbor Router" disabled=no dst-address=\
255.255.255.255 dst-port=67 in-interface=ether2-local-master protocol=udp \
src-address=0.0.0.0 src-mac-address=aa:bb:cc:dd:ee:ff src-port=68
My setup at home is almost completely static IP’s so it isn’t the easiest environment to watch DHCP packets but I inserted a drop rule for DHCP Response packets in the input chain of my main router. In the last 24 hours it has dropped 11 packets. I don’t even know where they are coming from! Time to turn on a logging rule
It turns out that those stray DHCP packets are coming from a non-routable address in my providers network. The Drop Rule that I am using appears before my illegal address rules. I will probably call them and ask them if it is of any concern.
It is interesting that the firewall does see DHCP packets even though I am not using a bridge. Perhaps it is because I do not have DHCP Server, DHCP Client, or DHCP Relay enabled here. I still want to do some testing at work if I ever get a quiet moment.