7

A central part of my firewall configuration is:

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

It seems that RELATED does not work for multicast responses: when the host sends to a multicast group (in my case a UPnP SSDP discovery, to 239.255.255.250:1900), the corresponding responses from a specific IP address back to the sender's randomly selected port are dropped.

What is the correct way to preserve the --state ESTABLISHED,RELATED semantics, but make the response matching work for multicast?

Improve this question
0

2 Answers 2

Reset to default
2

That's the problem with multicast: netfilter can never be sure whether it's related or not.

The only way you can allow UPnP SSDP will therefore be:

-A INPUT -p udp --sport 1900 -j ACCEPT

In addition to the existing ESTABLISHED,RELATED rule.

Improve this answer
6
  • Well, at least in this case it seems it could -- my machine makes the initial request to a multicast address, from an ephemeral port. It thus seems reasonable to permit subsequent messages to this local port as RELATED. Am I missing something? Commented Mar 24, 2011 at 20:17
  • 1
    @Christian not really. In netfilter's conntrack, the addresses would be stored as "SRC=<your_IP> DST=239.255.255.250", while the reply is "SRC=<someone's_IP> DST=<your_IP>". Without a helper module, the reply looks unrelated to the original entry. Unfortunately, AFAIK there's no helper module for UPnP. Commented Mar 25, 2011 at 8:11
  • @Christian there is a way to automatically add UPnP rules into iptables, but you'll need an additional piece of software. See this page: en.gentoo-wiki.com/wiki/UPnP (it's for Gentoo, but there should be something similar if you're using other distros). Commented Mar 25, 2011 at 8:35
  • 1
    Thanks for the pointer (and sorry for the delay)! I took a look and as far as I can tell linux-igd is meant for situations where Linux is running on a gateway, so iptables can install rules as needed. For example, the manual says that to start the required daemon you need to provide internal and external interfaces. That does not apply here -- I'd simply like my client to accept the response resulting from the broadcast discovery message it sends. Commented May 3, 2011 at 23:50
  • 1
    @pepoluan Isn't this dangerous to tell a device to accept all UDP traffic based on source address? It may be ok for internal net but not for a box in the wild, am I misreading? Commented May 12, 2015 at 16:25
16

With recent Linux kernels (>= 2.6.39) you can use kernel's ipset to workaround limitation of connection tracking. You do not need to write any userspace or kernel helper. For UPnP SSDP it can be written as:

$ ipset create upnp hash:ip,port timeout 3
$ iptables -A OUTPUT -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j SET --add-set upnp src,src --exist
$ iptables -A INPUT -p udp -m set --match-set upnp dst,dst -j ACCEPT

First command creates a new ipset called upnp which stores tuple (ip address, ip protocol, ip port) and every inserted record expires in 3 seconds.

Second command matches outgoing UPnP SSDP packet (destination is multicast address 239.255.255.250 on udp port 1900) and stores source ip address and source udp port of packet into ipset upnp. First keyword src means source ip address and second keyword src means source port as ipset of type hash:ip,port always needs such pair. Keyword --exists means that for existing record is timer reseted. This stored record is automatically removed in 3 seconds.

Third command matches incoming udp packet and if its destination address and destination port matches some record in ipset upnp then this packet is accepted. Syntax dst,dst means destination ip address and destination port.

UPnP clients normally sends udp packet to 239.255.255.250:1090 and wait just 2 seconds for response. So autoexpiration in 3 seconds in ipset is enough.

I have not found on internet any working firewall/iptables configuration for UPnP clients which is not too relax (e.g. accept all incoming UDP packet) or without some userspace tracking or need to patch kernel. Therefore I hope this example helps you.

Improve this answer
3
  • 2
    This is a great solution, and can be made generic enough for different kinds of multicast services. Commented Apr 3, 2021 at 14:02
  • 1
    Adapted to nftables and made generic for multiple multicast services in superuser.com/a/1838570/223854, thanks! Commented Apr 10, 2024 at 14:18
  • Thank you! This solved my problem with my chromecast TV not being discovered. Chrome was saying "No Cast destination found". I had set up wiki.archlinux.org/title/Simple_stateful_firewall so I was blocking the ssdp response because I had all UDP ports blocked. Commented Dec 15, 2024 at 22:57

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.