Proxying inner requests from EAP-TTLS
Hi, I'm currently working on a test setup for a study thesis. The goal is to use wired 802.1X and EAP-TTLS with a local AAA server which proxies the tunneled requests to the appropriate home servers. My problem right now is that I can't get freeradius to proxy the inner requests. The TTLS tunnel is successfully established and the inner request is sent to the virtual server. Freeradius recognizes that the inner request should be proxied but it says that it can't create a new socket. So my question is: Can requests in virtual servers be proxied at all or is there another way to do it? The version of freeradius is 2.1.9. The configuration on the local AAA server is: default site ------------ authorize { preprocess eap { ok = return } files } authenticate { eap } inner tunnel ------------ authorize { suffix eap { ok = return } files } authenticate { eap } proxy.conf ---------- home_server homeaaa { type = auth ipaddr = 10.10.0.22 port = 1812 secret = proxy require_message_authenticator = no response_window = 20 zombie_period = 40 revive_interval = 120 status_check = status-server check_interval = 30 num_answers_to_alive = 3 } home_server_pool aaa_pool { type = fail-over home_server = homeaaa } realm home { auth_pool = aaa_pool nostrip } The debug output: rad_recv: Access-Request packet from host 10.10.0.23 port 1645, id=12, length=254 User-Name = "anonymous@home" Service-Type = Framed-User Framed-MTU = 1504 Called-Station-Id = "00-16-C8-3D-1B-82" Calling-Station-Id = "00-1B-21-15-CF-1D" EAP-Message = 0x0207007015001703010020ffce9586905dafa8df6d7678d778ba49cf74ac059e4004604191a70b751841dd17030100400c32774ceaefd6d1544bc87a2bd47567e17f03976be24ebcd64faa95186efea24064f53563b55a98fb7469f9a83d191d15306fde31d0229d55fa27816cf55dfa Message-Authenticator = 0x6a3417e727dc739f3e989254b644b56f NAS-Port-Type = Ethernet NAS-Port = 50002 State = 0x47887413438f612a688db3fc6f33d684 NAS-IP-Address = 10.10.0.23 +- entering group authorize {...} ++[preprocess] returns ok [eap] EAP packet type response id 7 length 112 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] eaptls_verify returned 7 [ttls] Done initial handshake [ttls] eaptls_process returned 7 [ttls] Session established. Proceeding to decode tunneled attributes. [ttls] Got tunneled request EAP-Message = 0x0200000e0164656d6f40686f6d65 FreeRADIUS-Proxied-To = 127.0.0.1 [ttls] Got tunneled identity of demo@home [ttls] Setting default EAP type for tunneled EAP session. [ttls] Sending tunneled request EAP-Message = 0x0200000e0164656d6f40686f6d65 FreeRADIUS-Proxied-To = 127.0.0.1 User-Name = "demo@home" server inner-tunnel { +- entering group authorize {...} [suffix] Looking up realm "home" for User-Name = "demo@home" [suffix] Found realm "home" [suffix] Adding Realm = "home" [suffix] Proxying request from user demo to realm home [suffix] Preparing to proxy authentication request to realm "home" ++[suffix] returns updated [eap] Request is supposed to be proxied to Realm home. Not doing EAP. ++[eap] returns noop ++[files] returns noop } # server inner-tunnel [ttls] Got tunneled reply code 0 [ttls] Tunneled authentication will be proxied to home [eap] Tunneled session will be proxied. Not doing EAP. ++[eap] returns handled +- entering group pre-proxy {...} [pre_proxy_log] expand: /usr/local/radius/2.1.9/var/log/radius/radacct/%{Client-IP-Address}/pre-proxy-detail-%Y%m%d -> /usr/local/radius/2.1.9/var/log/radius/radacct/10.10.0.23/pre-proxy-detail-20100607 [pre_proxy_log] /usr/local/radius/2.1.9/var/log/radius/radacct/%{Client-IP-Address}/pre-proxy-detail-%Y%m%d expands to /usr/local/radius/2.1.9/var/log/radius/radacct/10.10.0.23/pre-proxy-detail-20100607 [pre_proxy_log] expand: %t -> Mon Jun 7 18:22:01 2010 ++[pre_proxy_log] returns ok Failed to create a new socket for proxying requests. ERROR: Failed inserting request into proxy hash. ERROR: Failed to proxy request 5 There was no response configured: rejecting request 5 Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> anonymous@home attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 5 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 5 Sending Access-Reject of id 12 to 10.10.0.23 port 1645 Waking up in 3.8 seconds. Cleaning up request 0 ID 7 with timestamp +32 Cleaning up request 1 ID 8 with timestamp +32 Cleaning up request 2 ID 9 with timestamp +32 Cleaning up request 3 ID 10 with timestamp +32 Cleaning up request 4 ID 11 with timestamp +32 Waking up in 1.0 seconds. Cleaning up request 5 ID 12 with timestamp +32 rlm_eap_ttls: Freeing handler for user demo@home Ready to process requests. If I read the code correctly, the problem should originate in listen.c in function rad_listen_t *proxy_new_listener(fr_ipaddr_t *ipaddr, int exists) I hope that I included all the neccessary information. Kind regards, Martin
Martin Merkel wrote:
Hi,
I'm currently working on a test setup for a study thesis. The goal is to use wired 802.1X and EAP-TTLS with a local AAA server which proxies the tunneled requests to the appropriate home servers. My problem right now is that I can't get freeradius to proxy the inner requests. The TTLS tunnel is successfully established and the inner request is sent to the virtual server. Freeradius recognizes that the inner request should be proxied but it says that it can't create a new socket. So my question is: Can requests in virtual servers be proxied at all or is there another way to do it?
It should work.
The version of freeradius is 2.1.9.
Hmm... that error was reported in older versions of the server, but it *should* work in 2.1.9. Ugh on quick inspection, no, it doesn't.
If I read the code correctly, the problem should originate in listen.c in function
rad_listen_t *proxy_new_listener(fr_ipaddr_t *ipaddr, int exists)
Yes.
I hope that I included all the neccessary information.
Yes. See the 'v2.1.x' branch on git.freeradius.org for a fix. Alan DeKok.
Am 07.06.2010 23:28, schrieb Alan DeKok:
See the 'v2.1.x' branch on git.freeradius.org for a fix.
Thank you, Alan, for your quick reply and fix. I compiled the latest version with your modifications, but unfortunately it still doesn't work. The error message changed to: WARNING: No previous template for proxy socket. Source IP address may be chosen by the OS Failed binding to proxy address 10.10.0.23 port 0: Cannot assign requested address Failed binding to new proxy socket Failed to create a new socket for proxying requests. ERROR: Failed inserting request into proxy hash. ERROR: Failed to proxy request 5 I tried adding a "listen { type=proxy }" block in radiusd.conf and setting the src_ipaddr in proxy.conf. Neither changed the output. What I just noticed is that 10.10.0.23 is the ip address of the switch where the request is coming from. Of course it can't bind to that address. Something is wrong there. The setup looks like this: - local AAA: 10.10.0.21 - home AAA: 10.10.0.22 - switch: 10.10.0.23 The only occurence of 10.10.0.23 in my config is in clients.conf: localaaa:/usr/local/radius/2.1.x/etc/raddb# grep -r 10.10.0.23 . ./clients.conf: ipaddr = 10.10.0.23 localaaa:/usr/local/radius/2.1.x/etc/raddb# Kind regards, Martin
Martin Merkel wrote:
Am 07.06.2010 23:28, schrieb Alan DeKok:
See the 'v2.1.x' branch on git.freeradius.org for a fix.
Thank you, Alan, for your quick reply and fix. I compiled the latest version with your modifications, but unfortunately it still doesn't work.
OK. A bit more investigation, and an updated fix is in the v2.1.x branch. Alan DeKok.
participants (2)
-
Alan DeKok -
Martin Merkel