IP Office Server Edition: issue with remote workers connecting via ASBCE

[NS_cpinc]

Hello,

I've been struggling with deploying remote workers in an IP Office Server Edition system.

The system is currently running IP Office Server Edition Release 11.1.1.1.0 (build 18). The Avaya Session Border Controller for Enterprise is running version 8.1.3. The SBC ports are in separate subnets and the B1 interface is mapped directly to WAN IP Addresses, but is still in a DMZ behind a firewall.

Currently the SIP trunks are configured to use the ASBCE and that works just fine, 100%.

However, I cannot get the remote workers to register with the IP Office system. I've followed the application notes (as well as many of the tips in this forum regarding things not covered in the notes), and when I run the tracesbc program from the CLI of the ASBCE, I see the TLS communications and handshakes, but never any actual SIP traffic. The devices themselves say "VOIP service unavailable" and fail to make a call using SIP. We are using a third party SSL certificate, and the certificate is installed in both the IP Office and the ASBCE, and appears valid when you check with OpenSSL and the MMC snap-in console and the web browser security tools.

I've tried copying and editing the default 46xxsettings.txt file but neither the default or any of the changes I've made have been successful in making this work.

Would anyone be able to share a configuration profile (even sanitized) with settings that will work? I suspect that there's something wrong with either my configuration profile or the application relay/reverse proxy settings on my ASBCE. I've reached out to my business partners AND avaya and they have been able to provide any insights into what might be the problem OR a working configuration profile for reference. If I could see a working configuration profile I could at least compare it to my own.

Thanks in advance for any advice!

 

[G van Hamburg]

Ok, there are a thousand things that could be happening.

The certificate: Does it contain the sip registrar and sip domain you used in IPO? And why did you not use the IPO Server to create the identity certificate for the SBCE A1 and IPO itself. Or did you use the same certificate on all servers/interfaces, which is a security breach.

Next, never change the 46xxsettings and leave it autogenerated, otherwise the no-user settings won’t work.
Is Split DNS set up correctly? Otherwise it might work internally but not externally, or the other way around.
Can you provision the client through the SBCE (do you see https traffic) or does that also fail?

I don’t have a document but I know everything about the setup. I can help you configure your sbce depending on where you are located. No cure no pay.

Freelance Certified Avaya Aura Engineer

 

[derfloh]

For me it looks like if it were a problem to do the HTTP connections needed.

Perhaps you use preferred phone ports in IPO, load the settings through port 411 and don't allow port 443 that is needed for the MTCTI communication.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[NS_cpinc]

Regarding the certificate:

It is a Multi-SAN certificate that has both the SIP Registrar FQDN and SIP domain (in this case, cloud.company.com and company.com as well as SIP:cloud.company.com and SIP:company.com, since the limit was 5). This certificate is only for the IP Office Server, and is installed in the certificate repository of the SBC. In addition, I used openssl to create a bundle out of the certificates from godaddy, including the root and intermediate certificates, called IXcerts.pem. I did not remove the "WebRootCA.pem" value from the "SET TRUSTCERTS" values, just added "IXcerts.pem" to it, and added it to the reverse proxy settings in the SBC.

Next:
I did not change the 46xx settings, just stated that it did not work when I tried to use it as the configuration profile. I created a new profile based on those settings called IXsettings.txt and specify so under "use a web address".

As far as Split DNS, I assume you mean how internally the cloud.company.com resolves to the IP address of the IP Office Server Edition, and outside it refers to the Static IP addresses assigned to the B1 interfaces' DMZ addresses? I've confirmed the IP address assignments are correct both outside and inside the network using nslookup on a windows terminal.

I do see traffic through the SBC, and can confirm that the settings values and certificate files do make it to the Apple iOS devices. Also, when I do a tracesbc in the SBC itself, I see the TLS communications (but no errors). However I do not see any SIP traffic at all. This is why I suspect that there's something I've misconfigured in the configuration file or the SBC itself.

I would be amenable to your assistance in this matter, and will send you a message.


Regarding the second message:

Which HTTP ports are needed? In the original file it specifies using 8411 for HTTPPORT and 411 for TLSPORT but I changed those to 80 and 443 respectively. Should I change them back and add reverse proxy entries for these other ports?

Do I need to keep port 411 open or is it possible to use port 443?

Thanks very much!

 

[G van Hamburg]

Hi, In my IPO, I unchecked ‘Use Preferred Phone Ports’. That might be a problem to change on a live system but for me I set this up during installation. By doing this, tcp 443 is used for loading the settings to the Client, used for Presence and also for the Apple Push notification. The only other needed port besides that is tcp 9443 for chat.

It is a Multi-SAN certificate that has both the SIP Registrar FQDN and SIP domain (in this case, cloud.company.com and company.com as well as SIP:cloud.company.com and SIP:company.com, since the limit was 5). This certificate is only for the IP Office Server, and is installed in the certificate repository of the SBC

This part I don’t understand. This what you loaded on the SBCE? And also on the IPO? The dns names are correct, but if it is only meant for the B-side of the SBCE the SIP:xxxxxx are not needed.

I would like to see your SBCE, just email me.



Freelance Certified Avaya Aura Engineer

 

[NS_cpinc]

Used Preferred Phone Ports" was selected, but I unchecked it and got the same issues. However I have not restarted the system yet, and will do that tonight to see if it affects a positive change.

The certificate is installed on the IP Office according to the IP Office Server Edition documentation. It is "installed" on the SBC - the certificate was uploaded into the certificate repository along with the CA and the key files. This way when remote users can securely connect using the certificate to the IP Office through the SBC.

Do you have a profile with your contact info on the forum? I can't quite seem to find it.

 

[G van Hamburg]

https://www.linkedin.com/in/gerardvanhamburg

Freelance Certified Avaya Aura Engineer

 

[derfloh]

Probably the WebRootCA.pem is not correct. The autogenerated contains only the intermediate certificate but the client needs to load the CA chain (root and intermediate). So you have to create your own WebRootCA.pem by combining the root and intermediate Certificate.

https://support.vidyocloud.com/hc/e...-Combining-Root-and-Intermediate-Certificates

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN