Jool blocks network connectivity with overlapping ports

[telmich]

If a program uses a source port that falls into jool's configured NAT64 port range, connections will fail / hang / never work.

Example:

apu9:/etc/jool# cat jool.conf
{
  "comment": "NAT64",

  "instance": "default",
  "framework": "netfilter",

  "global": {
    "comment": "pool6 prefix",
    "pool6": "2a0a:5480:1ac:c001::/96"
  },

  "comment": "IPv4 pool4 table",
  "pool4": [
    {
      "protocol": "TCP",
      "prefix": "185.169.241.66",
      "port range": "40001-65535"
    }, {
      "protocol": "UDP",
      "prefix": "185.169.241.66",
      "port range": "40001-65535"
    }, {
      "protocol": "ICMP",
      "prefix": "185.169.241.66",
      "port range": "40001-65535"
    }
  ]

Assume then a program uses source port = 60001, the connection will fail. The following example demonstrates this:

apu9:~# curl -I https://registry.k8s.io/v2/
curl: (28) Failed to connect to registry.k8s.io port 443 after 133128 ms: Could not connect to server

## stopping jool here -->

apu9:~# curl -I https://registry.k8s.io/v2/
HTTP/2 200 
docker-distribution-api-version: registry/2.0
date: Sat, 23 Aug 2025 15:24:46 GMT
content-type: text/html
server: Google Frontend
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

## it works. Starting jool again, it fails:

apu9:~# curl -I https://registry.k8s.io/v2/
curl: (28) Failed to connect to registry.k8s.io port 443 after 133697 ms: Could not connect to server
apu9:~# 

I've added a pcap showing the exact behaviour.

This can probably be avoided by configuring Linux to not use the same port range as the one jool uses, but it should probably be documented.

pcap-apu9.pcap.gz

[telmich]

Adding more context: default port range under Linux:

apu9:/etc/jool# cat /proc/sys/net/ipv4/ip_local_port_range 
32768	60999

Default config of jool actually covers this:

apu9:/etc/jool# grep "port range" jool.conf.apk-new 
      "port range": "61001-65535"
      "port range": "61001-65535"
apu9:/etc/jool# 

[pschmalenbach]

@telmich This behaviour is documented at https://nicmx.github.io/Jool/en/usr-flags-pool4.html#port-range.
Though I agree that it is not immediately obvious because most other programs don't require exclusive access to a specific port range.

[ydahhrk]

Right... since Jool and the kernel use separate port and session tables, it seems there's not much I can do to reconcile them, barring changing the implementation completely.

I mean, it's pretty normal. Under normal circumstances, you can't bind two different services to the same port. I guess the issue is not so much that Jool doesn't let you; it's that it doesn't warn you.

[telmich]

The main problem is that packets are dropped without notice. There were a few other scenarios that I ran into with jool (on openwrt at the time) that also made the box behave like a blackhole for some packets.

I wonder if jool could even refuse the port range, if it overlaps with /proc/sys/net/ipv4/ip_local_port_range , because it is not safe/sane.

If something is binding specifically in that port range, in the best case jool would also error out and in the even better place, no applications would be able to bind in the port range, once jool is up and running.

I think this way jool would behave like "other applications" and the behaviour would be more understandable as an operator.

Btw, in case there is a new effort for integrating jool into mainline kernel, we are still open for sponsoring (some part) of it.

[ydahhrk]

[A] I wonder if jool could even refuse the port range, if it overlaps with /proc/sys/net/ipv4/ip_local_port_range , because it is not safe/sane.

[B] If something is binding specifically in that port range, in the best case jool would also error out

[C] no applications would be able to bind in the port range

I just uploaded a validation that does A. I don't think B and C are possible without modifying Linux itself.

Btw, in case there is a new effort for integrating jool into mainline kernel, we are still open for sponsoring (some part) of it.

I haven't told you? Jool will probably never be accepted into the kernel, but joolif might: https://codeberg.org/IPv6-Monostack/ipxlat-net-next

These overlapping port woes should end when that's ready, since it'll reuse the NAT66 to simulate NAT64.

[telmich]

Ciao Alberto, wow, that looks very promising. I'll follow the development there and in case we can support it somewhat, give a shout! Best regards, Nico Alberto Leiva Popper ***@***.***> writes:

…

* ydahhrk left a comment (NICMx/Jool#437) [A] I wonder if jool could even refuse the port range, if it overlaps with /proc/sys/net/ipv4/ip_local_port_range , because it is not safe/sane. [B] If something is binding specifically in that port range, in the best case jool would also error out [C] no applications would be able to bind in the port range I just uploaded a validation that does A. I don't think B and C are possible without modifying Linux itself. Btw, in case there is a new effort for integrating jool into mainline kernel, we are still open for sponsoring (some part) of it. I haven't told you? Jool will probably never be accepted into the kernel, but joolif might: https://codeberg.org/IPv6-Monostack/ipxlat-net-next These overlapping port woes should end when that's ready, since it'll reuse the NAT66 to simulate NAT64. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

-- Sustainable and modern Infrastructures by ungleich.ch