FreeRADIUS 3.x package is here! Feedback, please
-
Very good. Glad I didn't miss a step.
FreeRADIUS settings are lower-case, i.e. ab-cd-ef-01-02-03.
pfSense Packet capture: AP>pfSense (FreeRADIUS2):
Username: e4ce8fxxxxxx
Password: 8e5e8b82…....
Called-Station-ID: 00-20-A6-XX-XX-XX
Calling-Station-ID: E4-CE-8F-XX-XX-XX
Message Authenticator: f8e5ecbd......The response, RADIUS>AP is Access-Accept with the Authenticator in all CAPS, and life goes on.
I'll revert back to v3 and repeat the capture a little later and post. Too much going on in the network at the moment.
Curious if formatting is the issue as there are formatting "normalization" routines at work here within the configuration scripts. Or are you referring to the bowels of the implementation?
-
Curious if formatting is the issue as there are formatting "normalization" routines at work here within the configuration scripts. Or are you referring to the bowels of the implementation?
Assuming the normalization is kicking in like it's supposed to… There is a policy in place that should be shifting the Calling-Station-ID to lowercase, but whether or not it's actually happening for your config is another question.
-
There are no differences between the captures, FreeRADIUSv2 versus v3. Everything on the wire is the same, with the exception of the RADIUS response for v3.
v2: Access-Accept
v3: Access-RejectEnvironment:
VMware ESXi 5.5
PfSense 2.3.4_1No hardware, application or environmental differences between the snapshots I am testing, with the exception of FreeRADIUSv2 versus v3
Uninstall v3. Re-install v3. No joy.
Restart radiusd. No joy.
Reboot pfSense. No joy.
Reboot workstation. No joy.
Reboot AP. No joy.Full capture v3:
14:03:37.079733 PROXIM AP > PFSENSE, ethertype IPv4 (0x0800), length 180: (tos 0x0, ttl 64, id 50596, offset 0, flags [none], proto UDP (17), length 166)
172.29.10.61.33996 > 172.29.10.1.1812: [udp sum ok] RADIUS, length: 138
Access Request (1), id: 0x0e, Authenticator: a4b81d694ec4f…............
Username Attribute (1), length: 14, Value: 44d884xxxxxx
0x0000: 3434 6438 3834 ......
Password Attribute (2), length: 18, Value:
0x0000: bd58 76d8 2e10 0ea9 .............
Called Station Attribute (30), length: 19, Value: 00-20-A6-XX-XX-XX
0x0000: 3030 2d32 302d 4136 .........
0x0010: 38
NAS Port Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11
0x0000: 0000 .......
Calling Station Attribute (31), length: 19, Value: 44-D8-84-XX-XX-XX
0x0000: 3434 2d44 382d 3834 ......
0x0010: 39
Connect Info Attribute (77), length: 24, Value: CONNECT 11Mbps 802.11b
0x0000: 434f 4e4e 4543 5420 .......
0x0010: 3032 2e31 ......
Message Authentication Attribute (80), length: 18, Value: ?. 0x0000: 3f95 3c21 3291 d6c7 .............
14:03:38.088976 PFSENSE > PROXIM AP, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 25537, offset 0, flags [none], proto UDP (17), length 48)
172.29.10.1.1812 > 172.29.10.61.33996: [bad udp cksum 0x6ca6 -> 0x7be5!] RADIUS, length: 20
Access Reject (3), id: 0x0e, Authenticator: 2a3e41ab58ca2b53…..........Full capture v2:
14:22:24.796839 PROXIM AP > PFSENSE, ethertype IPv4 (0x0800), length 180: (tos 0x0, ttl 64, id 50598, offset 0, flags [none], proto UDP (17), length 166)
172.29.10.61.33996 > 172.29.10.1.1812: [udp sum ok] RADIUS, length: 138
Access Request (1), id: 0x10, Authenticator: 2afd1eec286178d3d…............
Username Attribute (1), length: 14, Value: 44d884xxxxxx
0x0000: 3434 6438 3834 ...........
Password Attribute (2), length: 18, Value:
0x0000: 4bde 25e9 aa8c 15fa ................
Called Station Attribute (30), length: 19, Value: 00-20-A6-XX-XX-XX
0x0000: 3030 2d32 302d 4136 .............
0x0010: 38
NAS Port Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11
0x0000: 0000 .....
Calling Station Attribute (31), length: 19, Value: 44-D8-84-XX-XX-XX
0x0000: 3434 2d44 382d 3834 .............
0x0010: 39
Connect Info Attribute (77), length: 24, Value: CONNECT 11Mbps 802.11b
0x0000: 434f 4e4e 4543 5420 .............
0x0010: 3032 ..........
Message Authentication Attribute (80), length: 18, Value: ...B.....a.`.4..
0x0000: f2cf de42 ecd0 8a95 fe61 ...........
14:22:24.820913 PFSENSE > PROXIM AP, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 10718, offset 0, flags [none], proto UDP (17), length 48)
172.29.10.1.1812 > 172.29.10.61.33996: [bad udp cksum 0x6ca6 -> 0x5db7!] RADIUS, length: 20
Access Accept (2), id: 0x10, Authenticator: e5ff69f36735f1c8…............ -
Did you try changing your MAC in the user records or MACs tab to upper case instead of lower case?
-
Yes, lower case, ab-cd-ef-01-23-45, does not work for v3 MacAuth, but UPPERCASE MACs, AB-CD-EF-01-23-45, does work with v3 MacAuth.
Thanks for your help!
-
- authentication method: Google Authenticator
- init secret: 16 character long base32 encoded string. (used the same string as above)
- pin: 4 digit numeric pin
User-Password: PIN+OTP code. So in case the PIN was 1234 and 'Google Authenticator' app generated 564782, then 1234564782
[…]
So the key: password is the PIN+OTP.I added some notes to the FreeRADIUS 3 GUI to make this more clear. I also added a button to generate an OTP secret automatically of the correct type for the selected OTP method. So mOTP will generate one in hex (0-9,a-f) and GA will generate one in base32 (A-Z,2-7). I also added buttons to show the secret and PIN so they can stay obscured on the screen unless you want to see them. The secret is automatically displayed when generating a random one, otherwise you'd have no way to view it :-)
I'm also tinkering with a QR code generator for GA, we'll see how that goes tomorrow if I have time.
-
0.12 has a QR Code generator for Google Authenticator and also has some more improvements to the field notes for OTP in general.
-
Yes, lower case, ab-cd-ef-01-23-45, does not work for v3 MacAuth, but UPPERCASE MACs, AB-CD-EF-01-23-45, does work with v3 MacAuth.
Thanks for your help!
I found a problem in the code that writes out the policy files which may have prevented our MAC address normalization from working. Once you update to version 0.13 of the package, please try again with lowercase MAC addresses.
-
0.12 has a QR Code generator for Google Authenticator and also has some more improvements to the field notes for OTP in general.
Just updated to rel. 0.10, Google Authenticator now works great!
Aug 30 00:00:53 radiusd 29529 (0) Login OK: [GOTPTest] (from client apcups port 2) GOOGLEAUTH Aug 30 00:00:53 googleauth.py freeRADIUS: Google Authenticator - Authentication successful for user: GOTPTestalso using "Authy" app!
Well done!! ;D
-
0.12 has a QR Code generator for Google Authenticator and also has some more improvements to the field notes for OTP in general.
Now I'm on 0.13
Seems there is and issue related to QRCODE, It is't recognised by Google Auth. app (and neither by Authy app).
Decoding the qrcode into the string results in this :
otpauth://totp/FreeRADIUS:test_user?secret=ESMN3WTED43NGZ5Z&issuer=FreeRADIUS
where ESMN3WTED43NGZ5Z is correct, It's my Init-Secretps: to generate the qrcode for a new user on FreeRADIUS: Users/Edit/Users you must first create the user, save, then re-open.
 -
It works for me on the GA app, probably the username needs run through urlencode(), maybe that _ is throwing it off.
And you do not have to save a user before it will generate a QR code. Just click the button and it pulls the field values using JavaScript, it doesn't use PHP or anything that loads on save/edit.
-
Actually no, the _ is fine. That same user combination works for me here with the GA app. I copied your secret and username and used them and the resulting QR code worked for me, too, with the code in 0.13. I even scanned your barcode and it worked, too.
I'll add some encoding to be safe, but it doesn't seem to be needed.
-
Works fine here as well.
-
It works for me on the GA app, probably the username needs run through urlencode(), maybe that _ is throwing it off.
And you do not have to save a user before it will generate a QR code. Just click the button and it pulls the field values using JavaScript, it doesn't use PHP or anything that loads on save/edit.
After a lot of tests (using firefox 55.0.3 and ie11, same results) my conclusion is that this issue (Google's Authenticator app doesn't catch the code on the screen) seems to be related to the browser graphic render /antialiasing.
If I save the qr code pic as a file (it's a png pic) and then I open it outside the browser (in the same identical resolution and size) zac! It's catched immediately and recognized. -
you do not have to save a user before it will generate a QR code. Just click the button and it pulls the field values using JavaScript, it doesn't use PHP or anything that loads on save/edit.
On firefox (55.0.3 64bit) I need to save and re-open,
On IE (11) no need to save and re-openMaybe It's related to the fact that on firefox, from rel. 52, the java plugin was dropped?
-
Small typo:
QR Code
Goolge Authenticator supports adding entries via QR Code. Click the button below to generate a QR Code based on the current settings above when Google Authenticator is active. The image can be saved and shown to a user, but treat it as a secure piece of information and do not send it through an insecure channel such as e-mail.
-
The QR Code works for others, so it must still be something local to you on your workstation or your browser environment. There is nothing to make it fail before saving. There is no bug there or anything to solve.
The typo is fixed, it will come in whatever version gets pushed next, didn't warrant a bump just for that.
-
Someone broke the package…
/usr/local/etc/raddb/policy.d/pfs_custom_policies[2]: Reference "${policy.mac-addr-regexp}" not found /usr/local/etc/raddb/policy.d/pfs_custom_policies[2]: Parse error expanding ${...} in conditionThis should fix the breakage and also the policy: https://github.com/pfsense/FreeBSD-ports/pull/412
-
The QR Code works for others, so it must still be something local to you on your workstation or your browser environment. There is nothing to make it fail before saving. There is no bug there or anything to solve.
The typo is fixed, it will come in whatever version gets pushed next, didn't warrant a bump just for that.
Yes, I agree, definetely It isn't properly a pfsense issue but… one last thing...
Now I changed pfsense theme from "dark beta" (grey background) to the standard (white background) and... no more issue in reading qr codes...
perhaps the gray backgrond color interfere in some way,
there are many components, the monitor type and resolution, the smartphone optic and image sensor... anyway now It works...
maybe will be useful for other users ;) -
Someone broke the package…
/usr/local/etc/raddb/policy.d/pfs_custom_policies[2]: Reference "${policy.mac-addr-regexp}" not found /usr/local/etc/raddb/policy.d/pfs_custom_policies[2]: Parse error expanding ${...} in conditionThis should fix the breakage and also the policy: https://github.com/pfsense/FreeBSD-ports/pull/412
That would be me. Though the syntax I used was the same as what was in the stock policy to rewrite MACs. Odd. Anyhow, I merged your version. Hopefully that fixes it for good.
