[Galene] udp-port range and subsequent "turn" use of ports outside that range

[Galene] udp-port range and subsequent "turn" use of ports outside that range

[Dirk-Willem van Gulik]

I've got a minor puzzle in a fairly simple setup; where galene is behind a reverse proxy & in a freebsd jail (to co-exist with another video/blackboard/sip servers).

The web and web-socket proportion is fine; as is, I think TURN:

	... 2024/02/11 13:44:29 Starting built-in TURN server on 127.0.1.12:1194
	... 2024/02/11 13:44:29 Relay test successful in 6.018877ms, RTT = 71.363µs

The latter is given a limited range with

	 -turn <outside-ip-address>:1194 -udp-range 18100-19100

which is let through by the firewall (as is 1194 of course), etc in both directions. 

But I am seeing errors:

	turn ERROR: 2024/02/11 14:26:36 Failed to handle datagram: 
		unable to handle ChannelData from 127.0.1.12:32895: 
		failed writing to socket: write udp4 127.0.1.12:24074->DESTINATION_IP:54924: 
			sendto: permission denied

and note that the port numbers under control of Galene appear to be outside the provided 18100-19100 range.

Does the range also be specified somewhere else ? This is 'stock' galene against the https://github.com/jech/galene/releases/tag/galene-0.8 tag.

With kind regards,

Dw.


galene-0.8_1
Name           : galene
Version        : 0.8_1
Installed on   : Sun Feb 11 12:55:49 2024 UTC
Origin         : www/galene
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : www net-im
Licenses       : MIT
Maintainer     : bapt@FreeBSD.org
WWW            : https://galene.org
Comment        : The Galène videoconference server
Options        :
DOCS           : on
Annotations    :
FreeBSD_version: 1302001
build_timestamp: 2024-01-07T22:34:10+0000
built_by       : poudriere-git-3.4.0
port_checkout_unclean: no
port_git_hash  : 756e18783
ports_top_checkout_unclean: no
ports_top_git_hash: 756e18783
repo_type      : binary
repository     : FreeBSD
Flat size      : 12.2MiB

[Galene] Re: udp-port range and subsequent "turn" use of ports outside that range

[Juliusz Chroboczek]

> I've got a minor puzzle in a fairly simple setup; where galene is behind
> a reverse proxy & in a freebsd jail (to co-exist with another
> video/blackboard/sip servers).

This is described in the section "Configure your server's firewall" of the
documentation.

Galene uses :

  - one TCP port for the web server, as specified by the option "-http" ;

  - one TCP and one UDP port for the TURN server, as specified by the
    option "-turn" ;

  - many UDP ports (one per media stream), which are chosen randomly in
    the ephemeral port range of your system, and may be restricted using
    the option "-udp-range".

The use of "-udp-range" is not recommended, since giving Galene too few
ports will cause issues when the range runs out.

-- Juliusz

[Galene] Re: udp-port range and subsequent "turn" use of ports outside that range

[Dirk-Willem van Gulik]

> On 11 Feb 2024, at 18:56, Juliusz Chroboczek <jch@irif.fr> wrote:
> 
>> I've got a minor puzzle in a fairly simple setup; where galene is behind
>> a reverse proxy & in a freebsd jail (to co-exist with another
>> video/blackboard/sip servers).
> 
> This is described in the section "Configure your server's firewall" of the
> documentation.

:) which was followed to the letter - and works as advertised with the
exception of limiting galene to the (large) range provided.

> Galene uses :
> 
>  - one TCP port for the web server, as specified by the option "-http" ;
> 
>  - one TCP and one UDP port for the TURN server, as specified by the
>    option "-turn" ;
> 
>  - many UDP ports (one per media stream), which are chosen randomly in
>    the ephemeral port range of your system, and may be restricted using
>    the option "-udp-range".

Right - and as per the email - all this was done exactly in this fashion.

> The use of "-udp-range" is not recommended, since giving Galene too few
> ports will cause issues when the range runs out.

Correct - but the issue that surprised me was the error:


 	turn ERROR: 2024/02/11 14:26:36 Failed to handle datagram: 
		unable to handle ChannelData from 127.0.1.12:32895: 
			failed writing to socket: write udp4 127.0.1.12:24074->DESTINATION_IP:54924: 
				sendto: permission denied

