Unable to connect SBC to PBX...

[narrington]

I am trying to deploy a new SBC running on windows 2012. when I try to start the service, it fails and I see this in the log:

ERR | 20190531-095138.508 | 3CXTunnel | TUNL | 3592 | TunnelTcp.cpp:165 | Failed to resolved DNS SRV record for tunnel connection to [FQDN]
ERR | 20190531-095148.571 | 3CXTunnel | TUNL | 3592 | TunnelTcp.cpp:184 | Failed to resolve host name [FQDN]
ERR | 20190531-095148.571 | 3CXTunnel | TUNL | 3592 | TunnelTcp.cpp:232 | Failed to resolve connection [FQDN]

I noticed I am unable to ping the fqdn, but that's just icmp. The relevant ports are open and communicate (tested with port-checker). That said, running a ping on the fqdn DOES return the correct public IP of the PBX so I'm confident DNS isn't the issue, and as I said portchecker shows ALL the relevant ports including 5060 and 5090 are open.

Portchecker DOES report ports 5060 and 5090 are closed on the public IP of the SBC, but I followed this guide for the firewall: Link, and windows firewall is off entirely. I suspect portchecker is simply not getting a response from the server because the sbc service is down... right?

anyone?

 

[narrington]

UPDATE: I edited the config and swapped the fqdn with the public IP. the SBC is now working... but I dont think that's the best solution... I'm going to leave it for now, but I'd like to change it back if anyone can point me in the right direction.

 

[VoIP-Cloud]

It seems your SBC ( win 2012 server ) can't resolve the FQDN of your 3CX. What are your dns-Server for the SBC? Can you give output of a

nslookup <your-3cx-fqdn>

 

[AWS2P]

You use a windows server 2012 machine as SBC ? if so, perhaps DNS server is running from 2012 server.
Why did you choose this hardware to run as SBC ?

3CX prerequisite is dedicated computers with no others software nor DHCP or DNS services running on same PC

Try to install SBC on another small computer and see if problem is no longer existing

 

[eddv123]

This can be a common occurrence with the SBC on Windows. I have seen it several times on sites where the client leaves the box on DHCP and acquire DNS dynamically.

First tip - set your NIC card IP address and subnet statically as well as your DNS servers - which need to be static as well as reliable.

If the DNS does not resolve on the SBC machine the tunnel will not connect.

 

[JohnS_3CX]

Hi @narrington

Yes the tunnel port will need to be forwarded on the SBC side firewall, and the HTTPS port will also need to be open for outgoing.

Your windows machine should also be able to resolve the FQDN as @VoIP-Cloud mentioned and this machine will have to be dedicated to the SBC.

You also have the option of using our Debian ISO and installing the SBC on a dedicated machine.

 

[narrington]

Go away for the weekend and come back to lots of replies...

It seems your SBC ( win 2012 server ) can't resolve the FQDN of your 3CX. What are your dns-Server for the SBC? Can you give output of a

nslookup <your-3cx-fqdn>

I get this:

C:\Windows\system32>nslookup [removedFQDN]
Server:  UnKnown
Address:  192.168.0.10

Non-authoritative answer:
Name:    [removedFQDN]
Address:  [removedIP]

You use a windows server 2012 machine as SBC ? if so, perhaps DNS server is running from 2012 server.
Why did you choose this hardware to run as SBC ?

3CX prerequisite is dedicated computers with no others software nor DHCP or DNS services running on same PC

Try to install SBC on another small computer and see if problem is no longer existing

In a past life, this server was a domain controller. It's been demoted, decommissioned, and all related network services removed. I have no issues nuking and paving it, I just installed the SBC software on it as it was readily available. I KNOW this is not a DNS issue as both nslookup and ping return a valid IP address. True, Ping fails to get replies from the PBX, but this is a non issue. ICMP can't get through, but everything that matters can.

This can be a common occurrence with the SBC on Windows. I have seen it several times on sites where the client leaves the box on DHCP and acquire DNS dynamically.

First tip - set your NIC card IP address and subnet statically as well as your DNS servers - which need to be static as well as reliable.



If the DNS does not resolve on the SBC machine the tunnel will not connect.

