1

My tv (192.168.1.48) is multicasting an SSDP packet (to 239.255.255.250:1900), and on my server (192.168.1.17), by running smcroute and doing some packet mangling to increase the IP TTL of this multicast packet, I can get it routed to (Podman/Docker) containers that are connected on a bridge network:

ISP                LAN              bridge network @ server
 |           (192.168.1.0/24)            (10.1.1.0/24)
 |                  |                         |
 +--[router]--(.1)--+                         |
 |                  |                         |
 |                  +--(.48)--[tv]            +--(.2)--[container_A]
 |                  |                         |
 :                  |                         +--(.3)--[container_B]
                    |                         |
                    +--(.17)--[server]--(.1)--+
                    |                         |
                    :                         :

And the containers can even reply to this SSDP packet, and discovery of media servers in the containers is working, all routed without proxies or NAT. (Also helped by the fact that the router on the LAN (192.168.1.1) has a static route for the 10.1.1.0/24 network, via 192.168.1.17.)

My problem is that when I create an nft rule in the FORWARD chain on server, to permit SSDP traffic to and from the containers, the conntrack system doesn't seem to pick up that responses are part of an established flow from 192.168.1.48 to both of 10.1.1.2 and 10.1.1.3, so it sees the response packets (coming from 10.1.1.2:1900 and 10.1.1.3:1900) as new flows, and that means I have to add another rule to permit udp/1900 packets from the bridge network to the LAN.

These are the relevant firewall rules:

table inet fw {
    chain FORWARD {
        type filter hook forward priority filter; policy drop;
        ct state invalid drop
        ct state established accept
        ct state related accept
        ct state untracked counter packets 0 bytes 0
        ip daddr 239.255.255.250 udp dport 1900 accept comment "forward SSDP"
        log prefix "CHAIN=FORWARD " accept # TODO: remove temporary rule
    }

    chain MANGLE {
        type nat hook prerouting priority mangle; policy accept;
        meta pkttype multicast ip ttl set 2
    }
}

This is what conntrack -L conntrack shows, note in the first line it's expecting a reply packet coming from 239.255.255.250:1900, which in reality will be 10.1.1.2:1900 and 10.1.1.3:1900:

udp      17 3 src=192.168.1.48 dst=239.255.255.250 sport=49155 dport=1900 [UNREPLIED] src=239.255.255.250 dst=192.168.1.48 sport=1900 dport=49155 use=1
udp      17 3 src=10.1.1.2 dst=192.168.1.48 sport=1900 dport=49155 [UNREPLIED] src=192.168.1.48 dst=10.1.1.2 sport=49155 dport=1900 use=1
udp      17 3 src=10.1.1.3 dst=192.168.1.48 sport=1900 dport=49155 [UNREPLIED] src=192.168.1.48 dst=10.1.1.3 sport=49155 dport=1900 use=1

Shouldn't the conntrack system be intelligent enough to see that the multicast packet and the two responses are part of the same flow? Or should there be an expectation set by a helper so that these packets are seen as RELATED instead of ESTABLISHED?

j0057
  • 180
  • 1
  • 8
  • 2
    It seems only natural to me. There's no way for it to tell that *any* other IP belongs to the `239.255.255.250` group. I mean, I'm not familiar and have not much experience with multicast, and I am not ruling out that there might be a proper way to signify that to conntrack, but obviously it won't be able to tell based on just the "numbers" (IP / socket pair). – Tom Yan Dec 28 '22 at 01:56

0 Answers0