Setup A Remote SIP Extension Asterisk

copied from:
http://www.freepbx.org/support/documentation/howtos/howto-setup-a-remote-sip-extension


This HOWTO assumes that your FreePBX system is sitting behind a NATed firewall with no direct connection to the outside world and it is NOT in the DMZ zone. If you are relying on this article to set-up your system, DO NOT place your system on a public IP address or a DMZ zone. This article does not address the potential security implications involved in such a setup.

The four key considerations in setting up remote extensions are:

• 1. Ensure that your PBX is as secure as it can possibly be
• 2. Configure Asterisk so that it knows which IP addresses are inside your network and which ones are on the public internet
• 3. Forward the required ports from your firewall to your PBX
• 4. Configure the Extensions for External Use

In order to accomplish the above we need to apply some configuration information into FreePBX, some Asterisk configuration files and on your firewall/router.

Secure Your System

Anytime you access your PBX using a remote extension, you are exposing your PBX to the public internet. If you can access your system from the internet, so can anyone else. Before you begin, you might want to consider several security measures.

First, ensure that IPTables and Fail2Ban are installed and properly configured to protect Asterisk and FreePBX. Fail2Ban will temporarily ban any IP address that repeatedly attempts to connect to your PBX using the wrong password. This can effectively deter hackers, by making it take impossibly long to guess a password using brute force. Fail2Ban is already installed on the FreePBX distro, and can be configured from the System Administration module.

Second, make sure that all of your extensions are secured with a strong password. A strong password is composed of random letters (upper and lower case), numbers, and symbols, and is at least 15 characters long.

Third, you may wish to consider changing the default SIP Signaling Port from 5060 to an alternative. Port 5060 is widely used for VOIP services, and there are a number of hacking programs in the wild that scan for computers that have port 5060 open, and then attempt hack into any available PBX. If these hacking attacks succeed in obtaining a valid user/extension number and password, the hacker can use your system to place calls at your expense. Even if they don't succeed in obtaining a valid password, they can interfere with legitimate users (or crash asterisk) and thus cause your PBX to become inoperative.

In addition, Port 10000 is used for webmin (a tool that can be used to make substantial configuration changes on your machine using a web browser). If you have webmin on port 10000, either change webmin's default port to something else (such as 9001), or change the default RTP Media Ports from 10000-20000 to 10001-20000.

