Solved Can't register a remote DECT Yealink W60B using SBC located inside the office LAN

[ochapple]

Hi everyone,
I hope someone can help, I have looked at many different threads relating to W60B and SBC for registering remote phones and in particular the DECT Yealink W60B, but I've hit a brick wall and the thread info is not consistent with the 3CX documentation on the SBC setup at least Ports wise. What ports need simply to be allowed in, and on which firewall device/entity (LAN, GCP), and what ports specifically need to be forwarded to which device/entity (LAN, SBC, GCP), in order for the SBC to work with a remote PBX in Google Cloud and a remote handset behind a dynamic public IP address?

I have checked the base firmware is on the latest version (77.83.0.20) using the Yealink's site to that which is:- https://www.yealink.com/products_48.html
At the same time I also uploaded the latest firmware for the handset while i was at it, but still no joy "registering" the W60B. (As seen on the Account tab in the phone's Web GUI page.

The SBC (raspberry PI 4) shows a green light in 3CX Management Console SIP Trunk area and appears to have had no issues in the install phase and is UP.

I have a 3CX PBX in Google Cloud (GCP) installed using PBX Express (Debian 9 Stretch)

I can see one potential issue at this point, and although I believe it should be irrelevant given i'm using an SBC, when I run the 3CX firewall checker it gives me this warning/error:-

testing 3CX SIP Server... failed (How to resolve?)
testing port 5060... full cone test failed (How to resolve?)

Now I am fairly certain that this failure is due to the fact I have restricted the Inbound traffic (INGRESS) by IP's into the PBX's GCP Firewall to only ALLOW my Office's LAN's IP address, and the necessary ports that were setup by default before i restricted the IP as reommended to avoid all the port scans and hacking attempts we seemed to get before I did that.

I think, therefore, that this "failure" does not matter, but I would be interested to know if this is a correct assumption as it also potentially points to a problem of some kind that could affect the W60 from being unable to register even though the phones in the office work fine.

The PBX Express install onto GCP actually makes all IPs allowed for INGRES into the PBX via specific ports including 22,443, 5060, 5090 and 9000-10999 etc. the defaults.

I can successfully provision the W60B phone, as it says "Provision Success!" on the phone if is either configured to use the SBC or not, however it still fails to "register", and this seems to me to perhaps be down to the Proxy Server setting -> currently set to the LAN IP and Port of the SBC, set in the W60B Account tab in the Phone Web Page GUI. (see screenshot)

Presumably, the SBC is port 5060, as it's a default setup.

If I avoid using the SBC for provisioning (so remote/disable the proxy server entry) as long as I have a firewall rule to ALLOW, INGRESS for my Home/remote IP dynamic address, then the W60B works fine in this scenario; but the whole point is I want the phone to work using the SBC with the security that it intrinsically provides, and 3CX, with an SBC in place, as the point of registration, should not care what the remote phone's IP address is, and because remote phones in home setups are generally behind dynamic public IP addresses, not static, this is kind of the whole point of the SBC! So adding the IP address at this point is only a temporary measure to make the phone work for now. So the aim is clearly to remove that entry if i can get the phone to register without it.

The phone provisions happily over 5001 as we allowed this port to forward to the SBC on our CISCO firewall in the office. We did see during the config process that the NAT entries could not be created for a group object, however do we have access to remote CCTV cameras etc fine, and with no specific NAT rules, however the CISCO router ACL (Access control List) has been setup for both our office cameras which work and also the SBC ports 5001 and 5090 allowed in and forwarded to the SBC, in the same way and is presumably why the phone provisions successfully. Is anything missing in our setup here?

What part do ports udp:9000-10999 play in the SBC to PBX and remote phones setup, are they needed as we believe those ports are already being used, at least some of them, and would they prevent the registration?

We tried forwarding ports 5060 as well but that did not work and only then cut off our LAN based handsets from talking to the PBX because they would be then going back through the SBC and not out to the PBX directly. Even with Port 5060 forwarded temporarily to the SBC, the phone would not register and neither did the handset in the office register when i provisioned a handset to use the SBC to see if that made any difference.

So we then removed the port forward for 5060 as we want to use the SIP Server for a door entry device as well so basically we want our LAN phones to provision and work using the LAN provisioning/config method and I want the DECT W60B to use the SBC remote provisioning method.

The DECT W60 B is using the default port 5060.



Does anyone have any ideas where to go next with this as I am lost what we are trying to do with the SBC in terms of incoming ports and what to forward to where?
Outgoing connections from our LAN firewall should just connect and reach the PBX in GCP no problem. The phone provisions successfully over 5001 once we forwarded that port to the SBC. So what am I missing? Surely the outgoing connections and ports like 5090 should just work.

I would be most grateful for your help as I have no way to diagnose where it's going wrong and have spent hours on this problem. I can't tell if the issue of registering is happening at the LAN side or the PBX side, and there seems to be no definitive document from 3CX to say what ports where must be open for the SBC on a LAN behind a firewall to work with remote phones.

Kind Regards,
Oliver

 

[cobaltit]

Holy novel batman!

So the admin guide has pretty clear documentation as to what ports need to be forwarded where, and here's a hint. The PBXExpress does everything for you.

https://www.3cx.com/docs/manual/firewall-router-configuration/

I wouldn't restrict any ports on GCP until AFTER you have things working.

You don't need any port forwarding on the SBC side of things.

Be sure you are following this document regarding the W60B and you are following the steps for the SBC:

https://www.3cx.com/sip-phones/yealink-dect-w52p/

It's also unclear if you are talking about the base stations registering to the PBX or the handsets registering to the base station as far as what is failing.

 

[JohnS_3CX]

Hi Oliver,

The main scenario where you can get into trouble is when you block/manipulate outbound traffic at the phones site.

The gist of it is that if you don't block outgoing connections at the phones site, no forwards are needed at all. Literally none.

All the above work could have likely been skipped, by simply running a capture on the DECT device's interface and very quickly find out why registration fails (since that is the actual thing you need to troubleshoot).

- You should see the device IP sending a registration request to the SBC IP
- You should see the SBC IP replying to the SBC IP with an answer

 

[ochapple]

Thanks both for your replies,

every port is blocked on our LAN firewall except those specified for a device that needs to accept incoming connections on a specific port, so port forwarding is therefore required. This is because we use NAT. No corporate firewall should leave all the ports open.

You cant just 'open a port' as per your documentation, as it will not go to the device you need.

We don't block any outgoing ports on our LAN,

So until we forwarded the incoming port 5001 on our LAN to the SBC, the W60B phone could not auto-provision and that seems perfectly logical given the above.

This is why the documentation isn't clear. You do have to port forward if you have multiple devices where inbound ports are blocked by default.

The doc you reference: https://www.3cx.com/docs/manual/firewall-router-configuration/
doesn't show what ports need to be forwarded to the SBC and this IS required QED. So that's why i still need to see a document for this information. It's simply not clear to me or my Head of IT, on the 3CX site yet.

I was advised by 3CX support to secure the IP of the LAN in GCP's firewall because of all the port scans and warnings I was getting, due to hackers attempting to spoof the phones. Once I restricted access to the PBX down to just our LAN, this all stopped. This is why I was advised to use an SBC so we could maintain this security and not have all IP's being able to access the PBX, which is indeed the PBX Express default.
So where to now?
I did already attach a screenshot of the W60B Account settings, and it is the phone that is unable to register with the 3CX, when my home IP is not added to the firewall on GCP, not that the base or handset cannot register, the handset and phone work fine. The only way the phone "registers" in the Account tab of the phone GUI, as I said, is if I add my home's IP address to GCP's firewall rules, unless I expose our PBX to the whole internet (any IP). Which I perhaps incorrectly thought, as I believed I was told by 3CX was why I should install a Raspberry PI SBC and why I have.

So what are the must-haves, whys and wherefores, for the SBC to work with the 3CX PBX in GCP? is it that any IP address has to be able to reach the PBX (see screenshot of this being currently restricted to our office LAN IP)? If so surely the SBC becomes partly redundant? what benefit would the SBC now give me if I opened up any IP to being able to talk to the PBX allowing port scanning and hacking attempts? the W60B works without an SBC if any IP is set on the firewall and could be auto-provisioned without it. So I'm confused!

What do you specifically mean about Capture of the DECT device's interface? Screenshot, Wireshark the attempt to register? I can do that possibly.

 

[cobaltit]

Thanks both for your replies,

every port is blocked on our LAN firewall except those specified for a device that needs to accept incoming connections on a specific port, so port forwarding is therefore required. This is because we use NAT. No corporate firewall should leave all the ports open.

You cant just 'open a port' as per your documentation, as it will not go to the device you need.

We don't block any outgoing ports on our LAN,

So until we forwarded the incoming port 5001 on our LAN to the SBC, the W60B phone could not auto-provision and that seems perfectly logical given the above.

This is why the documentation isn't clear. You do have to port forward if you have multiple devices where inbound ports are blocked by default.

Ok either your network is more complex then you describe, or you (and your head of IT) are really not understanding how 3CX is architected.. The standard for most firewalls is to deny all new inbound traffic, allow all outbound traffic, and to allow any inbound traffic in response to outbound traffic. Since all the phone and SBC traffic is outbound or inbound in response to outbound traffic you do NOT need any port forwarding, assuming your previous statements are correct. The SBC and the phone should be on the same LAN, thus the firewall should not be seeing any traffic between them, and thus no port forward. And the SBC has nothing listening on port 5001 since that is the web administration port for 3CX which is in GCP according to you. If you do not have a simple network then you need to describe or provide a network diagram. By simple I mean this:

Internet <-----> Cisco Firewall <------> Local LAN

Put the firewall in GCP back to what it was out of the box. Then establish a working configuration, and then you can start locking it down if you feel you need to do so.

 

[ochapple]

Thanks Cobaltit,
Yes we don't understand what architecture is required for the SBC. It's not clear to us whether the SBC should be in front of or behind the firewall. Our SBC is on the Phone LAN, our phones all have dynamic IP's between 192.168.200.1-100 and the SBC is on a static 192.168.200.101.
We have

Internet (BT.NET fibre) - > Cisco Firewall -> VLAN Phones & SBC
-> VLAN PC's

Should the SBC be on the VLAN for PC's instead and have a static IP address there?

It seems by having the SBC we have simply just shifted the network admin from GCP to the Office Cisco router, which is more complex and more problematic and expensive to troubleshoot.

I think we would do better to find a way to put the SBC in the cloud, it's all getting too messy in the office and I think personally all this should be in the cloud.

Can you tell me if the ports in the PBX GCP Firewall all have to be open for remote handsets if the SBC is in the office? yes/no

If so then surely we need the SBC to reside in the Cloud to shield our LAN and PBX from hackers, and the raspberry PI now redundant.

Presumably, by switching the VM to cloud instead of Raspberry PI i can just fire up a new VM in GCP and install the SBC on that and open the ports between the two VM's??!!

 

[cobaltit]

I don't understand why you think having the SBC behind your firewall some how makes you vulnerable? You don't open any ports in your firewall for the SBC (or for the phones) so it's not changing the security posture of your firewall. Stop trying to over think things. You have a Cisco firewall for a reason right? Let it do it's job.

So assuming you aren't blocking any outbound traffic on the Cisco firewall, you should see the SBC registered as a trunk on your PBX. If that is registered properly. Once that's done you want to follow this guide for provisioning the base via SBC:

https://www.3cx.com/sip-phones/yealink-dect-w52p/

I think you are missing this step in the guide for actually putting the URL into the base station and you're going straight to the part about registering a handset to the base station:

https://www.3cx.com/sip-phones/manually-provision-yealink-dect/

The base station is what is provisioned by 3CX and registers via SIP to 3CX. The handset registers or pairs to the base station via DECT. Then you associate a handset with a line which is one of the SIP accounts provisioned on the base station:

https://www.3cx.com/sip-phones/register-yealink-handsets/

 

[ochapple]

I followed through the instructions above. The Base reset Ok, and once the base reset the handset automatically said de-register the handset? on the screen, so i pressed yes. The set of instructions thereafter to deregister the handset therefore could not be followed to de-register the handset as described as it had already de-registered itself and said so. It couldn't therefore do the handset reset.

So I then added the provisioning URL for Local LAN (in the office), not SBC remote, which i had used before, seeing that makes more logical sense given we now have the SBC, as the provisioning method. Having confirmed and pressed the auto-provision button, the Web Gui says Operation Completed, but the handset then said Unregistered.
The phone handset said Reg on the menu screen, so i pressed ok and it then says register failed.
So i used a logical workaround: I then managed to reset the handset in settings which failed before and then pressed the connect button on the base and managed re-register the handset from settings it then paired ok.

So now what should I do? I re-ran the auto-provision which failed. I then checked the registration status in Account in the WebGui and it says Register status: ' disabled'.
The SBC is up see attached screenshot.
Don't forget that the only IPs able to access the PBX is the office LAN but given we are provisioning via the office this should be ok right?

 

[ochapple]

From what I read elsewhere you are supposed to import the cfg file into the W60B WebGui then run Auto-provision. also for SBC this document says use the SBC remote provisioning method. https://www.3cx.com/sip-phones/yealink-dect-w52p/

 

[JohnS_3CX]

I followed through the instructions above. The Base reset Ok, and once the base reset the handset automatically said de-register the handset? on the screen, so i pressed yes. The set of instructions thereafter to deregister the handset therefore could not be followed to de-register the handset as described as it had already de-registered itself and said so. It couldn't therefore do the handset reset.

Oliver I have to note that you jumped from handset registration (a DECT matter) to base registration (a SIP matter). These should be kept entirely separate because your goal is to now deal with SIP registration first.

So I then added the provisioning URL for Local LAN (in the office), not SBC remote, which i had used before, seeing that makes more logical sense given we now have the SBC, as the provisioning method.

Using LAN provisioning on a device that is clearly not on the same LAN as the PBX will simply not work nor does it make logical sense to tell the device to look for the local IP of a PBX that is not inside your office network.

I think you should start from scratch and take it one step at a time if you want to do it yourself, and I'm confident that you can but:

1.) You need to begin with a PBX that has been deployed properly (meaning the firewall rule entry is removed manually, and recreated by PBX Express automatically) -> This is one variable eliminated

