Hello! I'm trying to integrate Duo auth proxy (2.4.19) and Freeradius 3.0.12 on Ubuntu 16.04 to have 2 Factor Authentication on VPN radius requests via Duo security. Active directory intergation done via Samba4 (winbindd). VPN authentication can be SSLVPN or L2TP. Both works - SSL uses pap authentication against the AD, L2TP uses MSCHAPv2 against the AD. SSL sends back only the Filter-Id, L2TP sends Filter-Id and MPPE keys. To have 2 Factor Authentication I created a module for Duo authentication which calls an external script with the user variables and the script writes them to a text file which is the input file for a radclient in the following way: /usr/bin/radclient -f /opt/duoauthproxy/packet -c 1 -r 2 -t 30 -x 127.0.0.1:1645 auth secret -x Radclient connects to the Duo Auth Proxy on the localhost and doing the authentication via Duo services (push/phone/otp code). After the authentication the module returns the Exit code 0 or Exit code 1 (depending on the authentication result). With the SSLVPN it works fine - simply put the Duo authorization before the AD auth in authorize section and works perfectly. With the L2TP it is not working at all. I see the successful authentication (both: Duo and Mschap), MPPE keys and Filter-Id returned, firewall grants the access - and the devices are just not connects. I don't see any errors, and as also the firewall grants the access I have no clue what could this be. Now duo auth happens at post auth section - but it can be anywhere - just not working. Here is the debug: (0) Received Access-Request Id 203 from 10.101.168.3:59819 to 10.148.64.67:1812 length 161 (0) Service-Type = Framed-User (0) Framed-Protocol = PPP (0) User-Name = "Peter Dudas" (0) NAS-IP-Address = 89.212.168.XYZ (0) NAS-Port = 0 (0) MS-CHAP-Challenge = 0x5556c20e9277af608a7ba5335955d181 (0) MS-CHAP2-Response = 0x32006b1c6f8f39c8c7049a9b365ac86156e90000000000000000f7a54abdb5fa7c889557a2729d2234117d36cd4a203ed4ac (0) Proxy-State = 0xfe80000000000000953e77ad63f094ba000000cb (0) # Executing section authorize from file /etc/freeradius/sites-enabled/default (0) authorize { (0) [preprocess] = ok (0) if (User-Name != ""){ (0) if (User-Name != "") -> TRUE (0) (User-Name != "") { ... } # empty sub-section is ignored (0) auth_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d (0) auth_log: --> /var/log/freeradius/radacct/ 10.101.168.3/auth-detail-20170104 (0) auth_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/10.101.168.3/auth-detail-20170104 (0) auth_log: EXPAND %t (0) auth_log: --> Wed Jan 4 22:35:44 2017 (0) [auth_log] = ok (0) if (User-Name != "" && Service-Type !* "") { (0) if (User-Name != "" && Service-Type !* "") -> FALSE (0) else { (0) if (MS-CHAP2-Response != "" && MS-CHAP-Challenge != "") { (0) if (MS-CHAP2-Response != "" && MS-CHAP-Challenge != "") -> TRUE (0) if (MS-CHAP2-Response != "" && MS-CHAP-Challenge != "") { (0) if (NAS-IP-Address == "89.212.168.XZY" && Framed-Protocol == "PPP") { (0) if (NAS-IP-Address == "89.212.168.XYZ" && Framed-Protocol == "PPP") -> TRUE (0) if (NAS-IP-Address == "89.212.168.XYZ" && Framed-Protocol == "PPP") { (0) if (Service-Type == "Framed-User" && Packet-Type == "Access-Request" ) { (0) EXPAND Packet-Type (0) --> Access-Request (0) if (Service-Type == "Framed-User" && Packet-Type == "Access-Request" ) -> TRUE (0) if (Service-Type == "Framed-User" && Packet-Type == "Access-Request" ) { (0) if (MS-CHAP-Challenge != "" && NAS-PORT == "0" ) { (0) if (MS-CHAP-Challenge != "" && NAS-PORT == "0" ) -> TRUE (0) if (MS-CHAP-Challenge != "" && NAS-PORT == "0" ) { (0) mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap' (0) [mschap] = ok (0) if (ok) { (0) if (ok) -> TRUE (0) if (ok) { (0) update reply { (0) Filter-Id := "L2TP-Users" (0) } # update reply = noop (0) } # if (ok) = noop (0) } # if (MS-CHAP-Challenge != "" && NAS-PORT == "0" ) = ok (0) } # if (Service-Type == "Framed-User" && Packet-Type == "Access-Request" ) = ok (0) } # if (NAS-IP-Address == "89.212.168.XYZ" && Framed-Protocol == "PPP") = ok (0) } # if (MS-CHAP2-Response != "" && MS-CHAP-Challenge != "") = ok (0) } # else = ok (0) } # authorize = ok (0) Found Auth-Type = mschap (0) # Executing group from file /etc/freeradius/sites-enabled/default (0) Auth-Type mschap { (0) mschap: Creating challenge hash with username: Peter Dudas (0) mschap: Client is using MS-CHAPv2 (0) mschap: Executing: /usr/bin/ntlm_auth --request-nt-key --username=%{request:User-Name} --domain=site.domain.local --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00} --require-membership-of=site.domain.local\l2tp-users: (0) mschap: EXPAND --username=%{request:User-Name} (0) mschap: --> --username=Peter Dudas (0) mschap: Creating challenge hash with username: Peter Dudas (0) mschap: EXPAND --challenge=%{mschap:Challenge:-00} (0) mschap: --> --challenge=397e282f44bc0581 (0) mschap: EXPAND --nt-response=%{mschap:NT-Response:-00} (0) mschap: --> --nt-response=f7a54abdb5fa7c889557a2729d2234117d36cd4a203ed4ac (0) mschap: Program returned code (0) and output 'NT_KEY: A1A055BBCC2133B2E1FCD8213C6B03FE' (0) mschap: Adding MS-CHAPv2 MPPE keys (0) [mschap] = ok (0) } # Auth-Type mschap = ok (0) # Executing section post-auth from file /etc/freeradius/sites-enabled/default (0) post-auth { (0) reply_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d (0) reply_log: --> /var/log/freeradius/radacct/ 10.101.168.3/reply-detail-20170104 (0) reply_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d expands to /var/log/freeradius/radacct/10.101.168.3/reply-detail-20170104 (0) reply_log: EXPAND %t (0) reply_log: --> Wed Jan 4 22:35:44 2017 (0) [reply_log] = ok (0) duo: Executing: /usr/bin/radclient -f /etc/freeradius/packet -c 1 -r 1 -t 45 127.0.0.1:1645 auth secret -x: (0) duo: Program returned code (0) and output 'Sent Access-Request Id 49 from 0.0.0.0:52464 to 127.0.0.1:1645 length 75 Packet-Type = Access-Request Service-Type = Framed-User Framed-Protocol = PPP User-Name = "Peter Dudas" User-Password = "push" NAS-IP-Address = 89.212.168.XYZ NAS-Port = 0 Cleartext-Password = "push" Received Access-Accept Id 49 from 127.0.0.1:1645 to 0.0.0.0:0 length 48 Reply-Message = "Success. Logging you in..."' (0) duo: Program executed successfully (0) [duo] = ok (0) reply_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d (0) reply_log: --> /var/log/freeradius/radacct/ 10.101.168.3/reply-detail-20170104 (0) reply_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d expands to /var/log/freeradius/radacct/10.101.168.3/reply-detail-20170104 (0) reply_log: EXPAND %t (0) reply_log: --> Wed Jan 4 22:35:44 2017 (0) [reply_log] = ok (0) [exec] = noop (0) reply_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d (0) reply_log: --> /var/log/freeradius/radacct/ 10.101.168.3/reply-detail-20170104 (0) reply_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d expands to /var/log/freeradius/radacct/10.101.168.3/reply-detail-20170104 (0) reply_log: EXPAND %t (0) reply_log: --> Wed Jan 4 22:35:44 2017 (0) [reply_log] = ok (0) } # post-auth = ok (0) Login OK: [Peter Dudas/<via Auth-Type = mschap>] (from client dc1 port 0) (0) Sent Access-Accept Id 203 from 10.148.64.67:1812 to 10.101.168.3:59819 length 0 (0) Filter-Id := "L2TP-Users" (0) MS-CHAP2-Success = 0x32533d34413036444345313735434538323544364344333939363634303638424345343738453634383132 (0) MS-MPPE-Recv-Key = 0x8e2b496673e4be264ff378973bfc4f0a (0) MS-MPPE-Send-Key = 0x3d999c39dd3234adb646ff83015329da (0) MS-MPPE-Encryption-Policy = Encryption-Required (0) MS-MPPE-Encryption-Types = RC4-40or128-bit-Allowed (0) Proxy-State = 0xfe80000000000000953e77ad63f094ba000000cb (0) Finished request Waking up in 4.9 seconds. (0) Cleaning up request packet ID 203 with timestamp +18 I've tried to run the duo auth ant the Authorize, post auth sections - no matter where it is, the connection is not successful. Do you maybe know what change with this second authentication which blocks the L2TP VPN connection? If I comment out the DUO - then L2TP VPN connects without problem. I don't find any difference in the Reply packets (chacked with Wireshark too). Thank you! Peter Dudas
On Jan 4, 2017, at 4:50 PM, Dudás Péter <peter.pdudas@gmail.com> wrote:
I'm trying to integrate Duo auth proxy (2.4.19) and Freeradius 3.0.12 on Ubuntu 16.04 to have 2 Factor Authentication on VPN radius requests via Duo security.
What's "duo auth" ?
Active directory intergation done via Samba4 (winbindd).
VPN authentication can be SSLVPN or L2TP. Both works - SSL uses pap authentication against the AD, L2TP uses MSCHAPv2 against the AD. SSL sends back only the Filter-Id, L2TP sends Filter-Id and MPPE keys.
To have 2 Factor Authentication I created a module for Duo authentication which calls an external script with the user variables and the script writes them to a text file which is the input file for a radclient in the following way: /usr/bin/radclient -f /opt/duoauthproxy/packet -c 1 -r 2 -t 30 -x 127.0.0.1:1645 auth secret -x
That works only for PAP. And why run "radclient" manually? The server can proxy RADIUS packets. Why not do that?
Radclient connects to the Duo Auth Proxy on the localhost and doing the authentication via Duo services (push/phone/otp code). After the authentication the module returns the Exit code 0 or Exit code 1 (depending on the authentication result).
Proxying RADIUS packets would be a lot easier.
With the SSLVPN it works fine - simply put the Duo authorization before the AD auth in authorize section and works perfectly. With the L2TP it is not working at all. I see the successful authentication (both: Duo and Mschap), MPPE keys and Filter-Id returned, firewall grants the access - and the devices are just not connects.
Blame the L2TP gateway then. If the attributes returned by FreeRADIUS are the same for both Duo and non-duo cases, then the NAS should behave the same in both situations.
I don't see any errors, and as also the firewall grants the access I have no clue what could this be.
Look at the firewall logs to see what it's doing. You can't debug the firewall by looking at the FreeRADIUS logs.
I've tried to run the duo auth ant the Authorize, post auth sections - no matter where it is, the connection is not successful.
You're looking at the wrong thing. Look at the debug log and Access-Accept packets for both the "with duo" and "without duo" cases. If the Access-Accepts are the same, then the firewall should behave the same in both situations.
Do you maybe know what change with this second authentication which blocks the L2TP VPN connection?
Since you've only given a non-working debug output and not a working one... no, we don't know what's going on.
If I comment out the DUO - then L2TP VPN connects without problem.
I don't find any difference in the Reply packets (chacked with Wireshark too).
Then blame the firewall. Alan DeKok.
Dear Alan! "What's "duo auth" ?" www.duo.com It is a 2 factor authentication service. And much more. "That works only for PAP. And why run "radclient" manually? The server can proxy RADIUS packets. Why not do that?" It is not relaying the password - only user name and authentication method relayed (SMS/Push/Phone). Writing the request attributes to a file then use that to authenticate on the Duo auth proxy running on the same host. Then Duo sends a request to the mobile phone - where the user grants or deny the access. So this is how it has the second authentication factor. And authentication successful. Why can't I chain 2 authentication? If they are chained, then something changes. I would proxy the request, but needs 2 authentication - first the Duo, then AD auth (SSL=pap, L2TP=MSCHAPv2). Or first Ad then Duo. Is it possible to proxy the request to Duo and then have a second authentication on the same request depending on the result of the proxy answer? I cannot figure out - I think it will be a bug (either in Freeradius or AD auth). Somehow, if any external script runs before/after the Mschap authentication that just fucks up the L2TP connection (PPP). In windows it is Error 734 - but believe me it is not related with multilink/single link at all. Tested with Windows10/Android 6.0/IOS9.3.5. Taking out DUO - works. Taking out mschap - works. Duo and mschap together: failed connection. Tried with just a module which runs a shell script which do nothing - except Exit 0 Module has no output_pairs defined. And it has the same result - connection failed. No red lines in the debug - all fine. I simply have no clue. Firewall log show authentication successful - but the devices are not connected (Windows10/Android/iPad). 99% that it is related with MPPE keys - I just simply have no clue what is the connection between the generated MPPE keys and a second authentication. Or is this related with Session State? It is 2 different session and that's why the reply changes? Just guessing - spent a whole day to figure out and simply have no more idea. I'm not able to decrypt/use the MPPE keys - so cannot verify them. Firewall just needs the Filter-Id and access-accept, then grants the connection. So it is not firewall related issue. PPP connection not established - that's why I think it can be related with the MPPE keys. But as you can see the keys are generated at the mschap authentication. Is it possible to cache the MPPE keys to be sure they are not changed during/because of the second authentication. "Since you've only given a non-working debug output and not a working one... no, we don't know what's going on." The debug contains 2 successful authentication and an Access-Accept answer. So it is a successful authentication - just have a problem somewhere. Thank you!
On Jan 4, 2017, at 6:05 PM, Dudás Péter <peter.pdudas@gmail.com> wrote:
I would proxy the request, but needs 2 authentication - first the Duo, then AD auth (SSL=pap, L2TP=MSCHAPv2). Or first Ad then Duo. Is it possible to proxy the request to Duo and then have a second authentication on the same request depending on the result of the proxy answer?
No. We're fixing that in v4.
Tried with just a module which runs a shell script which do nothing - except Exit 0 Module has no output_pairs defined. And it has the same result - connection failed. No red lines in the debug - all fine.
That's suspicious.
I simply have no clue. Firewall log show authentication successful - but the devices are not connected (Windows10/Android/iPad). 99% that it is related with MPPE keys - I just simply have no clue what is the connection between the generated MPPE keys and a second authentication.
The MPPE keys are automatically derived from the authentication method / credentials. They change with every login.
I'm not able to decrypt/use the MPPE keys - so cannot verify them.
You don't decrypt them. The debug log shows their real value.
Firewall just needs the Filter-Id and access-accept, then grants the connection. So it is not firewall related issue.
Well, if the firewall is not allowing the user online, then it is a firewall issue.
PPP connection not established - that's why I think it can be related with the MPPE keys. But as you can see the keys are generated at the mschap authentication.
Yes. And if your script doesn't modify the MPPE keys, everything should be dine.
Is it possible to cache the MPPE keys to be sure they are not changed during/because of the second authentication.
Don't do that.
"Since you've only given a non-working debug output and not a working one... no, we don't know what's going on." The debug contains 2 successful authentication and an Access-Accept answer. So it is a successful authentication - just have a problem somewhere.
If FreeRADIUS returns Access-Accept and the user doesn't get online.. blame the NAS. Alan DeKok.
Dear Alan! Please find the debug of the successful mschap authentication below. The Duo Auth removed from the post auth section. Ready to process requests (0) Received Access-Request Id 209 from 10.101.168.3:59819 to 10.148.64.67:1812 length 161 (0) Service-Type = Framed-User (0) Framed-Protocol = PPP (0) User-Name = "Peter Dudas" (0) NAS-IP-Address = 89.212.168.XYZ (0) NAS-Port = 0 (0) MS-CHAP-Challenge = 0x8ef379a65af2caa31bc58658cecfb468 (0) MS-CHAP2-Response = 0x3200b3c3cbfae01b4a336b36a956fd00a6010000000000000000b8e93f963a8a27ecd54c3bda0ffed73bf110dfae7bc9868b (0) Proxy-State = 0xfe80000000000000953e77ad63f094ba000000d1 (0) # Executing section authorize from file /etc/freeradius/sites-enabled/default (0) authorize { (0) [preprocess] = ok (0) auth_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d (0) auth_log: --> /var/log/freeradius/radacct/ 10.101.168.3/auth-detail-20170105 (0) auth_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/10.101.168.3/auth-detail-20170105 (0) auth_log: EXPAND %t (0) auth_log: --> Thu Jan 5 00:10:27 2017 (0) [auth_log] = ok (0) if (User-Name != "" && Service-Type !* "") { (0) if (User-Name != "" && Service-Type !* "") -> FALSE (0) else { (0) if (MS-CHAP2-Response != "" && MS-CHAP-Challenge != "") { (0) if (MS-CHAP2-Response != "" && MS-CHAP-Challenge != "") -> TRUE (0) if (MS-CHAP2-Response != "" && MS-CHAP-Challenge != "") { (0) if (NAS-IP-Address == "89.212.168.XYZ" && Framed-Protocol == "PPP") { (0) if (NAS-IP-Address == "89.212.168.XYZ" && Framed-Protocol == "PPP") -> TRUE (0) if (NAS-IP-Address == "89.212.168.XYZ" && Framed-Protocol == "PPP") { (0) if (Service-Type == "Framed-User" && Packet-Type == "Access-Request" ) { (0) EXPAND Packet-Type (0) --> Access-Request (0) if (Service-Type == "Framed-User" && Packet-Type == "Access-Request" ) -> TRUE (0) if (Service-Type == "Framed-User" && Packet-Type == "Access-Request" ) { (0) if (MS-CHAP-Challenge != "" && NAS-PORT == "0" ) { (0) if (MS-CHAP-Challenge != "" && NAS-PORT == "0" ) -> TRUE (0) if (MS-CHAP-Challenge != "" && NAS-PORT == "0" ) { (0) mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap' (0) [mschap] = ok (0) if (ok) { (0) if (ok) -> TRUE (0) if (ok) { (0) update reply { (0) Filter-Id := "L2TP-Users" (0) } # update reply = noop (0) } # if (ok) = noop (0) } # if (MS-CHAP-Challenge != "" && NAS-PORT == "0" ) = ok (0) } # if (Service-Type == "Framed-User" && Packet-Type == "Access-Request" ) = ok (0) } # if (NAS-IP-Address == "89.212.168.XYZ" && Framed-Protocol == "PPP") = ok (0) } # if (MS-CHAP2-Response != "" && MS-CHAP-Challenge != "") = ok (0) } # else = ok (0) } # authorize = ok (0) Found Auth-Type = mschap (0) # Executing group from file /etc/freeradius/sites-enabled/default (0) Auth-Type mschap { (0) mschap: Creating challenge hash with username: Peter Dudas (0) mschap: Client is using MS-CHAPv2 (0) mschap: Executing: /usr/bin/ntlm_auth --request-nt-key --username=%{request:User-Name} --domain=site.domain.local --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00} --require-membership-of=site.domain.local\l2tp-users: (0) mschap: EXPAND --username=%{request:User-Name} (0) mschap: --> --username=Peter Dudas (0) mschap: Creating challenge hash with username: Peter Dudas (0) mschap: EXPAND --challenge=%{mschap:Challenge:-00} (0) mschap: --> --challenge=a378e306f1156a0d (0) mschap: EXPAND --nt-response=%{mschap:NT-Response:-00} (0) mschap: --> --nt-response=b8e93f963a8a27ecd54c3bda0ffed73bf110dfae7bc9868b (0) mschap: Program returned code (0) and output 'NT_KEY: A1A055BBCC2133B2E1FCD8213C6B03FE' (0) mschap: Adding MS-CHAPv2 MPPE keys (0) [mschap] = ok (0) } # Auth-Type mschap = ok (0) # Executing section post-auth from file /etc/freeradius/sites-enabled/default (0) post-auth { (0) reply_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d (0) reply_log: --> /var/log/freeradius/radacct/ 10.101.168.3/reply-detail-20170105 (0) reply_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d expands to /var/log/freeradius/radacct/10.101.168.3/reply-detail-20170105 (0) reply_log: EXPAND %t (0) reply_log: --> Thu Jan 5 00:10:27 2017 (0) [reply_log] = ok (0) [exec] = noop (0) reply_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d (0) reply_log: --> /var/log/freeradius/radacct/ 10.101.168.3/reply-detail-20170105 (0) reply_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d expands to /var/log/freeradius/radacct/10.101.168.3/reply-detail-20170105 (0) reply_log: EXPAND %t (0) reply_log: --> Thu Jan 5 00:10:27 2017 (0) [reply_log] = ok (0) } # post-auth = ok (0) Login OK: [Peter Dudas/<via Auth-Type = mschap>] (from client dc1 port 0) (0) Sent Access-Accept Id 209 from 10.148.64.67:1812 to 10.101.168.3:59819 length 0 (0) Filter-Id := "L2TP-Users" (0) MS-CHAP2-Success = 0x32533d37394230393541463633444633413145353737343239303830353046363142434245353136424336 (0) MS-MPPE-Recv-Key = 0xbe1f6bc006bce75b35eea9768b019de5 (0) MS-MPPE-Send-Key = 0x76698eb2f646753c148e41dc1184bf5a (0) MS-MPPE-Encryption-Policy = Encryption-Required (0) MS-MPPE-Encryption-Types = 4 (0) Proxy-State = 0xfe80000000000000953e77ad63f094ba000000d1 (0) Finished request Waking up in 4.9 seconds. (0) Cleaning up request packet ID 209 with timestamp +70 I don't see any difference in the reply - checked the logs. 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. This is the only defference at the reply packet. Peter Dudas
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.
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
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
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.
Does the NAS have a timing limit on establishing a tunnel? If that's the case, I suggest you look at increasing that limit to allow a DUO 2FA to happen. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Dear Stefan! No, the firewall shows authentication accepted - also Wireshark logs shows accepted connection, NPS also (which proxies the request/answer) shows accept. I'm not aware of any timing limitations (as with the SSLVPN I can even wait for 30s using the same 2nd authentication as for L2TP) - the whole chain (firewall-Nps-Freeradius) has minimum 30s timeout configured. Regarding MPPE keys: is there an expiration encoded somehow? With 'Sleep 3' it is still connected successfully - anything above 3 seconds just makes the L2TP VPN connection unsuccessful. Checked in the firewall - timeout is 90s. Thank you! On 5 January 2017 at 12:48, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
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.
Does the NAS have a timing limit on establishing a tunnel? If that's the case, I suggest you look at increasing that limit to allow a DUO 2FA to happen.
Stefan Paetow Moonshot Industry & Research Liaison Coordinator
t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet
jisc.ac.uk
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Thu, Jan 05, 2017 at 01:54:42PM +0100, Dudás Péter wrote:
With 'Sleep 3' it is still connected successfully - anything above 3 seconds just makes the L2TP VPN connection unsuccessful. Checked in the firewall - timeout is 90s.
Logs on the end user client? There will be a timeout there as well. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
I'm not aware of any timing limitations (as with the SSLVPN I can even wait for 30s using the same 2nd authentication as for L2TP) - the whole chain (firewall-Nps-Freeradius) has minimum 30s timeout configured.
Ok... If 30 seconds is not enough, that is a bit of a concern.
With 'Sleep 3' it is still connected successfully - anything above 3 seconds just makes the L2TP VPN connection unsuccessful. Checked in the firewall - timeout is 90s.
You might want to check what the complete end-to-end timing is... Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Not more than 4s. Click on VPN connection on iPad/Android/Windows10 - and error appears in 7s. So 4 s as sleep and the rest is just the connection to the firewall -> firewall to NPS -> Nps to Freeradius (and back). Trying to get info about PPP timeouts of the firewall. Peter Dudas
Dear Stefan! This is the log of the firewall for an unsuccessful connection: 2017-01-05 15:35:23 accel-pppd msg=:: recv [L2TP tid=0 sid=0 Ns=0 Nr=0 <Message-Type Start-Ctrl-Conn-Request> <Protocol-Version 256> <Framing-Capabilities 3> <Host-Name Peters-iPad> <Assigned-Tunnel-ID 34> <Recv-Window-Size 4>] Debug 2017-01-05 15:35:23 accel-pppd msg=:: send [L2TP tid=34 sid=0 Ns=0 Nr=1 <Message-Type Start-Ctrl-Conn-Reply> <Protocol-Version 256> <Host-Name POW1> <Framing-Capabilities 3> <Assigned-Tunnel-ID 1> <Vendor-Name accel-ppp>] Debug 2017-01-05 15:35:23 accel-pppd msg=:: recv [L2TP tid=1 sid=0 Ns=1 Nr=1 <Message-Type Start-Ctrl-Conn-Connected>] Debug 2017-01-05 15:35:23 accel-pppd msg=:: recv [L2TP tid=1 sid=0 Ns=2 Nr=1 <Message-Type Incoming-Call-Request> <Assigned-Session-ID 332> <Call-Serial-Number 1>] Debug 2017-01-05 15:35:23 accel-pppd msg=:: send [L2TP tid=34 sid=332 Ns=1 Nr=3 <Message-Type Incoming-Call-Reply> <Assigned-Session-ID 1>] Debug 2017-01-05 15:35:23 accel-pppd msg=:: recv [L2TP tid=1 sid=1 Ns=3 Nr=2 <Message-Type Incoming-Call-Connected> <TX-Speed 1000000> <Framing-Type 3>] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: connect: ppp0 <--> l2tp( 89.212.168.xyz) Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: lcp_layer_init Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: auth_layer_init Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: ccp_layer_init Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: ipcp_layer_init Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: ipv6cp_layer_init Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: ppp established Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: lcp_layer_start Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: send [LCP ConfReq id=1 <auth MSCHAP-v2> <magic 2df6d648> <mru 1400>] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: send [L2TP tid=34 sid=0 Ns=2 Nr=4] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: recv [LCP ConfReq id=1 < 2 6 0 0 0 0 > <magic 57044e1e> <pcomp> <accomp>] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: send [LCP ConfRej id=1 < 2 6 0 0 0 0 > <pcomp> <accomp>] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: recv [LCP ConfAck id=1 <auth MSCHAP-v2> <magic 2df6d648> <mru 1400>] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: recv [LCP ConfReq id=2 <magic 57044e1e>] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: send [LCP ConfAck id=2 ] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: lcp_layer_started Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: auth_layer_start Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: send [MSCHAP-v2 Challenge id=1 <9db289b1154a96a74592f6278d5fbbc>] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: recv [LCP EchoReq id=0 <magic 57044e1e>] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: send [LCP EchoRep id=0 <magic 48d6f62d>] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: recv [MSCHAP-v2 Response id=1 <9864eb6874e71568292ed3764e322a8>, <62eb71aa08cf141c9d171c92ae423c08d1822fdcb47f>, F=0, name="Peter Dudas"] Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: tpas: id:1 flags:0x0 reserved:0x33800a93 Debug 2017-01-05 15:35:23 accel-pppd msg=ppp0:: tpas: auth_hand started (pid 19780) Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:: tpas: auth_hnd finished (0) Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:: tpas: result:OKAY S=D00BCA794534EC5AB5EB766E9AFD0B681CEA998E,A=a55b40eb94e2e1b7374b96d443b97397,B=5bc402515bbe524b8d983712821dc3bf Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: send [MSCHAP-v2 Success id=1 "S=D00BCA794534EC5AB5EB766E9AFD0B681CEA998E M=Authentication succeeded"] Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: recv [MSCHAP-v2 Response id=1 <9864eb6874e71568292ed3764e322a8>, <62eb71aa08cf141c9d171c92ae423c08d1822fdcb47f>, F=0, name="Peter Dudas"] Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: tpas: id:1 flags:0x0 reserved:0x33800a93 Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: tpas: auth_hand started (pid 19782) Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: tpas: auth_hnd finished (0) Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: tpas: result:OKAY Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: send [MSCHAP-v2 Failure id=1 "9db289b1154a96a745920f6278d5fbbc M=Access denied"] Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: ppp_terminate Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: lcp_layer_finish Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: send [LCP TermReq id=3] Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: auth_layer_finish Debug 2017-01-05 15:35:27 accel-pppd msg=ppp0:Peter Dudas: auth_layer_finished Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: IPCP: discarding packet Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: IPV6CP: discarding packet Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: recv [LCP TermAck id=3] Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: lcp_layer_finished Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: lcp_layer_free Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: auth_layer_free Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: ccp_layer_free Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: ipcp_layer_free Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: ipv6cp_layer_free Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: ppp destablished Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: l2tp: ppp finished Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: l2tp: terminate (0, 0) Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:Peter Dudas: send [L2TP tid=34 sid=0 Ns=2 Nr=4 <Message-Type Stop-Ctrl-Conn-Notify> <Assigned-Tunnel-ID 1> <Result-Code>] Debug 2017-01-05 15:35:28 accel-pppd msg=ppp0:: disconnected Debug And this is the successful: 2017-01-05 15:34:26 accel-pppd msg=:: recv [L2TP tid=0 sid=0 Ns=0 Nr=0 <Message-Type Start-Ctrl-Conn-Request> <Protocol-Version 256> <Framing-Capabilities 3> <Host-Name Peters-iPad> <Assigned-Tunnel-ID 33> <Recv-Window-Size 4>] Debug 2017-01-05 15:34:26 accel-pppd msg=:: send [L2TP tid=33 sid=0 Ns=0 Nr=1 <Message-Type Start-Ctrl-Conn-Reply> <Protocol-Version 256> <Host-Name POW1> <Framing-Capabilities 3> <Assigned-Tunnel-ID 1> <Vendor-Name accel-ppp>] Debug 2017-01-05 15:34:26 accel-pppd msg=:: recv [L2TP tid=1 sid=0 Ns=1 Nr=1 <Message-Type Start-Ctrl-Conn-Connected>] Debug 2017-01-05 15:34:26 accel-pppd msg=:: recv [L2TP tid=1 sid=0 Ns=2 Nr=1 <Message-Type Incoming-Call-Request> <Assigned-Session-ID 329> <Call-Serial-Number 1>] Debug 2017-01-05 15:34:26 accel-pppd msg=:: send [L2TP tid=33 sid=329 Ns=1 Nr=3 <Message-Type Incoming-Call-Reply> <Assigned-Session-ID 1>] Debug 2017-01-05 15:34:26 accel-pppd msg=:: recv [L2TP tid=1 sid=1 Ns=3 Nr=2 <Message-Type Incoming-Call-Connected> <TX-Speed 1000000> <Framing-Type 3>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: connect: ppp0 <--> l2tp( 89.212.168.xyz) Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: lcp_layer_init Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: auth_layer_init Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: ccp_layer_init Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: ipcp_layer_init Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: ipv6cp_layer_init Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: ppp established Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: lcp_layer_start Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: send [LCP ConfReq id=1 <auth MSCHAP-v2> <magic 68ebc550> <mru 1400>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: send [L2TP tid=33 sid=0 Ns=2 Nr=4] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: recv [LCP ConfReq id=1 < 2 6 0 0 0 0 > <magic 568bf110> <pcomp> <accomp>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: send [LCP ConfRej id=1 < 2 6 0 0 0 0 > <pcomp> <accomp>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: recv [LCP ConfAck id=1 <auth MSCHAP-v2> <magic 68ebc550> <mru 1400>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: recv [LCP ConfReq id=2 <magic 568bf110>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: send [LCP ConfAck id=2 ] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: lcp_layer_started Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: auth_layer_start Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: send [MSCHAP-v2 Challenge id=1 <b8cbbfa020ddad1e20bc4060c7bccfbf>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: recv [LCP EchoReq id=0 <magic 568bf110>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: send [LCP EchoRep id=0 <magic 50c5eb68>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: recv [MSCHAP-v2 Response id=1 <f1b3381d9a30e73a1dbd579844e575d2>, <7371de3c435d275975f17eae3ec9d5755a86207626f6>, F=0, name="Peter Dudas"] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: tpas: id:1 flags:0x0 reserved:0x33800a93 Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: tpas: auth_hand started (pid 19749) Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: tpas: auth_hnd finished (0) Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:: tpas: result:OKAY S=A540183EFBE609F94EAD79D80707C8D5ADC5C03A,A=79ebb8ec3143d8deb34d66dbbd900d88,B=1695340260afd1034cc9289f4535c415 Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: send [MSCHAP-v2 Success id=1 "S=A540183EFBE609F94EAD79D80707C8D5ADC5C03A M=Authentication succeeded"] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: auth_layer_started Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: ccp_layer_start Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: ipcp_layer_start Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: send [IPCP ConfReq id=1 <addr 10.148.76.36>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: ipv6cp_layer_start Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: Peter Dudas: authentication succeeded Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: recv [IPCP ConfReq id=1 <addr 0.0.0.0> <dns1 0.0.0.0> <dns2 0.0.0.0>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: send [IPCP ConfNak id=1 <addr 10.148.76.45> <dns1 10.101.168.3> <dns2 10.101.168.35>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: IPV6CP: discarding packet Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: send [LCP ProtoRej id=3 <8057>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: recv [IPCP ConfAck id=1 <addr 10.148.76.36>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: recv [IPCP ConfReq id=2 <addr 10.148.76.45> <dns1 10.101.168.3> <dns2 10.101.168.35>] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: send [IPCP ConfAck id=2] Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: ipcp_layer_started Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: l2tp: ppp started Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: tpas: ip-up started (pid 19751) Debug 2017-01-05 15:34:26 accel-pppd msg=ppp0:Peter Dudas: tpas: ip-up finished (0) Debug So it looks like a failed MsChapv2 authentication - which does not makes sense... It is the same mschap module with ntlm_auth. Does the challenge/response packets have a timeout? Peter Dudas On 5 January 2017 at 14:14, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
I'm not aware of any timing limitations (as with the SSLVPN I can even wait for 30s using the same 2nd authentication as for L2TP) - the whole chain (firewall-Nps-Freeradius) has minimum 30s timeout configured.
Ok... If 30 seconds is not enough, that is a bit of a concern.
With 'Sleep 3' it is still connected successfully - anything above 3 seconds just makes the L2TP VPN connection unsuccessful. Checked in the firewall - timeout is 90s.
You might want to check what the complete end-to-end timing is...
Stefan Paetow Moonshot Industry & Research Liaison Coordinator
t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet
jisc.ac.uk
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
participants (4)
-
Alan DeKok -
Dudás Péter -
Matthew Newton -
Stefan Paetow