[Nick60]

I have a Win 2003 Server with 2 NIC, the first with public IP (i.e. 1.2.3.4) and the other with private IP (i.e. 192.168.0.1).
I've setup the Windows Router with Firewall/NAT (more on this later)
I have installed the free version of 3CX in a Win XP Sp 2 Desktop PC, behind the NAT with private IP (i.e. 192.168.0.125)

First of all I want to share an info that made me loose lot of time (and patience):

We all know (or is easy to find this info) taht the Firewall/NAT feature of the Win 2003 router give you the ability to add port forwarding (and automatically create firewall exceptions to let the data go trougth that port). The pocedure is very boring, because you have to add every single port (no way to declare a port range).
But the missing info that I want to share is that if you and a port declared as UDP, no exeption will be created in the firewall, so the port remain closed!

So, after reading the 3CX Tech Manual, and found the the above tip, this is the setup I've made to the firewall/NAT:

Forward incoming data (UDP) from 1.2.3.4:5060 to 192.168.0.125:5060
Forward incoming data (TCP) from 1.2.3.4:5060 to 192.168.0.125:5060

Forward incoming data (UDP) from 1.2.3.4:3478 to 192.168.0.125:3478
Forward incoming data (TCP) from 1.2.3.4:3478 to 192.168.0.125:3478

Forward incoming data (UDP) from 1.2.3.4:9000 to 192.168.0.125:9000
Forward incoming data (TCP) from 1.2.3.4:9000 to 192.168.0.125:9000

Forward incoming data (UDP) from 1.2.3.4:9001 to 192.168.0.125:9001
Forward incoming data (TCP) from 1.2.3.4:9001 to 192.168.0.125:9001

Forward incoming data (UDP) from 1.2.3.4:9002 to 192.168.0.125:9002
Forward incoming data (TCP) from 1.2.3.4:9002 to 192.168.0.125:9002

Forward incoming data (UDP) from 1.2.3.4:9003 to 192.168.0.125:9003
Forward incoming data (TCP) from 1.2.3.4:9003 to 192.168.0.125:9003

Then, to be sure that all was working, I've stopped the 3CX server and installed a port listener with a data logger in the Desktop PC at 192.168.0.125:5060 (I've used the "Fake Daemon" (you can google for it if you need it, it's free) and checked the port forwarding from a web page (so outside my private net). I've used http://www.yougetsignal.com/openPortsTool, but there are many others out there.

The ports are open, and the data logger showed the port request received from the outside ip.

So I've closed the listener and restarted the 3CX Server, and I've tried to pass the "Firewall Test".

But the test failed (for this post I've replaced the real IP with 1.2.3.4):

Result: Firewall check failed! Hide details <<<

# Port Status Description Parameters
1 9000 Error (4) The STUN server returned an ip which is not accessible from outside. addrFromSTUN = 1.2.3.4:62292
2 9000 Warning (10) Port is open, but port number has been changed. In general this should not present any problems. externalAddress = 1.2.3.4:62292
3 9001 Warning (10) Port is open, but port number has been changed. In general this should not present any problems. externalAddress = 1.2.3.4:62293
4 9002 Warning (10) Port is open, but port number has been changed. In general this should not present any problems. externalAddress = 1.2.3.4:62294
5 9003 Warning (10) Port is open, but port number has been changed. In general this should not present any problems. externalAddress = 1.2.3.4:62295

Looking at the log is easy to understand that the NAT translated the port number from 5060 to a temporary number, in this case port 62421 at time 16:43:18.427, then changed it to port 62516 at later time (3CX by default recheck for NAT translation to find the external IP, using STUB server, every 1200 second).

This is the log (for this post I've replaced the real IP with 1.2.3.4):

17:03:18.921 StunClient::process [CM506003]: Resolved SIP external IP:port has changed to (1.2.3.4:62516) on Transport 192.168.0.125:5060
17:03:18.717 StunClient::onInitTests [CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN server 64.69.76.23:3478 over Transport 192.168.0.125:5060

16:43:18.427 StunClient::process [CM506003]: Resolved SIP external IP:port has changed to (1.2.3.4:62421) on Transport 192.168.2.125:5060
16:43:18.209 StunClient::onInitTests [CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN server 64.69.76.23:3478 over Transport 192.168.0.125:5060

Now we have two problems:

1. Why the NAT, having defined those ports as forwarding ports, continue to change port numbers.
2. Whorse than that, why the firewall/nat doesn't let the STUN access the translated port?

At this point I must admit it's time to ask for help!

Is there something that I've missed or that I don't understand?

Many thanks in advance.

[BJReplay]

The Firewall test in 3CX (as far as I can tell by the behaviour of the test) attemtps to determine if it can send traffic out on a given port (e.g. 9000).

As you've noted, you've set up NAT, and windows translates your (3CX's) outgoing packets by using the public IP and a "random" port. The traffic returned to the public IP:random port will be NATted back to the originating internal IP:port. All good.

Also, incoming traffic directed to externalIP:9000 will be directed through to the specified internalIP:port (and as you've shown in your mapping, you're using the same port number in each case), so external:9000 goes through to internal:9000 - but note that this is a rule for incoming connections.

I would suggest that you set up your PBX and specify the external IP as the IP to use for registration (e.g. with VOIP providers). The registration should work - specifying your external IP and port 5060.

If your VOIP provider then sends you a invite, they'll send it to externalIP:5060, and your firewall rule will forward that to internalip:5060, where 3cx is listening.

In summary, my take is that the firewall test is misleading. If you can receive calls, you're good to go.

P.S. the additional ports in the 9000 range are for RTP traffic, and are only relevant if the PBX is handling audio for you - it knows the port range from the settings, and will tell an external device to send RTP traffic on, for example externalIP:9000. Your firewall rule will make sure it gets in.

[HatchITMan]

I had the same problem with the 2003 firewall, in that nothing happened until the TCP port was opened as well as the UDP port. I didn't realise at the time, as I opened the TCP port to check my settings, as the port sniffer I was using only worked on TCP. Later, when I blocked the TCP port 3CX stopped again.

I get the same errors from my firewall check, but SIP calls get through all right.