OpenWrt Forum Archive

Topic: Control dumb APs on separate subnet without changing IPs?

The content of this topic has been archived on 6 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello,

I have the following setup at my organization:

  • Outbound Internet access given by a corporate router that only our provider can configure (all I can do is power cycle it).

  • Several switches to connect Ethernet-based workstations to the router.

  • Four OpenWrt dumb wireless APs configured as per this guide, one connected directly to the router, the others with the aforementioned switches in between.

The router delivers addresses in the 10.20.30.0/24 range. I have configured the access points' LAN interface to use 192.168.99.0/24 in order to completely avoid collisions. Whenever I need to access LuCI or SSH, I change my workstation's IP to 192.168.99.123/24, do my work, then switch back to DHCP.

That works very well. But my question is, is it possible to somehow have access to the APs without having to change subnets, i.e. reach 192.168.99.0/24 from my 10.20.30.0/24 address? While OpenWrt is very stable for this task and requires zero maintenance, I also have MAC filtering enabled so that only authorized employees may connect (I am aware this can be easily worked around, but in practice it has been very effective), and the whitelists must be updated regularly. Having to change to the other subnet regularly is cumbersome, and renders my workstation with no Internet access until I finish the task.

I only control them from a single computer, so solutions like static IP routes or ARP mappings, if that's involved, are acceptable. I know the best approach would be put another OpenWrt device or a Linux server between the APs and the router and centralize all filtering there, but that's a no-go at the moment.

Thanks in advance!

Bumping this. It's probably a pretty easy task, but these access points are already wall-mounted, so having to take them down to enter failsafe mode and such would be a hindrance.

Why don't you just let your APs get an IP address in the 10.20.30.0/24 range?

I thought of that, but I need to be completely sure there won't be any collisions with the main network. If one of the APs is ever down or rebooting, and the router's DHCP assigns its usual address to someone else in the meantime, then it would become unreachable.

It's also a bit more secure if the LuCI and SSH are isolated from the rest of the network and only respond to 192.168.99.0/24 (but that's not the only security measure in place, of course).

Dumb AP's can also grab an IP address from the DHCP server... you lose the "security", but there will be no collisions.

If someone can hack into a SSH server configured to accept only key-based authentication, then changing the IP address is not going to stop them.

I have some suggestions

1 - Set up one of your APs as a router on the ISP box, and then hang the other APs off of that.  Your router's WAN will get the one and only DHCP IP given by ISP's device.  You will then have your own OpenWrt network all on it's own subnet and can substantially ignore the ISP hardware.  There may be some issues with apps that need port forward I think. 

2 - Check to see what range your clients are getting from your ISPs router.  You can try assigning the APs a fixed IP value away from the DHCP clients.  The ISP router probably starts at  10.20.30.2 or  10.20.30.100.  Try  10.20.30.231-234 or such.  Yes, you are on the ISPs subnet.

3 - if it's a true Router you can try taking it out and replacing it with an OpenWrt router.  I know this works with Verizon routers.  You may need to clone the ISP's MAC to the OpenWrt device. (I did not)

Thank you for the thorough replies!

eduperez wrote:

Dumb AP's can also grab an IP address from the DHCP server... you lose the "security", but there will be no collisions.

If someone can hack into a SSH server configured to accept only key-based authentication, then changing the IP address is not going to stop them.

Getting an IP via DHCP sounds good, if I can combine it with registering the APs' hostnames on the local DNS, to e.g. connect to LuCI via https://apnumberone/ instead of hunting down the assigned addresses. How do you go about doing it? Is it enough to make eth1 a DHCP client at the same time it's bridged with eth0 and wlan0, or is something more advanced required?

I know subnet isolation is not bulletproof as a security measure, so it's something I'm willing to give up if necessary.

RangerZ wrote:

I have some suggestions

1 - Set up one of your APs as a router on the ISP box, and then hang the other APs off of that.  Your router's WAN will get the one and only DHCP IP given by ISP's device.  You will then have your own OpenWrt network all on it's own subnet and can substantially ignore the ISP hardware.  There may be some issues with apps that need port forward I think. 

