Connection with other participants may not be established without media permissions when using a VPN and Firefox

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

WebRTC connections are peer-to-peer (if the HPB is used the HPB acts as one of the peers), so in order to establish a connection the IP addresses of the local peer are gathered and sent to the other peer. Which addresses will be gathered depend on the WebRTC IP Address Handling mode; if media permissions are granted Firefox uses mode 1, but if they were not then it uses mode 2 (and probably 3 and 4 depending also on preferences like media.peerconnection.ice.relay_only).

It seems that it is not enough to grant media permissions in general (for example, by opening Talk settings or if prompted in the device checker); mode 2 seems to be used if the call is joined without any selected device or without publishing permissions which, in both cases, prevents any sender connection from being created, only receiver ones are used (but this needs to be verified).

In the past (Firefox 68) a connection could not be established when using two virtual machines (one for the Nextcloud server and the HPB, and another one for the browser) connected by an internal network if the client machine also has a public interface (which is its first interface). In this scenario when trying to connect with Firefox without media permissions (mode 2) Firefox tried to connect using the IP address of the public interface, so it was unable to connect to the server in the other virtual machine. When media permissions were granted (mode 1) it tried to use both the public IP address and the internal IP address, so it successfully connected using the internal IP address.

This is no longer the case in recent Firefox versions; when the media permissions are denied the single host IP address used now is the one from the internal network. Therefore, the connection works. This shows that how the default route is chosen was changed in recent Firefox versions (probably to adjust to changes in the spec), and it may be based on the route used to reach the web server.

Nevertheless, it seems that there are still some cases in which a connection can fail using mode 2; see:
https://bugzilla.mozilla.org/show_bug.cgi?id=1384265
https://bugzilla.mozilla.org/show_bug.cgi?id=1659672

Due to this a listener participant may not be able to connect to other participants if the listener is using a VPN (or other specific network setups) and Firefox.

No source files, tests, or entry points are identified in the issue. Start by reproducing the connection failure in Firefox with a VPN and media permissions unavailable, then compare the behavior with permissions granted; done means identifying a reproducible cause and a verified fix for listener connections.