Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

NAT port forwarding in Win 2003

Discussion in '3CX Phone System - General' started by Nick60, Feb 3, 2008.

Thread Status:
Not open for further replies.
  1. Nick60

    Joined:
    Feb 2, 2008
    Messages:
    1
    Likes Received:
    0
    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::eek:nInitTests [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::eek:nInitTests [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.
     
  2. BJReplay

    BJReplay New Member

    Joined:
    Oct 31, 2007
    Messages:
    133
    Likes Received:
    0
    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.
     
  3. HatchITMan

    Joined:
    Dec 18, 2007
    Messages:
    18
    Likes Received:
    0
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.