fail to send close messages to the radius server

[Yick Xie]

Hi Nikos,

> That's because the address is assigned after authentication (e.g., the
> address may be assigned by radius itself).

I just thought the ocserv would send update messages to the radius
server immediately after authentication. Whatever it's not a big
trouble.

> Not sure I understand the scenario or defect that you are describing.

For example:
ocserv -c /etc/ocserv/config_office with ip 192.168.1.0/24, public
dns, no-route, firewall
ocserv -c /etc/ocserv/config_R&D with ip 192.168.1.0/24, split-dns,
route, firewall
will they conflict or something else? even with ip-lease option?

> Not really, you cannot clear cookies, although that's something I'd
> like to add. However,
> there is a ban IP command in occtl.  It bans the IP for the configured
> in ocserv time.

Sorry I haven't realized that before, because I misunderstood the
ocserv is supposed to maintain sorts of cookie-IP related entries.
Anyway it still makes sense to use IP ban cmd to deal with it, yet
that cmd seems not available now in occtl.

At last, I want to share another idea. I glanced the freeradius wiki
and found the default SQL-schema includes ConnectInfo_start and
ConnectInfo_stop attributes, the former of which in my opinion can be
utilized to record the User-agent via "Connect-Info". Sometimes the
admin cannot check the log punctually and totally got no clues of
what's the client's application or platform, considering AnyConnect
covers so many OS and versions even as well as BlackBerry. Then UA
attribute must be helpful to collect more info about whether a problem
come from one specific APP/version or our server, meanwhile such
extension will be harmless to the freeradius infrastructure. What do
you think about it ? Perhaps I missed something about the protocol?

Regards,
Yick

2016-01-11 20:01 GMT+08:00 Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com>:
> On Wed, Jan 6, 2016 at 10:10 AM, Yick Xie <yick.xie at gmail.com> wrote:
>> Hi Nikos,
>
>> #B. BTW a tricky way I try to implement to avoid acct-stop-time
>> problems, is to modify the count query in freeradius to count distinct
>> frameipaddress, because a device typically will launch a new session
>> using the same local IP even with stall sessions before. However there
>> are two defects: #1. the ocserv doesn't seem to send frameipaddress to
>> the radius server in the initial connection.
>
> That's because the address is assigned after authentication (e.g., the
> address may be assigned by radius itself).
>
>> #2. A device might have
>> more than one IP especially when it can connect with different ocserv
>> instances in one server, such as ocserv1(office)(192.168.1.0/24),
>> ocserv2(R&D)(10.10.0.0/24). My idea to deal with #2 defect is to
>> assign them with one IP pool with ip-lease option. Is there going to
>> be some unexpected risks?
>
> Not sure I understand the scenario or defect that you are describing.
>
>> #C. Is it possible to invalidate cookies when the admin disconnects
>> manually certain IP/ID via occtl? Because when I checked the problem
>> with specified clients, they mobile devices may still try to connect
>> the server using cookies automatically. Then I have to block that IP
>> for a moment from iptables.
>
> Not really, you cannot clear cookies, although that's something I'd
> like to add. However,
> there is a ban IP command in occtl.  It bans the IP for the configured
> in ocserv time.
>
> regards,
> Nikos