Reputation: 127
I have build a one to one webrtc communication system (peer to peer). I use coturn as a STUN and as TURN. The connection works in chrome (72) and firefox (65) whithot VPN. The connection also works in chrome and firefox, when behind a symetric NAT (for example while using a mobile-phone). The connection works also when using VPN and chrome.
The connection (ICE) failed, when using VPN and firefox! Testet with a couple of popular VPN's.
Any Ideas, what could be wrong/ how to solve?
My TURN-Server Configuration looks like:
listening-port=3478
tls-listening-port=5349
realm=xyz.com
min-port=49152
max-port=65535
user=uuuuuuuuuuuuu:ppppppppppp
pkey=/usr/local/psa/var/modules/letsencrypt/etc/live/turn.xyz.net/privkey.pem
cert=/usr/local/psa/var/modules/letsencrypt/etc/live/turn.xyz.net/cert.pem
CA-file=/usr/local/psa/var/modules/letsencrypt/etc/live/turn.xyz.net/chain.pem
mysql-userdb="host=localhost dbname=turnxxxxxx user=uuuuuuuuuuuu password=ppppppppppp port=3306"
fingerprint
lt-cred-mech
Upvotes: 3
Views: 2769
Reputation: 2106
You should expect any WebRTC-related application to fail in all browsers, when VPN is on. I have exactly opposite situation - when VPN is on, no browser works except FireFox. And in my app no TURN servers are used at all. Somehow my VPN misses FireFox.
In general, WebRTC is prohibited by VPNs, because of IP address leak paranoia. Your real IP address can leak through signaling messages and STUN binding response, so once VPNs see STUN binding requests, they just kill it. VPNs cannot kill your signaling messages so your private IP can still leak, but that's a problem only with IPV6, where private and public IPs are the same. But, when it's time for STUN binding request/respose, VPNs kill it. Not sure how your Chrome survives.
Upvotes: 3