2.) You then make sure you remove any port forwards from your office firewall that have anything to do with the SBC and the phones -> This is another variable eliminated

3.) Finally you need to create a DECT device entry in 3CX, set it to SBC, fill in the blanks just like the guide describes, and paste the correct URL into the freshly reset base. -> Final goal

Only once the above is done should you then pair the handsets with the base, not before. And I can promise you that it will begin to work like a charm (having set one up myself yesterday behind a corporate firewall and on an SBC on the same network as the W60B base).

I think @cobaltit was correct in saying you are overthinking it and in your honest attempt to get it to work you appear to be introducing variables instead of eliminating them, so how about we start from scratch with a clean slate?

And if this is giving you too much pain or its taking up too much of your valuable time from your business, you can always hire a partner to sort everything out for you which will be money well spent.

 

[ochapple]

Got all that, and all of it makes sense.

Note that the first step in the instructions above was indeed to start from scratch which included the first instruction -> reset the W60B base. There was no confusion here. I've never had a base to handset registration problem before, i was simply 'starting from scratch'.

The one step that is still not clear to me is the one thing 3CX advised me to do, all due to all the port scan attempted hack warnings i was getting from 3CX PBX, and that advice was to change the 'any IP' Ingress firewall rule to just the office IP allowed in. As a result of that change the Port scan email warnings stopped immediately, and I could sleep at night.

