Collections is a hassle. We are thinking about simply forcing subscribers who have not paid their bill to a captive hotspot where they can pay etc.
I am curious if anyone has ideas on how to do this. We do not want regular clients who have accounts in good standing to go through the hotspot controller in any way. We have thousands of users and do not want them all on one hotspot controller and do not want to add another point of potential failure. If the past due clients have an outage due to a problem with the hotspot controller it is not a problem. It is also quite a cpu load to put everyone through the controller.
My best idea so far is to use mangle to tag packets from the client in the AP based on MAC address of the Proxy Arp based CPE. Then put the tagged packets in an IPIP tunnel to send them to the hotspot controller. This however will not work the way I would like and creates other issues.
I also thought about setting up Virtual APs and putting the offenders on that and tunneling or routing that directly to the hotspot controller. But this has the problem of the CPE being on a different segment from it’s default gateway.
Another idea I am investigating is to tunnel from the CPE itself right to the hotspot controller. The MT cpes can do this but on ubnt this is an untested solution. It is also difficult to automate.
The client is typically on a ubnt cpe but some are also on MT CPEs using WDS. The UBNT cpes are easier to work with in this case as all the clients traffic originates from the MAC of the CPE which we already track and use for radius. The WDS clients are harder as their MAC can be anything. I really wish Proxy arp bridging was supported on MT but that is another issue. The clients are nearly all on DHCP so filtering/mangle based on the client’s ip address(s) is not a simple matter.
If you aren’t using the web proxy, you can enable it and make a proxy access rule that denies proxying with an action of redirect to a URL you want to show those customers.
Then transparently proxy only the select clients - either by an address list, or by merit of them being dynamically assigned an IP in a range that should be redirected.
Since that will only intercept HTTP traffic it’d probably be prudent to block all or most other traffic from those IPs in different firewall rules.
You can go off MAC address, too, if you want. Mark the connection for those clients higher up and then transparently proxy everything with a connection mark. That would just potentially be a lot of rules (depending on how many people aren’t paying you) that your thousands of clients have to traverse.
Maybe combine this with RADIUS DHCP, where you could assign a range based on payment status. Or - the cheap way - set static DHCP bindings based on customer MAC address and use that range to identify them. I’m not familiar with how MT wireless works and how you could identify WDS clients, though.
Marking DHCP is a problem again as the DHCP is assigned to the client’s router and I have no record of what the mac addresses are of my client’s devices in their homes. Also they could just change the mac of their router/pc and bypass the captiveness.
I think I can get 80% of the way there if I can somehow tag the packets when they arrive in the AP from the client. I can identify the traffic ok, I just need a tag that will stay on the packet that an upstream router can act on and will pass through the routers in between without being removed.
Maybe I figure out some way to tunnel this? I have also never tried passing a vlan tagged packet through a router. Not sure if that even makes sense.
For the MT client devices, I think I can easily tunnel the clients eth directly to the hotspot controller and retain access to the admin interface on the MT on it’s original IP.
Without a tunneling protocol on the ubnt radios it is trickier.
Your idea of the proxy was a good one and got me looking in that vein. The piece that I am trying now is using NAT or firewall in the AP to redirect port 80 traffic to the proxy based on the client’s src mac address.