A central part of my firewall configuration is:


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, 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?


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.

  • 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?
    – Christian
    Mar 24 '11 at 20:17
  • 1
    @Christian not really. In netfilter's conntrack, the addresses would be stored as "SRC=<your_IP> DST=", 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.
    – pepoluan
    Mar 25 '11 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).
    – pepoluan
    Mar 25 '11 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.
    – Christian
    May 3 '11 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?
    – nhed
    May 12 '15 at 16:25

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 -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 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 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.

  • 1
    This is a great solution, and can be made generic enough for different kinds of multicast services. Apr 3 at 14:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.