Pixel Streaming failing silently on DMZ network

Development Pipeline & Plugins Plugins
, ,
1

Hi Epic Team,

We’re currently trying to get a Pixel Streaming system setup on a very locked down DMZ network.

Can you please provide a range of IPs, as well as ports/protocols required to get this working?

When I open up a browser window to localhost, it’s stuck on “CLICK TO START”. It seems to fail silently - all that appears in the Remote SignallingWebServer window when I click is this:

[09:45:53.583] info: New player connection: ::1 (/)

[09:45:53.584] info: Registered new player: Player0

[09:45:53.584] info: < Player0 :: {“type”:“config”,“peerConnectionOptions”:{“iceServers”:[{“urls”:[“stun:stun.l.google.com:19302”,“turn::19303”],“username”:“PixelStreamingUser”,“credential”:“AnotherTURNintheroad”}]},“protocolVersion”:“1.3.0”}

[09:45:53.585] info: > Player0 :: {“type”:“listStreamers”}

[09:45:53.585] info: < Player0 :: {“type”:“streamerList”,“ids”:[“Editor”]}

We’re trying to “Stream Level Editor” with “Use Remote Signalling Server” checked on in-editor, using the SignallingWebServer found here:

https://github.com/EpicGamesExt/PixelStreamingInfrastructure/releases/tag/UE5.5-4.1.2

Best,

Drew Perlman

2

Steps to Reproduce

3

Hi there Drew!

This is an interesting issue, a DMZ isn’t an environment we test in so it’s good to see a use case.

From an initial look at the log you shared, it appears your frontend isn’t trying to subscribe to the streamer. This could very well be due to unopen streamer ports.

Ports you’ll need to ensure are open are:

Signalling Server Ports

  • 80 : For HTTP requests from clients
  • 443 : for HTTPS requests from clients, when HTTPS is enabled
  • 8888 : for incoming connections from UE applications.

There are other ports for things such as Matchmaker and SFU, but if you’re just doing basic, local, editor streaming, they should not be required.

The IPs you need should simply be the relevant IPs for the machines on your network, as well as ensuring STUN and TURN have access mentioned in that log (“stun:stun.l.google.com:19302”,“turn::19303”)

You’ve mentioned you’re using infra branch 5.5, but the ticket says you’re using UE5.4, was there a particular reason for using branch 5.5?

Here’s hoping we can get to the bottom of your issue!

Kind regards,

Michael

4

Hi Michael, thank you for the reply.

Currently we have each of those ports open but are still running into issues connecting. Opening it up completely allows it to start working, but due to our network security requirements, that’s not a viable solution for us. Is there a range of IPs or hostnames you could provide that we would need to open up access to?

Re: using infra branch 5.5, we found it to be a lot more stable and consistent than previous infra releases. I confirmed we are still having issues with Pixel Streaming on UE5.5 as well, which confirms it is a networking issue vs a UE version issue.

Best,

Drew

5

Hello Drew, thank you for your patience.

To shed some more light on the issue, regarding the restrictions of IPs and Ports.

The minimum IP addresses you should have available for Pixel Streaming are:

  1. An IP address for the UE instance
  2. An IP address for the signalling server
  3. Optionally, an IP address for the TURN server (if used)

Pixel Streaming doesn’t enforce any specific IP addresses/ranges, though for our internal testing we generally run IPv4.

There are 3 methods that are best suited for Pixel Streaming for your scenario (a enterprise/restricted network). I’ll list them in order of best latency/experience to worst latency/experience.

Direct Peer-to-Peer in an Internal Network:

If the experience is being run entirely in an internal network and you know the users specific IP addresses, you should be able to give those users access to the large port range that P2P WebRTC requires. This will allow a direct peer-to-peer connection and has the highest stream quality and fidelity of all the options.

TURN Relay:

If the experience is being streamed externally or opening that large port range is not an option for those users, your second best option is to use a TURN server. A TURN server can be configured to relay all connections through a specified UDP port, for example by default the CoTURN server we configure when you run start_turn.bat will relay all media traffic over UDP port 19303. This is a common option for Pixel Streaming set-ups on restricted networks as it allows some limiting of ports for users by still allows media traffic to go over UDP (which is optimal). If you’re happy to run with the default turn configuration you can simply run start_turn.bat --default-turn alongside your signalling server and open UDP port 19303 for your users receiving the stream.

A key note is due to the nature of the TURN server relaying everything through that port, there will be an impact in latency and performance compared to the direct peer-to-peer approach mentioned above.

TCP 80 and 443:

This is a last resort option and is not recommended. This option is technically the most secure, but has a heavy performance and latency impact for Pixel Streaming that it’s nigh unusable for any streamed experience that needs any considerable video bitrate/low latency operation. This setup is more commonly used for things like conference calling, but, given that you’re using Level Streaming we believe this won’t be ideal.

This method involves having the TURN server relay the connection through common TCP ports such as 80 or 443. This would require some manual adjustment and args of the TURN server as we don’t ship this configuration out of the box, but the positive is you don’t have to open any ports on the client side.

Given your use case, I suspect the UDP TURN relay may be your best option, but I’m happy to explore the other options with you as well.

Please let me know if you had any other questions!

Kind Regards,

Michael

6

Hi Michael,

Thanks again for the response.

After opening up a few ports, we are now able to successfully Pixel Stream on the DMZ, on localhost only. That is - it works if we Pixel Stream to a local browser window on the host machine, but it does not work if we try to connect to the host from a client that’s outside the DMZ.

We prefer to use UDP, as you referred to above.

Do you have any advice settings-wise? Attached below is what we’re seeing on the firewall: all traffic is allowed, but with an error. And we’re only seeing traffic going one way: FROM the client TO the host (bluefin02). Not seeing any attempted traffic back the other way. As you can see, we’re seeing TCP resets from the host/server.

[Image Removed]

I’m seeing the message WEBRTC CONNECTION NEGOTIATED, but it doesn’t progress further than that.

[Image Removed]