-
-
Notifications
You must be signed in to change notification settings - Fork 488
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
STUN and TURN not working with Docker without "network_mode: host", as described in install instructions for "Port Range" docker-compose.yml #56
Comments
Have you tested screego without docker to ensure the docker container is really at fault here? Have you logged in and created a room with a user session or configured
The demo instance is hosted without docker. Turn on there is disabled for unauthenticated users, thus, it is perfectly fine that the stream doesn't work there because TURN isn't used. |
I didn't test it without docker, but it's working fine with a docker-compose.yml that uses I'm not sure what exactly causes this, but apparently there are frequent issues when hosting TURN using Docker, examples:
Further, afaik docker-compose (or Docker itself?) also seems to have troubles binding both TCP and UDP ports for the same port range. I first posted this issue as a comment in #27 because @mbleichner mentioned "inspecting port 3478 with tcpdump, it seems like some (not all) UDP packets use an internal docker IP address". Unfortunately I'm not sure whether his solution also was using Tbh, I'm really not sure if the issue is caused by Screego or the way how Docker binds the ports. If Docker is not supported without
I'm aware of the settings, so yes, everything done and running fine. However, I'm currently using
I know that TURN is not enabled on the demo instance for unauthenticated users, but I disagree that "it is perfectly fine that the stream doesn't work there because TURN isn't used". Using STUN is in some cases sufficient, even if both clients are behind are NAT. I've tested this with both Screego in STUN mode as well as another tool. In my 3rd scenario, I used a mobile client using a cellular connection (LTE). In that case, the stream does not load when only STUN is used, I assume that's because of some complex LTE proxies and IPv4 via IPv6 etc, but that's fine. When I switched to TURN, streams are working working for all three scenarios, including via the cellular connection. Therefore, my conclusions are:
By the way, I'd also recommend adding a brief explanation below the "create room" form that informs the user, that TURN is supported and built-in, but disabled (for unauthenticated users) on the demo server. |
Thanks for the great analysis (:,
This could be, I'll take this on my to do list to check. It should be possible to use the stun via tcp only (which is enabled by default), maybe we can workaround weird udp things in docker with this.
I've played with this thought already a little, this would require to have different UIs for public screego and self-hosted screego or some kind of hidden config flag. I rather keep screego simple (:.
So there is no difference between laplace and screego, only between public screego and self-hosted screego?
I can say that I use app.screego.net without turn with some of my colleagues, and we both have a nat'ed router. On app.screego.net IPv6 is enabled, which probably is used for most of the traffic. Maybe the IPv6 traffic is routed differently and thus, you're experiencing different results on self-hosted / public-hosted. Could you test on https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ that |
I switched to network_mode: host, so that was actually what solved it for me. And because it worked so well, I actually never tried to switch back to publishing ports explicitly. |
Screego (STUN) and Laplace (both on my instances behave) identical: 2 of 3 scenarios work (Please keep in mind that all three scenarios use NATs or firewalls. On a local network without NAT app.screego.net works well)
Ok, that's strange. Maybe it's indeed IPv6 ralated? I've been lazy and on I didn't configure IPv6 on my server yet, so maybe it's indeed related to this? A friend told my about Screego after I've showed him a Laplace demo instance. However, he mentioned that he also tried the public instance but for him it also did only work in a local network and failed on nat'ed connections otherwise.
Returned addresses are the same for both STUN servers, and the returned address is IPv4. However, for my machine I receive the message:
But I think that error is a result of missing IPv6 configuration and can be ignored |
Thank you for the information! :) |
Could you try https://appv4.screego.net/ this dns entry only has ipv4 settings. |
appv4.screego.net behaves the same as my instance (with STUN) and the two scenarios are working here as well. So apparently it's really an IPv4/IPv6 issue, interesting. Maybe noteworthy is that my Internet connection supports both IPv4 and IPv6 but the connection of my colleague seems to be IPv4 only (=scenario number 2), maybe this also a part of the problem? |
I think this is actually a bug in the implementation, dunno why I though this would make sense. If you connect via ipv6 then you only receive the ipv6 stun server thus only your external ipv6 and vice versa for the ipv4 address. If someone connects via ipv6 and another with ipv4 (without support for ipv6) then normal p2p connections cannot be established. |
* User1 connects with IPv6 * User2 connects with IPv4 (without any support for IPv6) * User1 asks via STUN for his address, and receives a IPv6 address back * User2 asks via STUN for his address, and receives a IPv4 address back * User2 cannot connect to User1 IPv6 address After this fix: User1 asks both for his IPv4 and IPv6 addresses. See #56
* User1 connects with IPv6 * User2 connects with IPv4 (without any support for IPv6) * User1 asks via STUN for his address, and receives a IPv6 address back * User2 asks via STUN for his address, and receives a IPv4 address back * User2 cannot connect to User1 IPv6 address After this fix: User1 asks both for his IPv4 and IPv6 addresses. See #56
Wanted to document a reproduction of what I think might be the same/similar issue that @ThelloD was initially seeing. There is a bit more complication in my setup for a couple reasons:
Upstream I have a public address, I'll say 200.100.100.100. I'm setting configuration parameters in a file
This is the desired invocation:
This doesn't appear to work. The we can get the web server side to function properly, but streams do not work unless you're in the same LAN. Testing with this gives us immediate feedback... but I'm not sure how to parse/understand the results. Changing invocation to
With:
I'd like not to run with the |
Yes, this is a similar problem, when using port ranges with docker the browsers cannot establish a connection with each other even when turn is used. |
Maybe I'm not grasping the state of the network in play, but I seem to be able to get things working without the turn ports being forwarded at my border firewall. Does the turn instance use a connection on 3478 to ratchet up to that port range? My border firewall is allowing through 80,443, and 3478. I'm guessing that once connection is made on 443, then 3478, it ratches up to the 50000 range and it does so by NAT punching? |
How do you test that it works? Turn is only needed if peers cannot connect to each other directly. So it can work without exposing the turn ports. |
If docker is used without network_mode: host, then the strict ip checks fails, this can be disabled with |
I've spent quite some time testing v1.1.1 in a Docker environment according to the "Port Range" section of the installation guide. I think with the current version it's (nearly?) impossible to get Screego to work outside of a local network with port mappings such as:
Locally it works fine, but behind a NAT, both STUN as well as TURN fail and the stream remains black.
The only solution I found to get it working with Docker was to use the
network_mode: host
syntax.(Other potential solutions approaches might involve additional firewall rules or explicitly specifying every in
ports:
with the- mode: host
syntax since docker-compose does not support ranges here, but I didn't check these.)I'm not really sure why the issue was closed but at least for me it's not working.
Further, I've tested Screego with STUN in various scenarios, all except one worked well. However, the demo instance at app.screego.net didn't work at all as soon as at least one NAT was in-between the connection path. If the demo instance is hosted using via Docker this might be caused by the same issue.
Originally posted by @ThelloD in #27 (comment)
The text was updated successfully, but these errors were encountered: