I have this drop all !LAN input:
/ip firewall add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN log=yes log-prefix=not-coming-from-LAN
But packets from the “lo” interface was getting dropped.
So I put “lo” in the LAN interface list.
Is this okay?
For me it doesn’t look ok, because lo doesn’t actually represent LAN. Eventually you could have some case when you have to have it separate. So my suggestion is to make an explicit accept rule for lo interface and place it before drop rule:
/ip firewall filter add action=accept in-interface=lo
You didn’t specify for which device this is but for most there should already be an input accept for 127.0.0.1 from default firewall (for capsman).
That also covers lo.
In case you removed that rule, I suggest you put it back.
I can’t say I understand it well enough to know what case that might be, but it makes sense.
As already stated above, there’s a defconf rule to accept input from loopback (commented for CAPsMAN) on some devices, so you probably already had the rule but accidentally removed it.
It’s an ax3, but it’s just my testing/learning/modeling MT device.
I do indeed have the default input accept 127.0.0.1 rule:
/ip firewall
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN log=yes log-prefix=not-coming-from-LAN
But, that default input accept 127.0.0.1 rule wasn’t catching the packets from “lo”
When I remove “lo” from the LAN list, the firewall log reads:
not-coming-from-LAN input: in:lo out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:5678->255.255.255.255:5678, len 169
And what traffic is being sent via lo ??
Can you use Tools/Torch to see what’s going over that interface ?
Best not to add firewall rules without knowing where the traffic comes from or what it is being used for.
5678 seems to be LLDP traffic
And that traffic is being sent to broadcast address … since only device, attached to that “network”, is sender itself, it won’t get any answer … like ever. So dropping this traffic doesn’t change anything.
It would be different, if some service would try to connect another internal service, in which case destination IP address would be 127.0.0.1 and that FW rule would allow it.
If I remove lo from LAN list, the firewall log captures the same message.
Running Packet Sniffer with filter set to interface=lo, I see that the packet is:
Source: 127.0.0.1
Direction: tx
Dst. mac: FF:FF:FF:FF:FF:FF
Src port: 5678
Dst port: 5678
Protocol: 2048
IP Protocol: UDP
I see that 5678 is the neighbor discovery port, so it could just be that the router (127.0.0.1) is sending out these broadcasts and the filter is rejecting them.
I turned off ip/neighbory discovey and the firewall has not caught these packets since then.
Does that make sense?
I’m pretty sure that router, when ND is enabled, sends out packets to broadcast address via all interfaces (which includes lo). And again, as I wrote, sending traffic to broadcast on lo won’t yield any response. Which means that dropping such traffic doesn’t do any harm. The only issue here is your setting for FW filter rule to actually log affected traffic.
I wouldn’t disable ND, it does come handy from time to time (e.g. when winbox builds a list of ROS devices attached to same L2 network).
Got it.
I re-enabled ND, which I do indeed like.
And I will ignore the !LAN FW log.
Thank you!