So if I unwind that rule and go back to the default PBX Express rule. Will the port scan warning emails start happening again, as i assume they will?? This as i have said in my previous posts in this thread is the specific goal that i have always been attempting to achieve and preserve by implementing the SBC so that we can now have remote handsets?

Lastly should all the phones, even the handets in the office, be provisioned via the SBC?

I'm going to have to now wait for a window of a couple of weeks before my head of IT can return to the office to remove the 2 port forwards to the SBC (5000-5001 and 5090) as doing it remotely last time shut down the VPN.

 

[JohnS_3CX]

Yes the emails may start again, but since we are in troubleshooting mode (temporarily) this should not be an issue.

Yes, all the deskphones, and DECT phone bases need to be on the SBC.

Since the port forwards are in place now, I expect it will not be possible to provision your base. You can however take it somewhere outside of your network, paste the link and let it provision, and then return it to the office where it can attempt to register via your SBC.

Ensure that in the management console > DECT > W60 you have set it to SBC and entered the correct LAN ip of your SBC before copying the link across. This will generate the correct config for you.


Once all is said and done, you should be able to see the W60 registered in the management console (even though the portable handsets have not been paired yet).

 

[ochapple]

I've now ensured we've removed all port forwarding for 5001, 5060 and 5090 on our LAN Cisco router, and we are not blocking any outbound ports from our CISCO on the LAN. I have I believe sufficiently enabled the PBXPorts rule in GCP's Firewall by applying the IP range to the PBXports (PBX Express's) rule for the range 0.0.0.0/0. That should mean no public IP restrictions IN to the PBX I believe.

