Strange issue with port forwarding

Discussion in '3CX Phone System - General' started by SentryIT, Jun 11, 2015.

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

    Joined:
    May 17, 2015
    Messages:
    8
    Likes Received:
    0
    This issue we've been trying to resolve for the past two weeks.
    First started out we had BT Infinity installed which for those who don't know is Fibre.
    We configured 3CX and the BT BusinessHub5 but had no joy with incoming calls, after much messing about with port forwarding and almost an hour by BT checking to see what we'd done wrong, BT decided it was a faulty router.
    Next day we had a new BT BusinessHub5, set it up and configured port forwarding, worked straight away. Excellent I thought.
    A week later BT finally issued the static IP we ordered. BT advised that all we needed to do was to restart the router and the new IP would be picked up via DHCP (they allocate the static IP by identifying the login details). IP address showed up fine on the router status page but then we were unable to receive any calls on 3CX and after running multiple checks again it turns out that the router was no longer forwarding ports. After much discussion with BT and the support at VOIPon both of whom say it's not an issue with their end we decided to try a Draytek Vigor 2680n+ which we had in stock for another client. Configured the port forwarding and it worked straight away.
    Now the customer doesn't feel as though they need a £300 router so we decided to purchase a TP-Link TD-W9980. Now we decided to test this in the workshop before taking to the client. We have 3CX installed on a test machine, set up the router and configured port forwarding and it worked straight away. Took the router to the client site modified the external IP to match the clients and no incoming calls, checks using web based open port checker shows the ports as closed, put the Draytek back on and it's fine, return the TP-Link to the workshop, connect back up to test system, works fine.

    I'm stumped - it can't be the firewall on the host machine running 3CX at the client site because it works with the Draytek router and also worked with the BT router for a week. Also can't be anything wrong with the port forwarding on the TP-Link router as it works fine on the test machine in the workshop and our test environment is configured exactly the same as the client site, host machines have the same IP address etc. etc. The only thing that changes between the client site and test is the external IP address and the VOIP provider and that's just a simple matter of modifying two entries in the Network settings of 3CX and re-registering with the VOIP provider so I just can't understand why it won't work at the client site with anything other than the Draytek router.

    Anyone have any suggestions as I know I could tell the client they should just bite the bullet and keep the Draytek router but they really shouldn't need to as I know the TP-Link router works just fine, it just won't work at their site. By the way their site is only a simple set up, 6 machines, 6 IP Phones, Router, Switch, NAS box and network printer.


    edit....

    I've also noticed that when running a port scan on the test system the online port checkers always show port 9000-9199 as being closed even though we are able to make and receive phone calls. This is the same no matter what router we use, even the Draytek.
     
  2. ian.watts

    ian.watts Active Member

    Joined:
    Apr 8, 2011
    Messages:
    532
    Likes Received:
    0
    Issues like this and choppy audio are reasons why I have gone with multi-homing the PBX machine, relying on Windows Firewall rules to shore up the public interface. Other than the occasional config errors on an extension (wrong interface address for the provisioning is set.. more of an oops or taking a default I don't want..), my tales of woe with poor or one-way audio and other network-related issues have gone away.

    I tend to configure the Public firewall profile to allow the known 3CX Ports directly, even though the programs add their own rules. Thus, I'm usually opening up the STUN, RTP, and Tunnel ports, and SIP is limited to just the SIP trunk provider.. or I try to train up ARIN-only network addresses if I have to have remote extensions (though I'm thinking the SBC options on rPi units may do the job for remote offices.. and tunnels for the lone-wolves and road warriors).

    We mainly leverage SonicWall.. has been quite hit and miss between deploys and models. Some NetGear my boss loves was the same.. stellar for one and epic fail crashes on another (for what.. RTP streams and SIP messages?...)
    The SIP-ALG configs sometimes helped.. other times did not.

    All that being said.. I removed sketchy equipment from the config. Yeah, we can argue to death why something worked better than the other.. but again it made no sense that a 5-user office kept killing a NetGear which was only routing for the PBX. Works better for me and those problems have died off since.
     
Thread Status:
Not open for further replies.