Solved Should router forward multicast and broadcast traffic across subnets?

Solved issue
CaffeineAddict

CaffeineAddict

Well-Known Member
Joined
Jan 21, 2024
Messages
3,968
Reaction score
4,157
Credits
32,446
My simple network topology consists of localhost (host, my computer) connected to ISP gateway/router that routes to WAN. (the usual home setup)

The host has a VM's installed and a virtual switch configured.
Virtual switch (vSwitch) acts as gateway for VM's (guests).
vSwitch and thus also guest systems are on different subnet (B class)

The host is on (C class) subnet.
The host has firewall rules set up to route traffic from guests over vSwitch to physical output NIC that's connected to ISP gateway (and vice versa).

Therefore the host acts as router for guests and it's how guests connect to WAN (internet) and LAN (local network that host and other home devices are on).

Question is, should host by default forward/route multicast and broadcast packets between guests and home devices or drop them?

Note that I'm not using any special multicast groups, I'm talking about multicast packets that every OS usually generates such as:
  • 224.0.0.0-224.0.0.255 (Local Network Control Block)
  • 239.0.0.0-239.255.255.255 (Administratively Scoped Block)
And when manually using ping to send broadcast from one subnet to another.

ISP gateway will always drop them, but should guests be able to send/receive multicast/broadcast to other devices (including my computer) on LAN? that is from B class to C class and vice versa.

What should be the default behavior for my custom router?
Why should I forward and if not why not?
 


CaffeineAddict said:
Question is, should host by default forward/route multicast and broadcast packets between guests and home devices or drop them?
Click to expand...
Since no one replied here yet. I'm using Proxmox as my vm host and my vm's have internet. If you tell what information you are looking for I can see how it's configured on my Proxmox host?

Maybe this will help?
Code: 
root@pve:~# sysctl -a | grep multicast
net.ipv4.conf.all.drop_unicast_in_l2_multicast = 0
net.ipv4.conf.default.drop_unicast_in_l2_multicast = 0
net.ipv4.conf.eno1.drop_unicast_in_l2_multicast = 0
net.ipv4.conf.lo.drop_unicast_in_l2_multicast = 0
net.ipv4.conf.tap100i0.drop_unicast_in_l2_multicast = 0
net.ipv4.conf.vmbr0.drop_unicast_in_l2_multicast = 0
net.ipv4.conf.wlp8s0.drop_unicast_in_l2_multicast = 0
net.ipv6.conf.all.drop_unicast_in_l2_multicast = 0
net.ipv6.conf.default.drop_unicast_in_l2_multicast = 0
net.ipv6.conf.eno1.drop_unicast_in_l2_multicast = 0
net.ipv6.conf.lo.drop_unicast_in_l2_multicast = 0
net.ipv6.conf.tap100i0.drop_unicast_in_l2_multicast = 0
net.ipv6.conf.vmbr0.drop_unicast_in_l2_multicast = 0
net.ipv6.conf.wlp8s0.drop_unicast_in_l2_multicast = 0
net.ipv6.icmp.echo_ignore_multicast = 0

