Hi Dennis,
I am not sure I agree with your assessment of the situation.
For one thing, do you need to run pfsetvlan?
Unless you have switches authenticating with port security or link-up/down
traps (and you really shouldn’t) then you don’t need it.
Turn it off if all you have is RADIUS authentication.
On Aug 5, 2015, at 11:48 , Dennis Schulmeyer <[email protected]> wrote:
> [root@testpf vlan]# tail -f /usr/local/pf/logs/packetfence.log
> Aug 05 17:12:42 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] handling radius
> autz request: from switch_ip => (192.168.6.20), connection_type =>
> WIRED_MAC_AUTH,switch_mac => (00:23:34:a6:0f:06), mac => [70:5a:b6:a7:a5:0d],
> port => 10504, username => "705ab6a7a50d" (pf::radius::authorize)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: Could not find any IP phones through
> discovery protocols for ifIndex 10504 (pf::Switch::getPhonesDPAtIfIndex)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] Can't find
> provisioner (pf::vlan::getNormalVlan)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] Can't find scan
> engine (pf::vlan::getNormalVlan)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] Connection type is
> WIRED_MAC_AUTH. Getting role from node_info (pf::vlan::getNormalVlan)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] Username was NOT
> defined or unable to match a role - returning node based role ''
> (pf::vlan::getNormalVlan)
> Aug 05 17:12:44 httpd.aaa(2825) WARN: No parameter Vlan found in
> conf/switches.conf for the switch 192.168.6.20 (pf::Switch::getVlanByName)
> Aug 05 17:12:44 httpd.aaa(2825) WARN: [70:5a:b6:a7:a5:0d] Resolved VLAN for
> node is not properly defined: Replacing with macDetectionVlan
> (pf::vlan::fetchVlanForNode)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] PID:
> "TESTDOMAIN\\dennis.schulmeyer", Status: reg Returned VLAN: 14, Role:
> (pf::vlan::fetchVlanForNode)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] (192.168.6.20)
> Returning ACCEPT with VLAN 14 and role
> (pf::Switch::Cisco::Catalyst_2960::returnRadiusAccessAccept)
I am seeing an access-accept here. It returns VLAN 14 which comes from the
configuration, in the switches config where you mapped “Mac Detection” to VLAN
14.
Usually what this means is that device is registered (probably because it did
so on an EAP connection before) but there is no role for it in the database.
Look for that device in the “nodes” panel.
I’ll bet you it does not have a role.
> Aug 05 17:31:56 pfsetvlan(1) INFO: nb of items in queue: 1; nb of threads
> running: 0 (main::startTrapHandlers)
> Aug 05 17:31:56 pfsetvlan(1) INFO: down trap received on 192.168.6.20 ifIndex
> 10504 (main::handleTrap)
> Aug 05 17:31:56 pfsetvlan(1) INFO: security traps are configured on this
> switch port. Stopping DOWN trap handling here (main::handleTrap)
> Aug 05 17:31:56 pfsetvlan(1) INFO: finished (main::cleanupAfterThread)
> Aug 05 17:32:05 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] handling radius
> autz request: from switch_ip => (192.168.6.20), connection_type =>
> Ethernet-EAP,switch_mac => (00:23:34:a6:0f:06), mac => [68:f7:28:d6:9a:04],
> port => 10504, username => "TESTDOMAIN\\dennis.schulmeyer"
> (pf::radius::authorize)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: Could not find any IP phones through
> discovery protocols for ifIndex 10504 (pf::Switch::getPhonesDPAtIfIndex)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: Memory configuration is not valid
> anymore for key resource::authentication_lookup in local cached_hash
> (pfconfig::cached::is_valid)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [TESTDOMAIN Users_AdminDept] Found a
> match (CN=Dennis Schulmeyer,OU=Users,DC=TESTDOMAIN,DC=com)
> (pf::Authentication::Source::LDAPSource::match_in_subclass)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [TESTDOMAIN Users_AdminDept] Found a
> match (CN=Dennis Schulmeyer,OU=Users,DC=TESTDOMAIN,DC=com)
> (pf::Authentication::Source::LDAPSource::match_in_subclass)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [TESTDOMAIN Users_AdminDept] Found a
> match (CN=Dennis Schulmeyer,OU=Users,DC=TESTDOMAIN,DC=com)
> (pf::Authentication::Source::LDAPSource::match_in_subclass)
> Aug 05 17:32:06 httpd.aaa(2825) WARN: Trying to compute the unreg date from
> an undefined value. Stopping processing and making unreg date undefined.
> (pf::config::dynamic_unreg_date)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] autoregister a node
> that is already registered, do nothing. (pf::node::node_register)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] Can't find
> provisioner (pf::vlan::getNormalVlan)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] Can't find scan
> engine (pf::vlan::getNormalVlan)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] Connection type is
> EAP. Getting role from node_info (pf::vlan::getNormalVlan)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] Username was
> defined "TESTDOMAIN\\dennis.schulmeyer" - returning user based role
> 'VLAN3_Guests' (pf::vlan::getNormalVlan)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] PID:
> "TESTDOMAIN\\dennis.schulmeyer", Status: reg Returned VLAN: 3, Role:
> VLAN3_Guests (pf::vlan::fetchVlanForNode)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] (192.168.6.20)
> Returning ACCEPT with VLAN 3 and role
> (pf::Switch::Cisco::Catalyst_2960::returnRadiusAccessAccept)
> Aug 05 17:32:10 pfsetvlan(4) INFO: nb of items in queue: 1; nb of threads
> running: 0 (main::startTrapHandlers)
> Aug 05 17:32:10 pfsetvlan(4) INFO: up trap received on 192.168.6.20 ifIndex
> 10504 (main::handleTrap)
> Aug 05 17:32:10 pfsetvlan(4) INFO: security traps are configured on this
> switch port. Stopping UP trap handling here (main::handleTrap)
> Aug 05 17:32:10 pfsetvlan(4) INFO: finished (main::cleanupAfterThread)
This , on the opposite, shows a successful authentication for a user.
The Users_AdminDept rule you have defined for the TESTDOMAIN returns the
VLAN3_Guests role.
If you want the rule to return a different role you have to configure it to do
so.
So I am not sure I understand the problem.
Both devices are successfully authenticated.
They may not get the VLANs you expect but that seems to have to do with the way
your sources are configured.
What was the expected behaviour, and how does the above differ from it?
Regards,
--
Louis Munro
[email protected] :: www.inverse.ca
+1.514.447.4918 x125 :: +1 (866) 353-6153 x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
------------------------------------------------------------------------------
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