A range of 10000 ports available for RTP Media is often unnecessarily large for most small systems, because one call requires only 4 active ports. Thus, you might consider narrowing the range of ports used for RTP Media. If you do narrow the range, keep the range somewhere within 10000 to 20000 (i.e. don't select 43500 to 44500), as going outside this range can lead to call quality issues.

For all of these reasons, you may wish to change the default ports to alternative ports in order to enhance the security of your system.

To change the RTP Media Ports, you have to edit an Asterisk file from the command line. Open a command prompt on your machine (either by sitting in front of your machine or by using the FreePBX Java SSH module) and type the following:

cd /etc/asterisk

nano rtp.conf

In the file, you'll see the options for the low and high ports used by Asterisk. Change them to something that is still within the range of 10000 to 20000 (using ports outside this range can lead to call quality issues). At a minimum, change the lower port to start at 10001 if you use webmin.

When you're done, hit CTRL-O, hit ENTER, and then hit CTRL-X.

You now need to restart the amportal to get Asterisk to use the new ports. Type:

amportal stop

and then:

amportal start

Note: Whenever you restart amportal, you may lose Busy Lamp Fields until your phones re-register. Aastra phones default to a 3,600 second re-registration time, and so it could take up to an hour before these services come back. You can change the registration time by changing those settings in your phone's configuration settings, or simply reboot the phones to cause them to re-register immediately.

To change the SIP Signaling Port from the default of 5060, open your browser and access the FreePBX GUI. Click on "Tools," and then "Asterisk SIP Settings." If this module is not available on your installation of FreePBX, you can install it using the "Module Admin" module.

Scroll down to Advanced General Settings, and fill-in the desired port to the right of the Bind Port field. If the field is left blank, the FreePBX should default to port 5060. Click "Submit Changes" at the bottom of the screen, and then click the orange "Apply Configuration Changes" bar at the top of the screen.

Remember that if you change any of these default ports, you'll want to change the port forwarding on your router to match the correct ports. If you change your SIP signaling port, you'll need to change your phones to use the new port you selected instead of port 5060.

Tell Asterisk Which IPs are Internal and which IPs are Public

Unless you have your PBX on a public IP address (which is a very bad idea), then you need to tell FreePBX which IP addresses are internal addresses and which IP addresses are external, public IP addresses. It is important for FreePBX to have this information so that it can adjust the SIP headers to use your external IP address when it is contacting extensions outside of your local network.

Open your browser and access the FreePBX GUI. Click on "Tools," and then "Asterisk SIP Settings." If this module is not available on your installation of FreePBX, you can install it using the "Module Admin" module.

Under NAT Settings, click "Auto Configure." If FreePBX correctly enters your static IP address, your internal network address ending in .0 (i.e., 192.168.1.0), and your subnet (usually 255.255.255.0), then click "submit changes" and then click the orange bar to reload Asterisk.

If FreePBX doesn't accurately enter your static IP address and local address, enter them manually. If you have an IP address that never changes (i.e., a static IP addresss), you can select "Static IP," and enter the IP address into the "External IP" field. If your external IP address changes, you may wish to register for a Dynamic IP address (for example, using dyndns.org), and then select "Dynamic IP." Your internal IP address should be the IP address on the machines on your network, but ending in a zero. For example, if your PBX is 192.168.1.101, then you should enter 192.168.1.0 in the internal IP address field. Your subnet mask will probably be 255.255.255.0.

If you plan to connect to your PBX using a VPN from another network, click on the "Add Local Network Field," and enter the internal address used on that VPN (i.e., 192.168.2.0) along with the subnet mask (usually 255.255.255.0).

Forward the Required Ports from your Router to your PBX

You also have to forward some ports on your Firewall/Router, so that phones that are outside of your local network can reach the PBX through your router/firewall.

The default installation of FreePBX is configured to use UDP port 5060 as the SIP signaling port and UDP ports 10000-20000 as the RTP Media ports.

These ports must be forwarded to your FreePBX System using your router/firwall configuration. How to do this varies widely depending on the firewall or equipment that you are using. It is commonly referred to as Port Forwarding or maybe Destination NAT (DNAT). However it is referred, if we assume in this example that your FreePBX system has an internal IP address of 192.168.1.100, that you didn't change the default 5060 port, and that you changed the lower range of the RTP Media Port from 10000 to 10001, then you will want:

• UDP/5060 -> Forward to 192.168.1.100
• UDP/10000-20000 -> Forward to 192.168.1.100

NEVER, EVER, EVER, EVER forward port 80 from your Router to your PBX. If you need remote access to FreePBX, the FOP, or the recording interface, set-up a VPN. You have been warned!

Configure Your Extensions for Remote Access

First, select a secure password. If you are making your system available over the internet, then anyone who has a valid extension password can connect to your system and make calls, unless you take action to lock the extensions down using the deny and permit fields (which can be used to limit access to certain extensions to local users).

Second, if possible, use the deny/permit fields in the Device/Extension modules to limit access to known IP addresses for every extension. For Devices/Extensions that don't need remote access, placing the entry "192.168.1.0/255.255.255.0" in the permit field should restrict access to your local network (change 192.168.1.0 to your internal IP addresses if they are different, but end in a .0). If you know the specific IP address from which you will access the remote Device/Extension, place it and the subnet mask in the permit field for the remote Device/Extension and subnet mask of 255.255.255.255 (not 255.255.255.0).

Third, you need to configure the remote Device/Extension with NAT enabled so that Asterisk knows this device is NATed and can apply the SIP rewriting rules that you previously configured above. Navigate to the desired extension and scroll down to the Device Options Section, it should look like:

Device Options - NAT

The configuration option nat must be set to yes, and you may want to set qualify to yes as well although not necessary.

With these steps, when properly configured, your external device should be able to communicate with your FreePBX server unless you have issues on the remote end where the device is located because of badly behaved Firewalls. The remote device should be configured to use your external IP address or domain name as specified above.

Network Address Translation (NAT) is a common practice used in networks, and it doesn't play well with VoIP. Solving this problem requires an understanding of NAT, VoIP and your VoIP setup. The following focuses on the SIP protocol for VoIP using Asterisk, but problems and solutions are applicable to most other situations.

NAT can cause problems in several places. If one of the PBXes is behind a NAT gateway, the other PBX will not be able to contact it without some additional network setup. If one or more of the phones are behind a NAT gateway, the other phone will be trying to send audio to a non-routable address. This results in failed calls or missing audio.

The alternative to a re-invite is to have the PBX relay the voice packets between the two endpoints.

SIP client is behind a NAT gateway connecting to a server on the Internet

The client creates the translation entry for the SIP traffic when it first registers. As long as there is frequent communication between the two hosts, such as one packet per minute, the channel will stay open. The only configuration needed is to have the client use its external address in all SDP packets. On clients that support it, enable STUN (Simple Traversal of UDP through NAT), so the client can determine the external address dynamically, or enter it manually. Asterisk doesn't support STUN at this time, so all NAT configuration must be done manually. The following commands in /etc/asterisk/sip.conf set up the NAT properly:

[general]

localnet=192.168.0.0/255.255.0.0   // or your subnet

externip=x.x.x.x                   // use your address

[YOURREMOTEPEER]                   // your peer's name

nat=yes

qualify=yes                       // force keepalives

With this configuration, Asterisk uses the address defined by externip for all calls to the peers configured with nat=yes. The addition of qualify=yes causes Asterisk to test the connection frequently so that the NAT translations are not removed from the firewall. With these two commands, there always will be a communications channel between Asterisk and the peer, and Asterisk will use the outside address when sending SDP messages.

Multiple SIP phones and an Asterisk server behind a NAT gateway

Calls between the phones will work fine because NAT is not needed. For calls between you and other systems on the Internet there will be problems. Unless you register to the remote side as a client (as done in the previous example), you will not be able to receive SIP messages, so you will not be able to accept calls. Second, the address information in the call setup will point to the internal address of the phone, and the one-way audio problems mentioned previously will crop up.

The easiest solution to this is to avoid NAT entirely. If you have a public IP address available for your call server, use it. If your Asterisk server is connected to both the Internet and the internal network, the SIP port is reachable from both the inside and the outside, and the only problem is ensuring RTP flows properly. The PBX server does not need to be configured to route between the interfaces or provide masquerading; it simply needs to bridge the inbound and outbound voice calls.

As I mentioned earlier, the PBX either can stay in the voice path or get out of the way. In the latter case, the PBX tells both endpoints about each other after which the endpoints talk directly. However, Asterisk could have a call setup with both endpoints and relay the RTP packets on behalf of each endpoint. The inside host would be talking to the inside address, and the outside host would be talking to the outside address. The only configuration required to achieve this in sip.conf is to disable re-invites:

[general]

canreinvite=no              // force relaying

This configuration works well because the Asterisk server can speak freely to the Internet to send and receive calls. It also can talk to the internal phones, and by some simple bridging, completely ignore NAT.

As it turns out, this relaying behavior also is required when the Asterisk server has only a private address. The RTP ports will have to be forwarded on the firewall too. RTP chooses random port numbers based on configured limits. Before the ports can be configured, they should be limited in range. Configuring the firewall rules is much easier if the range of ports is known beforehand.

The range of ports to be used for RTP is defined in rtp.conf. The following configuration will limit Asterisk's choice of RTP ports from 10000 to 20000:

[general]

rtpstart=10000         // first port to use

rtpend=20000           // last port to use, rounded up if odd

Asterisk will need several RTP ports to operate properly. Only even ports are actually used, and disabling of re-invites causes two connections to be built per call. These ports and the SIP port must then be forwarded in by the firewall. The iptables syntax is:

iptables -t nat -A PREROUTING -i eth0 -p udp \

-m udp --dport 10000:10100 -j DNAT \

--to-destination 192.168.1.10

iptables -t nat -A PREROUTING -i eth0 -p udp \

-m udp --dport 5060 -j DNAT \

--to-destination 192.168.1.10

Replace eth0 with the outside interface of your firewall and 192.168.1.10 with the address of your Asterisk server. These rules tell the Linux kernel to translate the destination address of any UDP packets in the given range that are entering the outside interface. This must happen at the PREROUTING stage as opposed to the POSTROUTING stage, because the destination address is being translated. At this point, any SIP or RTP packet from the Internet will be forwarded to the internal Asterisk server for processing.

When a remote station makes a call to Asterisk, the SIP packet will be forwarded in because of the iptables rules. Asterisk will stay in the media stream because of the canreinvite=no command and it will use the external address of the firewall in any SDP packets because of the NAT commands. Finally, the media stream will be forwarded to the Asterisk server because of the combination of iptables RTP forwarding and port ranges defined in rtp.conf.

Up to this point, the configuration has focused on getting Asterisk working behind a NAT gateway, with some extra details to make the phones relay through Asterisk. There are, of course, more general solutions.

If you can avoid NAT in the first place, it is in your best interests to do so because it avoids all the problems encountered so far.

The Asterisk gateway can have a very restrictive firewall policy applied to it – you just need to allow UDP 5060 for SIP and whatever port range is defined in rtp.conf. In this configuration, Asterisk can contact both the internal phones and the rest of the Internet.

If SIP is not a requirement, and you are using Asterisk, consider using the IAX protocol. IAX tunnels both the control traffic and the voice traffic over a single UDP conversation that can be port-forwarded, filtered or translated easily. This method is limited to a static set of tunnels, which is sufficient if you are connecting some PBXes over the Internet or connecting to a long-distance provider.

Sometimes the above solutions are not available to you. In that case, it might be advisable to move to a full-featured SIP proxy and use Asterisk only for voice applications, such as voice mail. SIP Express Router (SER) is a powerful SIP server that handles NAT well and is used by several high-volume services, including Free World Dialup. SER's job is only in setting up calls between endpoints, so it must rely on other applications, such as specialized media proxies, to handle RTP streams if needed.

The step beyond a SIP proxy is a Session Border Controller (SBC), which is like a VoIP firewall. The SBC can intercede in either the signaling or RTP paths to add extra features, such as signaling protocol or codec translation, all while enforcing security policies. These are almost exclusively commercial products.