Code: 
root@pve:~# sysctl -a | grep forward
net.ipv4.conf.all.bc_forwarding = 0
net.ipv4.conf.all.forwarding = 0
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.bc_forwarding = 0
net.ipv4.conf.default.forwarding = 0
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.eno1.bc_forwarding = 0
net.ipv4.conf.eno1.forwarding = 0
net.ipv4.conf.eno1.mc_forwarding = 0
net.ipv4.conf.lo.bc_forwarding = 0
net.ipv4.conf.lo.forwarding = 0
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.tap100i0.bc_forwarding = 0
net.ipv4.conf.tap100i0.forwarding = 0
net.ipv4.conf.tap100i0.mc_forwarding = 0
net.ipv4.conf.vmbr0.bc_forwarding = 0
net.ipv4.conf.vmbr0.forwarding = 1
net.ipv4.conf.vmbr0.mc_forwarding = 0
net.ipv4.conf.wlp8s0.bc_forwarding = 0
net.ipv4.conf.wlp8s0.forwarding = 0
net.ipv4.conf.wlp8s0.mc_forwarding = 0
net.ipv4.ip_forward = 0
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0
net.ipv6.conf.all.force_forwarding = 0
net.ipv6.conf.all.forwarding = 0
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.default.force_forwarding = 0
net.ipv6.conf.default.forwarding = 0
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.eno1.force_forwarding = 0
net.ipv6.conf.eno1.forwarding = 0
net.ipv6.conf.eno1.mc_forwarding = 0
net.ipv6.conf.lo.force_forwarding = 0
net.ipv6.conf.lo.forwarding = 0
net.ipv6.conf.lo.mc_forwarding = 0
net.ipv6.conf.tap100i0.force_forwarding = 0
net.ipv6.conf.tap100i0.forwarding = 0
net.ipv6.conf.tap100i0.mc_forwarding = 0
net.ipv6.conf.vmbr0.force_forwarding = 0
net.ipv6.conf.vmbr0.forwarding = 1
net.ipv6.conf.vmbr0.mc_forwarding = 0
net.ipv6.conf.wlp8s0.force_forwarding = 0
net.ipv6.conf.wlp8s0.forwarding = 0
net.ipv6.conf.wlp8s0.mc_forwarding = 0
These are all default settings on Proxmox except some of the ipv6 stuff which I configured which are these.
Code: 
root@pve:/etc/sysctl.d# cat 80-ipv6.conf
# Disable IPv6 and RA on all interfaces
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.accept_ra = 0

# Enable IPv6 on Loopback/vmbr0 and RA on vmbr0
net.ipv6.conf.lo.disable_ipv6 = 0
net.ipv6.conf.vmbr0.disable_ipv6 = 0
net.ipv6.conf.vmbr0.accept_ra = 2
 
f33dm3bits said:
If you tell what information you are looking for I can see how it's configured on my Proxmox host?
Click to expand...
Thanks for config, default configuration set by VM software (e.g. VBox, QEMU, Proxmox etc..) will always configure IP forwarding because that's needed, in your case net.ipv4.conf.vmbr0.forwarding = 1 where vmbr0 is Poxmox virtual switch.

In case of QEMU it does same, except NIC is called virbr0 IIRC.

However in addition to that VM software also does some sort of NAT on virtual switch, don't know how Proxmox handles it but QEMU does it very poorly, it uses hardcoded iptables rules that conflict with my firewall and it's impossible to change them, and also I'm using nftables so 2 separate firewalls is not right.

To overcome this, I've dumped default network config in QEMU and implemented routing and firewall myself, with Open vSwitch and nftables rules.

Rules responsible for SNAT (Source NAT) are this:
Bash: 
#
# Virtual subnet IPv4 SNAT
# Subnet -> vSwitch -> LAN/WAN
#

# Do not masquerade multicast and broadact, it's also not routed to WAN
add rule nat_4 virtual_nat_4 ip saddr $virt_network_addr_4 fib daddr type multicast return
add rule nat_4 virtual_nat_4 ip saddr $virt_network_addr_4 fib daddr type broadcast return

# Masquerade all packets originating from virtual network toward the LAN or WAN
add rule nat_4 virtual_nat_4 meta l4proto tcp ip saddr $virt_network_addr_4 ip daddr != $virt_network_addr_4 masquerade to :1024-65535
add rule nat_4 virtual_nat_4 meta l4proto udp ip saddr $virt_network_addr_4 ip daddr != $virt_network_addr_4 masquerade to :1024-65535
add rule nat_4 virtual_nat_4 ip saddr $virt_network_addr_4 ip daddr != $virt_network_addr_4 masquerade
Where virt_network_addr_4 is VM subnet, and these rules are in postrouting NAT chain.

These rules above don't prevent multicast/broadcast going from one subnet to another, all they do is it that source IP is not modified for multicast/broadcast, and is thus up to home network devices to respond or not to VM multicast/broadcast traffic.

My question is about this, should I drop multicast all together or letting it pass trough from VM subnet to LAN subnet and vice versa? What should be default behavior here from router implementation perspective?

System configuration you posted allows routing them by default (same is on my system) however whether to drop or not can also be handled in firewall (when host acts as router instead of letting VM do it trough obscure rules).

