What proxy features does the freeradius server support?
Hello, I want to implement the following proxy scenario: 1. User send request with eap-ttls or eap-tls or peap-mschapv2. 2. Proxy freeradius server analyze this requeset 3. If username from these request has custom radius attribute which determines whether the request should be sent to. 4. Send original or new request with the same type as original, to the home server 5. If home server return Accept, Accept- user, if no - reject. And I want to know is this possible or not ? If yes please give me some example. The protocols are eap-tls; eap-ttls; peap-mschapv2;
On Oct 19, 2017, at 2:23 PM, work vlpl <thework.vlpl@gmail.com> wrote:
Hello, I want to implement the following proxy scenario:
1. User send request with eap-ttls or eap-tls or peap-mschapv2. 2. Proxy freeradius server analyze this requeset 3. If username from these request has custom radius attribute which determines whether the request should be sent to.
If the request has a custom attribute, then it doesn't matter what EAP type is being used.
4. Send original or new request with the same type as original, to the home server
The server proxies packets as-is. It doesn't change EAP types.
5. If home server return Accept, Accept- user, if no - reject.
That's how proxying works.
And I want to know is this possible or not ? If yes please give me some example. The protocols are eap-tls; eap-ttls; peap-mschapv2;
It's not clear exactly what you're looking for. If you want to proxy on a RADIUS attribute such as Calling-Station-Id, just do: if (Calling-Station-ID == "value") { update control { Proxy-To-Realm := "realm_name" } } That's really it. All of this is documented. Alan DeKok.
On the step 2 and 3, when proxy radius server analyze username, I want to analyze real username, not the outer anonymous identity. To do that I handle eap message on proxy radius server. Then, if username not belongs to certain group I handle request on proxy server without calling home server. If username belongs to a certain group I set Proxy-To-Realm attribute. And here I have an issue. If request is peap-mschapv2 and I set proxy_tunneled_request_as_eap = yes, home radius server(freeradius v3.0.x branch) not understand eap message, if proxy_tunneled_request_as_eap = no home radius server have not problem to understand mschapv2 request. If request eap-ttls, ttls section in eap module config does not have option `proxy_tunneled_request_as_eap` and request on home server will be mschapv2. And I could not configure proxy server to send request after it look inside eap-tls request. Home server inform what eap message has a wrong state. So user request to proxy server is secured with eap, but proxy request to home server is send as simple mschapv2 without eap. And I want to know is it possible to send request as eap to home server, after proxy server handle (look inside) it? On 20 October 2017 at 00:28, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 19, 2017, at 2:23 PM, work vlpl <thework.vlpl@gmail.com> wrote:
Hello, I want to implement the following proxy scenario:
1. User send request with eap-ttls or eap-tls or peap-mschapv2. 2. Proxy freeradius server analyze this requeset 3. If username from these request has custom radius attribute which determines whether the request should be sent to.
If the request has a custom attribute, then it doesn't matter what EAP type is being used.
4. Send original or new request with the same type as original, to the home server
The server proxies packets as-is. It doesn't change EAP types.
5. If home server return Accept, Accept- user, if no - reject.
That's how proxying works.
And I want to know is this possible or not ? If yes please give me some example. The protocols are eap-tls; eap-ttls; peap-mschapv2;
It's not clear exactly what you're looking for. If you want to proxy on a RADIUS attribute such as Calling-Station-Id, just do:
if (Calling-Station-ID == "value") { update control { Proxy-To-Realm := "realm_name" } }
That's really it.
All of this is documented.
Alan DeKok.
On Oct 19, 2017, at 11:19 PM, work vlpl <thework.vlpl@gmail.com> wrote:
On the step 2 and 3, when proxy radius server analyze username, I want to analyze real username, not the outer anonymous identity. To do that I handle eap message on proxy radius server.
The RADIUS server has to do EAP. The "real" username is available only in the inner-tunnel.
Then, if username not belongs to certain group I handle request on proxy server without calling home server. If username belongs to a certain group I set Proxy-To-Realm attribute. And here I have an issue.
You can't do EAP on the server, *and* proxy EAP to another server. It's impossible. You *can* proxy the inner-tunnel session. But you also need to do it for all of the packets. You can't do EAP and also proxy, even inside of the inner-tunnel.
If request is peap-mschapv2 and I set proxy_tunneled_request_as_eap = yes, home radius server(freeradius v3.0.x branch) not understand eap message,
Then read *that* debug output to see what's going on. FreeRADIUS *can* proxy inner EAP methods. It *can* also act as a home server for those proxied requests.
if proxy_tunneled_request_as_eap = no home radius server have not problem to understand mschapv2 request. If request eap-ttls, ttls section in eap module config does not have option `proxy_tunneled_request_as_eap` and request on home server will be mschapv2.
That's fine.
And I could not configure proxy server to send request after it look inside eap-tls request. Home server inform what eap message has a wrong state.
Posting debug output would be more useful than posting vague descriptions.
So user request to proxy server is secured with eap, but proxy request to home server is send as simple mschapv2 without eap. And I want to know is it possible to send request as eap to home server, after proxy server handle (look inside) it?
No. You can (a) process EAP at a server, or (b) proxy it. You can't do both. Alan DeKok.
Thank you for your answers, you help a lot, could you answer a couple more questions? On 20 October 2017 at 16:56, Alan DeKok <aland@deployingradius.com> wrote:
If request is peap-mschapv2 and I set proxy_tunneled_request_as_eap = yes, home radius server(fremypythonmoduleius v3.0.x branch) not understand eap message,
Then read *that* debug output to see what's going on. FreeRADIUS *can* proxy inner EAP methods. It *can* also act as a home server for those proxied requests.
there is part of my log from proxy server == ... } # server peap_and_ttls (8) Virtual server sending reply (8) Supplicant-Use-Remote = "yes" (8) Supplicant-Password = "testing" (8) Supplicant-User-Name = "testing_remote" (8) Supplicant-Group = "testaccount::foo" (8) eap_peap: Got tunneled reply code 0 (8) eap_peap: Supplicant-Use-Remote = "yes" (8) eap_peap: Supplicant-Password = "testing" (8) eap_peap: Supplicant-User-Name = "testing_remote" (8) eap_peap: Supplicant-Group = "testaccount::foo" (8) eap_peap: Tunnelled authentication will be proxied to testing-realm (8) eap: WARNING: Tunneled session will be proxied. Not doing EAP (8) [eap] = handled (8) } # authenticate = handled (8) Starting proxy to home server 172.18.0.4 port 1812 (8) Proxying request to home server 172.18.0.4 port 1812 timeout 20.000000 (8) Sent Access-Request Id 14 from 0.0.0.0:43371 to 172.18.0.4:1812 length 265 (8) EAP-Message = 0x020800491a0208004431ef0b17ce3dd0e033380d0a0396b4fc2e000000000000000060800026d7a31747894bdd9887cf258fe12e06f6f3950c560074657374696e675f72656d6f7465 (8) User-Name = "testing_remote" (8) State = 0x0998f23b0990e83ccf3e67f5bc936f77 (8) NAS-IP-Address = 127.0.0.1 (8) Calling-Station-Id = "02-00-00-00-00-01" (8) Framed-MTU = 1400 (8) NAS-Port-Type = Wireless-802.11 (8) Service-Type = Framed-User (8) Connect-Info = "CONNECT 11Mbps 802.11b" (8) Called-Station-Id = "testaccount" (8) NAS-Identifier = "foo" (8) Event-Timestamp = "Oct 20 2017 16:15:16 UTC" (8) Supplicant-Radius-Ip = "0.0.0.0" (8) Supplicant-Radius-Port = "1812" (8) Message-Authenticator = 0x (8) Proxy-State = 0x38 Waking up in 0.2 seconds. (8) Expecting proxy response no later than 19.794262 seconds from now ... == log from home server == ... Ready to process requests (0) Received Access-Request Id 14 from 172.18.0.5:43371 to 172.18.0.4:1812 length 265 (0) EAP-Message = 0x020800491a0208004431ef0b17ce3dd0e033380d0a0396b4fc2e000000000000000060800026d7a31747894bdd9887cf258fe12e06f6f3950c560074657374696e675f72656d6f7465 (0) User-Name = "testing_remote" (0) State = 0x0998f23b0990e83ccf3e67f5bc936f77 (0) NAS-IP-Address = 127.0.0.1 (0) Calling-Station-Id = "02-00-00-00-00-01" (0) Framed-MTU = 1400 (0) NAS-Port-Type = Wireless-802.11 (0) Service-Type = Framed-User (0) Connect-Info = "CONNECT 11Mbps 802.11b" (0) Called-Station-Id = "testaccount" (0) NAS-Identifier = "foo" (0) Event-Timestamp = "Oct 20 2017 16:15:16 UTC" (0) Supplicant-Radius-Ip = "0.0.0.0" (0) Supplicant-Radius-Port = "1812" (0) Message-Authenticator = 0x799a6faef910ebeff0beacd45c6e946e (0) Proxy-State = 0x38 (0) session-state: No cached attributes (0) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/testing-site (0) authorize { (0) [preprocess] = ok (0) auth_log: EXPAND /var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d:%H (0) auth_log: --> /var/log/radius/radacct/172.18.0.5/auth-detail-20171020:16 (0) auth_log: /var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d:%H expands to /var/log/radius/radacct/172.18.0.5/auth-detail-20171020:16 (0) auth_log: EXPAND %t (0) auth_log: --> Fri Oct 20 16:15:16 2017 (0) [auth_log] = ok (0) update request { (0) Supplicant-Radius-Ip = 0.0.0.0 (0) Supplicant-Radius-Port = 1812 (0) } # update request = noop (0) eap: Peer sent EAP Response (code 2) ID 8 length 73 (0) eap: No EAP Start, assuming it's an on-going EAP conversation (0) [eap] = updated (0) if (noop) { (0) if (noop) -> FALSE (0) [chap] = noop (0) [mschap] = noop (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available (0) [pap] = noop (0) update control { (0) Cache-Status-Only := no (0) } # update control = noop (0) cache_mypythonmodule: EXPAND %{request:Supplicant-User-Name}-%{request:Calling-Station-Id}-%{request:Supplicant-Radius-Port} (0) cache_mypythonmodule: --> -02-00-00-00-00-01-1812 (0) cache_mypythonmodule: No cache entry found for "-02-00-00-00-00-01-1812" (0) cache_mypythonmodule: Creating new cache entry (0) cache_mypythonmodule: control::Auth-Type += &control:Auth-Type[*] -> eap (0) cache_mypythonmodule: Skipping Cache-Status-Only (0) cache_mypythonmodule: control:State := &request:State -> 0x0998f23b0990e83ccf3e67f5bc936f77 (0) cache_mypythonmodule: Merging cache entry into request (0) cache_mypythonmodule: &control:Auth-Type := eap (0) cache_mypythonmodule: &control:State := 0x0998f23b0990e83ccf3e67f5bc936f77 (0) cache_mypythonmodule: Committed entry, TTL 5 seconds (0) [cache_mypythonmodule] = updated (0) update reply { (0) Supplicant-Radius-Ip !* ANY (0) Supplicant-Radius-Port !* ANY (0) } # update reply = noop (0) } # authorize = updated (0) Found Auth-Type = eap (0) # Executing group from file /usr/local/etc/raddb/sites-enabled/testing-site (0) authenticate { (0) eap: ERROR: rlm_eap (EAP): No EAP session matching state 0x0998f23b0990e83c (0) eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request (0) eap: Failed in handler (0) [eap] = invalid (0) } # authenticate = invalid (0) Failed to authenticate the user (0) Using Post-Auth-Type Reject ... === there is config from proxy server == server testing-site { listen { type = auth ipaddr = * port = 1812 } authorize { preprocess #sanitizies attributes auth_log #log authorization request update request { Supplicant-Radius-Ip = 0.0.0.0 Supplicant-Radius-Port = 1812 } eap { ok = return } if (noop) { update request { Supplicant-User-Name := &User-Name } update control { Cache-Status-Only := 'yes' } cache_mypythonmodule if (notfound) { update request { Supplicant-User-Name !* ANY } mypythonmodule_auth if (updated){ update request { Supplicant-User-Name := &reply:Supplicant-User-Name } if(&reply:Supplicant-Password){ update control { Cleartext-Password := &reply:Supplicant-Password } } if(&reply:Supplicant-Use-Remote == 'yes') { update control { Proxy-To-Realm := 'testing-realm' Supplicant-Use-Remote := 'yes' } } if(&reply:Supplicant-Use-Mac-Auth == 'yes') { update control { Auth-Type := MYPYTHONMODULE } } } elsif (reject){ reject } } elsif (ok) { update control { Cache-Status-Only := 'no' } cache_mypythonmodule } } chap mschap pap update control { Cache-Status-Only := 'no' } cache_mypythonmodule update reply { Supplicant-Radius-Ip !* ANY Supplicant-Radius-Port !* ANY } } authenticate { Auth-Type MYPYTHONMODULE{ mypythonmodule_auth } Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } eap } post-auth { if(User-Name !~ /^anonymous*/){ linelog `test line` } exec remove_reply_message_if_eap Post-Auth-Type REJECT { linelog `test reject line` attr_filter.access_reject eap remove_reply_message_if_eap } } pre-proxy { } post-proxy { eap cache_mypythonmodule } } == and virtual site for inner tunnel == server peap_and_ttls { authorize { eap { ok = return } update request { Supplicant-User-Name := &User-Name } update control { Cache-Status-Only := 'yes' } cache_mypythonmodule if (notfound) { update request { Supplicant-User-Name !* ANY } mypythonmodule_auth if (reject){ reject } update request { Supplicant-User-Name := &reply:Supplicant-User-Name } if(&reply:Supplicant-Password ){ update control { Cleartext-Password := &reply:Supplicant-Password } } if(&reply:Supplicant-Use-Remote == 'yes') { update control { Proxy-To-Realm := 'testing-realm' Supplicant-Use-Remote := 'yes' } } if(&reply:Supplicant-Use-Mac-Auth == 'yes') { update control { Auth-Type := MYPYTHONMODULE } } } elsif (ok) { update control { Cache-Status-Only := 'no' } cache_mypythonmodule } chap mschap pap update control { Cache-Status-Only := 'no' } cache_mypythonmodule update reply { Supplicant-Radius-Ip !* ANY Supplicant-Radius-Port !* ANY } } authenticate { Auth-Type MYPYTHONMODULE { mypythonmodule_auth } Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } eap } post-auth { linelog `test log` exec remove_reply_message_if_eap Post-Auth-Type REJECT { linelog `test reject log` attr_filter.access_reject eap remove_reply_message_if_eap } } pre-proxy { } post-proxy { eap cache_mypythonmodule } } on home server virtual sites are the same except they don't have this block == if(&reply:Supplicant-Use-Remote == 'yes') { update control { Proxy-To-Realm := 'testing-realm' Supplicant-Use-Remote := 'yes' } } == and this peap config from both proxy and home server peap { tls = tls-common default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes proxy_tunneled_request_as_eap = yes virtual_server = peap_and_ttls } Why home server not accept eap-mscchpv2 message?
And I could not configure proxy server to send request after it look inside eap-tls request. Home server inform what eap message has a wrong state.
Posting debug output would be more useful than posting vague descriptions.
And on this questions I think you already answered
No. You can (a) process EAP at a server, or (b) proxy it. You can't do both.
i.e I can't read common name property from certificate in proxy server on eap-tls request, and then proxy this request to home server. Am I right?
On Oct 20, 2017, at 12:45 PM, work vlpl <thework.vlpl@gmail.com> wrote:
Thank you for your answers, you help a lot, could you answer a couple more questions?
Sure.
log from home server ... (0) eap: ERROR: rlm_eap (EAP): No EAP session matching state 0x0998f23b0990e83c (0) eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request
It's hard to tell from the truncated debug output. But I suspect the proxy is sending a State when it shouldn't.
and virtual site for inner tunnel
== server peap_and_ttls { authorize { eap { ok = return }
If you're doing to proxy the inner-tunnel session, you CANNOT do EAP in the inner-tunnel. Pick one: (a) run the EAP module in the inner-tunnel, or (b) proxy in the inner-tunnel.
if(&reply:Supplicant-Use-Remote == 'yes') { update control { Proxy-To-Realm := 'testing-realm'
You can't do that. I already said so in a previous message. Alan DeKok.
participants (2)
-
Alan DeKok -
work vlpl