Hi Antonio, > What's happening now is that when I authenticate in the CP, the > Access-Request packet is originating from 127.0.0.1 in the loopback. > This request gets proxied, the Access-Accept Packet comes back, it gets > sent back to 127.0.0.1 , freeRADIUS enters post-auth, runs the perl > script but packetfence doesn't do anything.
When you authenticate in the captive portal with the RADIUS back-end, no packetfence module interaction is to be expected. > It should be logging onto the controller via ssh to disassociate the station. Correct, this should happen but not because the CP used a RADIUS back-end, rather because we detect a status change for a node and we act on it. > > I also get an invalid login or password in the CP even though the packet > returned as accept. Could it be something with the packet coming from > the 127.0.0.1 instead of the management IP address? > > On our previous set up, the Access-Request packet came from the IP > address of the management interface but what I changed on the last set > up is not working on this set up which was adding the IP address and > hostname to /etc/hosts. > authentication::radius is meant to authenticate users on the captive portal using an *external* RADIUS where you have your users' credentials stored packetfence.pm is our FreeRADIUS module acting on network access requests. I think you got the two confused. -- Olivier Bilodeau [email protected] :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