for the very first packet ever sent out.

I.e where specifically the ports selected are outside the 10.000 (ten thousand) ports made available. This large, 10k, number was chosen to prevent Galene from running out. However it appears - even for the very first connection - to not select from this range.

Does something other than the flags:

	 -turn <outside-ip-address>:1194 -udp-range 18100-19100

need to be set to constrain the TURN port choice ?

Dw 

[Galene] Re: udp-port range and subsequent "turn" use of ports outside that range

[Juliusz Chroboczek]

> Right - and as per the email - all this was done exactly in this fashion.

[...]

> Correct - but the issue that surprised me was the error:
> 
> 
>  	turn ERROR: 2024/02/11 14:26:36 Failed to handle datagram: 
> 		unable to handle ChannelData from 127.0.1.12:32895: 
> 			failed writing to socket: write udp4 127.0.1.12:24074->DESTINATION_IP:54924: 
> 				sendto: permission denied

Right, I should have read your mail more attentively.  Sorry for that.

I'll have a look.

-- Juliusz

[Galene] Re: udp-port range and subsequent "turn" use of ports outside that range

[Dirk-Willem van Gulik]

On 11 Feb 2024, at 23:14, Juliusz Chroboczek <jch@irif.fr> wrote:
>> Correct - but the issue that surprised me was the error:
>> 
>> 
>> turn ERROR: 2024/02/11 14:26:36 Failed to handle datagram: 
>> unable to handle ChannelData from 127.0.1.12:32895: 
>> failed writing to socket: write udp4 127.0.1.12:24074->DESTINATION_IP:54924: 
>> sendto: permission denied

The situation is slightly more odd.  With galene ran as:

	/usr/local/bin/galene -static /usr/local/share/galene \
			.... \
			-turn OUTSIDEIP:SRCPORT \
			-udp-range 18100-19100

I would expect to only see UDP traffic going out that originates from OUTSIDEIP. However a machine that has two addresses, OUTSIDEIP and OUTSIDEIP_2 one sees below traffic wise (galene is working fine).

With OUTSIDEIP and OUTSIDEIP_2 normal public IPv4 addresses on an internet server (at OVH) and 10.11.0.240 the internal address of one of the clients behind NAT at some consumer ADSL.

1)	I had not expected to see OUTSIDEIP_2 in this list at all.

2) 	I had not expected source UDP ports such as 11247 in below list.

With the attempts to reach 10.11.0.240 a case where perhaps some RFC1918 optimisation can be applied.

Dw.

$ sudo dwatch -p `cat /var/run/galene.pid` -X udp-send 

INFO Sourcing udp-send profile [found in /usr/libexec/dwatch]
INFO Watching 'udp:::send' ...
INFO Filtering pid: 2109

2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:SRCPORT -> CLIENTIP:58806 48 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:SRCPORT -> CLIENTIP:7450 48 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:18824 -> OUTSIDEIP:SRCPORT 28 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:18558 -> OUTSIDEIP:SRCPORT 28 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:18757 -> 10.11.0.240:58291 108 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:11247 -> OUTSIDEIP:SRCPORT 44 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:SRCPORT -> OUTSIDEIP:18824 48 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:18757 -> 10.11.0.240:58289 108 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:SRCPORT -> OUTSIDEIP:18558 48 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:18757 -> 10.11.0.240:58291 108 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:SRCPORT -> OUTSIDEIP:11247 88 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:18757 -> 10.11.0.240:58289 108 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:11247 -> OUTSIDEIP:SRCPORT 132 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:18853 -> 10.11.0.240:58291 108 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:SRCPORT -> OUTSIDEIP:11247 84 bytes
2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:18853 -> 10.11.0.240:58289 108 bytes


 -> why OUTSIDEIP_2

	2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:SRCPORT -> CLIENTIP:58806 48 bytes
	2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:SRCPORT -> CLIENTIP:7450 48 bytes

-> we could probably apply RFC1918 optimisation
	2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:18757 -> 10.11.0.240:58291 108 bytes

-> why a PORT outside the 18100-19100 range ?
	2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:11247 -> OUTSIDEIP:SRCPORT 44 bytes

