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
Re: [RADIATOR] proxying POD reply packets
On 07/13/2013 08:20 PM, Michael wrote: So, my complicated config determines what device the request needs to go to and sends, and then it converts the POD and COA packets to accounting packets using scripting, then sends to my accounting handler and that POD/COA request is logged. Ok, so that's where the 'Accounting rejected' log entry in your first message came from. The default processing in Radiator will proxy back both ACKed and NAKed messages. The latter will be logged as a failed message with 'Change-Filter-Request rejected: thereason', but it will be proxied back just like an ACKed reply. However, rejected accounting messages are dropped. The RADIUS spec does not specify how to reject accounting messages, so there's no Accounting-Rejected message type to send back. You get drops instead. 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
Re: [RADIATOR] proxying POD reply packets
On 16/07/13 04:24 PM, Heikki Vatiainen wrote: On 07/13/2013 08:20 PM, Michael wrote: So, my complicated config determines what device the request needs to go to and sends, and then it converts the POD and COA packets to accounting packets using scripting, then sends to my accounting handler and that POD/COA request is logged. Ok, so that's where the 'Accounting rejected' log entry in your first message came from. The default processing in Radiator will proxy back both ACKed and NAKed messages. The latter will be logged as a failed message with 'Change-Filter-Request rejected: thereason', but it will be proxied back just like an ACKed reply. However, rejected accounting messages are dropped. The RADIUS spec does not specify how to reject accounting messages, so there's no Accounting-Rejected message type to send back. You get drops instead. Thanks, Heikki 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? ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] proxying POD reply packets
On 07/12/2013 06:46 PM, Michael wrote: also, Change-Filter-Request-NAKed would also need to be in that list. Hello Michael, I tested with this setup: radpwtst - R1 - R2 where R1 is a simple proxy Radiator and R2 is Radiator that replies with Change-Filter-NAKed or Disconnect-Request-NAKed. It also adds Error-Cause and Reply-Message to the responses. This is done with AuthBy INTERNAL. R1 config is simply this: Client DEFAULT Secret mysecret /Client Handler AuthBy RADIUS Secret mysecret Host 127.0.0.1 AuthPort 1812 AcctPort 1813 /AuthBy /Handler With the above setup the NAKed responses were proxied back to radpwtst correctly. Also the ACKed responses were proxied fine. R1 logs the message from R2 like this: DEBUG: Packet dump: *** Received from 127.0.0.1 port 1812 Code: Disconnect-Request-NAKed Identifier: 1 Authentic: C235235T17153RG13022121321327223184 Attributes: Reply-Message = No Matching Session Error-Cause = Session-Context-Not-Found INFO: Disconnect-Request rejected: No Matching Session DEBUG: Packet dump: *** Sending to 127.0.0.1 port 44624 Code: Disconnect-Request-NAKed Identifier: 90 Authentic: ZNg233165a23'3520118915514 Attributes: Reply-Message = No Matching Session Error-Cause = Session-Context-Not-Found The INFO line is logged by Handler which forwards the request back to radpwtst even if the request type was not added the the ACCEPTed request types. I wonder if you have a (very) old Radiator or more likely, a configuration that causes NAKed messages to be rejected. 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
Re: [RADIATOR] proxying POD reply packets
Heikki, to answer your questions at bottom snip I wonder if you have a (very) old Radiator or more likely, a configuration that causes NAKed messages to be rejected. snip I'm using v4.10 so it's not old. I do however have a quite complicated radiator configuration. Mainly, i inject POD's and COA's into radiator rather than sending directly to devices because i have many different cisco devices, some using different commands to accomplish the POD and COA. radiator applies the necessary commands for the given device before proxying. Also, i wanted these requests to be logged. So, my complicated config determines what device the request needs to go to and sends, and then it converts the POD and COA packets to accounting packets using scripting, then sends to my accounting handler and that POD/COA request is logged. So yes, i will have to review my config. For now though, adding the NAKed requests to the list in the code i described does make sure the reply packets coming back from the nas's are proxied to the radpwtst client. There's probably a better way of accomplishing this for sure. I'll look into this further Thanks. Michael On 13/07/13 03:25 AM, Heikki Vatiainen wrote: On 07/12/2013 06:46 PM, Michael wrote: also, Change-Filter-Request-NAKed would also need to be in that list. Hello Michael, I tested with this setup: radpwtst - R1 - R2 where R1 is a simple proxy Radiator and R2 is Radiator that replies with Change-Filter-NAKed or Disconnect-Request-NAKed. It also adds Error-Cause and Reply-Message to the responses. This is done with AuthBy INTERNAL. R1 config is simply this: Client DEFAULT Secret mysecret /Client Handler AuthBy RADIUS Secret mysecret Host 127.0.0.1 AuthPort 1812 AcctPort 1813 /AuthBy /Handler With the above setup the NAKed responses were proxied back to radpwtst correctly. Also the ACKed responses were proxied fine. R1 logs the message from R2 like this: DEBUG: Packet dump: *** Received from 127.0.0.1 port 1812 Code: Disconnect-Request-NAKed Identifier: 1 Authentic: C235235T17153RG13022121321327223184 Attributes: Reply-Message = No Matching Session Error-Cause = Session-Context-Not-Found INFO: Disconnect-Request rejected: No Matching Session DEBUG: Packet dump: *** Sending to 127.0.0.1 port 44624 Code: Disconnect-Request-NAKed Identifier: 90 Authentic: ZNg233165a23'3520118915514 Attributes: Reply-Message = No Matching Session Error-Cause = Session-Context-Not-Found The INFO line is logged by Handler which forwards the request back to radpwtst even if the request type was not added the the ACCEPTed request types. I wonder if you have a (very) old Radiator or more likely, a configuration that causes NAKed messages to be rejected. Thanks, Heikki ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] proxying POD reply packets
also, Change-Filter-Request-NAKed would also need to be in that list. On 09/07/13 07:00 AM, Heikki Vatiainen wrote: On 07/05/2013 09:17 PM, Michael wrote: In AuthRADIUS.pm, routine sub handleReply, should Disconnect-Request-NAKed also be listed in the code bellow? I think all types can be proxied back. Good news or bad news, the requestor will surely like to know abou them. Works for me now. The NAKed request now gets forwarded to the original requester (radpwtst). Thanks for reporting the results. If nothing special comes up the additional messages types will be in patches soon. Thanks, Heikki ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] proxying POD reply packets
On 07/05/2013 09:17 PM, Michael wrote: In AuthRADIUS.pm, routine sub handleReply, should Disconnect-Request-NAKed also be listed in the code bellow? I think all types can be proxied back. Good news or bad news, the requestor will surely like to know abou them. Works for me now. The NAKed request now gets forwarded to the original requester (radpwtst). Thanks for reporting the results. If nothing special comes up the additional messages types will be in patches soon. 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] proxying POD reply packets
Does anyone know of any issues with receiving reply packets from a packet-of-disconnect request which is proxied through radiator? For my POD requests, i inject them into radiator using radpwtst and have them configured to proxy to the proper device. The POD does work. When a session is matched and a user is disconnected, the AKed reply comes back to radiator and proxies back to radpwtst and radpwtst will exit with OK. But, when the device respondes with NOT acknowledged (ie. no matching session found), that reply is NOT proxied back to radpwtst and therefore produces a no response timeout issue for radpwtst. This is an example of the NAKed request coming back with No Matching Session which is correct, but it just stops and doesn't appear to forward that reply back to the waiting radpwtst. *** Received from 1.1.1.1 port 1700 Code: Disconnect-Request-NAKed Identifier: 22 Authentic: Attributes: Reply-Message = No Matching Session Error-Cause = Session-Context-Not-Found Fri Jul 5 09:50:26 2013: DEBUG: Accounting rejected: Proxied ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] proxying POD reply packets
In AuthRADIUS.pm, routine sub handleReply, should
Disconnect-Request-NAKed also be listed in the code bellow?
Works for me now. The NAKed request now gets forwarded to the original
requester (radpwtst).
# RadiusResult tells Synchronous mode that we have
# finished with this packet and what the result was
# ReplyHook above could set op-{RadiusResult} to force a
# required reponse type
if (!defined $op-{RadiusResult})
{
if ($p-code eq 'Access-Accept'
|| $p-code eq 'Accounting-Response'
|| $p-code eq 'Disconnect-Request-ACKed'
|| $p-code eq 'Disconnect-Request-NAKed'
|| $p-code eq 'Change-Filter-Request-ACKed')
{
$op-{RadiusResult} = $main::ACCEPT;
On 05/07/13 10:02 AM, Michael wrote:
Does anyone know of any issues with receiving reply packets from a
packet-of-disconnect request which is proxied through radiator? For my
POD requests, i inject them into radiator using radpwtst and have them
configured to proxy to the proper device. The POD does work. When a
session is matched and a user is disconnected, the AKed reply comes back
to radiator and proxies back to radpwtst and radpwtst will exit with OK.
But, when the device respondes with NOT acknowledged (ie. no matching
session found), that reply is NOT proxied back to radpwtst and therefore
produces a no response timeout issue for radpwtst.
This is an example of the NAKed request coming back with No Matching
Session which is correct, but it just stops and doesn't appear to
forward that reply back to the waiting radpwtst.
*** Received from 1.1.1.1 port 1700
Code: Disconnect-Request-NAKed
Identifier: 22
Authentic:
Attributes:
Reply-Message = No Matching Session
Error-Cause = Session-Context-Not-Found
Fri Jul 5 09:50:26 2013: DEBUG: Accounting rejected: Proxied
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
