How to configure Wifi client isolation with multiple access points while the server/gateway needs to know the MAC of each client?

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi,

I've tried searching for this on the internet but have not found a fitting solution so far.

We offer internet access to our clients via a hotspot solution of an external company. They supplied us with a small PC that creates a tunnel to their servers on the internet and presents itself as a normal router (dns-server, dhcp-server, gateway) to the client devices.

If a client tries to access the internet and is not logged in then instead of whatever page they try to surf to a login page is displayed. The check whether a client is logged in or not is done via the MAC address of the client, so it is important that the server sees the MAC of each client.

Currently we have 8 access points. All of them running OpenWrt and all set up as dumb APs with the hotspot SSIDs bridged to the network the server is connected to.

My big problem is that while I can tick the box so that clients are isolated per access point they are of course still able to see the clients connected to other access points.

I was thinking about removing the bridge and instead doing some magic in the firewall settings so that clients of the hotspot SSID can only access the IP of the server and nothing else. But doesn't that create separate networks and the server would only ever see the MACs of the access points?

So basically what I'm asking for is if there is a solution where i can limit access of all clients to the IP address of the server while keeping the ability that the clients' MAC addresses actually reach the server. And can this be done without changing any configuration on the server?

2

If you put your own router between the ISPs device, and the dumb APs, the ISPs router will only be able to see the MAC of your router.

This means only the 1st device connecting via your router will have to authenticate it, not itself.

3

Some managed switches support L2 port isolation schemes; this allows you to restrict traffic between ports even on the same VLAN. Here's an example howto for Zyxel enterprise class switches of the scenario you're describing; presumably this would work if you connect your APs to the vendor's server via this switch. (Note this feature is not available on the GS1900 series I have, which is more of a SOHO-class switch. Obviously you'd need to research that a switch can do what you want before buying it.)

Edit: here's a TP-Link L2 switch document on the same subject.

1 Like
4

You can do this with ebtables.

ebtables -t filter -A FORWARD -i "$lif" --logical-out br-lan -j DROP
ebtables -t filter -A INPUT -i "$lif" -p ARP -j ACCEPT
ebtables -t filter -A INPUT -i "$lif" -p IPV4 --ip-protocol udp --ip-destination-port 53 -j ACCEPT
ebtables -t filter -A INPUT -i "$lif" -p IPV4 --ip-protocol udp --ip-destination-port 67 -j ACCEPT
ebtables -t filter -A INPUT -i "$lif" -p IPV4 --ip-destination $lan_ip -j DROP

Where $lif is wlan0 for example. And $lan_ip is the router itself.

1 Like
5

That is the exact opposite of what I want to accomplish.

I'm not the end-user trying to circumvent "auth per MAC". I'm the guy running the local network and want to enforce "auth per MAC".

But I also don't want end-users connecting to each other so users with malicious intent at least have a harder time.

6

This does sound like it might be the solution.

I haven't worked with ebtables yet. Can you quickly explain what each lines does? I have an idea about what they might mean but am absolutely not sure.

7

It's not clear to me that there's anything you can do with ebtables on the APs that would prevent wireless clients on different APs and the same subnet from ARPing each other via the switch fabric.

However, I think you could use ebtables to accomplish it on an OpenWRT supported switch without investing in a potentially expensive enterprise L2 switch; but I have not tried this. If I'm not mistaken it would require a switch supported by DSA, so that each switch port can be treated as a separate interface without recourse to VLANs. Again, the goal is Layer 2 port isolation on the switch that is shared by all APs, such that the APs cannot reach each other at the ethernet frame level; they can only reach the upstream provider's router. (If the APs are not on a common switch it might get trickier depending on your exact topology.)

8

After thinking further it’s not quite right for what you’re after. We use those lines for separating a guest network on the same device (not an AP). A variation might work though.

For clarity though, lines:

  1. If a packet comes in from the wifi interface and is destined for the LAN bridge, drop it (i.e. only let them forward to WAN, which is where this comes unstuck for your AP scenario)
  2. ARP requests destined for the router coming in from the wifi interface are allowed
  3. DNS is allowed
  4. DHCP is allowed
  5. All other traffic destined for the router itself is dropped (i.e. don’t let them access the web interface or other services the router itself is hosting/providing)
9

If I can't get this working on each AP then I will try and get something like an Edgerouter X with OpenWrt on it.

But why wouldn't this work with VLANs? After all I can create an interface per VLAN and bridge them all together and then do ebtables magic on that bridge, right?

10

It's more a question of why you would want to use VLANs. They don't contribute to the solution in any way I can see, more an unhelpful complication. All you want to do is -- on the switch that links the AP to the uplink, if no one has a better idea -- say at the L2 level, "all the ports in a certain set can to talk to this other port, but not to each other". And VLANs don't help with that.

Edit: for completeness, VLANs will put your APs on different networks; from the provider upllink and/or from each other. You don't want that; they are on the same network and you don't want to mess with that. You just want to isolate them from each other on the switch at Layer 2 while still allowing them to interact with the uplink.

11

Yes, but the APs don't have separate cable runs to a central location. I have 4 simple smart switches daisy-chained together and already using VLAN to separate three different networks. And the 9 different APs and the hotspot server are connected to the respectively closest switch. One VLAN is for managing the APs, one VLAN is connected to the "internal" SSID and one VLAN is connected to the hotspot SSID.

So I'm going to use VLANs anyway if I'm going to use a central OpenWrt device like you suggested.

And they are only separated into different networks until they are bridged at that central OpenWrt device where some kind of ebtables magic is hopefully able to prevent inter-bridge communication.

I don't see the difference to using DSA where I would need a device with 10 ports AND a managed switch with 10 ports just to temporarily make all of those VLANs untagged and then join them back together in a bridge. Okay, the difference is a lot more money, but from a software standpoint it should be the same.

12

Okay, as I said, was making some simplifying assumptions about your topology. I can't make solid enough inferences about your situation from that description to contribute further.

BTW I wasn't suggesting both a managed switch and a DSA-capable OpenWRT device, rather using the latter in place of the former, since you'll be able to run arbitrary commands on it. But again, it sounds like you've got some complexity built into your present design that affects this in ways I can't really guess at.

13

I think you're thinking about this the wrong way.

What you're thinking about is that I have some number of APs connected with a physical cable per device to an OpenWrt device.

And I would be literally doing the same thing just with VLANs.

Whether the interfaces are called "lan1" and "lan2" or "eth1.1" and "eth1.2" doesn't really matter.