The W60B is all setup in 3CX to use SBC remote and then was auto provisioned.

I have brought the W60B phone into the office and reset the base and taken the steps above to add the Provisioning URL and provision to do the auto provisioning.

The phone will NOT register -> shown in the Account tab of the Phone's Yeaklink Web GUI. The Outbound Proxy server setting in the W60B firmware I can see is all set to the SBC's LAN IP and using port 5060, and its enabled. But still no dice.

I have also used the settings on the handset to Auto Provision the handset and it says 'provision successful', so there is no port blocking that. But it simply won't register to or VIA the SBC on the LAN.

What am I missing here? Can you please confirm the Ingress ports necessary to be open on GCP to allow the IP range 0.0.0.0/0 to use. Should there be a port entry for the port TCP 5001? I don't believe so.

I think it's time I looked into a remote SBC instead like NATPASS given there is clearly something missing in the setup documentation that is required for a pretty secure LAN setup that is using a CISCO router.

 

[JohnS_3CX]

Now is the time to run a capture of the device. We can see whether it attempts to register, and what reply it gets back

The capture can be run on the SBC machine, or you can mirror one of your ethernet ports

 

[ochapple]

Ok so I have found i should run this on the Raspberry PI to get the log file...

SBC Logging
Open Terminal Window
1) sudo nano /etc/3cxsbc.conf
2) Change Level = NONE to DEBUG (actually this was by default set to ERR not NONE)
3) Save and Exit
4) Stop the 3cxsbc service (service 3cxsbc stop)
5) Stop the rsyslog service (service rsyslog stop)
6) Delete file ls -l /var/log/ (sudo rm /var/log/3cxsbc.log)
7) Recreate /var/log/3cxsbc.log (touch /var/log/3cxsbc.log)
8) Start the rsyslog service (service rsyslog start)
9) Start the 3cxsbc service (service 3cxsbc start
Use the file manager to browse to /var/log/3cxsbc.log and open with text editor or Libre etc.
Remember to change 3cxsbc.conf back to NONE

NB * the log file is not in the directorty above its in the /var/log/3cxsbc directory not /var/log.
i discovered this by using cd /var and cd log and then ls to show the directory contents and then one more cd /3cxsbc

Now these are the errors (using Level = ERR) i can see in the log file,but I don't know what to do about them, perhaps you can help? (see attachment)


it seems to be pointing to a missing directory relating to certificates.
presumably some certificate is not downloading

 

[ochapple]

I have a 3CX capture where I restart the SBC service on the PI using service 3cxsbc start, then I go on seconds later to run the auto-provision of the W60B under SBC remote using TCP not TLS given the certificates error in the SBC log. Still the W60B will not register, the file contains sensitive data in it so i don't think it should be attached here.

 

[JohnS_3CX]

Hi Oliver,

Please upload the capture file somewhere and send me a private message with a link to download it.

I can check to see if I can help

 

[ochapple]

Hi John,
Sorry to sound thick how do i send you a private message?

 

[JohnS_3CX]

As per our PM, once an SBC is set up at the site where the W60B now resides you should be up and running.