I don't think default VM configuration can answer this because default configuration is too basic and subject to how VM implementor made it, I've confirmed default rules in QEMU are very basic and just bad, going only as far as enabling internet with SNAT for guests but not dealing with any detailed filtering for LAN.

It's likely the same with Proxmox, but I'm not sure how does Proxmox configure firewall.
I also think default VM NAT allows multicast by default only to not disable multicast groups that we may need, in other words VM implementor doesn't interfere with us.

But question is, what should a router really do with multicast across non WAN subnets? drop, SNAT or allow without SNAT?
 
CaffeineAddict said:
My question is about this, should I drop multicast all together or letting it pass trough from VM subnet to LAN subnet and vice versa? What should be default behavior here from router implementation perspective?

System configuration you posted allows routing them by default (same is on my system) however whether to drop or not can also be handled in firewall (when host acts as router instead of letting VM do it trough obscure rules).
Click to expand...
From a router perspective I don't know. I have a Unifi gateway/firewall, I just thought I would try giving you some information you should go on.
 
CaffeineAddict said:
I appreciate that, bud sadly it can't help because default config is generic, it allows all by default and lets users deal with it.
Just like default firewalls allow all by default until you add some rules.
Click to expand...
Now that I'm thinking of it. I just remembered you were talking about your Host being your router for your vm's. I also have Qemu setup on my normal desktop and my vm's there have internet either through NAT or by using the bridge interface I setup, the only thing for firewall rules I am running my desktop is using the default firewall rules, I can share those firewall rules if that helps you?
 
f33dm3bits said:
the only thing for firewall rules I am running my desktop is using the default firewall rules, I can share those firewall rules if that helps you?
Click to expand...
From my XP default firewall doesn't deal with multicast, just like it doesn't deal with NAT, this is up to users / administrators to configure if needed.

f33dm3bits said:
I also have Qemu setup on my normal desktop and my vm's there have internet either through NAT or by using the bridge interface I setup
Click to expand...
I've check default Qemu rules, they don't deal with multicast, only SNAT rules are in place to allow guests to internet.
They also don't deal with DNAT because it's up to user if they want to run a server on their VM.

So I understand why VM implementations don't define them, it's up to what users need, they only set up very minimal networking, so these defaults can't help.

I'll go now research a bit more about this online and will report back what I've found.
 
CaffeineAddict said:
Question is, should host by default forward/route multicast and broadcast packets between guests and home devices or drop them?
Click to expand...
CaffeineAddict said:
So I understand why VM implementations don't define them, it's up to what users need, they only set up very minimal networking, so these defaults can't help.

I'll go now research a bit more about this online and will report back what I've found.
Click to expand...
You could just test out what your original question is. First test out blocking multicast and broadcast packets between guest and home devices, test if everything still works and if not allow it?
 
CaffeineAddict said:
From my XP default firewall doesn't deal with multicast, just like it doesn't deal with NAT, this is up to users / administrators to configure if needed.
Click to expand...
My default firewall rules with firewalld and Qemu have prerouting and postrouting policies which includes NAT.
 
f33dm3bits said:
First test out blocking multicast and broadcast packets between guest and home devices, test if everything still works and if not allow it?
Click to expand...
Everything will work just fine because nothing on VM subnet needs multicast or broadcast to LAN, also guests don't need other devices on LAN, yet multicast is sent out by guests for network discovery and similar.

One example where I'd need multicast is if seeding torrents from guest to a computer on LAN, and similar scenarios where network discovery is needed.
However that's questionable, because it's not same subnet, I know too little about how this should work.

f33dm3bits said:
My default firewall rules with firewalld and Qemu have prerouting and postrouting policies which includes NAT.
Click to expand...
Can you please post them?
 
CaffeineAddict said:
Question is, should host by default forward/route multicast and broadcast packets between guests and home devices or drop them?
Click to expand...
I did find something not sure if it answers your questions.
networkengineering.stackexchange.com

Do routers forward broadcast traffic?

Consider a host on 10.0.0.0/24 sending a packet to 10.0.0.255 and 10.255.255.255. In the first case all hosts on his subnet should recieve the packets but would the entire network receive the pac...
networkengineering.stackexchange.com networkengineering.stackexchange.com
networkengineering.stackexchange.com

How broadcasting works on different networks?

