TLS failover behaviour and a backtrace if want it.

[FRANKS, Andy (SHREWSBURY AND TELFORD HOSPITAL NHS TRUST)]

Hi Alan,
  You're right of course, apologies I overlooked that.

Running 3.0.19, pulled this morning from the networkradius repo but I'll try again later today.

Thanks
Andy



-----Original Message-----
From: Alan DeKok <aland at deployingradius.com>
Sent: 18 November 2019 13:54
To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
Cc: FRANKS, Andy (SHREWSBURY AND TELFORD HOSPITAL NHS TRUST) <andy.franks1 at nhs.net>
Subject: Re: TLS failover behaviour and a backtrace if want it.

On Nov 18, 2019, at 8:44 AM, FRANKS, Andy (SHREWSBURY AND TELFORD HOSPITAL NHS TRUST) via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> Firstly, I must admit I expected failover to be "within same request", but it takes a repeat request from the client should a tls server be unavailable. I guess this is just me misunderstanding the failover for tls, I assumed same as something like a redundant {} section.

  This is documented.  Read proxy.conf:

#
#  In 2.0, the server is always "synchronous", and setting
#  "synchronous = no" is impossible.  This simplifies the
#  server and increases the stability of the network.
#  However, it means that the server (i.e. proxy) NEVER
#  originates packets.  It proxies packets ONLY when it receives
#  a packet or a re-transmission from the NAS.  If the NAS never
#  re-transmits, the proxy never re-transmits, either.  This can
#  affect fail-over, where a packet does *not* fail over to a
#  second home server.. because the NAS never retransmits the
#  packet.

> If the server isn't listening on 2083, i.e. service stopped:
>
> ..
> (1) Starting proxy to home server 192.168.110.46 port 2083
> (1) server default {
> (1) }
> Failed opening new proxy socket 'proxy (0.0.0.0, 0) -> home_server
> (192.168.110.46, 2083)' : Failed connecting socket: Connection refused
> (1) Failed to insert request into the proxy list
> (1) There was no response configured: rejecting request ..
>
> If the client repeats the request, it tries the next server ok, but I'd be a little concerned some might not after a direct reject reply.

  You can configure the proxy to do something else if the home server is down.  Again, read proxy.conf.  This is all documented.  It tells you how to do failover between multiple home servers.  It tells you how to have a "fallback" if the home servers are down.

> Could someone please confirm this is by design?

  It's not only by design, it's extensively documented.  if you're editing proxy.conf, it helps to read the comments located there.

  The idea is that *you* can control what happens when a home server is down.  The only caveat is that you actually have to tell the server what to do.

> Also, I'm noticing a crash if the home server pool is depleted to zero, i.e. all servers are down. It's unlikely to happen, but you may be interested in coding these out.

  If you're not running 3.0.20, upgrade.  Packages are available at http://packages.networkradius.com

  If you're running a very old version of the server, then this crash has likely already been fixed.

  Alan DeKok.



********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in relation to its contents. To do so is strictly prohibited and may be unlawful. Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland. NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and other accredited email services.

For more information and to find out how you can switch, https://portal.nhs.net/help/joiningnhsmail