/etc/freeradius/sites-available/originate-coa is in freeradius 2.1.12+dfsg-1.2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 | # -*- 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
}
}
}
|