This *may be the issue... I had set it to DHCP originally. I'll change it over later and see what works (we're live now so I need to wait for a service window).

Hi @narrington

Yes the tunnel port will need to be forwarded on the SBC side firewall, and the HTTPS port will also need to be open for outgoing.

Your windows machine should also be able to resolve the FQDN as @VoIP-Cloud mentioned and this machine will have to be dedicated to the SBC.



You also have the option of using our Debian ISO and installing the SBC on a dedicated machine.

But I CAN resolve the FQDN.

As for using the debian ISO, I tried that. Trouble is, the server in question uses a fakeraid (AKA hostraid) controller and my boss REALLY wants to make use of raid 1 (I'm just a minion here, I do as I'm told). I'm not sure if this is an issue with debian (tried on jessie, buster, and the 3CX iso) or the controller, but I was only able to get the drives recognized by the installer when set in legacy/IDE mode in bios...

Before anyone asks, yes, I tried setting dmraid=true. as far as I can tell the module loads (lsmod shows it loaded), but the drives are still not visible, even when set to AHCI mode with the array destroyed. so like I said, probably just a compatibility issue. I'd do softraid but the server only has two drive bays and putting /boot on a thumbdrive just felt silly. So here we are!

 

[JohnS_3CX]

If this is a decommissioned server, best re-install the the OS from scratch.

You can also go the VM route and install on Hyper-V for example where the 3CX ISO can deploy, skipping any need for RAID controller compatibility.

https://www.3cx.com/docs/installing-microsoft-hyper-v/

 

[narrington]

This can be a common occurrence with the SBC on Windows. I have seen it several times on sites where the client leaves the box on DHCP and acquire DNS dynamically.

First tip - set your NIC card IP address and subnet statically as well as your DNS servers - which need to be static as well as reliable.

If the DNS does not resolve on the SBC machine the tunnel will not connect.

Tried this, did not work...

If this is a decommissioned server, best re-install the the OS from scratch.

You can also go the VM route and install on Hyper-V for example where the 3CX ISO can deploy, skipping any need for RAID controller compatibility.

https://www.3cx.com/docs/installing-microsoft-hyper-v/

I'm thinking this is my best bet all round.

The thing is, the SBC is really only a test. the site in question has a VPN to the admin site where the pbx is located. The only reason the phone (yes, all this for just ONE blinking phone) doesn't register with the PBX directly is because for some reason the router at this site wont allow the VPN tunnel for the Network Infrastructure and SIP vlans to link up. All other vlan tunnels open just fine. Ultimately, when we resolve THAT issue, this SBC will become completely unnecessary anyway.

 

[Lee Cramman]

Got a spare RPi?

 

[narrington]

Got a spare RPi?

No. We're using them all for retro-gaming. a very important task, I might add.

 

[Lee Cramman]

No. We're using them all for retro-gaming. a very important task, I might add.

Ha ha. TBH a Windows Server machine is massive overkill for an SBC handling 1 phone. Something like an RPi, an old linux box or even a small VM would do.

 

[narrington]

Ha ha. TBH a Windows Server machine is massive overkill for an SBC handling 1 phone. Something like an RPi, an old linux box or even a small VM would do.

I agree, hence the use of an old, decommissioned domain controller. even if this gets resolved, that SBC is likely going to go away. Either it'll get virtualized once I get HyperV up and running over here, or we'll sort out the VPN and it'll be unnecessary.

Besides, the one phone it handles isn;t always going to be the only phone, there are half a dozen phones hooked up to an aging NEC SV8100. they all gotta go at some point so they'll be replaced with IP phones eventually... but that's miles down the road from where we're at.

 

[Lee Cramman]

I agree, hence the use of an old, decommissioned domain controller. even if this gets resolved, that SBC is likely going to go away. Either it'll get virtualized once I get HyperV up and running over here, or we'll sort out the VPN and it'll be unnecessary.

Yep - I was just thinking about the effort of troubleshooting or blowing away the Windows Server install and starting again versus 10 minutes with the 3CX debian ISO. Even if you use the same hardware, the 3CX ISO makes it really fast to deploy an SBC.

edit: Although I just remembered that Windows Server installs DNS server by default if you make the machine a DC. Might be worth uninstalling this feature in case it's interfering.