We have much the same situation and we have solved it by assigning the category
to the user according to what module they use to authenticate.
For example, we have 3 types of users: Admin, Student, and Guest.
We have 3 authentication modules named .. can you guess : ) Admin, Student, and
Guest.
I think it would be lot simpler if you just set normalVlan and guestVlan to the
same number in pf.conf/switches.conf (or to two different numbers, both
restricted), and use vlan/custom.pm to assign nodes manually assigned to the
"corporate" category to an unrestricted VLAN.
--
Rich Graves http:
Dan Nelson writes:
>
>
> I have combed through the forum to try and find a solution to this but haven't
found exactly what I am looking for. Right now the captive portal is working
fine with Radius authentication. Upon successful authentication the node will go
to the normalVlan but with no c
Yes, change your normalvlan to the guest one.
Also, if you want to assign categories, make sure you create them first.
This is how I configured my custom.pm file:
Under getNormalVlan sub ---
if ($node_info->{'category'} =~ /^MYCATEGORYNAME$/i) {
return $switch->getVlanByName('custom
I have combed through the forum to try and find a solution to this but haven't
found exactly what I am looking for. Right now the captive portal is working
fine with Radius authentication. Upon successful authentication the node will
go to the normalVlan but with no category assigned.
I have se
Intuitively, I'm expecting that if I enter in an unregdate for a node, that
once the time passes the unregdate, that the status of that node should revert
to unregistered.
However, I do not see this happening for a particular test. Is there a given
interval which PF decides to review/checks on
Okay! Figured it out. Turns out if I edit the switch.conf file directly via
CLI it poses a problem, although it looks correct in everything I verify...
So, I edited it from the PF web GUI and that seems to have fixed the problem.
I'm not sure why this caused an issue
Anyhow, deauthentica
I see where I went wrong. I had added the client into the client.conf file,
which you had mentioned is in the admin guide on several other postings.
I removed it from the clients.conf file and added the secret to the
switches.conf file.
Now, when I try to connect to the SSID, it fails outright
On Mon, Oct 22, 2012 at 06:50:57PM +, Thomas Tsai wrote:
> I think I found the smoking gun. It's a problem with freeradius.
>
> I am using FreeRADIUS Version 2.1.12, for host x86_64-redhat-linux-gnu, built
> on Jun 22 2012 at 11:13:32, which was included with latest PF distribution.
>
> Per
Actually I did not put radiusSecret in switches.conf. Let me try that now.
-Original Message-
From: Francois Gaudreault [mailto:fgaudrea...@inverse.ca]
Sent: Monday, October 22, 2012 11:39 AM
To: packetfence-users@lists.sourceforge.net
Subject: Re: [PacketFence-users] Cisco WLC 5508 DeAu
Francois,
I think I found the smoking gun. It's a problem with freeradius.
I am using FreeRADIUS Version 2.1.12, for host x86_64-redhat-linux-gnu, built
on Jun 22 2012 at 11:13:32, which was included with latest PF distribution.
Per http://freeradius.org/ , v2.20 fixes the following BUG:
*Cor
Francois,
FWIW, I read other freeradius forums regarding 64bit platforms (Which I'm
using) where some versions fails to correctly calculate the md5 checksum.
I wonder if this is the issue.
-Original Message-
From: Francois Gaudreault [mailto:fgaudrea...@inverse.ca]
Sent: Monday, Octobe
On 2012-10-22 2:27 PM, Thomas Tsai wrote:
> *radiusRFC3576TransportThread: Oct 19 11:02:14.140: Request
>>Authenticator(recv'd) -
>>*31:42:70:62:b8:0e:0e:ea:a3:ef:01:1e:fa:c5:58:5a*
>>
>>*radiusRFC3576TransportThread: Oct 19 11:02:14.140: Request
>>Authenticator(calc'd) -
>>*8e:5f:11:72:7e:f4:28:bf
> Also, if it's a wrong shared secret, the initial authentication request
> via WLC (not deauth), would fail as well. But it does not.
>
> Am I incorrect in thinking this?
Possibly. The authentication request goes from WLC to PacketFence. The CoA goes
from PacketFence to WLC. I don't have a WL
I do not. I have tried to set my secret to "testing123", just for testing.
Also, if it's a wrong shared secret, the initial authentication request via
WLC (not deauth), would fail as well. But it does not.
Am I incorrect in thinking this?
-Original Message-
From: Francois Gaudreault
I still continue to believe a wrong shared secret. Do you have special
chars in your secret?
On 2012-10-22 11:49 AM, Thomas Tsai wrote:
> Bump.
>
> Thomas Tsai, CISSP
> Sr. Systems Engineer
> Canyon Partners, LLC
> tt...@canyonpartners.com
> +1.310.272.1746 (o)
> +1.310.600.6651 (c)
>
>
> *From*
My host is running CentOS, not Windows 7.
I am not sure if Windows 7 can 'add' virtual adapters for each VLAN you want to
access... IF it can, add the VLAN interfaces and then map them through using
VBoxManage commands to the Packetfence guest VM.
The interfaces are all 'bridge' mode, not NAT
Hi,
Is it possible to receive the Guest Network Access Enabled
confirmation via sms instead of Email?
Thanks
TeT
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics
18 matches
Mail list logo
