4

I'm trying to get a WebRTC service running, through a corporate firewall. The service works on the local network, but it appears that the firewall is stopping it from working globally.

I'm using a code example from the Python aiortc package, found here, with the minor addition of a STUN server URL on both the the client- and server-side.

The client-side appears to be working as it should, and correctly sends its external IP as an ICE candidate.

The server-side, however, only sends candidates with local addresses. It appears that STUN is blocked.stunclient returns the following:

$ stunclient --verbosity 9 --mode full --localaddr eno1 
stun.stunprotocol.org
Resolved stun.stunprotocol.org to 52.15.67.208:0
config.fBehaviorTest = true
config.fFilteringTest = true
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 52.15.67.208:3478
socketconfig.addrLocal = <MyLocalIp>:0
Sending message to 52.15.67.208:3478
Continuing to wait for response...
...
Continuing to wait for response...
Sending message to 52.15.67.208:3478
Continuing to wait for response...
...
Continuing to wait for response...
Binding test: fail
Behavior test: fail
Filtering test: fail

Other STUN servers fail as well.

I think this is caused by the firewall blocking anything other than TCP on the port that I use for HTTPS.

How should the firewall be configured in order to allow STUN and WebRTC?

Thanks!

Soren
  • 41
  • 1
  • 1
  • 3

1 Answers1

3

I am the maintainer of stun.stunprotocol.org and the stuntman code itself. Just happened to catch your question here a bit late. I normally monitor the stun questions on stackoverflow.com, but only occasionally make it to serverfault.

Yes, it looks like your firewall is blocking traffic to the stun server. This isn't unexpected in big enterprise environments.

STUN, by default, works on UDP ports, not TCP. You could try specifying --protocol tcp on the stunclient command line to see if that makes any difference. But WebRTC only uses the UDP mode. One cheezy idea to try would be to host your own stun server on UDP port 53 (same as DNS) and see if that works. Again, enterprises may restrict DNS traffic to well known or internal servers.

The ask to your IT administrator would be to "open access to a remote server listening on UDP ports 3478 and 3479". You may find, if they do open those ports, that the enterprise firewall acts as a symmetric NAT and doesn't do a good job of enabling WebRTC connections. YMMV.

selbie
  • 227
  • 4
  • 7