July 2014 - Freeradius-Users - lists.freeradius.org

Re: Re: Some inconsistencies concerning OpenSSL include configuration in FRS 3
by rieke＠isl.de 28 Jul '14

28 Jul '14

Alan DeKok wrote: > Dr. Andreas Rieke wrote: >> I am quite sure that FRS compiles without problems on many other systems, but in those cases, the compiler takes the OpenSSL header files from the system and not from the specified directories - on my machine, I have removed the openssl-devel RPM package (CentOS), and thus, I get that failure. However, maybe the failure is better than a wrong header file... >> >> When I pass 'CPPFLAGS="-I /opt/openssl/include"' to the main configure script, the problems are solved for the headers - as an example, ec.h is found immediately. However, FRS still uses the system libraries :-( > > The issue is that the CPPFLAGS are *supposed* to be passed from the > main configure script to the lower-level ones. They do - today I have also tested that for the LDFLAGS, and this works, too. If you pass the OpenSSL directories twice to the main configure script, everything works great: > ./configure --prefix=/opt/freeradius-server \ > --with-openssl-include-dir=/opt/openssl/include \ > --with-openssl-lib-dir=/opt/openssl/lib \ > CPPFLAGS="-I /opt/openssl/include" \ > LDFLAGS="-L/opt/openssl/lib" I checked the config.log files and the shared objects with ldd - all headers are found and the correct library files are used. For that reason, everything is great for me - thank you very much for your help, best regards, Andreas

3 2

control-socket bug in the last one v3.x updates?
by Rui Ribeiro 28 Jul '14

28 Jul '14

Hi, I am using the git versions of 3.x, and I *think* that maybe for a month, there has been a bug that prevents freeradius to boot it in Debian 7 if control-socket is configured. I have tried this with a copy of my configuration, and with a pristine copy of freeradius, which only got inserted the link to activate control socket into sites-enabled. Without control-socket all is well: without control socket: root@x:/etc/freeradius/sites-enabled# /etc/init.d/freeradius start [ ok ] Starting FreeRADIUS daemon: freeradius. root@x:/etc/freeradius/sites-enabled# The errors are: root@x:/home/rui# /etc/init.d/freeradius start [FAIL] Starting FreeRADIUS daemon: freeradius failed! root@x:/home/rui# /etc/init.d/freeradius restart [....] Checking FreeRADIUS daemon configuration...Trace/breakpoint trap failed (Debugger detected, raising SIGTRAP). #freeradius -X .... .... radiusd: #### Opening IP addresses and Ports #### listen { type = "control" listen { socket = "/var/run/freeradius/freeradius.sock" } /etc/freeradius/sites-enabled/control-socket[23]: No such server "(null)" Debugger detected, raising SIGTRAP Trace/breakpoint trap In /var/log/freeradius/radius.log, I only have: Mon Jul 28 12:13:35 2014 : Error: /etc/freeradius/sites-enabled/control-socket[23]: No such server "(null)" Regards, Rui Ribeiro ISCTE-IUL sysadmin

2 1

Re: Re: Some inconsistencies concerning OpenSSL include configuration in FRS 3
by rieke＠isl.de 27 Jul '14

27 Jul '14

Alan DeKok wrote: > Dr. Andreas Rieke wrote: >> On 26 Jul 2014, at 20:56, Arran Cudbard-Bell wrote: >> 1. The current v3.0.x source does not compile because of a problem in pcap.c. >> There is no pcap installed on my machine, and configure has detected that correctly. >> However, there are two functions at the end of pcap.c which are not included >> in the "#ifdef HAVE_LIBPCAP" and for that reason, the compiler creates errors. >> If you simply put everything in pcap.c between the "#ifdef HAVE_LIBPCAP" and >> "#endif", everything works well on my machine. > > I've pushed a fix. Thanks - I have tested it, it works great. >> 2. The configuration for types/rlm_eap_pwd does not yet work: >>> checking for openssl/ec.h... no >>> checking for openssl/ec.h in /usr/local/include/... no >>> checking for openssl/ec.h in /opt/include/... no >>> checking for OpenSSL support... yes >>> checking for EVP_sha256 in -lc -lcrypto -lssl... no >>> configure: WARNING: EVP_sha256 not found, may have issues wirh WiMAX certificates >>> checking for EC_GROUP_free... no >>> configure: WARNING: silently not building rlm_eap_pwd. >>> configure: WARNING: FAILURE: rlm_eap_pwd requires: EC_GROUP_free. >> I am sure that ec.h is in the directory where it should be. > > Is it in the directories which are printed out above? > > What does the "config.log" file say? i.e. > src/modules/rlm_eap/types/rlm_eap_pwd/config.log It should be filled > with logs from all of the attempts to compile the source. > >> 3. The configuration of src/modules/rlm_unbound does not yet work: >>> checking for openssl/crypto.h... no >>> checking for openssl/crypto.h in /usr/local/include/... no >>> checking for openssl/crypto.h in /opt/include/... no >>> configure: WARNING: silently not building rlm_unbound. >>> configure: WARNING: FAILURE: rlm_unbound requires: libunbound unbound.h openssl/crypto.h. >> Again, I am sure that openssl/crypto.h is in place and readable by the compiler. > > The same comments apply as above. > >> 4. This issue is about src/modules/rlm_wimax: >>> checking openssl/hmac.h usability... no >>> checking openssl/hmac.h presence... no >>> checking for openssl/hmac.h... no >>> configure: WARNING: silently not building rlm_wimax. >>> configure: WARNING: FAILURE: rlm_wimax requires: openssl/hmac.h. > > The same comments apply here, too. Let us merge the three problems types/rlm_eap_pwd, src/modules/rlm_unbound and src/modules/rlm_wimax: All of the configuration scripts are somehow called by the main configuration script, and the two parameters for the OpenSSL directories are passed to each of the three "sub" configuration scripts. However, in contrast to the main configure script, none of the three knows the parameters for the OpenSSL directories: > [rieke@archer freeradius-server-2014-07-27_21-23]$ grep -i openssl-.*-dir configure src/modules/rlm_eap/types/rlm_eap_pwd/configure src/modules/rlm_unbound/configure src/modules/rlm_wimax/configure > configure: --with-openssl-lib-dir=DIR > configure: --with-openssl-include-dir=DIR > configure:# Check whether --with-openssl-lib-dir was given. > configure:# Check whether --with-openssl-include-dir was given. > configure:as_fn_error $? "failed linking to libssl. Use --with-openssl-lib-dir=<path>, or --with-openssl=no (builds without OpenSSL) > configure:as_fn_error $? "failed linking to libcrypto. Use --with-openssl-lib-dir=<path>, or --with-openssl=no (builds without OpenSSL) > configure:as_fn_error $? "failed locating OpenSSL headers. Use --with-openssl-include-dir=<path>, or --with-openssl=no (builds without OpenSSL) For that reason, the config.log files show that the parameters are passed correctly to the configure "sub" script, but since these parameters are ignored the compiler is not able to find the header files. The following log lines are from rlm_eap_pwd, but the others have the same problem: > configure:2758: checking for openssl/ec.h > configure:2773: gcc -c -g -O2 conftest.c >&5 > conftest.c:10:30: error: openssl/ec.h: No such file or directory ... > configure:2850: checking for openssl/ec.h in /usr/local/include/ > configure:2865: gcc -c -g -O2 -isystem /usr/local/include/ conftest.c >&5 > conftest.c:10:30: error: openssl/ec.h: No such file or directory ... > configure:2850: checking for openssl/ec.h in /opt/include/ > configure:2865: gcc -c -g -O2 -isystem /opt/include/ conftest.c >&5 > conftest.c:10:30: error: openssl/ec.h: No such file or directory I am quite sure that FRS compiles without problems on many other systems, but in those cases, the compiler takes the OpenSSL header files from the system and not from the specified directories - on my machine, I have removed the openssl-devel RPM package (CentOS), and thus, I get that failure. However, maybe the failure is better than a wrong header file... When I pass 'CPPFLAGS="-I /opt/openssl/include"' to the main configure script, the problems are solved for the headers - as an example, ec.h is found immediately. However, FRS still uses the system libraries :-( > checking for openssl/ec.h... yes > checking for OpenSSL support... yes > checking for EVP_sha256 in -lc -lcrypto -lssl... no > configure: WARNING: EVP_sha256 not found, may have issues wirh WiMAX certificates Please let me know if I can do anything to help you solving the issue, Andreas

2 1

Re: EAP-GTC configuration
by Levavi, Yariv 27 Jul '14

27 Jul '14

Hello Alan and thanks for answering. More questions were raised: 1) Is the first entered password being transferred to FreeRadius? What attributes can we use in order to obtain it? In which way is it encoded? 2) May you please send us an example for attribute to check, redirect sentence and where should the check be placed? 3) Can we configure FreeRadius as a client of another Radius (to whom we want to redirect to) and so we can establish a secured channel through? 4) The documents you refer us to are not complete. Are there any other documentation regarding FreeRadius full configuration? Regards, Yariv Levavi SafeNet's Integration Team The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

