Hi,
> I looked with little success
> for some guidance on building a custom switch configuration file for
> Vyatta. Any suggestions?
We never had the opportunity to spend some time with their products and
I know virtually nothing about them.. I'm sorry but you are on your own.
>
> The only problem I have seen is that unlike a Cisco switch, I have not
> been able to move devices from various VLAN IDs when they connect via
> Vyatta and its VPN. The VPN provides the IP address and default
> gateway. This is why I wanted to move away from the VLAN isolation
> method and try one of the other two. Can PF work with VPNs? What can
> PF do when the IP address of the client is fixed by the VPN gateway?
Some VPNs can use RADIUS as AAA so I would look in that direction.
>
> I installed the ARP patch, and spend several hours trying to get that to
> work. For some reason, PF was not poisoning the gateway MAC entry on
> the "unregistered" client, allowing them complete network access. I
> used configurator.pl and build numerous configuration files ... all with
> the same result of not being able to block access. Even looking at
> dozens of search results, many others seemed to have the same problem.
I would assume that if poisoning didn't work for unregistered but worked
for a registered node with a violation then the patch was wrongly
applied or was wrong in itself (it is old after all).
Otherwise, it could be
a) PF was not located in the correct L2 network (inside the VPN, not
outside maybe?)
b) virtual switches have poisoning protection built-in
c) something else...
>
> I am going to work with the Radius AAA approach you mention. This is
> actually where I wanted to end up ... I just didn't want to enable to
> many components too early. I am struggling with the FreeRADIUS
> configuration, as most of the documentation seems to address using this
> with wireless. Since I am relatively new to PF, it is hard to
> understand exactly what modules I will need to customize.
>
At this point, you are almost out of PacketFence land so don't worry
about not knowing it enough. PF only adds RADIUS attributes after
everything else was handled by FreeRADIUS.
You might need to return specific attributes to the Vyatta. Check what
they support. The easiest/best integration would be that you can return
a VLAN (and this VLAN would span into and through the VPN).
In a nutshell, here are general FreeRADIUS tips:
- go with the 802.1X config. don't mind wireless or wired, both
transport EAP so they are transparent on the FreeRADIUS side of things
- run radiusd in debug (IMPORTANT!)
radiusd -X
- configure a simpler packetfence module only for tests (modify
rlm_perl_packetfence.pl)
sub authorize {
my $vlan = 10;
$RAD_REPLY{'Tunnel-Medium-Type'} = 6;
$RAD_REPLY{'Tunnel-Type'} = 13;
$RAD_REPLY{'Tunnel-Private-Group-ID'} = $vlan;
return RLM_MODULE_OK;
}
this will return VLAN 10. Put in your registration VLAN instead. You
might need other attributes, check Vyatta doc.
- start reading the FreeRADIUS debug trace from last entry and read up
until you see the mention of an error. Because of the modular nature of
FreeRADIUS the last message is often not the problem, you need to dig up.
> I am worried that I have hit a wall, because my limitation is that the
> "soft" switches will only support link change. Where can I read about
> the limitations of PF when using switches with such limited capabilities?
By 'Link change' you mean 'link change traps'? If so then by taking the
FreeRADIUS approach, you completely avoid that problem. Under AAA, it's
the server who asks PacketFence for access requests and when PacketFence
needs to isolate or perform any state change, it will ask the VPN (if
the VPN is the NAS) to perform re-negotiation of the client, which will
trigger the appropriate change. No down/up traps required.
>
> Appreciate your help.
No problem.
If you feel you are getting into too many unknown territory, consider
sponsoring us for the development in that area. I would love to work on
that (Vyatta and purely virtual environments) but unfortunately, I can't
unless it can sustain our business.. If you are interested in knowing
more about this possibility, let me know.
Have a nice day!
--
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)
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Packetfence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
