OK, after analysing some radius debug logs it looks like packetfence is being
called from the post-auth section of the sites-enabled/packetfence server:
post-auth {
exec
if (!EAP-Type || (EAP-Type != 21 && EAP-Type != 25)|| (User-Name =~
/^.*\@.+/ && User-Name !~ /^.*\@cardiffmet.ac.uk/)|| (User-Name =~ /^.*\@.+/ &&
User-Name !~ /^.*\@uwic.ac.uk/)) {
packetfence
}
Post-Auth-Type REJECT {
attr_filter.access_reject
}
}
I put this in, so that the visiting users (users from other organisations at
our university) would have their devices automatically registered in
packetfence. If I comment out the above section our users at remote
institutions now authenticate, but visiting users don't show up in the
packetfence.
Looks like I need to tweak the above code somehow.
Any suggestions?
Cheers,
Andi
From: Morris, Andi [mailto:amor...@cardiffmet.ac.uk]
Sent: 17 July 2014 09:33
To: packetfence-users@lists.sourceforge.net
Subject: [PacketFence-users] eduroam home users being processed by packetfence
Hi,
I have a packetfence setup, version 4.2.2, which is configured to proxy
visiting users out to our eduroam ORPS servers, and process local users here.
This is all working well and we have a record of what users are on the wireless
on our campus. However, there's an issue with our users connecting in from
other institutions, where it looks like Packetfence is rejecting the radius
request because it doesn't know about the switch.
I have the setup as per the admin guide. My orps servers are declared in my
clients.conf file with shortnames configured:
client orpsserver1.internal {
ipaddr = 192.168.1.1
secret = *****
shortname = orps01
}
client orpsserver2.internal {
ipaddr = 192.168.1.2
secret = ****
shortname = orps02
}
And I have packetfence-tunnel configured to skip packetfence if the request
comes from the orps servers:
post-auth {
exec
# we skip packetfence when the request is coming from the eduroam
servers
if ( "%{client:shortname}" != "orps01" && \
"%{client:shortname}" != "orps02" ) {
packetfence
}
Post-Auth-Type REJECT {
attr_filter.access_reject
}
}
However I'm seeing the following in my radius logs when home users try to
connect in from outside:
Wed Jul 16 16:21:41 2014 : Auth: Login OK: [sm12...@cardiffmet.ac.uk] (from
client orps01 port 0 cli cc-fa-00-f4-4a-c3 via TLS tunnel)
Wed Jul 16 16:21:41 2014 : Auth: Login OK: [sm12...@cardiffmet.ac.uk] (from
client orps01 port 0 cli cc-fa-00-f4-4a-c3)
Wed Jul 16 16:21:41 2014 : Info: rlm_perl: request from cc:fa:00:f4:4a:c3 port
was not accepted but a proper error code was provided. Check server side logs
for details
The eduroam test site shows the following log entries for remote requests:
Jul 16 15:10:11 194.83.56.233 radiator: INFO: Access rejected for
sm18...@cardiffmet.ac.uk<mailto:sm18...@cardiffmet.ac.uk>: Switch is not
managed by PacketFence
Packetfence.log shows:
Jul 16 15:46:12 httpd.webservices(29980) WARN: Request type was not set. There
is a problem with the NAS, your radius config or rlm_perl packetfence.pm
FreeRADIUS module. (pf::Switch::_identifyConnectionType)
Jul 16 15:46:12 httpd.webservices(29980) INFO: We decided not to act on this
radius call. Stop handling request from 127.0.0.1. (pf::radius::authorize)
Should I be declaring localhost as a known switch, or should I be bypassing
packetfence for remote radius requests in a different way?
Cheers,
Andi
-------------------------------------
Andi Morris
IT Security Officer
Cardiff Metropolitan University
T: 02920 205720
E: amor...@cardiffmet.ac.uk<mailto:amor...@cardiffmet.ac.uk>
--------------------------------------
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users