3 2

Re: Re: Some inconsistencies concerning OpenSSL include configuration in FRS 3
by rieke＠isl.de 27 Jul '14

27 Jul '14

On 26 Jul 2014, at 20:56, Arran Cudbard-Bell wrote: > > On 26 Jul 2014, at 14:13, Dr. Andreas Rieke <rieke(a)isl.de> wrote: > >> On 26 Jul 2014, at 17:31, Arran Cudbard-Bell wrote: >> >>>> However, there is another problem which causes the make process to fail; the problem occurs with rlm_always first: >>>>>>> CC /home/freeradius/freeradius-server-3.0.3/src/modules/rlm_always/rlm_always.c >>>>>>> In file included from /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/radiusd.h:59, >>>>>>> from /home/freeradius/freeradius-server-3.0.3/src/modules/rlm_always/rlm_always.c:27: >>>>>>> /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/tls.h:39:25: error: openssl/err.h: No such file or directory >>>>>>> /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/tls.h:41:30: error: openssl/engine.h: No such file or directory >>>>>>> /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/tls.h:43:25: error: openssl/ssl.h: No such file or directory >>>>> I already tried to use an environment variable CPPFLAGS="-I /opt/openssl/include" for the main configure script, but that did not help. What else can I do to convice FreeRADIUS to use the correct OpenSSL system? >>> You'd set it in Make.inc. >>> >>> With v3.0.x head >>> >>> Works for me with v3.0.x... >>> >>> ./configure --with-openssl-lib-dir=/usr/local/opt/openssl/lib --with-openssl-include-dir=/usr/local/opt/openssl/include >>> ... >>> checking OpenSSL library and header version consistency... library: 1000108f header: 1000108f... yes >>> ... >>> >>> LINK build/lib/libfreeradius-radius.la >>> CC /Users/arr2036/Documents/Repositories/freeradius-server-master/src/tests/rbmonkey.c >>> LINK build/bin/rbmonkey >>> CC /Users/arr2036/Documents/Repositories/freeradius-server-master/src/modules/rlm_always/rlm_always.c >>> LINK build/lib/rlm_always.la >> >> Hi again, >> >> first thanks a lot for your answer. Things work exactly as you said - in 3.0.2, but not in 3.0.3. >> >> The Make.inc file already contains the correct parameters - even without the parameter CPPFLAGS="-I /opt/openssl/include" for the configuration script: >>> CPPFLAGS = -isystem /opt/openssl/include >> If you pass CPPFLAGS="-I /opt/openssl/include" to the configure script, you get the path twice: >>> CPPFLAGS = -isystem /opt/openssl/include -I /opt/openssl/include >> >> However, in both cases make fails compiling the module rlm_always because the >> system can not find openssl/err.h and other openssl header files. Is it >> possible that there are system openssl header files on your machine, maybe in >> /usr/local/include or in /opt/include, which the preprocessor uses? I am sure that such files do not exist on my machine. Could this be the rason why make runs well on your system, but not on my machine? > > No. The runtime version compatibility checks use the OpenSSL version from a macro > in the OpenSSL include files. > > If it were using the system OpenSSL header files, and non system libraries the server > would error out on startup (which it doesn't). > > Could you try with the v3.0.x branch and see if it's been fixed. I remember Alan > complaining about it not working correctly, but I can't remember if his issues > were fixed before 3.0.3 was released or after. Hi, let me start with the good news: The main problem is solved, rlm_always and all other files now compile without errors. However, we have also bad news, let me explain step by step: 1. The current v3.0.x source does not compile because of a problem in pcap.c. There is no pcap installed on my machine, and configure has detected that correctly. However, there are two functions at the end of pcap.c which are not included in the "#ifdef HAVE_LIBPCAP" and for that reason, the compiler creates errors. If you simply put everything in pcap.c between the "#ifdef HAVE_LIBPCAP" and "#endif", everything works well on my machine. 2. The configuration for types/rlm_eap_pwd does not yet work: > checking for openssl/ec.h... no > checking for openssl/ec.h in /usr/local/include/... no > checking for openssl/ec.h in /opt/include/... no > checking for OpenSSL support... yes > checking for EVP_sha256 in -lc -lcrypto -lssl... no > configure: WARNING: EVP_sha256 not found, may have issues wirh WiMAX certificates > checking for EC_GROUP_free... no > configure: WARNING: silently not building rlm_eap_pwd. > configure: WARNING: FAILURE: rlm_eap_pwd requires: EC_GROUP_free. I am sure that ec.h is in the directory where it should be. 3. The configuration of src/modules/rlm_unbound does not yet work: > checking for openssl/crypto.h... no > checking for openssl/crypto.h in /usr/local/include/... no > checking for openssl/crypto.h in /opt/include/... no > configure: WARNING: silently not building rlm_unbound. > configure: WARNING: FAILURE: rlm_unbound requires: libunbound unbound.h openssl/crypto.h. Again, I am sure that openssl/crypto.h is in place and readable by the compiler. 4. This issue is about src/modules/rlm_wimax: > checking openssl/hmac.h usability... no > checking openssl/hmac.h presence... no > checking for openssl/hmac.h... no > configure: WARNING: silently not building rlm_wimax. > configure: WARNING: FAILURE: rlm_wimax requires: openssl/hmac.h. 5. The last issue is good news again: The problems with the otp configuration are solved. Please let me know if I can help you with these issues, best regards, Andreas

