Is anyone currently implimenting a captive portal / walled garden for cable modem customers?
If so, can you give me some ideas on how you're implementing this and what the positives and negatives are of your method?
I'm looking to send our non-pay customers to a web portal where they can make a payment but can't go anywhere else. The payment system and web page isn't an issue, just how to direct cable modem customers to it.
We have a large variety of cable modems deployed - all Docsis 2.0 and 3.0 - including various Arris and Motorola models as well as some newer Cisco and older SA models. We have both bridged (traditional cable modem) and residential gateway models deployed as well as eMTA modems for voice using SIP.
If possible, I'd like to avoid an SNMP set to the modem because of the variety of modems deployed (the OID would be different on most) and the fact that a modem reset would clear that value until the next set was pushed.
Currently, a non-pay customer is updated to a 0 Mbps connection in the modem specific config file and this takes effect on the next modem reboot but, we don't have an automatic script in place to reboot modems when they provisioning file is updated.
I've never tried to do this on cable, but I have done it before for ppp connections.
A solution for cable that comes to mind would be :
- have your normal users on a bundle subinterface
- have your suspended users on a second bundle subinterface
- have different cable modem and cpe pools on each subinterface
- on the captive subinterface you could probably use private IP for CPE
- on the captive subinterface add a service policy that matches the source IP of CPE and sets the next hop
- if you have multiple CMTS then use a GRE tunnel from each with /30 subnets. Set the next-hop to the far end of the /30.
- terminate the GRE tunnels on a linux server, use iptables to redirect all incoming eg port 80 traffic to localhost
- on this linux server, in set the index.html to be something that says "please call customer service", and then symlink the 404 page to index.html
- with the route map above, maybe exclude matching for some destinations eg your dns server, or other local OK content
If you only had 1 POP, and the intercept server was on the same LAN/subnet as the CMTS, then you wouldnt need GRE, just set the next hop to the linux server...
so its looking like this so far:
int bundle1.1
desc normal users here
ip address x.x.x.1/24 secondary ! cpe
ip address 10.0.1.1/24 ! cm
cable dhcp-giaddr policy
cable helper-address y.y.y.1
int bundle1.2
desc suspended users here
ip address 192.168.2.1/24 secondary ! suspended cpe
ip address 10.0.2.1/24 ! suspended cm
cable dhcp-giaddr policy
cable helper-address y.y.y.1
ip policy route-map TO-INTERCEPT-SERVER
ip access-list extended INTERCEPT-THESE
deny ip any host y.y.y.1 ! dont redirect your dhcp tftp server
deny ip any host y.y.y.2 eq 53 ! dont redirect your dns server
deny ip any host y.y.y.3 eq 80 ! dont redirect your web server
permit ip 192.168.2.0/24 any ! redirect all other CPE traffic traffic
deny ip any any ! dont match other stuff (eg cm traffic)
route-map TO-INTERCEPT-SERVER permit 10
match ip address INTERCEPT-THESE
set ip next-hop 192.168.3.2 ! far end of GRE tunnel
OK so when a customer is suspended, change the DHCP IP of their cable modem to be one from the cm pool on captive bundle (10.0.2.x), and then kick them off (script a simple snmpset docsdevreset or even script a ssh into cmts and "clear cable modem x.x.x.x reset"). When the modem boots back up it will then land on the captive bundle. The CPE will be allocated an CPE IP from the captive bundle (192.168.2.x). Customer then tries to websurf, DNS etc works as usual but all browser traffic is matching the route-map and gets forced into the tunnel. Traffic pops out the far end of the tunnel onto the "intercept" server. Then iptables stuffs it into local apache and since there are no real pages setup every web surfing request results in 404 which actually comes back to the customer as a nice branded "please call customer service". You could add other iptables/daemons to match pop and smtp and other common requests to also return please call customer service. Other more tricky services like VPN or whatever will just be busted. But as long as you intercept port 80 at minimum the customer is going to get the message pretty quickly.
Once customer has paid bill, change the cable modem IP back to one from the main subinterface (10.0.1.x) and kick their modem off. Modem will land back on first subinterface, CPE will get a normal IP, no route-map applied and all services should be restored.
Or other (much more expensive option) would be to use a Redback or other BNG type device upstream of the CMTS with IPoE to do the captive stuff
Hope that helps!