-> testing myself. Fair enough
	2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:SRCPORT -> OUTSIDEIP:18824 48 bytes

[Galene] Re: udp-port range and subsequent "turn" use of ports outside that range

[Juliusz Chroboczek]

> The situation is slightly more odd.  With galene ran as:
> 
> 	/usr/local/bin/galene -static /usr/local/share/galene \
> 			.... \
> 			-turn OUTSIDEIP:SRCPORT \
> 			-udp-range 18100-19100

> I would expect to only see UDP traffic going out that originates from
> OUTSIDEIP.

I don't see why.  The above configuration only specifies that the TURN
server is advertised on OUTSIDEIP.  It says nothing about the addresses
that are advertised for direct (non-TURN) traffic.

So in the above configuration, Galene will advertise:

  - all local addresses with ports 18100-19100 ;
  - arbitrary STUN-ed addresses ;
  - TURN addresses on OUTSIDEIP:SRCPORT.

> 1)	I had not expected to see OUTSIDEIP_2 in this list at all.

That's a STUNed address.

> 2) 	I had not expected source UDP ports such as 11247 in below list.

If you seen port 11247 inside the NAT, then it's suprising.  Seeing port
11247 outside the NAT might happen if the NAT remapped a port in udp-range
to a different value.

> With the attempts to reach 10.11.0.240 a case where perhaps some RFC1918
> optimisation can be applied.

That's normal behaviour, the first point in the enumeration above.

Please be patient, I'm up to my ears in other stuff right now, but I'm
really interested in understanding the behaviour you've pointed out.

-- Juliusz

[Galene] Re: udp-port range and subsequent "turn" use of ports outside that range

[Dirk-Willem van Gulik]

> On 15 Feb 2024, at 19:09, Juliusz Chroboczek <jch@irif.fr> wrote:
> 
>> The situation is slightly more odd.  With galene ran as:
>> 
>> /usr/local/bin/galene -static /usr/local/share/galene \
>> .... \
>> -turn OUTSIDEIP:SRCPORT \
>> -udp-range 18100-19100
> 
>> I would expect to only see UDP traffic going out that originates from
>> OUTSIDEIP.
> 
> I don't see why.  The above configuration only specifies that the TURN
> server is advertised on OUTSIDEIP.  It says nothing about the addresses
> that are advertised for direct (non-TURN) traffic.
> 
> So in the above configuration, Galene will advertise:
> 
>  - all local addresses with ports 18100-19100 ;
>  - arbitrary STUN-ed addresses ;
>  - TURN addresses on OUTSIDEIP:SRCPORT.
> 
>> 1) I had not expected to see OUTSIDEIP_2 in this list at all.
> 
> That's a STUNed address.
> 
>> 2) I had not expected source UDP ports such as 11247 in below list.
> 
> If you seen port 11247 inside the NAT, then it's suprising.  Seeing port
> 11247 outside the NAT might happen if the NAT remapped a port in udp-range
> to a different value.
> 
>> With the attempts to reach 10.11.0.240 a case where perhaps some RFC1918
>> optimisation can be applied.
> 
> That's normal behaviour, the first point in the enumeration above.
> 
> Please be patient, I'm up to my ears in other stuff right now, but I'm
> really interested in understanding the behaviour you've pointed out.

No worries - feel free to ignore this completely - I'll see if I can get a more decent test case using some logging inside the sturn/ice code.

Dw.

[Galene] Re: udp-port range and subsequent "turn" use of ports outside that range

[Juliusz Chroboczek]

Hi Dirk,

Sorry for the delay.  

> 1)	I had not expected to see OUTSIDEIP_2 in this list at all.

That's ICE, the part of WebRTC that does NAT and firewall avoidance.  It's
going to try all of your addresses, that's perfectly normal.

If it is a problem for you, I may add an option to filter out a set of
addresses.

> 2) 	I had not expected source UDP ports such as 11247 in below list.

This is communication between Galene and the TURN server.  Even though
Galene has a built-in TURN server, it still communicates with the TURN
server using UDP.  Outgoing UDP traffic to the TURN server is not
controlled by udp-range, only normal RTP traffic is.

> With the attempts to reach 10.11.0.240 a case where perhaps some RFC1918 optimisation can be applied.

That's ICE again.

-- Juliusz