EAP-Peap-MSchapv2 proxy from innertunnel
I'm trying to do a proxy from the inner-tunnel over to another radius server. The primary reason for this is that we need to strip off the realm before passing to the proxy. I'm getting an EAP error response from the other server about it not liking the id number "Supplicant sent unmatched EAP response packet identifier" ( This is an EAP-PEAP-MSCHAPv2 scenerio) The EAP.conf file is configured with: proxy_tunneled_request_as_eap = yes I've included a TCP dump of the main freeradius server below WC -- Wireless controller FR-2.10 -- Freeradius server ISE-proxy -- The server FR-2.10 is sending proxy requests to: It does appear that FR-2.10 is beginning a conversation with ISE-proxy and id: 0xde It seem that ISE-proxy responds ok, but then the next message from FR-2.10 to ISE-proxy has id: 0xa8, but I'm thinking that ISE-proxy is expecting 0xdf ?.. I'll admit I'm still pretty confused about much of the EAP, stuff.. but maybe I'm missing something simple in the config ? Any ideas would be greatly appreciated.. Thanks, Robert 07:03:51.286831 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x82 length: 227 07:03:51.287639 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x82 length: 64 07:03:51.289921 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x83 length: 354 07:03:51.300931 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x83 length: 1090 07:03:51.304143 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x84 length: 238 07:03:51.304640 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x84 length: 1086 07:03:51.307583 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x85 length: 238 07:03:51.314568 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x85 length: 1086 07:03:51.317658 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x86 length: 238 07:03:51.324409 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x86 length: 923 07:03:51.335322 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x87 length: 440 07:03:51.337658 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x87 length: 123 07:03:51.339867 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x88 length: 238 07:03:51.344424 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x88 length: 101 07:03:51.346564 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x89 length: 328 --- Begin proxy ? 07:03:51.354527 IP FR-2.10.1814 > ISE-proxy.radius: RADIUS, Access Request (1), id: 0xde length: 246 07:03:51.371848 IP ISE-proxy.radius > FR-2.10.1814: RADIUS, Access Challenge (11), id: 0xde length: 132 07:03:51.372108 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x89 length: 101 07:03:51.374137 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x8a length: 312 07:03:51.384449 IP FR-2.10.1814 > ISE-proxy.radius: RADIUS, Access Request (1), id: 0xa8 length: 306 07:03:51.386386 IP ISE-proxy.radius > FR-2.10.1814: RADIUS, Access Reject (3), id: 0xa8 length: 49 07:03:52.387589 IP FR-2.10.radius > WC.32769: RADIUS, Access Reject (3), id: 0x8a length: 101 --End proxy
On 29/08/13 14:35, Robert Roll wrote:
I'm trying to do a proxy from the inner-tunnel over to another radius server. The primary reason for this is that we need to strip off the realm before passing to the proxy.
I'm getting an EAP error response from the other server about it not liking the id number
"Supplicant sent unmatched EAP response packet identifier"
( This is an EAP-PEAP-MSCHAPv2 scenerio)
The EAP.conf file is configured with:
proxy_tunneled_request_as_eap = yes
I've included a TCP dump of the main freeradius server below
But not a debug gathered with "radiusd -X" which is the only thing anyone ever wants to see.
Ok, Below is the TCP dump. I have attached the Freeradius Debug output beginning near the start of the proxy.. WC -- is the wirless controller (155.99.193.24) FR-2.10 -- Freeradius 2.10 (155.97.182.175) ISE-proxy -- ISE proxy server (155.97.185.76) Again, any help would be much appreciated.. Thanks, Robert 09:31:25.451223 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x72 length: 229 09:31:25.452467 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x72 length: 64 09:31:25.454469 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x73 length: 355 09:31:25.461847 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x73 length: 1090 09:31:25.465436 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x74 length: 239 09:31:25.465779 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x74 length: 1086 09:31:25.469322 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x75 length: 239 09:31:25.469644 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x75 length: 1086 09:31:25.472928 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x76 length: 239 09:31:25.473199 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x76 length: 923 09:31:25.482815 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x77 length: 441 09:31:25.485315 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x77 length: 123 09:31:25.488059 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x78 length: 239 09:31:25.488362 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x78 length: 101 09:31:25.490724 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x79 length: 329 --Begin Proxy 09:31:25.491570 IP FR-2.10.1814 > ISE-proxy.radius: RADIUS, Access Request (1), id: 0xd8 length: 242 09:31:25.497310 IP ISE-proxy.radius > FR-2.10.1814: RADIUS, Access Challenge (11), id: 0xd8 length: 128 09:31:25.497504 IP FR-2.10.radius > WC.32769: RADIUS, Access Challenge (11), id: 0x79 length: 101 09:31:25.499645 IP WC.32769 > FR-2.10.radius: RADIUS, Access Request (1), id: 0x7a length: 313 09:31:25.500528 IP FR-2.10.1814 > ISE-proxy.radius: RADIUS, Access Request (1), id: 0x47 length: 300 09:31:25.502871 IP ISE-proxy.radius > FR-2.10.1814: RADIUS, Access Reject (3), id: 0x47 length: 49 09:31:26.504148 IP FR-2.10.radius > WC.32769: RADIUS, Access Reject (3), id: 0x7a length: 101 ________________________________________ From: freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org] on behalf of Phil Mayers [p.mayers@imperial.ac.uk] Sent: Thursday, August 29, 2013 7:58 AM To: freeradius-users@lists.freeradius.org Subject: Re: EAP-Peap-MSchapv2 proxy from innertunnel On 29/08/13 14:35, Robert Roll wrote:
I'm trying to do a proxy from the inner-tunnel over to another radius server. The primary reason for this is that we need to strip off the realm before passing to the proxy.
I'm getting an EAP error response from the other server about it not liking the id number
"Supplicant sent unmatched EAP response packet identifier"
( This is an EAP-PEAP-MSCHAPv2 scenerio)
The EAP.conf file is configured with:
proxy_tunneled_request_as_eap = yes
I've included a TCP dump of the main freeradius server below
But not a debug gathered with "radiusd -X" which is the only thing anyone ever wants to see. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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.
Phil Mayers wrote:
[peap] Got tunneled request EAP-Message = 0x02090006031a
0x03 == 3 = NAK, 0x1a == 26 == MS-EAP (SoH, I think?)
That's EAP-MSCHAP-v2.
...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.
i.e. set "proxy_tunneled_request_as_eap = no" Alan DeKok.
On 29/08/13 18:16, Alan DeKok wrote:
Phil Mayers wrote:
[peap] Got tunneled request EAP-Message = 0x02090006031a
0x03 == 3 = NAK, 0x1a == 26 == MS-EAP (SoH, I think?)
That's EAP-MSCHAP-v2.
Doh, yes, brain fade. TBH this page could be clearer: http://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml ;o)
On Thu, Aug 29, 2013 at 01:35:25PM +0000, Robert Roll wrote:
I'm getting an EAP error response from the other server about it not liking the id number
"Supplicant sent unmatched EAP response packet identifier"
EAP Response identifier sent by the client has to match EAP Request identifier sent by the server which would be ISE. can you see the EAP-Message AVPs sent and received by freeradius? identifier is the second byte. mk
I guess I assumed the id: in the TCP dump below was the "EAP Response Identifier" maybe not ? Is there a different EAP response identifier ? I actually have been running with debug radius -X. Obviously a lot longer output than just the TCP dump. That is why I first tried just the TCP dump. I guess I was also hoping somebody might have just had a thought about a common configuration issue... I just went back to run another test and the proxy server now seems to be down. This server is run by our network group and I don't know when it might be back.. As soon as it comes back, I will run and capture the debug and see if I can see the EAP-message AVP's ? I will also post the debug Thanks, Robert 07:03:51.354527 IP FR-2.10.1814 > ISE-proxy.radius: RADIUS, Access Request (1), id: 0xde length: 246 07:03:51.371848 IP ISE-proxy.radius > FR-2.10.1814: RADIUS, Access Challenge (11), id: 0xde length: 132 07:03:51.384449 IP FR-2.10.1814 > ISE-proxy.radius: RADIUS, Access Request (1), id: 0xa8 length: 306 07:03:51.386386 IP ISE-proxy.radius > FR-2.10.1814: RADIUS, Access Reject (3), id: 0xa8 length: 49 ________________________________________ From: freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org] on behalf of Martin Kraus [lists_mk@wujiman.net] Sent: Thursday, August 29, 2013 8:11 AM To: FreeRadius users mailing list Subject: Re: EAP-Peap-MSchapv2 proxy from innertunnel On Thu, Aug 29, 2013 at 01:35:25PM +0000, Robert Roll wrote:
I'm getting an EAP error response from the other server about it not liking the id number
"Supplicant sent unmatched EAP response packet identifier"
EAP Response identifier sent by the client has to match EAP Request identifier sent by the server which would be ISE. can you see the EAP-Message AVPs sent and received by freeradius? identifier is the second byte. mk - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thu, Aug 29, 2013 at 02:56:44PM +0000, Robert Roll wrote:
I guess I assumed the id: in the TCP dump below was the "EAP Response Identifier" maybe not ? Is there a different EAP response identifier ?
That is the id of the radius packet. EAP lives insided radius packet AVPs called EAP-Message. You can see the AVPs when you run tcpdump -vv. What is worth noting is that radius Access-Request carries EAP-Response from the client to the server and Access-Challenge carries EAP-Request from the server to the client. mk
On 29/08/13 15:56, Robert Roll wrote:
I guess I assumed the id: in the TCP dump below was the "EAP Response Identifier" maybe not ? Is there a different EAP response identifier ?
Yes, in the EAP-Message attribute (EAP packet)
I actually have been running with debug radius -X. Obviously a lot longer output than just the TCP dump. That is why I first tried just the TCP dump. I guess I was also hoping somebody might have just had a thought about a common configuration issue...
TBH proxying EAP inner is not common at all; there have been bugs in that area in the past. Re-reading I notice that you're running 2.10 - upgrade. I'm pretty certain that version has inner-eap proxy bugs. Go to 2.2.0.
Ok, I've tried this with 2.2 and still get the same behavior.. If I actually look at the proxy-inner-tunnel I see the following for post-proxy.. post-proxy { # # This is necessary for LEAP, or if you set: # # proxy_tunneled_request_as_eap = no # eap I see that eap needs be invoked if using proxy_tunneled_request_as_eap = no Does it actually need to NOT be there for proxy_tunneled_request_as_eap = no I should say I'm actually NOT using the proxy-inner-tunnel server, but rather the default inner-tunnl with: # If you want the inner tunnel request to be proxied, delete # the next few lines. # # update control { # Proxy-To-Realm := LOCAL # } Thanks, Robert ________________________________________ From: freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org] on behalf of Phil Mayers [p.mayers@imperial.ac.uk] Sent: Thursday, August 29, 2013 9:38 AM To: freeradius-users@lists.freeradius.org Subject: Re: EAP-Peap-MSchapv2 proxy from innertunnel On 29/08/13 15:56, Robert Roll wrote:
I guess I assumed the id: in the TCP dump below was the "EAP Response Identifier" maybe not ? Is there a different EAP response identifier ?
Yes, in the EAP-Message attribute (EAP packet)
I actually have been running with debug radius -X. Obviously a lot longer output than just the TCP dump. That is why I first tried just the TCP dump. I guess I was also hoping somebody might have just had a thought about a common configuration issue...
TBH proxying EAP inner is not common at all; there have been bugs in that area in the past. Re-reading I notice that you're running 2.10 - upgrade. I'm pretty certain that version has inner-eap proxy bugs. Go to 2.2.0. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Robert Roll wrote:
If I actually look at the proxy-inner-tunnel I see the following for post-proxy..
The post-proxy stage has NOTHING to do with the home server. If the home server rejects the request, the issue is WAY before the post-process stage.
I see that eap needs be invoked if using
proxy_tunneled_request_as_eap = no
Does it actually need to NOT be there for
proxy_tunneled_request_as_eap = no
No. See my reply to Phil. You need to set: proxy_tunneled_request_as_eap = no in eap.conf, peap{} subsection. Alan DeKok.
participants (4)
-
Alan DeKok -
Martin Kraus -
Phil Mayers -
Robert Roll