2 1

Re: Re: Some inconsistencies concerning OpenSSL include configuration in FRS 3
by rieke＠isl.de 26 Jul '14

26 Jul '14

On 26 Jul 2014, at 17:31, Arran Cudbard-Bell wrote: >> However, there is another problem which causes the make process to fail; the problem occurs with rlm_always first: >>> >> CC /home/freeradius/freeradius-server-3.0.3/src/modules/rlm_always/rlm_always.c >>> >> In file included from /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/radiusd.h:59, >>> >> from /home/freeradius/freeradius-server-3.0.3/src/modules/rlm_always/rlm_always.c:27: >>> >> /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/tls.h:39:25: error: openssl/err.h: No such file or directory >>> >> /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/tls.h:41:30: error: openssl/engine.h: No such file or directory >>> >> /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/tls.h:43:25: error: openssl/ssl.h: No such file or directory >> > I already tried to use an environment variable CPPFLAGS="-I /opt/openssl/include" for the main configure script, but that did not help. What else can I do to convice FreeRADIUS to use the correct OpenSSL system? > You'd set it in Make.inc. > > With v3.0.x head > > Works for me with v3.0.x... > > ./configure --with-openssl-lib-dir=/usr/local/opt/openssl/lib --with-openssl-include-dir=/usr/local/opt/openssl/include > ... > checking OpenSSL library and header version consistency... library: 1000108f header: 1000108f... yes > ... > > LINK build/lib/libfreeradius-radius.la > CC /Users/arr2036/Documents/Repositories/freeradius-server-master/src/tests/rbmonkey.c > LINK build/bin/rbmonkey > CC /Users/arr2036/Documents/Repositories/freeradius-server-master/src/modules/rlm_always/rlm_always.c > LINK build/lib/rlm_always.la Hi again, first thanks a lot for your answer. Things work exactly as you said - in 3.0.2, but not in 3.0.3. The Make.inc file already contains the correct parameters - even without the parameter CPPFLAGS="-I /opt/openssl/include" for the configuration script: > CPPFLAGS = -isystem /opt/openssl/include If you pass CPPFLAGS="-I /opt/openssl/include" to the configure script, you get the path twice: > CPPFLAGS = -isystem /opt/openssl/include -I /opt/openssl/include However, in both cases make fails compiling the module rlm_always because the system can not find openssl/err.h and other openssl header files. Is it possible that there are system openssl header files on your machine, maybe in /usr/local/include or in /opt/include, which the preprocessor uses? I am sure that such files do not exist on my machine. Could this be the rason why make runs well on your system, but not on my machine? Best regards, Andreas

