Well, I updated the certificates on the end-point RADIUS server, and I made
sure to uncomment out the section of the eapol_test config file to include
the same ca.pem file that the RADIUS server uses.
When running the eapol_test setup from the end-point RADIUS server,
everything says success. The certificate is approved, and the MPPE keys
are declared OK.
However, when I run the test from the initial RADIUS server where the relay
will occur, the certificates are declared good, but the MPPE keys are still
mismatched.
...
RADIUS packet matching with station
MS-MPPE-Send-Key (sign) - hexdump(len=32): 02 05 ad fc 4e 86 a3 d6 1f f6 ca
af 00 b9 ee 5f f7 6f e5 60 4f 78 70 c8 88 da 22 7b 44 56 51 03
MS-MPPE-Recv-Key (crypt) - hexdump(len=32): 64 bc 06 07 41 ec bf 15 3e dc
14 9d 9b 8d 2a 28 75 a8 26 70 dd 23 4b e9 7b 0d 94 1f 34 af f1 20
Decapsulated EAP packet - hexdump(len=17): 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
decapsulated EAP packet (code=0 id=0 len=0) from RADIUS server: unknown EAP
code
EAPOL: Received EAP-Packet frame
EAPOL: SUPP_BE entering state REQUEST
EAPOL: getSuppRsp
EAP: EAP entering state RECEIVED
EAP: Ignored EAP-Packet with unknown code 0
EAP: EAP entering state DISCARD
EAP: EAP entering state IDLE
EAPOL: SUPP_BE entering state RECEIVE
EAPOL: startWhen --> 0
EAPOL test timed out
EAPOL: EAP key not available
EAPOL: EAP Session-Id not available
WPA: Clear old PMK and PTK
EAP: deinitialize previously used EAP method (25, PEAP) at EAP deinit
ENGINE: engine deinit
MPPE keys OK: 0 mismatch: 1
FAILURE
What would it be about the relay that is interfering?
Thanks,
Joshua Nathan
Level 3 IT Support and Development
Black Forest Academy
+49 (0) 7626-9161-630
On Tue, Apr 12, 2016 at 10:19 AM, Nathan, Josh <[email protected]>
wrote:
> OK, that makes sense. I thought all communication was happening between
> the client and the PF server, and then the PF server (RADIUS) was then
> establishing a separate connection to defer to the other server rather than
> just tunnelling the connection.
>
> OK, well... I had originally setup a separate RADIUS server because it
> looks like the PF RADIUS instance is linked to the PF database. The
> problem with that, is that I don't see a way to establish the NT Hash on
> the passwords. I'd at least rather not store them plain-text. So I was
> left with using either plaintext or setting up a separate server for
> handling credentials.
>
> Thanks,
> Joshua Nathan
> Level 3 IT Support and Development
> Black Forest Academy
> +49 (0) 7626-9161-630
>
>
> On Mon, Apr 11, 2016 at 7:18 PM, Louis Munro <[email protected]> wrote:
>
>> Hi Nathan,
>>
>> On Apr 11, 2016, at 10:21 , Nathan, Josh <[email protected]> wrote
>>
>>
>> As a side note, I am actually forwarding credentials to another radius
>> server to actually handle the authentication, as you'll see in the logs. I
>> did bold within the RADIUS logs where it is showing the default SSL cert
>> even though I have replaced the references to it in the eap.conf file with
>> new certs that actually have legitimate information.
>>
>>
>> Pretty big side note actually.
>>
>> If you are proxying authentication somewhere else, the certificate you
>> are seeing is coming from that server, not the PacketFence one.
>> Think about it: the cert comes from wherever the TLS tunnel terminates,
>> not anywhere else along the way.
>>
>>
>>
>> While that certification reference bothers me, it still looks like the
>> eapol_test is actually successful. Am I wrong?
>>
>>
>> Yes and no.
>> It looks to me like the server accepted the authentication but
>> eapol_rejected the reply because of a mismatch in the MPPE keys.
>>
>> Note that the FreeRADIUS debugging output is not going to allow you to
>> see what is going on between the supplicant and the radius server where the
>> request is proxied.
>> That data is encrypted between the supplicant and the (proxied-to) radius
>> server.
>>
>> So your certificate issues cannot be resolved by editing eap.conf on the
>> PacketFence server.
>> Have a look a the config of the other server.
>>
>> Or, you could just authenticate from the PacketFence server ;-)
>>
>> Regards,
>> --
>> Louis Munro
>> [email protected] :: www.inverse.ca
>> +1.514.447.4918 x125 :: +1 (866) 353-6153 x125
>> Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (
>> www.packetfence.org)
>>
>>
>> ------------------------------------------------------------------------------
>> Find and fix application performance issues faster with Applications
>> Manager
>> Applications Manager provides deep performance insights into multiple
>> tiers of
>> your business applications. It resolves application problems quickly and
>> reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
>> gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
>> <http://pubads.g.doubleclick.net/gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532>
>> _______________________________________________
>> PacketFence-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>
>>
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
