On 29/08/13 17:01, Robert Roll wrote:
Ok, Below is the TCP dump. I have attached the Freeradius Debug output beginning
near the start of the proxy..
The problem here is pretty straightforward, but not obvious from the
debugs since FR is just proxying.
Basically, the client sends the inner EAP-identity, and the proxy server
responds with an EAP-TLS start i.e. you would be doing EAP-TLS inside
PEAP, if this worked:
rad_recv: Access-Challenge packet from host 155.97.185.76 port 1812,
id=216, length=128
State = ...
Proxy-State = 0x313231
EAP-Message = 0x010900060d20
0x0d == 13 == EAP-TLS. This is encrypted and sent down the tunnel. The
client then sends an EAP-NAK, listing 26 as the only supported EAP type
(which is weird - is it a Windows machines set to some odd combo like
cryptobinding enabled?):
[peap] Got tunneled request
EAP-Message = 0x02090006031a
0x03 == 3 = NAK, 0x1a == 26 == MS-EAP (SoH, I think?)
...which the proxy server then rejects:
rad_recv: Access-Reject packet from host 155.97.185.76 port 1812, id=71,
length=49
Proxy-State = 0x313232
EAP-Message = 0x04090004
So the solution is simple - if you're going to proxy the inner auth,
ensure the client inner auth method and upstream proxy auth method are
mutually compatible.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