2 1

Some inconsistencies concerning OpenSSL include configuration in FRS 3
by rieke＠isl.de 26 Jul '14

26 Jul '14

Hi, due to the heartbleet bug, I want the FreeRADIUS server to use my own (new) OpenSSL library, and not the (old) system include/lib files. According to the main configuration utility (parameters for openssl include and lib directories) and accoring to Alan DeKok's email from May 16 (How to link to openssl if two versions of libssl are on the system, when building FreeRadius on Debian wheezy 7.4?) this should be possible: > I use it that way every day. However, this stopped working in my environment (CentOS) in the current 3.0.3 version of FRS; but let's start step by step with version 3.0.2. CentOS has own packages for development purposes, for example openssl-devel; to be sure that FreeRADIUS does not include the wrong header file, I have removed this package. Thus, FreeRADIUS will either take the correct file or report a missing file. In version 3.0.2 of FRS, there are two options for the configure script for that purpose (--with-openssl-includes=DIR and --with-openssl-libraries=DIR) which work well. However, there are a few small inconsistencies concerning the modules: - The configure script for rlm_eap_pwd is not able to find openssl/ec.h although the file is present in the folder given by the with-openssl-includes parameter to the main configure script: > checking for openssl/ec.h... no > checking for openssl/ec.h in /usr/local/include... no > checking for openssl/ec.h in /opt/include... no > checking for OpenSSL support... yes - The configure script for rlm_otp reports inconsistencies: > checking openssl/des.h usability... yes > checking openssl/des.h presence... no > configure: WARNING: openssl/des.h: accepted by the compiler, rejected by the preprocessor! > configure: WARNING: openssl/des.h: proceeding with the compiler's result > checking for openssl/des.h... yes - The configure script for rlm_wimax is not able to find openssl/hmac.h although the file is present in the folder given by the with-openssl-includes parameter to the main configure script: > checking openssl/hmac.h usability... no > checking openssl/hmac.h presence... no > checking for openssl/hmac.h... no > configure: WARNING: silently not building rlm_wimax. > configure: WARNING: FAILURE: rlm_wimax requires: openssl/hmac.h. However, most modules in 3.0.2 compile well, and ldd makes sure that the wanted libraries are linked. But several things change in version 3.0.3. First of all, the parameters of the main configuration script changed in the following way: --with-openssl-includes -> --with-openssl-include-dir --with-openssl-libraries -> --with-openssl-lib-dir Unfortunately, this parameter change has been done only for the main configuration script, but not for the modules. Concerning the modules, rlm_otp is the only module which offers configuration parameters for OpenSSL directories, and this module still uses the old parameter names in 3.0.3 and in the git version from today. There is an easy workaround for this problem: Simply pass both (old and new) parameters to the main configuration script! However, there is another problem which causes the make process to fail; the problem occurs with rlm_always first: > CC /home/freeradius/freeradius-server-3.0.3/src/modules/rlm_always/rlm_always.c > In file included from /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/radiusd.h:59, > from /home/freeradius/freeradius-server-3.0.3/src/modules/rlm_always/rlm_always.c:27: > /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/tls.h:39:25: error: openssl/err.h: No such file or directory > /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/tls.h:41:30: error: openssl/engine.h: No such file or directory > /home/freeradius/freeradius-server-3.0.3/src/freeradius-devel/tls.h:43:25: error: openssl/ssl.h: No such file or directory I already tried to use an environment variable CPPFLAGS="-I /opt/openssl/include" for the main configure script, but that did not help. What else can I do to convice FreeRADIUS to use the correct OpenSSL system? Thanks in advance, Andreas Rieke

