You are not logged in.
Pages: 1
Topic closed
Hi,
I'm having trouble diagnosing what these messages mean. Here's a sample:
[13016.574909] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:00:00:fb:a4:77:33:a0:56:94:08:00 SRC=192.168.1.77 DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13018.418478] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:7f:ff:fa:40:16:7e:30:3f:a0:08:00 SRC=192.168.1.1 DST=239.255.255.250 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13018.418508] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:7f:ff:fa:a4:77:33:a0:56:94:08:00 SRC=192.168.1.77 DST=239.255.255.250 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13137.924214] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:00:00:01:40:16:7e:30:3f:a0:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13140.687516] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:7f:ff:fa:40:16:7e:30:3f:a0:08:00 SRC=192.168.1.1 DST=239.255.255.250 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13140.994650] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:00:00:fb:a4:77:33:a0:56:94:08:00 SRC=192.168.1.77 DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13263.570847] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:00:00:01:40:16:7e:30:3f:a0:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13268.567570] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:00:00:fb:a4:77:33:a0:56:94:08:00 SRC=192.168.1.77 DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13270.943992] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:7f:ff:fa:40:16:7e:30:3f:a0:08:00 SRC=192.168.1.1 DST=239.255.255.250 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13388.913709] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:00:00:01:40:16:7e:30:3f:a0:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13391.984000] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:7f:ff:fa:a4:77:33:a0:56:94:08:00 SRC=192.168.1.77 DST=239.255.255.250 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13396.592035] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:7f:ff:fa:40:16:7e:30:3f:a0:08:00 SRC=192.168.1.1 DST=239.255.255.250 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13398.435173] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:00:00:fb:a4:77:33:a0:56:94:08:00 SRC=192.168.1.77 DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13514.254682] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:00:00:01:40:16:7e:30:3f:a0:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13515.174373] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:7f:ff:fa:a4:77:33:bb:2e:84:08:00 SRC=192.168.1.193 DST=239.255.255.250 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13519.168130] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:00:00:fb:a4:77:33:a0:56:94:08:00 SRC=192.168.1.77 DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[13522.240178] [UFW BLOCK] IN=wlp58s0 OUT= MAC=01:00:5e:7f:ff:fa:40:16:7e:30:3f:a0:08:00 SRC=192.168.1.1 DST=239.255.255.250 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
There are pages of these, and they repeat over and over. My UFW setup is the following:
# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
5556/tcp ALLOW IN 192.168.1.0/24
5558/tcp ALLOW IN 192.168.1.0/24
This is happening on my home WiFi network. Any tips are welcome. Thanks.
Last edited by kgizdov (2016-08-18 13:51:39)
Offline
The destination addresses look like multicast adresses .
The src addresses indicates 3 devices are involved , 192.168.1.1 & 192.168.1.77 & 192.168.1.193 .
Try to find which devices use those addresses ( 192.168.1.1 is probably your router/modem) .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Yes, it is indeed multicast. Thanks. Is there a way to exclude multicast from the logging, because I don't really want to disable the log altogether?
Offline
Yes, it is indeed multicast. Thanks. Is there a way to exclude multicast from the logging, because I don't really want to disable the log altogether?
Came onto something similar today setting up ufw for a vpn leak barrier. I had similar messages spamming my logs, and tried allowing in and out the specific IP listed (224.0.0.1 to be exact). Nothing I did seemed to work. I decided to open up my computer to the local network:
sudo ufw allow in from 192.168.1.0/24
Then disabled and enabled firewall again. Messages stopped. 192.168.1.0 indicates a range, and /24 indicates port 24. Be sure to run:
ifconfig
to see what IP is listed for you. If for example your IP on the local network was 192.168.100.1, then youd do:
sudo ufw allow in from 192.168.100.0/24
Let us know what you find out..
Offline
192.168.1.0 indicates a range, and /24 indicates port 24
Incorrect, 192.168.1.0/24 describes this range : 192.168.1.0 <= ip <= 192.168.1.255
192.168.1.0/26 gives this range : 192.168.1.0 <= ip <= 192.168.1.64
----------------------------
ufw allow in from 192.168.1.0/24
This would allow ALL incoming traffic from that network range and should only be used if you really trust everything in your network.
Better would be to allow only multicast traffic.
That can be done by allowing udp traffic going to 2 ranges , 224.0.0.0/4 & 239.0.0.0/8
I don't use ufw myself, but the rules would probably look like this :
allow in proto udp to 224.0.0.0/4
allow in proto udp to 239.0.0.0/8
Last edited by Lone_Wolf (2016-05-15 10:05:06)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
GSF1200S wrote:192.168.1.0 indicates a range, and /24 indicates port 24
Incorrect, 192.168.1.0/24 describes this range : 192.168.1.0 <= ip <= 192.168.1.25
192.168.1.0/26 gives this range : 192.168.1.0 <= ip <= 192.168.1.64
----------------------------GSF1200S wrote:ufw allow in from 192.168.1.0/24
This would allow ALL incoming traffic from that network range and should only be used if you really trust everything in your network.
Better would be to allow only multicast traffic.
That can be done by allowing udp traffic going to 2 ranges , 224.0.0.0/4 & 239.0.0.0/8I don't ufw myself, but the rules would probably look like this :
allow in proto udp to 224.0.0.0/4 allow in proto udp to 239.0.0.0/8
Thought I knew how it worked, but obviously not. Thanks for the lesson! Ill get to changing my rules right away. I trust everything on my local network but that can always change- best to have it stripped down as possible
Offline
Lone_Wolf wrote:GSF1200S wrote:192.168.1.0 indicates a range, and /24 indicates port 24
Incorrect, 192.168.1.0/24 describes this range : 192.168.1.0 <= ip <= 192.168.1.25
192.168.1.0/26 gives this range : 192.168.1.0 <= ip <= 192.168.1.64
----------------------------GSF1200S wrote:ufw allow in from 192.168.1.0/24
This would allow ALL incoming traffic from that network range and should only be used if you really trust everything in your network.
Better would be to allow only multicast traffic.
That can be done by allowing udp traffic going to 2 ranges , 224.0.0.0/4 & 239.0.0.0/8I don't ufw myself, but the rules would probably look like this :
allow in proto udp to 224.0.0.0/4 allow in proto udp to 239.0.0.0/8
Thought I knew how it worked, but obviously not. Thanks for the lesson! Ill get to changing my rules right away. I trust everything on my local network but that can always change- best to have it stripped down as possible
Upon further consideration, I realized how bad having the local network open was. Its fine at my house but as a laptop that hits the open wifi quite a bit (one of the reasons I got a VPN), it would leave me very vulnerable. Tried to use your rules but for some reason they didnt work. Upon more googling I stumbled onto this link:
http://unix.stackexchange.com/questions … ific-event
and noted the bottom response where it was said:
ufw supports per rule logging. By default, no logging is performed when a packet matches a rule.
All you have to do is create a UFW deny rule to match those multicast packets.
I created a rule as follows:
sudo ufw deny from 192.168.1.1 to 224.0.0.1
and now all the log entries are gone
My final ufw ruleset looks like:
Logging: on (low)
Default: deny (incoming), deny (outgoing), deny (routed)
New profiles: skip
To Action From
-- ------ ----
224.0.0.1 DENY IN 192.168.1.1
Anywhere ALLOW OUT Anywhere on tun0
55.55.543.56 443 ALLOW OUT Anywhere
11.123.456.789 443 ALLOW OUT Anywhere
87.654.321.11 443 ALLOW OUT Anywhere
with made up IP addresses for the entry of my vpn servers I have entry IPs of my vpn servers so I can connect without downing the firewall first. I think this setup is pretty locked down, and it doesnt bomb my logs. OP, give the deny rule a shot to see if it stops the logs. The errors arent really a problem and wont hurt anything, but if you want them kept out of logs I think this will work well.
Offline
Keep in mind that with that rule you block that multicast traffic.
224.0.0.1 The All Hosts multicast group addresses all hosts on the same network segment.
I'm not sure what impact blocking this will have on a home network, but blocking traffic because it clutters the log doesn't strike me as a good idea.
For a non-home network (like a company network) i'd check with IT before blocking it.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Keep in mind that with that rule you block that multicast traffic.
wikipedia wrote:224.0.0.1 The All Hosts multicast group addresses all hosts on the same network segment.
I'm not sure what impact blocking this will have on a home network, but blocking traffic because it clutters the log doesn't strike me as a good idea.
For a non-home network (like a company network) i'd check with IT before blocking it.
Perhaps, but better than having an open local network on unprotected wifi! Still, I saw your logic, did more searching, and finally got the error to go away by using allow:
sudo ufw allow in from 192.168.1.1 to 224.0.0.1
I can see why I didnt try this before- it didnt make sense to me since I didnt realize what 224.0.0.1 meant before. Its all good now- no blocks logged and multicast functions.
Does anything look wrong with this command lol? Im expecting you to bring up something I missed prior each time I reply to this thread
Offline
It helps that i took CCNA when it was one exam instead of 3.
( Modern CCNA routing & switching is close to original CCNA, though a bit easier )
That command looks fine, GSF1200S .
Last edited by Lone_Wolf (2016-05-18 13:51:27)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
kgizdov wrote:Yes, it is indeed multicast. Thanks. Is there a way to exclude multicast from the logging, because I don't really want to disable the log altogether?
Came onto something similar today setting up ufw for a vpn leak barrier. I had similar messages spamming my logs, and tried allowing in and out the specific IP listed (224.0.0.1 to be exact). Nothing I did seemed to work. I decided to open up my computer to the local network:
sudo ufw allow in from 192.168.1.0/24
Then disabled and enabled firewall again. Messages stopped. 192.168.1.0 indicates a range, and /24 indicates port 24. Be sure to run:
ifconfig
to see what IP is listed for you. If for example your IP on the local network was 192.168.100.1, then youd do:
sudo ufw allow in from 192.168.100.0/24
Let us know what you find out..
:~$ curl ifconfig.me
xxxxxxxxx
:~$ sudo ufw allow in from xxxxxxxxx
Sςιβrοκεrs Trαdιηg®
http://github.com/scibrokes/owner
Offline
Don't necrobump 5 year old threads: https://wiki.archlinux.org/title/Genera … bumping%22
Closing.
Online
Pages: 1
Topic closed