I was reading DHCP ( RFC 2131 ), I have basic knowledge about Relay Agent and Broadcasting. But for Understanding DHCP in depth, I felt like I have to know Broadcasting and Relay Agent ( RFC 1542 )...
networkengineering.stackexchange.com networkengineering.stackexchange.com
 
f33dm3bits said:
Qemu have prerouting and postrouting policies which includes NAT.
Click to expand...
There is prerouting chain, however it jumps to sub chains, final ones of which are all empty, so there's no DNAT:
Bash: 
    chain mangle_PREROUTING {
        type filter hook prerouting priority mangle + 10; policy accept;
        jump mangle_PREROUTING_POLICIES
    }

But it does have SNAT (srcnat) rules as it should have to allow guests to internet:
Bash: 
    chain guest_nat {
        type nat hook postrouting priority srcnat; policy accept;
        ip saddr 192.168.122.0/24 ip daddr 224.0.0.0/24 counter packets 1 bytes 40 return
        ip saddr 192.168.122.0/24 ip daddr 255.255.255.255 counter packets 0 bytes 0 return
        meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535
        meta l4proto udp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535
        ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade
    }

This are basically same rules I posted in post #3, however what's interesting is ... ip daddr 224.0.0.0/24 ... return, this tells default config does deal with multicast and it doesn't SNAT them, just like my config so that's something! it's confirmation they shouldn't masqueraded :)

And other chain also allows multicast out because it doesn't check for destination address, only source is checked:
Bash: 
    chain guest_output {
        ip saddr 192.168.122.0/24 iif "virbr0" counter packets 0 bytes 0 accept
        iif "virbr0" counter packets 0 bytes 0 reject
    }

And chain forward allows all by default.

So your configuration is just like mine, doesn't SNAT multicast and it allows it to other subnet.
What happens with those packets on another subnet, whether there is response and whether response gets back to guest IDK, didn't test.

f33dm3bits said:
I did find something not sure if it answers your questions.
Click to expand...
This definitely answers broadcast, thanks!
By default they shouldn't be forwarded with exception when administrator wants it.

And now for multicast it's harder but found that whether it's routable or not depends on individual address scope...

Scroll down to "IPv4", there is "routable" column in the image:

Multicast address - Wikipedia

en.wikipedia.org en.wikipedia.org

Some multicast traffic is therefore purposed to be routed but not all.

I'd say this resolves it, multicast should be handled on individual basis and broadcast dropped.

In any case default configuration is not good enough because it lets multicast/broadcast out by default and doesn't check individual addresses.

Now it's time to adjust firewall to work by some standards. ;)
 
CaffeineAddict said:
There is prerouting chain, however it jumps to sub chains, final ones of which are all empty, so there's no DNAT:
Click to expand...
I didn't bother reading them, I just shared them since the default rules work what I need them to do on my desktop.
CaffeineAddict said:
Scroll down to "IPv4", there is "routable" column in the image:

Multicast address - Wikipedia

en.wikipedia.org en.wikipedia.org
Click to expand...
Yeah I see that.

CaffeineAddict said:
This definitely answers broadcast, thanks!
Click to expand...
Great! :)

CaffeineAddict said:
Now it's time to adjust firewall to work by some standards. ;)
Click to expand...
Curious to see your new firewall setup when you are done just to get an idea what you are trying to get done, that way I may understand what you are actually trying to accomplish since I'm still a bit confused what you are trying to achieve.
 
f33dm3bits said:
I didn't bother reading them, I just shared them since the default rules work what I need them to do on my desktop.
Click to expand...
hm, you're not worried about firewall correctness as much as I am...
I want it to not only protect system but also work by some established standards.

f33dm3bits said:
Curious to see your new firewall setup when you are done just to get an idea what you are trying to get done.
Click to expand...
Sorry but that's top secret, not sure I'll be ever sharing it and there's also a lot of LOC.

