Subversion Repositories configs

# -*- text -*-

######################################################################

#

#  The server can originate Change of Authorization (CoA) or

#  Disconnect request packets.  These packets are used to dynamically

#  change the parameters of a users session (bandwidth, etc.), or

#  to forcibly disconnect the user.

#

#  There are some caveats.  Not all NAS vendors support this

#  functionality.  Even for the ones that do, it may be difficult to

#  find out what needs to go into a CoA-Request or Disconnect-Request

#  packet.  All we can suggest is to read the NAS documentation

#  available from the vendor.  That documentation SHOULD describe

#  what information their equipment needs to see in a CoA packet.

#

#  This information is usually a list of attributes such as:

#

#	NAS-IP-Address (or NAS-IPv6 address)

#	NAS-Identifier

#	User-Name

#	Acct-Session-Id

#

#  CoA packets can be originated when a normal Access-Request or

#  Accounting-Request packet is received.  Simply update the

#  "coa" list:

#

#	update coa {

#	       User-Name = "%{User-Name}"

#	       Acct-Session-Id = "%{Acct-Session-Id}"

#	       NAS-IP-Address = "%{NAS-IP-Address}"

#	}

#

#  And the CoA packet will be sent.  You can also send Disconnect

#  packets by using "update disconnect { ...".

#

#  This "update coa" entry can be placed in any section (authorize,

#  preacct, etc.), EXCEPT for pre-proxy and post-proxy.  The CoA

#  packets CANNOT be sent if the original request has been proxied.

#

#  The CoA functionality works best when the RADIUS server and

#  the NAS receiving CoA packets are on the same network.

#

#  If "update coa { ... " is used, and then later it becomes necessary

#  to not send a CoA request, the following example can suppress the

#  CoA packet:

#

#	update control {

#		Send-CoA-Request = No

#	}

#

#  The default destination of a CoA packet is the NAS (or client)

#  the sent the original Access-Request or Accounting-Request.  See

#  raddb/clients.conf for a "coa_server" configuration that ties

#  a client to a specific home server, or to a home server pool.

#

#  If you need to send the packet to a different destination, update

#  the "coa" list with one of:

#

#	Packet-Dst-IP-Address = ...

#	Packet-Dst-IPv6-Address = ...

#	Home-Server-Pool = ...

#

#  That specifies an Ipv4 or IPv6 address, or a home server pool

#  (such as the "coa" pool example below).  This use is not

#  recommended, however,  It is much better to point the client

#  configuration directly at the CoA server/pool, as outlined

#  earlier.

#

#  If the CoA port is non-standard, you can also set:

#

#	Packet-Dst-Port

#

#  to have the value of the port.

#

######################################################################

#

#  When CoA packets are sent to a NAS, the NAS is acting as a

#  server (see RFC 5176).  i.e. it has a type (accepts CoA and/or

#  Disconnect packets), an IP address (or IPv6 address), a

#  destination port, and a shared secret.

#

#  This information *cannot* go into a "client" section.  In the future,

#  FreeRADIUS will be able to receive, and to proxy CoA packets.

#  Having the CoA configuration as below means that we can later do

#  load-balancing, fail-over, etc. of CoA servers.  If the CoA

#  configuration went into a "client" section, it would be impossible

#  to do proper proxying of CoA requests.

#

home_server localhost-coa {

	type = coa

	#

	#  Note that a home server of type "coa" MUST be a real NAS,

	#  with an ipaddr or ipv6addr.  It CANNOT point to a virtual

	#  server.

	#

	ipaddr = 127.0.0.1

	port = 3799

	#  This secret SHOULD NOT be the same as the shared

	#  secret in a "client" section.

	secret = testing1234

	#  CoA specific parameters.  See raddb/proxy.conf for details.

	coa {

		irt = 2

		mrt = 16

		mrc = 5

		mrd = 30

	}

}

#

#  CoA servers can be put into pools, just like normal servers.

#

home_server_pool coa {

	type = fail-over

	# Point to the CoA server above.

	home_server = localhost-coa

	#  CoA requests are run through the pre-proxy section.

	#  CoA responses are run through the post-proxy section.

	virtual_server = originate-coa.example.com

	#

	#  Home server pools of type "coa" cannot (currently) have

	#  a "fallback" configuration.

	#

}

#

#  When this virtual server is run, the original request has FINISHED

#  processing.  i.e. the reply has already been sent to the NAS.

#  You can access the attributes in the original packet, reply, and

#  control items, but changing them will have NO EFFECT.

#

#  The CoA packet is in the "proxy-request" attribute list.

#  The CoA reply (if any) is in the "proxy-reply" attribute list.

#

server originate-coa.example.com {

  pre-proxy {

	update proxy-request {

		NAS-IP-Address = 127.0.0.1

	}

  }

  #

  # Handle the responses here.

  #

  post-proxy {

	switch "%{proxy-reply:Packet-Type}" {

		case CoA-ACK {

			ok

		}

		case CoA-NAK {

			# the NAS didn't like the CoA request

			ok

		}

		case Disconnect-ACK {

			ok

		}

		case Disconnect-NAK {

			# the NAS didn't like the Disconnect request

			ok

		}

		# Invalid packet type.  This shouldn't happen.

		case {

		     fail

		}

	}

	#

	#  These methods are run when there is NO response

	#  to the request.

	#

	Post-Proxy-Type Fail-CoA {

		ok

	}

	Post-Proxy-Type Fail-Disconnect {

		ok

	}

  }

}