How to configure HA with certificates

[gabecz]

hi

we'd like to configure HA with 2 servers duo1 and duo2, however if we for example try to have a www application, our dns server of course won't let us create 2 CNAMEs also if we'd want to create let's encrypt certificates with the same name on both servers the new request overwrites the old so we need to create 2 relays rdprelay1 on duo1 and rdprelay2 on duo2 (which is fine) the problem starts when it's about www or custom apps with the same external urls for obvious reasons.

the question is if how to do this, and if we're missing some through documentation on this, if so please send the link and we do the reading.

thanks

[DuoKristina]

If this is a HA scenario wouldn't you be using the same external URLs and the same certificates?

[gabecz]

yes we should. however as of dng server XYZvpn1.website.com requires a cname for externalurl.website.com to be pointed to dng server XZYvpn1.website.com for the external website where as dng server XYZvpn2.webiste.com needs a cname for externalurl.website.com to be pointed to dng server XYZvpn2.website.com and as of dns design, there can't be a cname for externalurl.website.com pointing at 2 different real sites (xyzvpn1 and xyzvpn2) i hope i explained it semi-well. here are three very secrecy screenshots that may give a better view.

[DuoKristina]

Our recommendation for active/passive HA is to put a load-balancer in front of identically configured DNGs (where your DNS records would point to the load-balancer VIP).

https://duo.com/docs/dng#active-/-passive

[gabecz]

i'd like to understand correctly.

our dns settings should look something like this right? (let's say 10.x.y.z is public ip for the sake of this conversation)

dng.ourdomain.com (A name) 10.0.0.3 (load balancer VIP)
dng1.ourdomain.com (A name) 10.0.0.1 (physical server 1)
dng2.ourdomain.com (A name) 10.0.0.2 (physical server 2)
rdprelay.ourdomain.com (CNAME) dng.ourdomain.com
rdp.ourdomain.com (NS) under properties: dng.ourdomain.com

our load balancer is set up to reverse proxy (is that correct?) and has the dng1 and dng2 in as physical servers in the group.

then on dng1 and dng2 we need to set up the same things. under applications / rdp we use rdprelay.ourdomain.com and add our desktops with .ourdomain.local at the end and under subdomains we add rdp.ourdomain.com as external and ourdomain.local as internal.

is this correct?

[DuoKristina]

Yes, I think that is right. Th actual DNGs would have unique hostnames but the application hostnames would be cloned between the two and the external DNS points to the LB VIP. There should be session persistence to the DNG nodes.

[gabecz]

i had a bad concept of "identically set up" now it all looks good. Yet when I open a session say \\thisfileserver.duo.ourserver.com\home\gabe edge pops up (still random relays not always the proper one but that's for later) then i enter my ad credentials, get the prompt on my phone and after that i get a blank page saying 401 Authorization Required (Duo/1.0) while having xyz.10 and xzy.11 servers set up by importing xyz.10 to xyz.11, added to the load balancer as reverse proxy (?), and having duo.ourserver.com set up in our dns server. ANAME and CNAMEs plus NS using duo.ourserver.com and adding xyz.10 and xyz.11 ip addresses. which seems to be working, but i get the 401 for some reason.

any clue? thank you so much for the help so far it was really great.

[gabecz]

looks like that error went away when i set up the load balancer apparently correctly but there's some issue still.

it's with the randomly chosen relays. when it picks the correct relay (filerelay.ourserver.com when opening a samba share, and rdprelay.ourserver.com when a rdp session), then it works fine. when it mixes them up, the connection fails.

i have a support ticket open for this, and another topic open also where you have answered that it is not an expected behaviour.

i can't seem to find the reason myself but will dig the logs to see if i can find why this is happening.

[gabecz]

another update here, i have created a virtual service application on our load balancer for port tcp/80, tcp/443, AND udp/53 (dns). which after i got "duoconnect can't verify the certificate" makes sense, because the load balancer only used its uploaded certificate which was created only for duo.ourserver.com now i recreated a certificate with filerelay.ourserver.com, rdprelay.ourserver.com, duo.ourserver.com, and 2 more web applications we use. and it seems to be working, so far the relays are chosen correctly but that i'll have to test for hours to see if it's accidental or it actually works now fine.

is THIS expected when behind a load balancer? (we use radware alteon 5208)

[DuoKristina]

Hmm... what does "THIS" refer to in your last post?

It is totally expected that you'd need to issue certs with friendly names or SANs that match the external hostnames for your relays.

For whether the relays get chosen correctly behind the load balancer - I am not a LB expert by any means but it should pick the right one based on the port you used for that specific relay, and if they're getting mixed up it might be something weird with the LB config? I am not familiar with radware but it probably has both port mapping/definition and some concept of defining persistence?

[gabecz]

that we need our own certificate fed to the dng instances and the load balancer instead of let's encrypt certificates.

we're now waiting for the duo engineers to check our logs, and we have a meeting with alteon tomorrow on the load balancer config. i'm not sure if that's got anything to do with it but does duo "dns" not need both tcp and udp to work properly? on the LB we only can configure either or. we for sure have set up client ip persistency meaning the session sticks to the chosen real server based on client ip. let's give this a rest until the two teams above investigating.