[c-nsp] PPPoE and HTTP Redirect

Charles Sprickman spork at bway.net
Sat Oct 3 12:11:16 EDT 2020



> On Oct 3, 2020, at 2:59 AM, Eugene Grosbein <eugen at grosbein.net> wrote:
> 
> 03.10.2020 12:52, Scott Miller wrote:
> 
>> Hello all, I’m looking for some recommendations.  I have a customer, an
>> ISP, who is doing PPPoE for residential and “some” smaller business
>> accounts.  PPPoE terminated on an ASR9010, DaloRadius for authentication
>> and IP assignments.  DaloRadius is configured for static IP per customer.
>> All that is working fine.  Recently, we enabled HTTP redirect on the 9010
>> because the customer wanted to try out a walled garden for past due
>> accounts.  So, past due accounts are handed a static 10.x.x.x IP, and
>> password changed.  Next time customer re-auth’s, they get the 10.x IP
>> because of the bad pass, and put into the HTTP redirect jail, and are
>> supposed to be redirected to a http site.  “Sometimes” http redirect works,
>> sometimes it doesn’t.  It seems as though it depends on the destination
>> address the end user is trying to go to.
>> 
>> At any rate, the ISP is wanting to investigate something else for PPPoE and
>> their walled garden.  Has anyone used anything else successfully for PPPoE
>> auth, and walled garden jail?  Something that is a bit more seamless?  The
>> ISP has their own home-brewed billing/account software, and just wants a
>> redirect to their landing page to work each time when a customer is
>> disconnected for non-pay.  I have not done a lot with PPPoE myself, so
>> reaching out for possible 3rd party solutions that can do all-in-one.
> 
> I'm pretty sure the problem occurs due to HTTP/HTTPS differences,
> so for plain unencrypted HTTP user request it works but for HTTPS is does not, and should not.
> HTTPS is made to prevent such in-the-middle embedding from working.

I had some luck on wifi walled garden stuff doing the following:

- The device (in this case a Ruckus Zone Director) that does the redirect, listens
on both http and https for the redirect
- The device has a valid hostname and TLS cert for the https redirect host
- The device does NOT allow traffic to any of the hosts that apple’s, microsoft’s or android’s “am I connected to the internet?” features use
- You leverage this “am I connected to the internet” (which is NOT https, at least w/apple) check do do a 301 redirect to your own walled garden (which IS https, does have a valid cert, etc.)

I wrote up what I saw when sniffing this traffic here:

https://sporklab.com/2019/01/30/ruckus-captive-portal-packet-capture-dns-spoof-or-no/

Bottom line, it all sucks, but you can probably work something out.

Captive portal stuff relies on the conditions of the pre-https world.

Charles

> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list