IP Office - ASBCE - Remote Worker IX Workplace and Certificates

[FinkDix]

Hi all,

First post here. Finally signed up and hopefully I can provide some assistance here as well. It's a great community that has helped me many times in the past.

Anyway, I have a general query around IPO, ASBCE and remote workers please.

In terms of certificates, the Avaya documentation is clear as mud. I've also raised a ticket with Avaya for certificate clarity and they haven't really offered much by way of clarity. They actually directed me to an Aura document on the subject. So I have 2 SBC's, not configured as HA. 2 IP office systems also. Our "primary" SBC is configured for IP Office failover. e.g. B1 address routes through to primary IPO, and B2 to secondary. We will then use the secondary SBC if/when the primary SBC goes down, and this also has 2 routes configured in the same way for IP office failover. So if SBC A goes down, we need to try and weigh the public DNS so that our FQDNs uses the secondary SBC B1 and B2 address respectively for IPO1 and IPO2.

I'm trying to figure out what certificates I need to use here. I have the A side working with IP Office root installed on SBC and client. SBC ID cert on SBC, and IP Office ID cert on IPO. Is the only cert needed on the client the IPO root? It seems to be as I'm registering with presence perfectly fine. If I register to the secondary - while not failed over - I do not get presence. This may be an internal DNS thing, but I fear my certs are messed up.

On the SBC and IPO ID certs should I just put every possible FQDN and IP address in the SAN?
Does anyone know how to setup public DNS to weight the resolution of addresses using DNS Srv and A records?

Apologies for the long winded post. Hope I'm being clear. Thanks in advance.

MrFink.

 

[G van Hamburg]

Perhaps this document helps, at least for the failover part.

https://ipofficekb.avaya.com/busine...ojects/manuals/interop/ipo_asbce.pdf?rnd=5834

Are your SBCE's on VMWare? How many remote workers do you have? If not too much, in that case, to be honest, I’d change the design a bit and let SBCE1 connect to the Primary IPO and SBCE2 to the seconndary.

I will get back to you about the certs.

Freelance Certified Avaya Aura Engineer

 

[derfloh]

To have failover you will need two separate FQDNs. One for each IPO. Each FQDN should point to a different public IP pointing to individual B1 Interfaces of a single SBC, a SBC HA pair or of two different SBCs as GvH sais.

The certificate should have the FQDN you connect to and the SIP domain as URI. You can either create a single certificate containing all the SANs and deploy it for primary and failover connection or you can create a single certificate for each connection.

Regarding the needed SANs have a look into this document, Appendix F:

https://ipofficekb.avaya.com/busine...jects/manuals/mgr/ipo_security_guidelines.pdf

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

 

[FinkDix]

Thanks for the replies folks.
GvanH - there'll likely be up to 200 remote workers here. Indeed I did follow the doc you referenced. So the idea is we have resilience in both SBC and IPO. If IPO Primary fails, secondary route kicks in on SBC A. If SBC primary fails, then secondary SBC B1 is also configured to connect to IPO Primary. Based on your replies, I seem to be on the right track. Seems to me only the root CA is needed on the client.

So I do have 2 separate public FQDN pointing to 2 different public IP's which in turn are pointing to the B1 interfaces of my SBC's. My main concern now is on the public DNS side of things. e.g. how do I configure public DNS records so that if my primary SBC fails, that public DNS has a secondary route it will attempt? I can't seem to find any information on this.

Appreciate the help so far.

 

[G van Hamburg]

You just configure the DNS. In the 200OK of the register message the client recieves the failover IP Office FQDN. There is chapter in the document describing the behaviour of the IX client in combination with IP Office resilience.

And my advice is to buy a UC certificate for the B1. Connecting from outside the wifi for the first time will also load the IPO root-ca so after that you can use it on wifi as well. So the identity certificate on the A1 is created by IPO and the B1 is 3rd party. This will save you the time to install the IP office root-ca on the clients.

Freelance Certified Avaya Aura Engineer

 

[derfloh]

You will need two different DNS records for two different public IPs pointing to two different SBCs.

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

 

[FinkDix]

Thanks for replies again but I fear I may not be explaining myself very well here folks. I actually have 2 fqdn's configured for each IP office - primary and secondary, routing to 4 public IP's. What I want to try achieve is FQDN A for IP office primary resolves either to public IP for SBC A B1 as priority, of if my A SBC does down, FQDN resolved to second public IP to SBC B B1 as a second option. Likewise on the B side. Is this even possible in DNS?

So my primary FQDN can resolve to 2 different public IPs with priority weighting. The A route is the preference, the B is the failover.

So ultimately, I'm just trying to setup priority routing in DNS to resolve 1 FQDN to 2 IP's in a primary, secondary order.

Hope that makes sense!

 

[derfloh]

From my point of view this should be possible

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

 

[G van Hamburg]

When using TLS I am not sure. But if it’s possible, I think you need both FQDN’s in the cert and use topology hiding in the SBCE to change the domain from SBCE to IPO. But I think this is why they designed the HA SBCE.

Freelance Certified Avaya Aura Engineer

 

[FinkDix]

Thanks folks. I'm not sure it's possible having done some further research. I have both FQDN's in cert and have been able to get this working, but not in a primary/secondary fashion. Externally, the FQDN will randomly resolve to one or the other specified addresses. More like load balancing. I don't know what dictates this. It just seems like something that should be possible. It may be the case I need to manually update DNS records in the event of an A side failure. Obviously not ideal.

 

[derfloh]

The two DNS A records must have different priorities or you need a DNS provider that is able to determine if the primary target becomes unavailable and starts to answer with the secondary IP.

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

 

[FinkDix]

Indeed that is the case far as I can see now derfloh. Appreciate your help folks.

Looks like these guys do this kind of thing;

https://dnsmadeeasy.com/services/dnsfailover/