Here is LOC stats for *.nft scripts:
Bash: 
find . -name '*.nft' | xargs wc -l
   102 ./scripts/load.nft
    11 ./scripts/import.nft
    23 ./ruleset/IPv4/output/broadcast.nft
   178 ./ruleset/IPv4/output/output.nft
    50 ./ruleset/IPv4/output/virtual.nft
    37 ./ruleset/IPv4/output/multicast.nft
    14 ./ruleset/IPv4/output/related.nft
    39 ./ruleset/IPv4/output/icmp.nft
    23 ./ruleset/IPv4/input/broadcast.nft
    48 ./ruleset/IPv4/input/virtual.nft
    37 ./ruleset/IPv4/input/multicast.nft
    72 ./ruleset/IPv4/input/input.nft
    15 ./ruleset/IPv4/input/related.nft
    39 ./ruleset/IPv4/input/icmp.nft
    85 ./ruleset/IPv4/limits.nft
    79 ./ruleset/IPv4/counters.nft
    94 ./ruleset/IPv4/prerouting/attacker.nft
   273 ./ruleset/IPv4/filter.nft
    21 ./ruleset/IPv4/postrouting/virtual.nft
   141 ./ruleset/IPv4/postrouting/zombie.nft
   188 ./ruleset/IPv4/sets.nft
   107 ./ruleset/IPv4/forward/forward_out.nft
    37 ./ruleset/IPv4/forward/forward_x.nft
    49 ./ruleset/IPv4/forward/forward_in.nft
    25 ./ruleset/ARP/storm.nft
    30 ./ruleset/ARP/output.nft
    33 ./ruleset/ARP/input.nft
   112 ./ruleset/ARP/filter.nft
    37 ./ruleset/ARP/sets.nft
    71 ./ruleset/hosts.nft
    60 ./ruleset/variables.nft
    15 ./ruleset/marks.nft
     4 ./ruleset/netdev/egress.nft
    48 ./ruleset/netdev/filter.nft
    25 ./ruleset/netdev/ingress.nft
    25 ./ruleset/netdev/sets.nft
    21 ./ruleset/IPv6/output/output.nft
    46 ./ruleset/IPv6/output/virtual.nft
    66 ./ruleset/IPv6/output/multicast.nft
     9 ./ruleset/IPv6/output/related.nft
    37 ./ruleset/IPv6/output/icmp.nft
    43 ./ruleset/IPv6/input/virtual.nft
    66 ./ruleset/IPv6/input/multicast.nft
    21 ./ruleset/IPv6/input/input.nft
     9 ./ruleset/IPv6/input/related.nft
    37 ./ruleset/IPv6/input/icmp.nft
    88 ./ruleset/IPv6/limits.nft
    72 ./ruleset/IPv6/counters.nft
    93 ./ruleset/IPv6/prerouting/attacker.nft
   245 ./ruleset/IPv6/filter.nft
    20 ./ruleset/IPv6/postrouting/virtual.nft
   124 ./ruleset/IPv6/postrouting/zombie.nft
   330 ./ruleset/IPv6/sets.nft
    37 ./ruleset/IPv6/forward/forward_out.nft
    30 ./ruleset/IPv6/forward/forward_x.nft
    38 ./ruleset/IPv6/forward/forward_in.nft
    19 ./ruleset/bridge/counters.nft
   138 ./ruleset/bridge/filter.nft
  3836 total

And also for *.sh scripts:
Bash: 
 find . -name '*.sh' | xargs wc -l
   48 ./scripts/config.sh
   12 ./scripts/listsets.sh
   11 ./scripts/export.sh
  796 ./scripts/deploy.sh
   20 ./scripts/rotatelog.sh
   17 ./scripts/check.sh
   54 ./scripts/enable.sh
  958 total

That's 4794 LOC.

It should be more and there's a lot of todo's but I don't work on it much lately.

I did make my Windows firewall open source, but it won't happen with Linux firewall, I feel better if it's not public :)

Thanks a lot for help!
 
f33dm3bits said:
You don't have to share the files, I was just trying to understand what you were doing and why. That's all.
Click to expand...
Yeah, I'll post multicast implementation soon, working on it slowly to make sure no mistakes and no bloat because address scope is huge.

Categorizing multicast scopes into nf sets to be reused by rules as one liners.

Results soon! ;) it's going to be specially crafted hehe.
 
f33dm3bits said:
trying to understand what you were doing and why.
Click to expand...
Ok, here is multicast but only for output/forward.

