Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hello, Am 15.07.2013 10:07, schrieb Ralf Paffrath: ... anyway it's a bit proprietary that Radiator ignores the correct identifier in an Access-Reject packet. The Identifier is also part of RFC2865: Identifier The Identifier field is one octet, and aids in matching requests and replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time. 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. Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ 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 h...@open.com.au 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
[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
