I gave up, too many people now don’t even go to web pages. Just video streaming, phone apps, and game networks. They just perceive it as my Internet is down, they never see the redirect page because they aren’t even using a web browser. At that point, you might as well just shut them off and wait for them to call.
I’m always amazed if we have an outage, how many people call to pay their bill. From: AF <af-boun...@af.afmug.com> On Behalf Of Adam Moffett Sent: Tuesday, September 10, 2019 8:31 PM To: AnimalFarm Microwave Users Group <af@af.afmug.com> Subject: Re: [AFMUG] HTTPS redirect Ok, This is not bad at all, but only works with WiFi.....I'm on ethernet in the lab and I was sitting here beating my head like an idiot wondering why it didn't work. Just something to keep in mind. This is probably what I'll end up doing though. I appreciate the tip. On 9/10/2019 7:04 PM, Jesse DuPont wrote: Redirecting HTTPS, as you know, doesn't work because of the certificate. Even using your own certificate won't work because you can't get a trusted certificate issues that is valid for all domain names. The only think you can do is redirect them BEFORE they try to do HTTPS by triggering the captive portal detection methods in modern OS's - like they're in a hotel. https://success.tanaza.com/s/article/How-Automatic-Detection-of-Captive-Portal-works As you can see in that doc, all devices try to reach a known URL and expect to see a well-known result. If the result is different than what it expects, it assume it's behind a capture portal. We exploit this (in a non-black-hat-hacker kind-of-way). Our billing system is tied to our RADIUS server so when a suspended account authenticates, RADIUS sends an additional attribute (instead of denying it) - basically an address-list entry. We use this additional attribute on routers to treat traffic from these people differently. Primarily: 1) We DST-NAT all their DNS queries to a fake-master server which issues our "you haven't paid" landing page IP for ANY DNS query they do except for our website and billing portal, which are right (this is the first part of triggering captive portal detection - the IP returned to the OS isn't right). 2) We DST-NAT all their HTTP traffic to the proxy configured on the router, which triggers the second part of triggering captive portal detection - the HTTP server doesn't return the expected response. Also, using the proxy, we allow them to be able to reach our walled-garden content (our web page, our billing system portal) using the actual URLs, not just the IP. All other requests are redirected to our landing page. 3) In the firewall, even though we've essentially blocked it in the proxy, we only allow traffic from suspended customers to reach our landing page, our payment portal and our web site (the walled-garden). 4) Once they pay, they reboot their router and it's resolved. I can share specifics if you want. Jesse DuPont Network Architect email: jesse.dup...@celeritycorp.net <mailto:jesse.dup...@celeritycorp.net> Celerity Networks LLC Celerity Broadband LLC Like us! facebook.com/celeritynetworksllc Like us! facebook.com/celeritybroadband <file://Users/jessedupont/Google%20Drive%20File%20Stream/My%20Drive/Celerity%20Broadband%20LLC/Marketing/Celerity%20Broadband%20Final__04.12.2015/Source%20Files/Celerity%20Broadband_cv-sig.png> On 9/10/19 4:05 PM, Adam Moffett wrote: I already know the answer I think, but if you're redirection non-pay customers to a web page what do you do with (the majority) who have an HTTPS home page? do you A) present your own certificate and expect them to click through the warnings? B) Don't bother and just drop https? C) do something else? I told the boss if there was a way to do this then we should quit the ISP game and make a killing with phishing scams, but he seems to think there's a way to handle it. Thanks, Adam
-- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com
