|
|
|
|
Our network has three different access points (AP), all of them connected to the same subnet. Two of them are being used for the employees in the building, and the third one is a guest AP. DHCPd is currently configured so that all the pools are denying unknown-clients. For the public AP, I have to create a (public) pool that does allow unknown-clients, but how would I restrict that pool to only assign IPs to devices connecting through that one AP? Right now if any unknown client connects through the other APs or directly through the network, that (public) pool assigns an IP. I don't want that. I only want the (public) pool to assign IPs if the device is connected through that one open AP, and deny any other unknown clients that connect through any other means.
Is that possible? _______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Ashley M. Kirchner < [hidden email]> wrote:
> Our network has three different access points (AP), all of them connected to the same subnet. Two of them are being used for the employees in the building, and the third one is a guest AP. DHCPd is currently configured so that all the pools are denying unknown-clients. For the public AP, I have to create a (public) pool that does allow unknown-clients, but how would I restrict that pool to only assign IPs to devices connecting through that one AP? Right now if any unknown client connects through the other APs or directly through the network, that (public) pool assigns an IP. I don't want that. I only want the (public) pool to assign IPs if the device is connected through that one open AP, and deny any other unknown clients that connect through any other means.
>
> Is that possible?
To do what you want as written will need a managed switch that can add circuit-id to DHCP requests, then you can manage pool availability from that.
But - this is rubbish from a security PoV. Unless you have other measures in place (in which case I doubt you'd be asking the question) then any client can manually configure an address and access the network - and finding out the required details is fairly trivial to do.
I would suggest some re-engineering of the network would be a better course of action.
Split the guests off onto a separate network - then you can stop them accessing your internal network as they can right now. Then DHCP would simply manage it as two different subnets. To do that just needs a spare port on a router.
Better would be to offer both networks across all the APs. Many APs support multiple SSIDs (wireless networks), using a different VLAN for each SSID. With a managed switch, you trunk the VLANs required to the AP, and it's logically much the same as having multiple switches and multiple sets of APs - again from the DHCP PoV it's just two (or more) subnets.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Unfortunately we have neither a managed switch, a spare router port, nor the ability to use VLANs on the current equipment. While the individual APs themselves are capable of being configured to use a VLAN id, the "router" as it is, is simply a multi-homed machine, not a managed switch. And while I can probably add another NIC to it, I was hoping not to have to do that. So it seems, from what you are suggesting, that my only options are to either:
a) add another NIC to the current multi-homed machine and configure that as the guest network with a completely different subnet, or b) get a managed switch with VLAN capabilities (not likely to happen), or alternatively c) say screw it, and deal with the limitations I'm facing and face the consequences ... heh. _______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Ashley M. Kirchner < [hidden email]> wrote:
> Unfortunately we have neither a managed switch, a spare router port, nor the ability to use VLANs on the current equipment.
That is something of a limitation !
> While the individual APs themselves are capable of being configured to use a VLAN id, the "router" as it is, is simply a multi-homed machine, not a managed switch. And while I can probably add another NIC to it, I was hoping not to have to do that. So it seems, from what you are suggesting, that my only options are to either:
> a) add another NIC to the current multi-homed machine and configure that as the guest network with a completely different subnet, or
> b) get a managed switch with VLAN capabilities (not likely to happen), or alternatively
> c) say screw it, and deal with the limitations I'm facing and face the consequences ... heh.
That about sums it up !
But don't dismiss the managed switch - we're not talking big money here. There are many small switches which will do the job - eg Netgear GS110TP is one I've used, and also does PoE which is handy for APs :-) I think the GS108PE is now cheaper. Other manufacturers (TP-Link, D-Link, Linksys, ...) also do some small "budget" switches.
Then, depending on the capabilities of your "router", convert the current inside port to a VLAN trunked port and it can run multiple virtual LANs on the one NIC.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Re: Assign IP Range to specific AP
A used manged vlan switch off of the bay is like <$100. [Example. Dell Powerconnect 3448]
[That's a 10/100, but unless you've got pretty high-end AP's the speed should be adequate.]
GbE managed switches aren't a lot more. [$200-300 tops, IIRC]
"Facing the consequences" seems to imply a lot more lost value/cost than a few hundred dollars, so it seems like a trivial decision, IMO. [But I don't know your limitations.]
-Greg
|
Unfortunately we have neither a managed switch, a spare router port, nor the ability to use VLANs on the current equipment. While the individual APs themselves are capable of being configured to use a VLAN id, the "router" as it is, is simply a multi-homed machine, not a managed switch. And while I can probably add another NIC to it, I was hoping not to have to do that. So it seems, from what you are suggesting, that my only options are to either:
a) add another NIC to the current multi-homed machine and configure that as the guest network with a completely different subnet, or
b) get a managed switch with VLAN capabilities (not likely to happen), or alternatively
c) say screw it, and deal with the limitations I'm facing and face the consequences ... heh.
On Mon, Apr 25, 2016 at 9:09 AM, Simon Hobson <[hidden email]> wrote:
Ashley M. Kirchner <[hidden email]> wrote:
> Our network has three different access points (AP), all of them connected to the same subnet. Two of them are being used for the employees in the building, and the third one is a guest AP. DHCPd is currently configured so that all the pools are denying unknown-clients. For the public AP, I have to create a (public) pool that does allow unknown-clients, but how would I restrict that pool to only assign IPs to devices connecting through that one AP? Right now if any unknown client connects through the other APs or directly through the network, that (public) pool assigns an IP. I don't want that. I only want the (public) pool to assign IPs if the device is connected through that one open AP, and deny any other unknown clients that connect through any other means.
>
> Is that possible?
To do what you want as written will need a managed switch that can add circuit-id to DHCP requests, then you can manage pool availability from that.
But - this is rubbish from a security PoV. Unless you have other measures in place (in which case I doubt you'd be asking the question) then any client can manually configure an address and access the network - and finding out the required details is fairly trivial to do.
I would suggest some re-engineering of the network would be a better course of action.
Split the guests off onto a separate network - then you can stop them accessing your internal network as they can right now. Then DHCP would simply manage it as two different subnets. To do that just needs a spare port on a router.
Better would be to offer both networks across all the APs. Many APs support multiple SSIDs (wireless networks), using a different VLAN for each SSID. With a managed switch, you trunk the VLANs required to the AP, and it's logically much the same as having multiple switches and multiple sets of APs - again from the DHCP PoV it's just two (or more) subnets.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users |
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Yeah, I hear you guys. I have a list of TODOs for this year, and one of them is a complete swap-out of the aging "router" in favor of an Ubiquity EdgeRouter, particularly since the APs are also Ubiquity UniFi APs. And everything is on track to be done in the next several months, except this third AP is the wrench that got thrown in recently and it simply "has to be done now" as I've been told by the higher ups. So I have to find a way to make it work now. I'm looking into just adding another NIC to the current "router" and doing it that way. The problem there is that I would have to also move my desktop machine onto that subnet just to configure the AP ... (breathe, I need to just breathe)
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Re: Assign IP Range to specific AP
Hey, as long as I'm beating the dead horse... :)
Again, I don't know your situation, but if your job is asking you to sacrifice security and can't cough up, say, $500 to fix this problem right, then, IMO, I would be looking for another job. Their priorities are just _really_ not in the right place. [Unless, I guess, that $500 might bankrupt the company - but if that's the case, your job stability looks very bad.]
Heck, your time alone, in struggling to cobble the thing together, is probably worth more than the cost of the equipment, unless you work _really_ cheap.
I was young and naive once and I remember making similar compromises and trying to save a buck by doing things that seemed to make sense at the time - and in retrospect were just nuts.
Resist the urge Luke!
Summary: I'll just say - make the best of what you've got.
But if these scant few hundred dollars is going to break the bank, IMO, something's really wrong.
But most of all, good luck! [Seriously - that's not snark.]
-Greg
|
Yeah, I hear you guys. I have a list of TODOs for this year, and one of them is a complete swap-out of the aging "router" in favor of an Ubiquity EdgeRouter, particularly since the APs are also Ubiquity UniFi APs. And everything is on track to be done in the next several months, except this third AP is the wrench that got thrown in recently and it simply "has to be done now" as I've been told by the higher ups. So I have to find a way to make it work now. I'm looking into just adding another NIC to the current "router" and doing it that way. The problem there is that I would have to also move my desktop machine onto that subnet just to configure the AP ... (breathe, I need to just breathe)
On Mon, Apr 25, 2016 at 9:38 AM, Gregory Sloop <[hidden email]> wrote:
A used manged vlan switch off of the bay is like <$100. [Example. Dell Powerconnect 3448]
[That's a 10/100, but unless you've got pretty high-end AP's the speed should be adequate.]
GbE managed switches aren't a lot more. [$200-300 tops, IIRC]
"Facing the consequences" seems to imply a lot more lost value/cost than a few hundred dollars, so it seems like a trivial decision, IMO. [But I don't know your limitations.]
-Greg
|
Unfortunately we have neither a managed switch, a spare router port, nor the ability to use VLANs on the current equipment. While the individual APs themselves are capable of being configured to use a VLAN id, the "router" as it is, is simply a multi-homed machine, not a managed switch. And while I can probably add another NIC to it, I was hoping not to have to do that. So it seems, from what you are suggesting, that my only options are to either:
a) add another NIC to the current multi-homed machine and configure that as the guest network with a completely different subnet, or
b) get a managed switch with VLAN capabilities (not likely to happen), or alternatively
c) say screw it, and deal with the limitations I'm facing and face the consequences ... heh.
On Mon, Apr 25, 2016 at 9:09 AM, Simon Hobson <[hidden email]> wrote:
Ashley M. Kirchner <[hidden email]> wrote:
> Our network has three different access points (AP), all of them connected to the same subnet. Two of them are being used for the employees in the building, and the third one is a guest AP. DHCPd is currently configured so that all the pools are denying unknown-clients. For the public AP, I have to create a (public) pool that does allow unknown-clients, but how would I restrict that pool to only assign IPs to devices connecting through that one AP? Right now if any unknown client connects through the other APs or directly through the network, that (public) pool assigns an IP. I don't want that. I only want the (public) pool to assign IPs if the device is connected through that one open AP, and deny any other unknown clients that connect through any other means.
>
> Is that possible?
To do what you want as written will need a managed switch that can add circuit-id to DHCP requests, then you can manage pool availability from that.
But - this is rubbish from a security PoV. Unless you have other measures in place (in which case I doubt you'd be asking the question) then any client can manually configure an address and access the network - and finding out the required details is fairly trivial to do.
I would suggest some re-engineering of the network would be a better course of action.
Split the guests off onto a separate network - then you can stop them accessing your internal network as they can right now. Then DHCP would simply manage it as two different subnets. To do that just needs a spare port on a router.
Better would be to offer both networks across all the APs. Many APs support multiple SSIDs (wireless networks), using a different VLAN for each SSID. With a managed switch, you trunk the VLANs required to the AP, and it's logically much the same as having multiple switches and multiple sets of APs - again from the DHCP PoV it's just two (or more) subnets.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users |
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users |
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
"Ashley M. Kirchner" < [hidden email]> wrote:
> Yeah, I hear you guys. I have a list of TODOs for this year
Don't we all :-(
> ... the APs are also Ubiquity UniFi APs.
Good choice IMO - I've put a lot of those in.
> ... I would have to also move my desktop machine onto that subnet just to configure the AP ...
Ah, you don't :-)
See https://help.ubnt.com/hc/en-us/articles/204909754-UniFi-Layer-3-methods-for-UAP-adoption-and-managementI can vouch for both DHCP and SSH methods working. Just tell the AP where the controller is, and as long as the routing and firewalling permits it, they'll talk just fine.
I think the easiest way to handle things until you get VLAN capability is to configure the guest WiFi as a separate site on the controller - that way it's settings won't clash with those of the office WiFi. When you get the network sorted, you can un-adopt the guest WiFi AP and adopt it into the main site config - and configure the VLANs to suit.
> (breathe, I need to just breathe)
Now you're just being greedy :-)
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Gregory Sloop < [hidden email]> wrote:
> Again, I don't know your situation, but if your job is asking you to sacrifice security and can't cough up, say, $500 to fix this problem right, then, IMO, I would be looking for another job.
I didn't read it as being so much the money, as that there are plans to sort out the network "real soon now" and this is a "bung it in now to tide us over" move until that happens. I think we've all been in situations where we're working hard to sort out a mess, but need to do "quick fixes" in the meantime even though we don't have time for it.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Quick update:
Turns out the current "router", which is a multi-homed machine, had an available port on it (it's a rack server with two dual-port NICs in it, I put those in ages ago ... phew!) So I went that route, configured the available port as a different subnet, configured DHCPd and iptables to isolate it from everything, connected the guest AP to that, adopted, configured, et voila. I can see and mange it from the regular internal network that we're all on, without needing to move my system onto the guest subnet. For the time being, crisis resolved.
Thanks everyone for your wise comments and suggestions! _______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
"Ashley M. Kirchner" < [hidden email]> wrote:
> Turns out the current "router", which is a multi-homed machine, had an available port on it (it's a rack server with two dual-port NICs in it, I put those in ages ago ... phew!) So I went that route, configured the available port as a different subnet, configured DHCPd and iptables to isolate it from everything, connected the guest AP to that, adopted, configured, et voila. I can see and mange it from the regular internal network that we're all on, without needing to move my system onto the guest subnet. For the time being, crisis resolved.
Result !
Glad you got it sorted.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
Locked
