RADIUS message format needed to trigger EAP-TLS/EAP-TTLS negotiation

[Alan DeKok]

On Nov 7, 2018, at 1:54 AM, Joe Garcia <joe27256 at gmail.com> wrote:
> 
> Alan DeKok <aland at deployingradius.com> wrote:
> 
>> If you don't control the server and can't get it's debug output, then you
>> should configure your *own* FreeRADIUS server.  Which you can then control
>> and get debug output for.
> 
> It's a bit more complex than that,

  Not on the RADIUS side.

  If you're being asked to send packets to a RADIUS server, then you can:

a) use espoo_test to test EAP over RADIUS to their RADIUS server

b) set up your own RADIUS server to accept RADIUS packets from any RADIUS client you control

  Between those two options, you should be able to figure out where in the EAP / RADIUS stack the problem lies.

> the embedded device(s) and server
> are on an isolated network and talk DNP3 (a SCADA protocol), so they
> can't easily be redirected to a standard FreeRADIUS server we set up.

  Something needs to send RADIUS packets to the RADIUS server.  This isn't difficult.

  If something is doing EAP, then the EAP packets need to be received by an EAP peer, encapsulated into RADIUS, and then sent to the RADIUS server.

> Without getting into too much boring details, I'm trying to resolve a
> case of two parties pointing fingers at the other side for doing
> things wrong, while operating mostly blindfolded...

  The components and their function can be described in 2-3 sentences, as above.

  It really is that simple.

  Alan DeKok.