2 1

HP M200 certificate authentication fails
by Gordon Cook 25 Jul '14

25 Jul '14

Hi. I have been struggling with this for about a week now. We just purchased an HP M200 access point to replace an old cisco. We are using EAP-TLS using certificates. Here is what I have done so far. I have both access points using the same freeRadius2 server which is running FreeBSD 9 The client can authenticate using the certificate through the cisco. The client can authenticate using PAP through the HP The client cannot authenticate using the certificate through the HP. I get the following message Cleaning up request 0 ID 206 with timestamp +281 WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING: !! EAP session for state 0xe4bd4b63e4b14652 did not finish! WARNING: !! Please read http://wiki.freeradius.org/guide/Certificate_Compatibility WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Cleaning up request 1 ID 248 with timestamp +281 Cleaning up request 2 ID 239 with timestamp +281 Cleaning up request 3 ID 167 with timestamp +281 Cleaning up request 4 ID 102 with timestamp +281 WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING: !! EAP session for state 0x8c4bc3ec8f5acec4 did not finish! WARNING: !! Please read http://wiki.freeradius.org/guide/Certificate_Compatibility WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I have looked through everything I can find and I can't seem to get it to work. Gordon Cook Network Administrator Sault Ste Marie Innovation Centre Work: 705-942-6938 x3042 Cell: 705-971-3852 [comptia]<http://www.comptia.com/> [ssmic-one-2013]

4 12

