User + Device Authentication to Specific Network

[Alan DeKok]

On Jun 10, 2019, at 10:59 AM, Duncan X Simpson <virtualdxs at gmail.com> wrote:
> Yep, I double checked that. I was worried that case could be a problem, or a typo, but it's there:
> 
>         (10) Received Access-Request Id 165 from 174.79.36.24:51183 to 192.168.5.51:1812 length 261
>         (10)   User-Name = "duncan"
>         (10)   NAS-Identifier = "802AA8834B4728077AE8"
>         (10)   Called-Station-Id = "A2-2A-A8-85-4B-47:802.1X test"
>         (10)   NAS-Port-Type = Wireless-802.11
>         (10)   Service-Type = Framed-User
>         (10)   Calling-Station-Id = "10-98-C3-A9-2C-D4"

  Read the *rest* of the debug output.

> >   Post the WHOLE debug output, and let someone else explain it.
> 
> https://pastebin.com/3bXzp79D

  Which shows you're running EAP.  Which would have been good to know.

> >   But odds are that the Service-Type attribute isn't in the request.  There isn't a lot that can go wrong here.
> 
> See above.

  Again, *read* the debug output.  ALL OF IT.  If it's hard to read, see:

	http://wiki.freeradius.org/radiusd-X

  You're doing EAP.  And running the "inner-tunnel" virtual server.  Which DOES show the request it receives.  AND it shows that request doesn't contain Calling-Station-Id.

  The relevant lines are below:

(9) eap_peap:   State = 0x7d495cdf7c54466d1d9baad7442a1d1a
(9) Virtual server inner-tunnel received request
(9)   EAP-Message = 0x021d00061a03
(9)   FreeRADIUS-Proxied-To = 127.0.0.1
(9)   User-Name = "duncan"
(9)   State = 0x7d495cdf7c54466d1d9baad7442a1d1a
(9) WARNING: Outer and inner identities are the same.  User privacy is compromised.
(9) server inner-tunnel {
(9)   session-state: No cached attributes
(9)   # Executing section authorize from file /etc/raddb/sites-enabled/inner-tunnel

  See?  No Calling-Station-Id in the inner tunnel.

  Then later in the same packet, you do:

(9)       update reply {
(9)         EXPAND %{request:Calling-Station-Id}
(9)            -->
(9)         Unix-FTP-Shell :=
(9)       } # update reply = noop

  Which makes sense.

  If you want to access the *outer* Calling-Station-ID attribute, you can do %{outer.request:Calling-Station-Id}.  See "man unlang" for details.

  The debug output is large and complex, but it is *all* there for a reason.  If you carefully read it, it will answer most of your questions.

  In this case:

* the update Unix-FTP-Shell is happening in packet (9), so looking at packet (10) is a waste of time
* once you see the update Unix-FTP-Shell happening, look BACKWARDS in the debug output to see the "received request" line
* which then shows you what packet is being received
* AND where that packet came from

  Alan DeKok.