I’m quite new to FreePBX and Asterisk so this could possible be a newbie issue solved easily, but I have searched the forums and manuals and not been able to find a solution to the issue.
I’m running the FreePBX on a public IP (behind external firewall) and a few local networks including remotely VPN-connected local networks to the same firewall. All extensions are working fine that are on local networks and remote VPN-connected networks.
I however want to connect remote extensions behind NAT over internet. Doing this it is important for me to use built in protocol security/encryption and have therefore configured “SIPS” through TLS & SRTP. These encrypted extensions have been tested locally and over VPN without any issues, but when I place them on a remote network behind NAT and connecting over public internet I get some issues.
Registration looks OK, and calls go through but I don’t get any audio in the calls. I could see in the firewall that the server seem to try to reach the extensions private IP when sending audio packets while SIP communications are made through the public IP that the extension sits NAT’ed behind.
I made a tshark trace and this confirmed the issue.
When logging SIP-traffic i Asterisk, I can clearly see that the remote extension responds from it’s public IP that Audio should be connected to it’s private IP. See below:
So to sum it up… I can quite clearly see what’s going on but I don’t know how to fix it. Could anyone send me in the right direction?
Is this just a configuration issue on the client side (I’m guessing configuration of ICE/STUN/TURN to handle NAT on the client)?
Or is it something that could be fixed in the server configuration? I see that ICE could be configured on the server as well.
Thanks for your reply!
Since the FreePBX is on a public IP I haven’t found any NAT settings to be made for the server, except setting the correct “External Address” that the interface has in the Settings->Asterisk SIP Settings->NAT Settings->External Address of the GUI.
I’m using PJSIP-extensions and from what I can see there is no “nat=yes” setting for a PJSIP extension since NAT should “just magically work with PJSIP” from what I have read… Doesn’t seem to be that easy though.
The strange thing i my eyes is that it seems to be the server initiating media communications to the client/extension.
Since the client is behind NAT and the media is on a new, different port from the SIP negotiation I can’t see how the traffic ever would go through the client side NAT if not initiated by the client/extension to the server?
Is there a global or local setting in the FreePBX/Asterisk if it should be the server or extension/client that initiates media traffic in a call?
Normal operation does not require ICE, STUN or TURN and IMO these often cause trouble and should be turned off. Usually, proper operation of an extension behind NAT does require RTP Symmetric, Rewrite Contact and Force rport for the extension to all be Yes, though that’s not normally an issue because these are the defaults.
On a call to an extension, Asterisk sends an INVITE requesting audio be sent to its external IP. If Asterisk is itself behind a NAT, this requires that Local Networks and External address be properly set. When the extension is answered, the 200 OK will usually have a private address in the SDP and Asterisk will indeed attempt to send a few packets there. However, as soon as RTP starts coming in from the extension, Symmetric RTP causes Asterisk to start sending to the same IP address and port number as the RTP is coming from.
If the extension → Asterisk path has no audio, something must be wrong unrelated to what the extension is sending in its SDP.
If you still have trouble, I recommend setting up a test extension without encryption. If it fails, it’s much easier to debug. If it works, you’ll know the problem is encryption related.
RTP Symmetric, Rewrite Contact and Force rport for the extension to all be Yes, though that’s not normally an issue because these are the defaults.
These are all Default/Yes.
So in this case, it seems the extension’s RTP-packets for some reason never reach the server and therefore the server keeps trying on the private IP. That would give the issue I’m experiencing.
I will follow your advice on monday and make a unencrypted setup to see if I can get that working on the same extension/environment.
It was definitely a “rookie mistake”, of course not my mistake , but anyway… Thanks everyone for all your help with information/suggestions!
I was aware of UDP 10000-20000 inbound to the server and had requested this from the team managing our external firewalls. Unfortunately that team had made a mistake in the fw rules when traffic came from the public internet.
So to sum it all up, through your help @Stewart1 I understood what was going on and got “evidence” that the firewall-people had made a mistake. When ports were opened OK, everything of course worked fine.
Another question on the IPport-topic. I would like to limit the ports used for media-traffic. UDP 10000-20000 is quite the range… Is it just one port for every active call through the server or are more than one port used per call?
I will never have more than 10-20 concurrent calls. Can I safely change “RTP Port Ranges” in SIP Settings from UDP 10000-20000 to UDP 10000-10100?
Each active channel takes 2 ports, one for each direction. Know that there is a chance of a sophisticated hacker intercepting an non-encrypted audio stream if they successfully guess an RTP port while it’s in use. Having a very large range reduces that possibility to near zero.
Thank you for your reply!
We implement SRTP for media streams over the Internet. I don’t believe in “hiding” unencrypted media streams behind a large number of open UDP-ports as a security measure.
I consider it “best practice” to limit exposure by reducing number of open ports to the internet. I do however realize that limiting the number of open ports, all open to the same type of traffic really doesn’t do much for added security.
The ports are only open during the time that Asterisk is using them.
Therefore having a bigger RTP range is not any concern.
Having a smaller range, in theory, gives an attacker a narrower field to attack, if they know of it. It also increases the likelihood you will run out of ports (for a 100 port range = 50 channels = 25 calls because remember Asterisk is a B2BUA which handles media and signaling between two endpoints).
, but anyway… Thanks everyone for all your help with information/suggestions!