Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hi, > in case of connection oriented RADSEC/TCP proxying, it's problem to > decide on client addresses and client ports, It's always the same peer > socket and 8 bits can be very soon to short on a heavy used proxy > connection. > > RADSEC/TCP or RADIUS/TCP came after RFC-2865, maybe we should make > an RFC addendum, that Proxy-State MUST ALWAYS be replied, even in > Status-Server requests. > > Meanwhile we could/should add a config flag in radsecproxy to allow > this. You only send Status-Server once in a long while, meaning you'll only have one packet in flight. You also send it only to servers from which you haven't heard from in a while, so the number of packet identifiers which are currently in use on the socket is always very near 0. Independently of this, it remains a bit unclear to me why Radiator needs the extended-IDs in Proxy-State anyway; if you run out of packet IDs on a given src/dest port/ip combination: you can choose a new source port to send your request from there! There's plenty of source ports. The only reason why identifiers really could run out is if you've used up all your source ports * 256 identifiers for one single destination server. And if you are that busy, you don't need Status-Server :-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Using Radiator as EAP-SIM proxy
Hi All, I'm trying to do some testing using authentication with EAP-SIM via radiator as a proxy. The EAP-SIM authentication is handled by another radius. The wireless is using Cisco WLC, it will send the authentication request to radiator and radiator will proxy it to another radius that supports EAP-SIM authentication. I understand that the EAP-SIM module is not required on radiator if it is just doing proxy. When the response from the EAP-SIM radius is forward to radiator back to the Cisco WLC, the error was the client is not accepting the key. Anyone has any idea what could be the issue? Best Regards, Ryan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] proxying POD reply packets
On 07/17/2013 12:17 AM, Michael wrote: > hmm so, are you saying radiator after proxying out my POD/COA requests, > and after i then convert the packet to an accounting packet and log it, > radiator is actually expecting that the POD/COA reply coming back is > actually an accounting reply and does not relay it to the radpwtst? I was thinking the conversion to accounting packet is the reason why it is not proxied back to radpwtst. If the original request was an Accounting-Request and the Handler result after the AuthBys is REJECT, then the reply is just dropped. This is because there is no Accounting-Reject message type to send back. About the conversion: are you doing the conversion so that you can log the various RFC 5176 replies? Would a separate log file type à la AuthLog be the way to solve this? Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
