Multiplex TCP connections to Controllers and Workers over single port 443/TCP?

Boundary
1

Using default port numbers, Boundary clients (cli, Desktop) require that egress ports 9200/TCP towards Boundary Controllers and 9202/TCP towards Boundary Workers are open.

However, for various reasons, enterprise networks, or some ISPs upstream, or even at country level block egress connections to any ports other than a few selected, well-known ports, such as 53/UDP (DNS), 80/TCP (HTTP), 443/TCP (HTTPS). If very unlucky, they won’t
even allow egress ICMP, flows to 53/TCP, 443/UDP for QUIC/HTTP/2, and might start to block TLS 1.3, out of ignorance, by error, or on purpose.

Users of the popular Open Source software “Jitsi-Meet” for example must be able to open connections towards port 10’000/UDP in addition to 443/TCP of the conference server(s) in order to participate in Video Conferences. This turns out to be often a show-stopper and prevent users’ clients to connect to the Videobridge servers.
Therefore, over the past year or so, Devs of Jitsi have implemented at least two solutions which allow to “multiplex” also the audio/video streams through the single port 443/TCP which must be open for egress flows (using TCP streams, WebSockets, or WebRTC for ex.), in order to avoid port 10’000/UDP.

Is it already possible to coerce the Boundary clients so they “multiplex” the TCP flows to both Controllers and Workers over a single port 443/TCP, for example by using session multiplexing of HTTP/2, SNI, or looking at HTTP headers etc. to “demultiplex” them at
the server-side? Or is this a new feature which would require development?

1 Like
2

Is there a reason not to simply configure the controllers and workers on separate nodes, and configure the listeners on 443?

1 Like
3

@grantorchard1 's suggestion is spot on.

We could actually enable something like this within Boundary that switches based on TLS ALPN – a lot of the code for that already exists in the codebase – but we didn’t yet because we didn’t have time to fully flesh it out and test it, and because it may not work well with some other features we have planned later. The best idea for now is to simply run different nodes.

1 Like