Any work being done to better support large port ranges

Docker Engine General
1

Hello, there has been a few posts about this throughout the years but little positive feedback whether or not it is considered as a usable addition.

We’ve run Asterisk (a PBX system) containerised with Docker on Ubuntu 22.04 for quite some time. I got around to updating the engine a few days ago and suddenly our SIP calls ended up with no audio. SIP needs to have large port ranges available, 10000-32767 and 62000-62513. Any attempt at activating these natively within Docker failed when we set everything up originally, but luckily the solution then was rather simple. We could add the required NAT entries to nftables.conf like so:

chain dstnat {
                type nat hook prerouting priority dstnat - 10; policy accept;
                iifname != "asterisk" ip daddr 192.168.3.1 udp dport { 5088, 10000-32767, 62000-62513 } counter packets 0 bytes 0 dnat to 172.20.0.2
                iifname != "asterisk" ip daddr 10.9.0.50 udp dport { 10000-32767, 62000-62513 } counter packets 0 bytes 0 dnat to 172.20.0.2
        }
chain srcnat {
                type nat hook postrouting priority srcnat - 10; policy accept;
                ip saddr 172.20.0.2 ip daddr 172.20.0.2 udp dport { 10000-32767, 62000-62513 } counter packets 0 bytes 0 masquerade
        }

This worked beautifully. After the recent update however, I think that this entry in ip filter → chain DOCKER put an end to the elegance:

iifname != "asterisk" oifname "asterisk" counter packets 0 bytes 0 drop

With this change Docker now removed the last easy way to co-exist with nftables, and we’ll have to resort to setting our own accept rule in DOCKER-USER with a custom service after startup. It would in my opinion save a great deal of headache if proper support for port ranges could be considered: A docker-proxy that could handle a range of ports and nftables/iptables rules with range entries rather than singles.

A perhaps easier to implement workaround would be to let Docker merge its DOCKER-USER chain with pre-existing entries on start, so that these could be set in nftables.conf. Behavior now is that Docker completely disregards that chain if it exists, and does not create the counter packets 0 bytes 0 jump DOCKER-USER-rule in the FORWARD chain. This would at least avoid the extra clutter and invisibility with additional scripts/services.

Best regards
Alexander

1 Like
2

Thank you for sharing your insights with the community.

I assume you want your post to be read by the developers as well, as such I would suggest to reach out to them by raising an issue in docker’s upstream project moby:

3

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.