Re: [Packetfence-devel] problem assigning to a vlan

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

HI

I was just writing you a reply about this very thing! We actually switched
the code to look for a 2 instead of a 6 and it worked. What would you need
the DA filtering for? In our documentation on DA filtering it reads:

"When set to enabled this field isolates the intruding node by filtering
(discarding) packets sent to that MAC address".

Since we still wanted packets to go to the "filtered node" so that it could
register and such, we left this to its default of Disabled. Is there a good
reason to set it to Enabled?

Thanks for all your help. I believe we have this working now. We will have
to increase the breadth of our testing by including a few more switches from
different networks.

Thanks for your assistance on this.

Cheers

Matt

md...@un...

From: pac...@li...
[mailto:pac...@li...] On Behalf Of
Dominik Gehl
Sent: Thursday, May 29, 2008 3:06 PM
To: md...@un...
Cc: pac...@li...
Subject: Re: [Packetfence-devel] problem assigning to a vlan

Hi Matt,

1.3.6.1.4.1.45.1.6.5.3.5 is the OID for 

s5SbsSecurityAction OBJECT-TYPE

            SYNTAX        INTEGER{

                        noAction(1),

                        trap(2),

                        partitionPort(3),

                        partitionPortAndsendTrap(4),

                        daFiltering(5),

                        daFilteringAndsendTrap(6),

                        partitionPortAnddaFiltering(7),

                        partitionPortdaFilteringAndsendTrap(8)

                        }

            ACCESS         read-write

            STATUS         mandatory

            DESCRIPTION

                        "Action performed by software when a violation
occurs (if

                        s5SbsSecurityStatus is enabled).  The security
action specified

                        here applies to all ports of the switch.

                        NOTE: da means destination address.

                        A blocked address will always cause the port to be
partitioned

                        when unauthorized access is attempted. See

                        s5SbsAuthCfgAccessCtrlType for more information on
allowed

                        and blocked addresses."

            ::= { s5SbsAuth 5 }                

So the value '2' means that trapping is enabled but that daFiltering is not
activated. The isPortSecurityEnabled routine on the other hand is is
checking for a value of '6'. Could you change your switch's security
configuration to 'filter and trap' ?

Dominik

On 29-May-08, at 1:40 PM, Matt Ashfield wrote:

The results are as follows:

[]$ snmpwalk -v2c -c public 13.20.209.253 1.3.6.1.4.1.45.1.6.5.3.3

SNMPv2-SMI::enterprises.45.1.6.5.3.3.0 = INTEGER: 1

[]$ snmpwalk -v2c -c public 13.20.209.253 1.3.6.1.4.1.45.1.6.5.3.5

SNMPv2-SMI::enterprises.45.1.6.5.3.5.0 = INTEGER: 2

[]$ snmpwalk -v2c -c public 13.20.209.253 1.3.6.1.4.1.45.1.6.5.3.11.1.6

SNMPv2-SMI::enterprises.45.1.6.5.3.11.1.6.1.15.0.17.37.129.29.218 = INTEGER:
2

SNMPv2-SMI::enterprises.45.1.6.5.3.11.1.6.1.22.0.1.2.37.109.6 = INTEGER: 2

SNMPv2-SMI::enterprises.45.1.6.5.3.11.1.6.1.23.0.16.181.110.1.16 = INTEGER:
2

SNMPv2-SMI::enterprises.45.1.6.5.3.11.1.6.1.24.0.0.0.0.0.0 = INTEGER: 1

Not sure what those values are supposed to be.

Matt Ashfield

md...@un...

-----Original Message-----
From: Dominik Gehl [mailto:dg...@in...]
Sent: Thursday, May 29, 2008 2:22 PM
To: md...@un...
Cc: pac...@li...
Subject: Re: [Packetfence-devel] problem assigning to a vlan

Hi Matt,

looks like the isPortSecurityEnabled subroutine does not correctly  

return the port status in your case. Could you send us the snmpwalk  

results for the following OIDs (this is in fact what the  

isPortSecurityEnabled routine is doing):

1.3.6.1.4.1.45.1.6.5.3.3

1.3.6.1.4.1.45.1.6.5.3.5

1.3.6.1.4.1.45.1.6.5.3.11.1.6

Thanks a lot,

Dominik

On 29-May-08, at 1:06 PM, Matt Ashfield wrote:

> Hello All,

> 

> We are using the new version of packetfence with Mac-Security traps  

> on Nortel equipment with RHEL5 as our server.

> 

> We can get a computer to register, but the PF system does not flip  

> the port from the registration vlan to the regular/working vlan  

> after the registration takes place.  The only way it does work is as  

> follows:

> Plug unregistered computer into port-x. It gets placed in  

> registration vlan and redirected to registration webpages. Once  

> registration takes place, the device appears as registered in the PF  

> database. However, as mentioned above, its port does not get flipped  

> to the regular/working vlan. IF HOWEVER, we then take this device  

> and plug it into another port on the switch, the new port does in  

> fact get placed in the correct vlan.

> 

> Some interesting log entries related to this from pfsetvlan.log:

> May 29 11:57:14 => thread 1: reAssignVlan trap received on  

> 13.20.209.253 ifIndex 7 (main::handleTrap)

> May 29 11:57:15 => thread 1: no security traps are configured on  

> 13.20.209.253 ifIndex 7. Flipping port admin status (main::handleTrap)

> 

> Security traps are definitely enabled on this port. Obviously they  

> are, because that is the same port that sent the security trap that  

> started the registration process!

> 

> Any help/advice is appreciated. Thanks

> 

> 

> Matt Ashfield

> md...@un...

> 

> -------------------------------------------------------------------------

> This SF.net email is sponsored by: Microsoft

> Defy all challenges. Microsoft(R) Visual Studio 2008.

>
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_____________________
__________________________

> Packetfence-devel mailing list

> Pac...@li...

> https://lists.sourceforge.net/lists/listinfo/packetfence-devel

--

Dominik Gehl

dg...@in...  ::  (514) 755-4520  ::  http://www.inverse.ca

--

Dominik Gehl

dg...@in...  ::  (514) 755-4520  ::  http://www.inverse.ca