[Galene] About UDP multiplexing

[Galene] About UDP multiplexing

[Juliusz Chroboczek]

Hi,

By default, Galene will use random UDP ports for media traffic.  If the
high ports are inaccessible for some reason (say, because there is
a firewall in the way), it will fall back to routing through the built-in
TURN server.  While this is the right approach, it makes Galene
challenging to install for people who wish to put it behind a firewall.

There is another approach, which is to put all the UDP traffic on a single
port; this is called UDP multiplexing.  I tried it a couple of years ago,
and it did not work well, apparently Pion (our WebRTC library) had some
issues with double-stack hosts when multiplexing.  It appears to work now,
and I've implemented it in the branch "udpmux".

UDP muxing is very simple to use: just add the option "-udp 10000", where
10000 is the port that you wish to use for UDP traffic.  There are some
caveats:

  - there is a slight performance penalty, but it should be negligible;

  - if the server is renumbered (its IP address changes), you will need
    to restart Galene.

The code is live on galene.org, and it seems to work fine.  I've
reimplemented it just today, so if you did test before, please test again.

Note that UDP muxing, in its current state, does not solve the NAT
problem: if your server is behind NAT, Galene will still fallback to TURN,
even if the mux port is forwarded on the NAT.  I'll see if I can implement
something, but please don't hold your breath, I'm not really interested in
working around NAT issues.

-- Juliusz

  

[Galene] Re: About UDP multiplexing

[Dirk-Willem van Gulik]