2 - Check to see what range your clients are getting from your ISPs router.  You can try assigning the APs a fixed IP value away from the DHCP clients.  The ISP router probably starts at  10.20.30.2 or  10.20.30.100.  Try  10.20.30.231-234 or such.  Yes, you are on the ISPs subnet.

3 - if it's a true Router you can try taking it out and replacing it with an OpenWrt router.  I know this works with Verizon routers.  You may need to clone the ISP's MAC to the OpenWrt device. (I did not)

Replacing their router with our own would be the best solution, but it's been tried and it doesn't work. You get zero connectivity if you connect anything else to the fiber converter, MAC cloning and all. I would guess they use SNMP or similar to make sure only their equipment can get online.

Putting an OpenWrt router between the provider's and the rest of the network is the second best choice, and one I'm highly looking forward to. For various reasons, it's not a short-term goal, but it could be done some months from now. Centralizing all filtering on a single device would solve the problem at hand, create less further work, and give me more control over the network. Our provider is already using carrier-grade NAT and none of our services needs to be reachable from the global Internet anyway, so port forwarding wouldn't be a problem.

In the meantime, your second suggestion sounds pretty good. We have approximately 40 Ethernet workstations, plus a couple dozen wireless clients connected at any given time, so high addresses like 10.20.30.251-254 are probably very unlikely to be assigned. I'll check it next week.

johndoe wrote:

Thank you for the thorough replies!

eduperez wrote:

Dumb AP's can also grab an IP address from the DHCP server... you lose the "security", but there will be no collisions.

If someone can hack into a SSH server configured to accept only key-based authentication, then changing the IP address is not going to stop them.

Getting an IP via DHCP sounds good, if I can combine it with registering the APs' hostnames on the local DNS, to e.g. connect to LuCI via https://apnumberone/ instead of hunting down the assigned addresses. How do you go about doing it? Is it enough to make eth1 a DHCP client at the same time it's bridged with eth0 and wlan0, or is something more advanced required?

I know subnet isolation is not bulletproof as a security measure, so it's something I'm willing to give up if necessary.

Yes, you just have to change your interface from a fixed IP configuration to a DHCP client configuration; since you bridged them all together, there should be just one interface to configure.

Being able to assign a name to each IP address depends on the "main" router. I would configure it to assign a fixed IP address to each AP, and also a specific name. But I do not know how much can you tinker with it.

eduperez wrote:

Yes, you just have to change your interface from a fixed IP configuration to a DHCP client configuration; since you bridged them all together, there should be just one interface to configure.

Thanks, I'll try it and get back with the results.

Being able to assign a name to each IP address depends on the "main" router. I would configure it to assign a fixed IP address to each AP, and also a specific name. But I do not know how much can you tinker with it.

I have zero control over it, unfortunately. However, all workstations on the network can be reached through their Windows computer name, so all I need to do is find OpenWrt's equivalent of "Register this connection's addresses in DNS".

johndoe wrote:

... so all I need to do is find OpenWrt's equivalent of "Register this connection's addresses in DNS".

Your search is misguided.

DNSmasq, an OpenWrt convenience package, will solve your quest.

Open OpenWrt and go to the Status page (default).  Find the Hostname value (default is  "OpenWrt").  I think you should make them all different if they are not. (AP1, AP2, etc).  Save and reboot.

In your browser enter:  //[hostname] or http://[hostname]

Unclear if this will work in your config or not, but does in a vanilla landscape.

RangerZ wrote:

In your browser enter:  //[hostname] or http://[hostname]

Shockingly presumptuous that the APs are registered with a local DNS.

Max Hopper wrote:
RangerZ wrote:

In your browser enter:  //[hostname] or http://[hostname]

Shockingly presumptuous that the APs are registered with a local DNS.

You're welcome to contribute a more universal solution or pfo.

The provider's router's DHCP pool seems to go from .20 to .200. I gave the four access points very high fixed addresses, immediately below broadcast. This works fine (no collisions so far) and I can access them without changing my IP now.

I will soon switch them to DHCP clients, and research how to register them with local DNS if necessary.

The discussion might have continued from here.