Sets define groups which are routable and desired to be routed, non routable and not desired to be routed and reserved blocks that are always blocked as per IANA rules:

Bash: 
#
# Reserved multicast sets
#

add set filter_4 multicast_block_reserved_4 {
    type ipv4_addr
    flags constant, interval
    comment "Dropped IPv4 reserved multicast blocks"
    elements = {
        224.1.0.0-224.1.255.255, # RESERVED
        224.5.0.0-224.255.255.255, # RESERVED
        225.0.0.0-231.255.255.255, # RESERVED
        235.0.0.0-238.255.255.255, # Scoped Multicast Ranges (RESERVED)
    }
}

#
# Input IPv4 multicast sets
#

add set filter_4 multicast_block_accept_in_4 {
    type ipv4_addr
    flags constant, interval
    comment "Accepted LAN input IPv4 multicast blocks"
    elements = {
        224.0.0.0-224.0.0.255, # Local Network Control Block
        239.0.0.0-239.255.255.255 # Administratively Scoped Block
    }
}

add set filter_4 multicast_block_drop_in_4 {
    type ipv4_addr
    flags constant, interval
    comment "Dropped LAN input IPv4 multicast blocks"
    elements = {
        224.0.1.0-224.0.1.255, # Internetwork Control Block
        224.0.2.0-224.0.255.255, # AD-HOC Block I
        224.2.0.0-224.2.255.255, # SDP/SAP Block
        224.3.0.0-224.4.255.255, # AD-HOC Block II
        224.252.0.0-224.255.255.255, # DIS Transient Groups
        232.0.0.0-232.255.255.255, # Source-Specific Multicast Block
        233.0.0.0-233.251.255.255, # GLOP Block
        233.252.0.0-233.255.255.255, # AD-HOC Block III
        234.0.0.0-234.255.255.255 # Unicast-Prefix-based IPv4 Multicast Addresses
    }
}

add set filter_4 multicast_block_virtual_accept_in_4 {
    type ipv4_addr
    flags constant, interval
    comment "Accepted virtual input IPv4 multicast blocks"
    elements = {
        239.0.0.0-239.255.255.255 # Administratively Scoped Block
    }
}

add set filter_4 multicast_block_virtual_drop_in_4 {
    type ipv4_addr
    flags constant, interval
    comment "Dropped virtual input IPv4 multicast blocks"
    elements = {
        224.0.0.0-224.0.0.255, # Local Network Control Block
        224.0.1.0-224.0.1.255, # Internetwork Control Block
        224.0.2.0-224.0.255.255, # AD-HOC Block I
        224.2.0.0-224.2.255.255, # SDP/SAP Block
        224.3.0.0-224.4.255.255, # AD-HOC Block II
        224.252.0.0-224.255.255.255, # DIS Transient Groups
        232.0.0.0-232.255.255.255, # Source-Specific Multicast Block
        233.0.0.0-233.251.255.255, # GLOP Block
        233.252.0.0-233.255.255.255, # AD-HOC Block III
        234.0.0.0-234.255.255.255 # Unicast-Prefix-based IPv4 Multicast Addresses
    }
}

I make use of these sets in multicast chain that's jumped to for both output and forward chains like this:

Bash: 
#
# Output multicast IPv4 traffic
#

