Anonymous | Login | 2024-11-22 23:41 EST |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | Project | Category | View Status | Date Submitted | Last Update | |||
0000777 | PacketFence | core | public | 2009-08-19 10:43 | 2015-02-13 15:26 | |||
Reporter | obilodeau | |||||||
Assigned To | obilodeau | |||||||
Priority | normal | Severity | feature | Reproducibility | N/A | |||
Status | closed | Resolution | open | |||||
Platform | OS | OS Version | ||||||
Product Version | ||||||||
Target Version | devel | Fixed in Version | ||||||
Summary | 0000777: Strong guest isolation / per-user passthrough | |||||||
Description | Very interesting idea from Rich Rumble on the -user mailing list. > > What I want in a NAC is to be able to specify and control access with > the NAC box itself. Assign guests /30's (or even /32's) to keep them > isolated from one another and the lan in general, so i don't care how > infected or unpatched they are (or aren't), they are isolated. Using the > NAC in a gateway fashion and assigning a visitor a temp/guest account > and being able to use Iptables to assign ip restrictions to them based > on their active directory/LDAP username and IP assigned via DHCP. > Guest_22 can access a.b.c.d - a.b.c.g, a.b.a.a + internet. Guest_22 > would naturally have to pass some "test" before allowing them on to the > network, otherwise it's internet only. If snort triggers an alert and > they are infected to high heaven, perhaps block all access so they don't > infect others that are internet facing, or so they don't violate our > acceptable use policy and null route them because of BT use. > | |||||||
Tags | No tags attached. | |||||||
fixed in git revision | ||||||||
fixed in mtn revision | ||||||||
Attached Files | ||||||||
Notes | |
(0001300) obilodeau (reporter) 2009-08-20 10:13 |
Some more mailing list context. Here's what I replied: The problem with assigning little subnets to guests is that it's a layer 3 operation that need to happen in another kind of equipment that what packetfence deals with right now. It's already hard enough to play in all of these vendor's switches using SNMP / telnet / ssh. I can't imagine what it would look like if we started to play with L3 switches and routers also. Now, we could send back a small netmask in the dhcp ack but this would not prevent someone from re-applying a broader mask. Maybe that would be a good 80/20 solution. The iptables stuff is definitely interesting and we are looking at implementing something around those lines for a passthrough feature. Thanks to Josh from UOregon, we already know how to do it, all that is missing is automatic configuration from packetfence's config files. |
(0002102) obilodeau (reporter) 2011-07-05 15:40 |
Something can be done rather easily at the switch level. See http://www.packetfence.org/support/faqs/article/restrict-communications-in-registrationisolation-vlans.html [^] |
(0003713) lmunro (administrator) 2015-02-13 15:26 |
Old issues. Most are not relevant to PF 4 and up. Let's reopen the ones that matter when we move to github. |
Issue History | |||
Date Modified | Username | Field | Change |
2009-08-19 10:43 | obilodeau | New Issue | |
2009-08-19 15:55 | obilodeau | Status | new => assigned |
2009-08-19 15:55 | obilodeau | Assigned To | => obilodeau |
2009-08-20 10:13 | obilodeau | Note Added: 0001300 | |
2011-01-18 12:03 | obilodeau | Target Version | => trunk |
2011-07-05 15:40 | obilodeau | Note Added: 0002102 | |
2012-02-29 10:58 | obilodeau | Category | future => core |
2015-02-13 15:26 | lmunro | Note Added: 0003713 | |
2015-02-13 15:26 | lmunro | Status | assigned => closed |
Copyright © 2000 - 2012 MantisBT Group |