3

I am trying to set up an authentication system for home WiFi that is agnostic about what access point/router is being used. This authentication system will closely follow the captive portal model, but I don't believe the details of the (custom) captive portal are important.

In order to accomplish this, I'd like to host the captive portal and authentication on an inexpensive device (like a Raspberry Pi). However, after they authenticate themselves, I would like the users to be reconnected to a different access point. That is, the Raspberry Pi would only perform the authentication step, but would not act as the normal-usage access point for authenticated users. Again, optimally this would work with any access point/router which has a normal password-protected WiFi network.

Here is the desired login flow for this project:

  1. User connects to the WiFi-enabled Raspberry Pi
  2. User is directed to a captive portal site hosted on the Pi and logs in
  3. (Assuming authentication is successful) User is disconnected from Pi and connected to main access point
  4. User can now browse the web as normal

Are there any methods for accomplishing this sort of thing? I am aware of how to set up a Raspberry Pi to act as both the access point and captive portal, but not just as the captive portal.

Improve this question

3 Answers 3

Reset to default
1

This is not really feasible to do this securely although it may be possible using a 'Rube Goldberg' type arrangement.

I guess it could be done - crudely - by customising a DHCP router on the PI and providing a short lease time until released- and modifying the IP address handed out (and not enabling DHCP on the router) - but then you would have a huge battle ensuring this can't be bypassed with some simple static addressing.

You may be able to largely achieve something similar with the co-operation of the router to disallow port DNS (port 53 requests) onto the WAN from any device other then the captive portal - and handing out the captive portal DNS with DHCP, and have the captive portal provide DNS responses for itself until the user is released. This could be subverted with a simple VPN or tunnel though.

Its a lot harder then it looks (Something I'm playing with in my spare time - so not much!) , but depending on your router, would something like "Wild Dog" - which is built in to modern versions of DD-WRT - work for you - it would appear that the router does the underlying capturing, and hands off the portal work to another device.

Improve this answer
2
  • Unfortunately, it doesn't look like my router supports DD-WRT. Correct me if I'm wrong, but it seems like the handoff may be the biggest barrier based on your answer. I'm not opposed to the "handoff" being manual on the client's side. Essentially, the capability I'm looking for here is the ability to grant the user access to the main router once they've passed a custom captive portal in a router-agnostic way. That is, I'm okay with forcing the user to manually disconnect from the Pi and reconnect to the router, so long as no shared secret is required.
    – phepp
    Commented Mar 10, 2018 at 23:12
  • 1
    I understand what you are trying to do (but not the use case), and am politely trying to point out that it does not make sense. With your level of networking the best solution is probably to put a captive portal/second router behind your main router.
    – davidgo
    Commented Mar 10, 2018 at 23:30
0

Given that OpenBSD runs on Raspberry Pi, you can use authpf to let each user authenticate his/her session with pubkey/password, and let such authenticated clients pass through the firewall - it really works best directly on the router responsible for filtering however. See https://www.openbsd.org/faq/pf/authpf.html , and google for examples of implementations.

More userfriendly option is something like https://coova.github.io/CoovaChilli/ It appears to be actively maintained, and has RADIUS support.

Improve this answer
0

Again, optimally this would work with any access point/router

Access points handle Wi-Fi (link layer), routers handle IP (network layer). Although they're often combined into a single plastic box, they still perform two distinct functions.

So the idea of captive portals is that a device along the regular path of the packets intercepts them and generates a fake "redirect" response, which tells the user they have to visit the login page. The redirection could be done by:

  • the default gateway (router), by intercepting the entire TCP connection using iptables (the most common method);
  • the DNS server, by returning fake DNS lookup replies which point to the "captive" server (unreliable and very easy to bypass);
  • the access point or switch, by rewriting packet headers so that the packet reaches a different gateway (very rare but technically possible)…

In any case, however, your "captive portal" Raspberry has to be inserted into the regular path. Even if you build it using the "fake DNS server" method (which handles very little traffic, but is also very easy to bypass), at minimum you would need to reconfigure the main router to provide your Raspberry's IP address via DHCP.

(And many cheap wireless routers don't actually allow you to configure that – I guess you'd have to turn off the regular DHCP service, and serve DHCP entirely from the Raspberry as well.)

So in short, no, I don't believe a "plug and play" captive portal device is possible to implement in this manner.

In fact, it has major issues from a security point of view. If it were possible for a Raspberry Pi to simply connect and somehow intercept everyone's traffic, with no router configuration... then it would also be possible for any rogue client with malware to simply connect and intercept everyone's traffic.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .