Dear Alan! I*t is a timing issue.* I just forwarded the Access Request to another radius server (Domain Controller) which replies immediately - access accepted, VPN client logged in successfully. If I put a 'sleep 10' in the shell script (duo2.sh) before the radtest (please see below) to send the request to the Domain Controller (10.101.168.3), then the VPN connection fails like with the DUO. Details: */etc/freeradius/Duo2.sh * #!/bin/bash sleep 10 if (/usr/bin/radtest -d /usr/share/freeradius/ -t mschap 'Peter Dudas' 'password' 10.101.168.3:1812 0 secret 0 10.148.64.67) | grep -Fq 'Access-Accept'; then echo "Access-Accept" else echo "Access-Reject" exit 1 *fi * */etc/freeradius/mods-available/duo2 * exec duo2 { wait = yes program = "/etc/freeradius/duo2.sh" timeout = 30 *} * */etc/freeradius/sites-available/default * server dafault { listen { type = auth ipaddr = 10.148.64.67 port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } listen { type = auth ipaddr = 127.0.0.1 port = 0 limit { } } listen { type = acct ipaddr = 10.148.64.67 port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } listen { type = acct ipaddr = 127.0.0.1 port = 0 limit { } } authorize { preprocess auth_log #KIPOW1 SSL-VPN Radius Request attributes checked before MS-CHAPv2 auth if (User-Name != "" && Service-Type !* "") { if (Packet-Type == "Access-Request" && NAS-IP-Address == " 89.212.168.xyz") { sslvpn if (ok) { update control { Auth-Type := Accept } update reply { Filter-Id := "SSLVPN-Users" } return } } } else { # KIPOW1 L2TP-VPN Radius Request attributes checked before MS-CHAPv2 auth if (MS-CHAP2-Response != "" && MS-CHAP-Challenge != "") { if (NAS-IP-Address == "89.212.168.xyz" && Framed-Protocol == "PPP") { if (Service-Type == "Framed-User" && Packet-Type == "Access-Request" ) { if (MS-CHAP-Challenge != "" && NAS-PORT == "0" ) { mschap if (ok) { update reply { Filter-Id := "L2TP-Users" } } } } } } } } authenticate { Auth-Type mschap { mschap } Auth-Type sslvpn { sslvpn } Auth-Type duo { duo } } preacct { preprocess acct_unique suffix files } accounting { detail radutmp attr_filter.accounting_response } session { radutmp } post-auth { reply_log duo2 exec Post-Auth-Type REJECT { attr_filter.access_reject } reply_log } pre-proxy { } post-proxy { } *} * /etc/freeradius/radiusd.conf prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = ${exec_prefix}/sbin logdir = /var/log/freeradius raddbdir = /etc/freeradius radacctdir = ${logdir}/radacct name = freeradius confdir = ${raddbdir} modconfdir = ${confdir}/mods-config certdir = ${confdir}/certs cadir = ${confdir}/certs run_dir = ${localstatedir}/run/${name} db_dir = ${raddbdir} libdir = /usr/lib/freeradius pidfile = ${run_dir}/${name}.pid correct_escapes = true max_request_time = 45 cleanup_delay = 5 max_requests = 16384 hostname_lookups = no regular_expressions = yes extended_expressions = yes checkrad = ${sbindir}/checkrad log { destination = files colourise = yes file = ${logdir}/radius.log syslog_facility = daemon stripped_names = no auth = yes auth_badpass = yes auth_goodpass = yes } security { user = freerad group = freerad allow_core_dumps = no max_attributes = 200 reject_delay = 1 status_server = yes } proxy_requests = no $INCLUDE clients.conf thread pool { start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 auto_limit_acct = no } modules { $INCLUDE mods-enabled/ } instantiate { } policy { $INCLUDE policy.d/ } *$INCLUDE sites-enabled/ * /etc/freeradius/clients.conf client localhost { ipaddr = 127.0.0.1 proto = * secret = bekapodafaszomhajohanemjo require_message_authenticator = no nas_type = other # localhost isn't usually a NAS... # response_window = 10.0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } client dc1 { ipaddr = 10.101.168.3 secret = secretofclient response_window = 30.0 So it is not related with DUO - it is a simple timing/timeout issue. Do you have any idea why this happens? Thank you! Peter Dudas On 5 January 2017 at 01:27, Dudás Péter <peter.pdudas@gmail.com> wrote:
Dear Alan!
Working means the devices are successfully connected - so the connection not depending on the strenght of the tunnel encryption (if duo authentication disabled).
Somenthing should be different - I have a feeling that Duo and Freeradius uses the same resources and this cause the problem. Tomorrow I'll move the Duo to a new server and we'll see if the problem stays or not.
On 5 January 2017 at 00:35, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 4, 2017, at 6:17 PM, Dudás Péter <peter.pdudas@gmail.com> wrote:
I don't see any difference in the reply - checked the logs.
Then the NAS should do the same thing in both cases.
With this I was able to login from and Android phone. MPPE encryption type I changed to Required (at module mschap) - but as you can see it is working with that as well.
Please be clear about "working". There are multiple pieces involved.
If the Access-Accepts are the same in both cases, then the NAS should behave the same in both cases.
And there is no way that adding a simple program to be executed will make the NAS misbehave.
Something else is going wrong. Find that, and the problem will be fixed.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list /users.html