Solve problems with remote connections in 3CX

We periodically receive appeals about incorrect work of remote users connected to 3CX via corporate NAT router or firewall. In this article, we offer a step-by-step guide to solving problems with remote connections.

Unfortunately, 3CX cannot guarantee the correct operation of “direct” remote connections, especially without the use of 3CX Tunnel technology.

Correct work is not guaranteed for the following reasons:

• Specific or incorrect network topology;
• Specific or incorrect settings of the router or firewall from both the 3CX side and the remote user;
• Incorrect work of NAT or SIP ALG services in network devices (sometimes eliminated by updating the firmware);
• Blocking certain ports by Internet providers (for some operators or in hotels);
• The lack of access by a VoIP specialist to network equipment, i.e. the inability to configure the customer's network for the operation of VoIP applications.

What should I pay attention to if you encounter problems with a remote connection?

Allow remote connection for user

In the 3CX management interface, go to the Properties tab of the Account tab.

• In order to allow a “direct” remote connection, disable the option Block connection outside the local network.
• In order to allow remote connection via 3CX Tunnel, disable the option Block connection from public network through 3CX tunnel

Publication of 3CX services (port forwarding) on ​​a router

First of all, we note that the simpler the topology of your network, the fewer intermediate devices between the 3CX server and the WAN interface of the router to which external users connect, the greater the chances of success. You may not even suspect that the ISP has given you not a “white” IP address on the WAN interface, but a “gray” IP from its internal network. This is especially common in business centers where the Internet is distributed over an internal local area network.

For correct connection of external users, as well as for audio and video streaming through them, the following ports should be published (forwarded to the IP address of the 3CX server) on the router:

• 5060 UDP - SIP server port 3CX
• 9000-9500 UDP - RTP Audio / Video stream with a remote user
• 5090 UDP and TCP - 3CX Tunnel service port
• 5000 - 5001 or 80/443 - HTTP ports for 3CX web service

We recommend that you familiarize yourself with the complete list of ports used by 3CX.

Remote SIP devices supporting NAT

If you plan to use direct SIP connection (i.e., without 3CX Tunnel technology), it is recommended to use only supported 3CX phones . They, in particular, correctly support the following functions:

• Rport
• STUN
• Keep - Alive

Connect one of the recommended phones remotely and make sure that it is registered to 3CX. Make a call on the 3CX ping * 777 . If you have correctly configured the router from the 3CX server side (as described above), but the call does not go through or the hearing is one-way - most likely the problem is in the router that connects the remote IP phone to the Internet (that is, on your side).

Try connecting again, but using 3CX Tunnel (3CX SBC). If the audibility is normal, you should return to the router settings - update the firmware, make sure that the port forwarding settings are configured correctly, contact the manufacturer’s technical support, etc.

Using 3CX Tunnel and 3CX Session Border Controller

If you find it difficult to determine the cause of incorrect registration of a remote subscriber, or you cannot achieve two-way audibility, we recommend that you do not use the “direct” SIP connection and use 3CX Tunnel technology. 3CX Tunnel is built into the 3CX Client for all platforms. If you need to connect a hardware phone or a group of phones, we recommend using 3CX Session Border Controller .

Using 3CX Firewall Checker Client

If you still need to achieve correct operation of the “direct” connection, we recommend running the 3CX Firewall Checker Client . The main task of this utility is to determine whether the static port forwarding on the 3CX server is configured correctly. Using 3CX Firewall Checker Client can “give a hint” in the following situations:

• Remote subscriber is not registered
• One-way sound with a remote subscriber
• STUN server issues

The 3CX Firewall Checker Client error log will give you a rough idea of ​​where to look for the source of the problems.

Routers with SIP ALG and SIP Helper

Many routers have a feature called SIP ALG or SIP Helper. SIP ALG modifies the SIP packet header for correct NAT / PAT translation. However, with the development of the SIP standard, more reliable NAT traversal mechanisms have appeared, for example, the RIP SIP field in the VIA header. All phones recommended by 3CX support the Rport field. The SIP ALG router function may undesirably modify the VIA SIP header, distorting the data set by the Rport extension. Therefore, we strongly recommend disabling the SIP ALG or SIP Helper option if it is present in your router. Familiarize yourself with the features of VoIP traffic passing through the NAT / PAT broadcast .

System parameter “ALLOWSOURCEASOUTBOUND”

The system parameter ALLOWSOURCEASOUTBOUND is set in the 3CX control console in the Parameters section.

By default, it is 0 (disabled). If it is set to 1 (enabled), 3CX will use the IP address and port from the IP packet header (network layer) for registration of the remote phone, and not from the Contact field of the SIP packet header (application layer). 3CX Media Server will also use the packet's RTP (Incoming Media Stream) IP packet data to determine the address to which the outgoing media stream should be sent.

It is recommended to set the specified parameter if there are the following problems:

• Remote subscriber for double or triple NAT
• Remote subscriber does not support Rport extension
• Remote subscriber sends incorrect registration information due to errors in its SIP stack
• The remote subscriber is connected to his network via a NAT router with SIP ALG enabled. This router incorrectly modifies the information in the SIP header. In this case, you do not have access to a remote router.

Spread SIP ports on remote devices

If several remote devices are connected from the same network (LAN), and all the methods described above do not solve the problem, you can try to assign your own, non-recurring SIP port on each such device. For example, on the first device (phone, gateway, etc.), set the SIP port 5060, on the second 5062, on the third 5064, etc. In some cases, after this device starts to work successfully.

Conclusion

Now you can see how proper planning and correct operation of the network infrastructure are important for connecting remote users, and even VoIP systems as a whole. Summing up, let us once again pay attention to the features of the work of 3CX with remote connections:

• If the remote subscriber is not connected, or the sound does not come from it - this is not a 3CX problem, this is a problem of the network infrastructure, in particular, WAN - LAN routing
• Try to simplify the infrastructure as much as possible and eliminate double and triple NAT conversion
• Use recommended, proven firewalls and recommended 3CX SIP equipment
• Install the latest 3CX updates and the latest firmware on routers and SIP devices
• If possible, use 3CX Tunnel, which is used in all 3CX softphones, or 3CX SBC to remotely connect standard SIP phones

To repeat: 3CX supports remote direct SIP connections. Nevertheless, 3CX guarantees the correct operation of remote subscribers only if using the 3CX Tunnel technology. In all other cases, due to a multitude of factors beyond our control, it is impossible to guarantee a correct remote connection!