[-- Attachment #1: Type: text/plain, Size: 4029 bytes --]

On 22 Mar 2025, at 19:29, Juliusz Chroboczek <jch@irif.fr> wrote:

> By default, Galene will use random UDP ports for media traffic.  If the
> high ports are inaccessible for some reason (say, because there is
> a firewall in the way), it will fall back to routing through the built-in
> TURN server.  While this is the right approach, it makes Galene
> challenging to install for people who wish to put it behind a firewall.
> 
> There is another approach, which is to put all the UDP traffic on a single
> port; this is called UDP multiplexing.  I tried it a couple of years ago,
> and it did not work well, apparently Pion (our WebRTC library) had some
> issues with double-stack hosts when multiplexing.  It appears to work now,
> and I've implemented it in the branch "udpmux".
> 
> UDP muxing is very simple to use: just add the option "-udp 10000", where
> 10000 is the port that you wish to use for UDP traffic.

Works most splendidly. 

I am wondering if the config could be simpler; e.g we now have

	-udp-range 10000:20000

Which clashes (obviously) with this new

	-udp 100000

So perhaps it would be nice to simplify this in one option to:

	-udp-range 10000-20000
	-udp-range 10000

Or - when nothing is specified —  just use any port above 1024.

> There are some caveats:
> 
>  - there is a slight performance penalty, but it should be negligible;
> 
>  - if the server is renumbered (its IP address changes), you will need
>    to restart Galene.
> 
> The code is live on galene.org, and it seems to work fine.  I've
> reimplemented it just today, so if you did test before, please test again.
> 
> Note that UDP muxing, in its current state, does not solve the NAT
> problem: if your server is behind NAT, Galene will still fallback to TURN,
> even if the mux port is forwarded on the NAT.  I'll see if I can implement
> something, but please don't hold your breath, I'm not really interested in
> working around NAT issues.

For what it is worth this works fairly ok with NAT now in a somewhat neutered FreeBSD jail; config below through NAT.

Install is `stock’ freebsd from ports; with just the galene binary swapped for the one from the usbmux branch.

Which comes very close to what is ideal to deploy in a more controlled/enterprise/defence-in-depth sort of setting.

So that is most lovely !

Dw.




Jail - minimal jail with just ‘pkg install galena’ and:

/etc/rc.conf
	galene_enable=yes
	galene_http=127.0.2.1:8888
	galene_args=" -turn $EXT_VISIBLE_IP:1195 -http 127.0.2.1:8888 -insecure -udp 10000 "

Reverse proxy on the outside via apache or nginx (both work):

        
        location /ws {
            proxy_pass http://127.0.2.1:8888/ws;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }
        location  / { proxy_pass http://127.0.2.1:8888; }
    

And tied in to normal certificate mngt, logging, etc done entirely outside galene.  If needed - intercepting the web furniture.

With as the firewall setting nothing more than:

/etc/rc.conf:
	pf_enable="YES"
	pf_rules="/etc/pf.conf"

/etc/pfc.conf:

		
	ext_if=“vtnet0"
	set skip on lo
	scrub in all

	turn_range="10000"

	jails="{ 127.0.2.0/24 }"
        galene_jail_ip=127.0.2.1

	# Jails allowed to do any outbound (via NAT)
	jails_outbound="{ $galene_jail_ip }"

	nat pass on $ext_if from $jails_outbound to any -> $ext_vis_ip static-port

	rdr pass on $ext_if proto {udp,tcp} from any to $ext_jail_ip port 1195        -> $galene_jail_ip
	rdr pass on $ext_if proto {udp,tcp} from any to $ext_jail_ip port $turn_range -> $galene_jail_ip

	….
	pass in on $ext_if proto tcp          to { $ext_vis_ip } port { http, https } keep state # HTTP reverse proxy (ngix)
	pass in on $ext_if proto { tcp, udp } to { $ext_vis_ip } port 1195 keep state		# Turn
	pass in on $ext_if proto { udp, tcp } to { $ext_vis_ip } port $turn_range keep state	# RTP






[-- Attachment #2: Type: text/html, Size: 26609 bytes --]

[Galene] Re: About UDP multiplexing

[Juliusz Chroboczek]

Hi Dirk,

> Or - when nothing is specified —  just use any port above 1024.

That's pretty much what we do.  When nothing is specified, we let the
kernel choose the port every time we need a UDP socket.

> So perhaps it would be nice to simplify this in one option to:
> 
> -udp-range 10000-20000
> -udp-range 10000

I'm not sure what's less confusing: using two mutually exclusive options,
or using a single option that's overloaded (currently, -udp-range does not
enable muxing, it merely restricts the range of ports used for un-muxed
sockets).

OTOH, we'll likely have requests for other functionality (binding to
a single interface, or binding to a single IP address comes to mind), so
perhaps overloading the option will prevent multiplying options in the
future.

I'm also wondering whether we shouldn't move this to data/config.json.
Right now, data/config.json is restricted to options that can be changed
at runtime without restrarting the server, but perhaps it might make sense
to relax this requirement and put everything except debugging options into
the config file.
pp
Does anyone have opinions?

-- Juliusz

[Galene] Re: About UDP multiplexing

[Dirk-Willem van Gulik]

On 23 Mar 2025, at 10:59, Juliusz Chroboczek <jch@irif.fr> wrote:

>> So perhaps it would be nice to simplify this in one option to:
>> 
>> -udp-range 10000-20000
>> -udp-range 10000
> 
> I'm not sure what's less confusing: using two mutually exclusive options,
> or using a single option that's overloaded (currently, -udp-range does not
> enable muxing, it merely restricts the range of ports used for un-muxed
> sockets).

So as they are mutually exclusive - I like the explicitness of this.
> 
> OTOH, we'll likely have requests for other functionality (binding to
> a single interface, or binding to a single IP address comes to mind), so
> perhaps overloading the option will prevent multiplying options in the
> future.

Indeed - and one can go to the common syntax of [[ip][:port][:[ip][:port]].
> 
> I'm also wondering whether we shouldn't move this to data/config.json.
> Right now, data/config.json is restricted to options that can be changed
> at runtime without restrarting the server, but perhaps it might make sense
> to relax this requirement and put everything except debugging options into
> the config file.


For me; having things that require a restart away from things that don’t (or can be API changed) is goodness.  And generally easier on, for example, the FreeBSD modular conf system. It also conceptually aligns well; as right now things you specify on the command line need to be in sync with other things at OS level (such as firewall ports) - whereas the things in config.json are more private to galene and do not require anyone outside the galene ecosystem to know.

Dw

[Galene] Re: About UDP multiplexing

[Juliusz Chroboczek]

>> I'm not sure what's less confusing: using two mutually exclusive options,
>> or using a single option that's overloaded (currently, -udp-range does not
>> enable muxing, it merely restricts the range of ports used for un-muxed
>> sockets).

Changes this -- it's now

    -udp-range port

or

    -udp-range port1-port2

It still feels slightly off -- perhaps I should rename the option?

-- Juliusz

[Galene] Re: About UDP multiplexing

[Gabriel Pruvost-Kerneis]

> Changes this -- it's now
>
>     -udp-range port
>
> or
>
>     -udp-range port1-port2
>
> It still feels slightly off -- perhaps I should rename the option?

--udp-ports maybe? 

Gabriel

[Galene] Re: About UDP multiplexing

[Juliusz Chroboczek]

>> Changes this -- it's now
>>
>>     -udp-range port
>>
>> or
>>
>>     -udp-range port1-port2
>>
>> It still feels slightly off -- perhaps I should rename the option?

> --udp-ports maybe?

Yes, that's clearly better.  I'll wait a couple of days to see if anyone
else has a suggestion.

-- Juliusz