RE: STILL Trying to get tunneling to work
Alan, A few days ago I sent you a private email to your deployingradius address. I attached a bunch of config files and log output so you could see the issues in my working 2.1.4 vs non-working 2.1.8 installations. I did not scrub the config files since it was a private email. If you want the configs to be public, I'll scrub them and send them again to an appropriate location, but I do not have a place to post them myself. I never got a response to that email, so I wanted to make sure you know I sent it. If it should go elsewhere, let me know. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: STILL Trying to get tunneling to work
Mike Bernhardt wrote: I never got a response to that email, so I wanted to make sure you know I sent it. If it should go elsewhere, let me know. I received it. I'll take a look and see if I can figure out what's going on. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: STILL Trying to get tunneling to work- resolved, and a question
It doesn't work referred to the original question I posted with the same subject a few weeks ago. At that time I provided debug output. I tried this configuration with 2.1.7 and 2.1.8 but it didn't work in that the request never left freeradius for the downstream server. After I installed 2.1.4, it worked as it should without changing anything else. I will try reinstalling 2.1.8 just for fun and see if it behaves this time. If it doesn't, I'll stick with 2.1.4 and send you my config files. As far as status checks, the authentication pings will work fine. I see now that they only kick in when a server is marked dead. If I can figure out how to shorten the time before it is marked dead I'll be very satisfied with that setup. -Original Message- From: Alan DeKok [mailto:al...@deployingradius.com] Sent: Friday, January 29, 2010 11:12 PM To: FreeRadius users mailing list Subject: Re: STILL Trying to get tunneling to work- resolved, and a question Mike Bernhardt wrote: Just to clarify my questions: If one of the servers I'm proxying to is dead, is there a way to reduce the number of times freeradius tries before failing over to the next one? Read raddb/proxy.conf 2. Are there any ways to make this process more efficient, given that status check currently doesn't work with the downstream servers? Since that isn't a given... I'm not sure what else to say. Testing for 2.1.8 involved *billions* of packets go through it in prixying non-proxying setups, with status checks enabled and disabled, with home servers going up down... Please be more specific than it doesn't work. Many people are using 2.1.8 in similar setups to yours, and they see that it works. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: STILL Trying to get tunneling to work- resolved, and a question
Mike Bernhardt wrote: It doesn't work referred to the original question I posted with the same subject a few weeks ago. At that time I provided debug output. Ah... that's the failed creating proxy socket issue. Weird. I tried this configuration with 2.1.7 and 2.1.8 but it didn't work in that the request never left freeradius for the downstream server. After I installed 2.1.4, it worked as it should without changing anything else. I will try reinstalling 2.1.8 just for fun and see if it behaves this time. If it doesn't, I'll stick with 2.1.4 and send you my config files. OK. If 2.1.8 didn't work 2 weeks ago, re-installing it will likely not help. As far as status checks, the authentication pings will work fine. I see now that they only kick in when a server is marked dead. If I can figure out how to shorten the time before it is marked dead I'll be very satisfied with that setup. raddb/proxy.conf. All of the configuration items are documented there. Be aware, though, that 2.1.8 makes these work better than 2.1.4. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: STILL Trying to get tunneling to work- resolved, and a question
I found the major problem that caused my configuration to not work. This was in regards to getting freeradius to proxy EAP/PEAP to IAS servers as standard CHAP. I was using freeradius 2.1.7, and then 2.1.8 as recommended by someone. Neither worked. The solution was to back down to 2.1.4. Is this a bug that was introduced after that, or what? I can email config files to whomever needs them to work on it. So, I now have another question: I have set up 2 IAS servers in a pool. I would like to drastically reduce the timeout before freeradius fails over to the 2nd one. How do I do that? Right now it takes about 30 seconds but I don't see a variable to change that. I also noticed that the status requests, which begin after it has marked a server as bad, do not work. How do I use the user name and [bad] password to check status and bring it back sooner? It only seems to try it once and that's it. Thanks, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: STILL Trying to get tunneling to work- resolved, and a question
Mike Bernhardt wrote: I found the major problem that caused my configuration to not work. This was in regards to getting freeradius to proxy EAP/PEAP to IAS servers as standard CHAP. ? That's impossible. PEAP uses a MD4 hash of the password, and CHAP uses an MD5 hash of the password. You can't turn one into the other. Perhaps you mean something else, like proxying PEAP as plain MS-CHAP? The solution was to back down to 2.1.4. Is this a bug that was introduced after that, or what? I can email config files to whomever needs them to work on it. Sure. Send them over. So, I now have another question: I have set up 2 IAS servers in a pool. I would like to drastically reduce the timeout before freeradius fails over to the 2nd one. How do I do that? Right now it takes about 30 seconds but I don't see a variable to change that. See proxy.conf. The variables there control fail-over per home server. I also noticed that the status requests, which begin after it has marked a server as bad, do not work. What does that mean? How do I use the user name and [bad] password to check status and bring it back sooner? It only seems to try it once and that's it. It does try more than once... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: STILL Trying to get tunneling to work- resolved, and a question
Just to clarify my questions: If one of the servers I'm proxying to is dead, is there a way to reduce the number of times freeradius tries before failing over to the next one? 2. Are there any ways to make this process more efficient, given that status check currently doesn't work with the downstream servers? -Original Message- From: Mike Bernhardt [mailto:bernha...@bart.gov] Sent: Friday, January 29, 2010 11:36 AM To: 'freeradius-users@lists.freeradius.org' Subject: Re: STILL Trying to get tunneling to work- resolved, and a question I found the major problem that caused my configuration to not work. This was in regards to getting freeradius to proxy EAP/PEAP to IAS servers as standard CHAP. I was using freeradius 2.1.7, and then 2.1.8 as recommended by someone. Neither worked. The solution was to back down to 2.1.4. Is this a bug that was introduced after that, or what? I can email config files to whomever needs them to work on it. So, I now have another question: I have set up 2 IAS servers in a pool. I would like to drastically reduce the timeout before freeradius fails over to the 2nd one. How do I do that? Right now it takes about 30 seconds but I don't see a variable to change that. I also noticed that the status requests, which begin after it has marked a server as bad, do not work. How do I use the user name and [bad] password to check status and bring it back sooner? It only seems to try it once and that's it. Thanks, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: STILL Trying to get tunneling to work- resolved, and a question
Mike Bernhardt wrote: Just to clarify my questions: If one of the servers I'm proxying to is dead, is there a way to reduce the number of times freeradius tries before failing over to the next one? Read raddb/proxy.conf 2. Are there any ways to make this process more efficient, given that status check currently doesn't work with the downstream servers? Since that isn't a given... I'm not sure what else to say. Testing for 2.1.8 involved *billions* of packets go through it in prixying non-proxying setups, with status checks enabled and disabled, with home servers going up down... Please be more specific than it doesn't work. Many people are using 2.1.8 in similar setups to yours, and they see that it works. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: STILL Trying to get tunneling to work
Still waiting for 2.1.8. Any update on a release date? Thanks, mike -Original Message- From: Alan DeKok [mailto:al...@deployingradius.com] Sent: Monday, December 21, 2009 11:09 AM To: FreeRadius users mailing list Subject: Re: STILL Trying to get tunneling to work Mike Bernhardt wrote: ERROR: Failed to create a new socket for proxying requests. ERROR: Failed inserting request into proxy hash. Install 2.1.8 when it comes out. That should be tomorrow, or maybe Wednesday. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: STILL Trying to get tunneling to work
Mike Bernhardt wrote: Still waiting for 2.1.8. Any update on a release date? This week. Maybe today, depending on timing. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
STILL Trying to get tunneling to work
From: t...@kalik.net [mailto:t...@kalik.net]
Sent: Thursday, December 10, 2009 5:05 PM
To: FreeRadius users mailing list
Subject: Re: Trying to get tunneling to work
I am trying to set up freeradius to proxy requests 802.11 MSCHAPv2 to an
IAS
server. The IAS requests are authenticated by a Safeword server, which
doesn't support 802.11. So the idea is that freeradius takes the request,
proxies it to IAS as if it was a non-802.11 client, IAS passes it to the
integrated Safeword server, and everything is happy.
My configuration works from a 802.11 supplicant if the user exist locally
in
freeradius, but no proxying happens when the user doesn't exist locally.
Read comments in peap section of eap.conf. Replace LOCAL in Proxy-To-Realm
statement in inner-tunnel virtual server with the name of the realm
pointing to IAS server.
Ivan Kalik
As far as I know, this is the case. It is replaced in the users file. I did
a little cleanup on the other config files too. Here is the new output,
though the result is the same. The request is never forwarded out from
freeeradius. Help, anyone?
radiusd: Loading Realms and Home Servers
proxy server {
retry_delay = 5
retry_count = 3
default_fallback = no
dead_time = 120
wake_all_if_all_dead = no
}
realm safeword.eng {
authhost = 192.168.30.29:1812
accthost = 192.168.30.29:1813
secret = Testing_Testing
}
home_server localhost {
ipaddr = 127.0.0.1
port = 1812
type = auth
secret = testing123
response_window = 20
max_outstanding = 65536
require_message_authenticator = no
zombie_period = 40
status_check = status-server
ping_interval = 30
check_interval = 30
num_answers_to_alive = 3
num_pings_to_alive = 3
revive_interval = 120
status_check_timeout = 4
irt = 2
mrt = 16
mrc = 5
mrd = 30
}
home_server_pool my_auth_failover {
type = fail-over
home_server = localhost
}
radiusd: Loading Clients
client 192.168.7.139/32 {
require_message_authenticator = no
secret = Testing_Testing
}
client 127.0.0.1/32 {
require_message_authenticator = no
secret = testing123
}
radiusd: Loading Virtual Servers
server inner-tunnel {
modules {
Module: Checking authenticate {...} for more modules to load
Module: Linked to module rlm_pap
Module: Instantiating pap
pap {
encryption_scheme = auto
auto_header = no
}
Module: Linked to module rlm_chap
Module: Instantiating chap
Module: Linked to module rlm_mschap
Module: Instantiating mschap
mschap {
use_mppe = yes
require_encryption = no
require_strong = no
with_ntdomain_hack = no
}
Module: Linked to module rlm_unix
Module: Instantiating unix
unix {
radwtmp = /usr/local/var/log/radius/radwtmp
}
Module: Linked to module rlm_eap
Module: Instantiating eap
eap {
default_eap_type = peap
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
max_sessions = 2048
}
Module: Linked to sub-module rlm_eap_md5
Module: Instantiating eap-md5
Module: Linked to sub-module rlm_eap_leap
Module: Instantiating eap-leap
Module: Linked to sub-module rlm_eap_gtc
Module: Instantiating eap-gtc
gtc {
challenge = Password:
auth_type = PAP
}
Module: Linked to sub-module rlm_eap_tls
Module: Instantiating eap-tls
tls {
rsa_key_exchange = no
dh_key_exchange = yes
rsa_key_length = 512
dh_key_length = 512
verify_depth = 0
pem_file_type = yes
private_key_file = /usr/local/etc/raddb/certs/server.pem
certificate_file = /usr/local/etc/raddb/certs/server.pem
CA_file = /usr/local/etc/raddb/certs/ca.pem
private_key_password = whatever
dh_file = /usr/local/etc/raddb/certs/dh
random_file = /usr/local/etc/raddb/certs/random
fragment_size = 1024
include_length = yes
check_crl = no
cipher_list = DEFAULT
make_cert_command = /usr/local/etc/raddb/certs/bootstrap
cache {
enable = no
lifetime = 24
max_entries = 255
}
}
Module: Linked to sub-module rlm_eap_ttls
Module: Instantiating eap-ttls
ttls {
default_eap_type = md5
copy_request_to_tunnel = no
use_tunneled_reply = no
virtual_server = inner-tunnel
include_length = yes
}
Module: Linked to sub-module rlm_eap_peap
Module: Instantiating eap-peap
peap {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
use_tunneled_reply = yes
proxy_tunneled_request_as_eap = no
virtual_server = inner-tunnel
}
Module: Linked to sub-module rlm_eap_mschapv2
Module: Instantiating eap-mschapv2
mschapv2 {
Re: STILL Trying to get tunneling to work
Mike Bernhardt wrote: ERROR: Failed to create a new socket for proxying requests. ERROR: Failed inserting request into proxy hash. Install 2.1.8 when it comes out. That should be tomorrow, or maybe Wednesday. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
