> Ok, found the issue. The issue was the shared secret in the radius auth > script and the clients list of FreeRADIUS. Small variation in one of > the passwords (I thought it would of complained about this). What I > don't understand is how the packet still gets generated (from the CP) > and proxied even though the shared secret between the auth.pm and the > FreeRADIUS clients.conf was not the same. Does this mean there is no > client-server communication in the request?
The captive portal is the client, your RADIUS server is the server. No proxying needed. No need to use or rely on the local PacketFence FreeRADIUS server. CP Auth module (conf/auth../radius.pm) needs the same secret as your RADIUS server. -- 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) ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
