What is the purpose for this?:
input: in:(unknown 1) out:(unknown 0), proto UDP, 127.0.0.1:13231->127.0.0.1:0, len 176
Without context no idea?
What is the requirement or where did you see this??
Even would like to add
What are we looking at ???
Sorry if (mis)using this thread, perhaps I can add some information.
Running Wireguard on my RB4011. When looking at the logging it is showing (just like the TS):
input: in:(unknown 1) out:(unknown 0), proto UDP, 127.0.0.1:13231->127.0.0.1:0, len 176
This is logged by this firewall rule (where allowed to router is the list of my internal IP addresses):
/ip/firewall/filter
add action=accept chain=input comment="Allow access to addresslist" src-address-list=allowed_to_router
As learned from anav I added the drop all rule at the end of both the input and the forward chains (that is the reason why the above rule was introduced in the first place).
Why is this logged and what does it mean?
what you have inside allowed_to_router the 127.0.0.0/8 ?
/ip/firewall/address-list
allowed_to_router 10.0.0.0/24
allowed_to_router 192.168.60.0/24
allowed_to_router 192.168.50.0/24
allowed_to_router 192.168.99.0/24
allowed_to_router 127.0.0.1
Remove the 127.0.0.1 and you do not see any log about… “localhost” internal CPU local loopback traffic…
Why would one have such a list entry ??? What was the purpose of it??
I suppose than is a generic copy and paste from somewhere, because from the question probably the user do not know what is localhost / 127.0.0.1
Loopback interface is required for testing purpose and normal working from some services.
The “drop all” rule “at the end” of input chain destroy the internal loopback functionality, if the 127.0.0.1 is not allowed before.
For example, self-ping:
ping 127.0.0.1
this work also if the device do not have any IP and the configuration is totally blank.
Think I added it to prefend it from showing in the logging through the drop all rule.
Still learning guys, thanks for the info.Conclusion is that the 127.0.0.1 doesn't have to be allowed on the input.
Is the opposite… 127.0.0.1 must be allowed…
for example again: ping 127.0.0.1 produce an echo request from output chain to input chain, and a subsequent echo reply
Echo request: CPU → RAW/Output → Filter/Output → “loopback” → RAW/prerouting → Filter/Input → CPU
Echo reply (same path): CPU → RAW/Output → Filter/Output → “loopback” → RAW/prerouting → Filter/Input → CPU
The schema is not exactly on this way and is incomplete, but is just for example.
Since, when,
I think you have your claws stuck in some wool!!
127 is not allowed on any of my input chains, and I am happy happy happy
The only time its required is for capsman.
If internally Wireguard use the UDP 13231 and the loopback traffic, there is probably a reason.
Blocking Internal CPU loopback traffic (that never come outside the router) can degrade the service.
But only MikroTik know why Wireguard use local loopback.
Blindly blocking a service used internally by RouterOS can have a negative impact and CAPsMAN is one example.
Not even then it is mandatory. Only when using capsman on LOCAL device (capsman and Wifi AP on the same device) and even then I doubt it is really needed.
If capsman is on another controller, it’s not needed at all.
If MikroTik didn’t hide loopback interface for no good reason (we know it’s there!), we could simply accept everything coming from there. Accepting traffic from 127.0.0.0/8 is not the same, because it allows even spoofed packets from network. You can’t probably do much with that, because it will go only one way without responses, but it’s still not ideal.
Yes, but spoofed traffic is coming from LAN or WAN, from real or virtual interface, not from loopback/CPU…
Correct. I meant if packet with 127.x.x.x as source or destination came from LAN, WAN, etc, then it could pass through firewall if there are rules with src/src-address=127.0.0.0/8. Although it may not be so simple. I can easily test spoofed source (just srcnat on another router) and I see those packets in prerouting, but for some reason they don’t continue to input, so maybe there’s some built-in filter.