I’ve recently setup a turn server and still carrying out some testing on it. My infrastructure is all of my webRTC browser phones are ideally going to be external to my network with Asterisk behind a strict NAT allowing no external connections into it.
I’ll then have my turn server sitting on my network and it will be locked down to only talk to my Asterisk server and my external phone browsers can hit my public facing turn server which should relay the traffic into Asterisk.
The issue I’ve got is that when my browser phones makes a call and it generates the ICE candidate list it has the public IP of my turn server but because the turn server and asterisk sit on the same network when the traffic is relayed into Asterisk it sees the source IP as the internal IP of the turn server which isn’t in the ICE candidate list and drops the connection with the above error.
I’m really looking for a way for me to be able to have this setup but Asterisk allow the connection from the internal IP address of turn server when only the external IP address is in the candidate list, I know I’m probably just missing a setting in the pjsip / rtp conf files or something easy like that.
I’m using Asterisk 20.9.2.
Any help on this is much appreciated.
Just to add a bit more information to this below are the errors that I can see in the Asterisk CLI showing the internal IP of my turn server but as stated the candidate list obviously only has the external IP as a candidate
[Jan 28 16:12:11] WARNING[1392331][C-0001b9ca] res_rtp_asterisk.c: 1769616723.498619: DTLS packet from 10.20.30.3:61930 dropped. Source not in ICE active candidate list.
Are you sure you need a TURN server at all? If you can control/access the router, simple destination nating would do the job, so long as you describe the NAT layout to Asterisk.
Running your Asterisk box “behind a strict NAT” and having the phones “external to my network”… is pretty much exactly the same as saying “You have a hosted PBX” - except you are the host. Asterisk has no problem in this configuration even with WSS for signaling and UDP for media.
The ice candidates are more about getting the correct live IP address to populate the SDP that the WebRTC Client sends to Asterisk. Asterisk should already know its own live IP address (provided to you by your ISP)
One of the apprehensions was to have Asterisk directly contactable by external phones, I believe this was attempted in the past and not implemented correctly which basically left the door open for hackers. The idea was to keep the PBX hidden in the network and only have the turn server exposed externally and use this has an extra layer of security so that, for RTP, they would have to negotiate turn and then get through to Asterisk but in hindsight this might have been a fool’s errand
Ok, I get it - you reduce your attack surface - if the TURN server is on a static IP address, then you can set to only allow inbound media traffic from that one IP, right? fair enough - however the effort may be in the wrong place.
Since you will need to have the SIP messages flow in from the outside you are probably opening the firewall to at least the HTTPS port - this is the more serious part. And worth more consideration than media.
Media is over UDP, and there is little to nothing that any hacker could do over UPD ports between 10,000 to 65,000. (Other than flood them). Also you don’t actually need to open the UDP ports for media either - Routers generally don’t allow inbound connections by default anyway, and if you use Asterisk right - you can get it to send and receive media on the same port… meaning the outflow of audio packets makes an inbound port for your webrtc media. (rtp_symmetric = yes). Although, there can be a standoff there, if two webrtc agents are talking to each other - in this case use (rtp_keepalive = 2).
Going back to signalling - The easiest is just to make that HTTPS port high, and arbitrary… (nothing under 1024). Generally you can configure the WebSocket int he WebRTC phone to anything you want.
The best, and probably the only way to fully protect yourself here is to issue your own CA Certificate, and install it onto your own WebRTC clients - then generate a server certificate, and host it on the HTTPS port. Make sure to validate the certificate and voilà! only your own WebRTC clients can connect to your Asterisk box using HTTPS (WSS://). If you have a public service and random WebRTC clients connecting… sorry you just have to deal with it.
Disclaimer: I’m not a security expert - seek advice.
From a media injection perspective with WebRTC the media port is actually more restricted, so firewalling it is a bit of a shrug. The ICE negotiation requires a username/password exchanged in the signaling layer in SDP, packets won’t be accepted if they are not part of the ICE candidates, plus DTLS-SRTP is also negotiated which involves fingerprints also exchanged in the signaling layer in SDP. If none of this is correct the packets get dropped by Asterisk on ingress.
Yeah so reducing the attack surface was exactly where we were going. For the SIP messages these flow through our website into IIS which then reverse proxies the data into the asterisk box which means we don’t have any direct connection into Asterisk and gives us the added security of this only being accessible by users logged into our system with their own unique extension password etc all that normal stuff.
So it seems to make sense to keep the above reverse proxy we have but then open media ports as again there isn’t much anyone can do with these ports and have added security on these rather than faffing about with a turn server which seems quite overkill for what we’re trying to achieve?