wildcard/regex Auth-Type in authenticate section
by Zenon Mousmoulas 25 Jul '14

25 Jul '14

Hi again, sorry if this is a trivial question, but I couldn't find a definitive answer and I need to clarify: My understanding is that modules set Auth-Type in the authorize section and the server looks in the authenticate section for a matching sub-section. Different instances of rlm_eap set Auth-Type to their xlat name. The question is: Other than adding an Auth-Type subsection for every such variation, is it possible to match them e.g. in a regex comparison? As far as I can tell, I can only use unlang within Auth-Type subsections and not directly in the authenticate section. Thanks, Z.

2 7

Timeout problem behind load balancer
by Simon Morley 25 Jul '14

25 Jul '14

I've got a few working freeradius servers that we've spread the load with some basic round robin dns shizzle. Today I found out that Google's Compute Engine network load balancers support UDP traffic so I thought I'd try them out. Firstly I thought everything had gone smoothly as I could see Access-Accept appearing in the debug logs. However on further inspection, whilst I always get this message (when using a valid account), my client doesn't actually receive the response and therefore fails. I've tried with a simulator (jradius) and a coova client - all the same. There's no errors in the logs - the last few lines are as so: Thu Jul 24 23:51:23 2014 : Debug: rlm_sql (sql_primary): Reserving sql socket id: 3 Thu Jul 24 23:51:23 2014 : Info: row[0] returned NULL Thu Jul 24 23:51:23 2014 : Debug: rlm_sql (sql_primary): Released sql socket id: 3 Thu Jul 24 23:51:23 2014 : Info: expand: %{sql_primary:select location_id from nas where calledstationid='%{Called-Station-Id-Clean}'} -> Thu Jul 24 23:51:23 2014 : Info: ++} # update request = noop Thu Jul 24 23:51:23 2014 : Info: ++? if ("%{Tmp-String-4}") Thu Jul 24 23:51:23 2014 : Info: expand: %{Tmp-String-4} -> Thu Jul 24 23:51:23 2014 : Info: ? Evaluating ("%{Tmp-String-4}") -> FALSE Thu Jul 24 23:51:23 2014 : Info: ++? if ("%{Tmp-String-4}") -> FALSE Thu Jul 24 23:51:23 2014 : Info: [sql_cache] expand: %{User-Name} -> test Thu Jul 24 23:51:23 2014 : Info: [sql_cache] sql_set_user escaped user --> 'test' Thu Jul 24 23:51:23 2014 : Info: [sql_cache] expand: %{User-Password} -> account Thu Jul 24 23:51:23 2014 : Info: [sql_cache] expand: INSERT INTO radpostauth_cache (username, pass, reply, authdate) VALUES ( '%{User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S') -> INSERT INTO radpostauth_cache (username, pass, reply, authdate) VALUES ( 'test', 'account', 'Access-Accept', '2014-07-24 23:51:23') Thu Jul 24 23:51:23 2014 : Debug: rlm_sql (sql_cache) in sql_postauth: query is INSERT INTO radpostauth_cache (username, pass, reply, authdate) VALUES ( 'test', 'account', 'Access-Accept', '2014-07-24 23:51:23') Thu Jul 24 23:51:23 2014 : Debug: rlm_sql (sql_cache): Reserving sql socket id: 2 Thu Jul 24 23:51:23 2014 : Debug: rlm_sql (sql_cache): Released sql socket id: 2 Thu Jul 24 23:51:23 2014 : Info: ++[sql_cache] = ok Thu Jul 24 23:51:23 2014 : Info: ++[exec] = noop Thu Jul 24 23:51:23 2014 : Info: +} # group post-auth = ok Sending Access-Accept of id 8 to 213.205.230.210 port 49080 Thu Jul 24 23:51:23 2014 : Info: Finished request 7. Thu Jul 24 23:51:23 2014 : Debug: Going to the next request Thu Jul 24 23:51:23 2014 : Debug: Waking up in 1.9 seconds. Thu Jul 24 23:51:25 2014 : Info: Cleaning up request 7 ID 8 with timestamp +177 Thu Jul 24 23:51:25 2014 : Info: Ready to process requests. I've discussed with Google and they're saying the connection isn't closed and the load-balancer therefore puts the instance in 'unhealthy' mode. This doesn't sound right to me. I think the traffic is being blocked. The only reference I can find to a similar issue was a user years ago who had network issues.. Has anyone tried this successfully - either on GCE or other UDP load balancer? Does anyone have any thoughts about how I could solve?

4 5