#
# Address Range                    Size        CIDR                Routable    Designation
# -------------                    ----        -----------            --------    -----------
# 224.0.0.0 - 224.0.0.255        (/24)        224.0.0/24            No          Local Network Control Block
# 224.0.1.0 - 224.0.1.255        (/24)        224.0.1/24            Yes         Internetwork Control Block
# 224.0.2.0 - 224.0.255.255        (65024)                            Yes         AD-HOC Block I
# 224.1.0.0 - 224.1.255.255        (/16)        224.1/16                        RESERVED
# 224.2.0.0 - 224.2.255.255        (/16)        224.2/16            Yes         SDP/SAP Block
# 224.3.0.0 - 224.4.255.255        (2 /16s)    224.3/16, 224.4/16    Yes         AD-HOC Block II
# 224.5.0.0 - 224.255.255.255    (251 /16s)    251 /16s                        RESERVED
# 224.252.0.0 - 224.255.255.255    (/14)        224.252/14            Yes         DIS Transient Groups
# 225.0.0.0 - 231.255.255.255    (7 /8s)        7 /8s                            RESERVED
# 232.0.0.0 - 232.255.255.255    (/8)        232/8                Yes         Source-Specific Multicast Block
# 233.0.0.0 - 233.251.255.255    (16515072)                        Yes         GLOP Block
# 233.252.0.0 - 233.255.255.255    (/14)        233.252/14            Yes         AD-HOC Block III
# 234.0.0.0 - 234.255.255.255    ()                                Yes         Unicast-Prefix-based IPv4 Multicast Addresses
# 235.0.0.0 - 238.255.255.255    ()                                            Scoped Multicast Ranges (RESERVED)
# 239.0.0.0 - 239.255.255.255    (/8)                            Yes         Scoped Multicast Ranges (Organization-Local Scope) aka Administratively Scoped Block.
#
# https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
# https://en.wikipedia.org/wiki/Multicast_address
#

# Detect excessive output multicast
# add rule filter_4 multicast_out_4 fib daddr type multicast limit name total_multicast_limit_4 log flags skuid flags ip options prefix "LOG excessive output IPv4 multicast "

# Reserved multicast scope
add rule filter_4 multicast_out_4 ip protocol @multicast_proto ip daddr @multicast_block_reserved_4 log flags ip options prefix "DROP reserved multicast_out_4: " counter name multicast_count_4 drop

# LAN multicast
add rule filter_4 multicast_out_4 ip protocol @multicast_proto ip saddr $network_addr_4 ip daddr @multicast_block_accept_out_4 accept
add rule filter_4 multicast_out_4 ip protocol @multicast_proto ip saddr $network_addr_4 ip daddr @multicast_block_drop_out_4 log flags skuid flags ip options prefix "DROP multicast_out_4: " counter name multicast_count_4 drop

# Virtual subnet multicast
add rule filter_4 multicast_out_4 ip protocol @multicast_proto ip saddr $virt_network_addr_4 ip daddr @multicast_block_virtual_accept_out_4 accept
add rule filter_4 multicast_out_4 ip protocol @multicast_proto ip saddr $virt_network_addr_4 ip daddr @multicast_block_virtual_drop_out_4 log flags skuid flags ip options prefix "DROP virtual multicast_out_4: " counter name multicast_count_4 drop

#
# Default chain action
#
add rule filter_4 multicast_out_4 log flags skuid flags ip options prefix "DROP default multicast_out_4: " counter name default_multicast_count_4 drop

This handles both subnets based on source address with only 5 rules that select particular sets.
If desired sets can be modified to allow/drop specific multicast address space without needing to modify rules, and in doing so it has to be respected whether specific address space is routable or not, that's where code comments help to decide.

Looks like overkill for home computer but given how rare multicast traffic is and with only 5 rules performance isn't an issue IMO.
 
Brickwizard said:
i have done the same myself when running with several forum pages open
Click to expand...

I'm going to nuke the user and clean the thread up.

Condobloke said:
Totally unrelated to this topic
Click to expand...

Thanks.

EDIT: They also had a 2nd user on their same IP address.

If one link is spam, don't clean that one up. Just nuke 'em from orbit and let their deity of choice sort them out.

Also, I've cleaned up the thread.

Now back to the topic at hand. Thanks!
 
You must log in or register to reply here.

Similar threads

CaffeineAddict
Tutorial ip command output breakdown
Replies
0
Views
867
CaffeineAddict
CaffeineAddict
Jarret B
Banana Pi R4 (BPI-R4) - DHCP for Multiple Subnets
Replies
0
Views
1K
Jarret B
Jarret B
CaffeineAddict
Tutorial Virtual machine on Linux with secure networking, firewall, TPM and secure boot
Replies
2
Views
2K
CaffeineAddict
CaffeineAddict
dos2unix
How to use Linux as a router.
Replies
7
Views
5K
f33dm3bits
f33dm3bits
D
Redirect the traffic of all my home devices to a proxy server, is it possible?
Replies
4
Views
3K
KGIII
KGIII


Follow Linux.org

Members online

Total: 4,387 (members: 1, guests: 4,386)

Latest posts

Top