OpenWrt Forum Archive

Topic: Redirecting Clients to Web Page Before Granting Internet Access

The content of this topic has been archived on 21 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I'm sure this has been documented in a number of threads, but I must be using the wrong terminology in my searches.

Let's say I have a single LAN that gives Internet access to its clients.  What I would like to accomplish is this:
when a user connects to the LAN and gets assigned an IP, I want all of their traffic to redirect to a "login/registration" page before being allowed to access the Internet.

Basically, I want to do what hotels do, where a client opens a web browser, and they are redirected to an internal page until they enter, for example, a room number and a last name.

In reality, my setup will be much simpler, but it's more or less the same idea.

To start, I was trying to set up some iptables rules to redirect a particular client to an internal web page.

Here is my first attempt at the "/etc/firewall.user" rules:

iptables -t nat -A PREROUTING -m --mac-source xx:xx:xx:xx:xx:xx -p tcp --dport 80 -j DNAT --to-destination 192.168.1.1:81

iptables -t nat -A PREROUTING -m --mac-source xx:xx:xx:xx:xx:xx -p tcp ! --dport 80 -j DNAT --to-destination 192.168.1.1:82

iptables -t nat -A POSTROUTING -m mac --mac-source xx:xx:xx:xx:xx:xx -j MASQUERADE

This works to some extent.  While these rules are in effect, the mac address in question is redirected to my internal web page.  For http traffic, it works a treat.  For https traffic, the user is directed to the https port for my internal page, which prompts them that the certificates do not match.

This is why I bring up the hotel example.  How do they manage to redirect all traffic to an internal page without doing masquerading.  I have read that you have to use DNAT (as opposed to REDIRECT) to redirect external requests to a local address, but I don't want to do masquerading.  I'd simply like to redirect all requests, http or https, to the internal page.  Initially, I was not using MASQUERADE, and I seem to recall that the https redirects were not working at all.  Now they do, but obviously the browser thinks that it is still on the original page and indicates that the certificate is untrusted.

I will test further without MASQUERADE when I get home, but I was surprised I couldn't find more information on accomplishing this commonly-employed mechanism in OpenWrt.

(Last edited by fecaleagle on 24 Aug 2015, 20:15)

Is it the case that I need to add a POSTROUTING SNAT rule as opposed to the MASQUERADE?  I actually don't want masquerading, and I should not be changing protocols on the majority of browser traffic, because I am only directing port 80 (http) to my http port (81).  All other browser traffic should be directed to my https port (82).

Initially, my https rule only redirected 443, but Google searches via iPhone were bypassing the rule entirely, so I adopted using "! --dport 80", which I do realize is not a good assumption to make, although it does succeed at redirecting Dr. Google.

How is it exactly that hotel routers are able to redirect all traffic to an internal page so transparently?  Am I going about this all wrong?

I do not want to use NoDogSplash, as I'd prefer to be able to manage the firewall myself, but I am open to using OpenWrt firewall configuration (as documented here: http://wiki.openwrt.org/doc/uci/firewal … ombination) rather than my creating my own iptables rules if that is a better approach.

(Last edited by fecaleagle on 24 Aug 2015, 21:27)

Clever suggestion on the Nodogsplash GitHub:

https://github.com/nodogsplash/nodogspl … t-67356684

The suggestion is to send https traffic to a 302 redirect, which redirects to http, (potentially) bypassing the bad certificate warning and (definitely) changing protocol for me automatically.  Sounds like it's worth a try for sure...  I am surprised to hear that Nodogsplash does not support redirecting https to the splash page.  I thought this was standard in captive portals, but maybe I just haven't been paying enough attention.

Actually, further Googling suggests that this will not bypass the invalid certificate warning.  It basically just replicates the scenario I'm already in with the invalid certificate for my captive login page.

So, in my case, I have do have physical access to all of my clients.  Can I just install a self-signed trusted CA certificate on each client and use something like SSLsplit (https://www.roe.ch/SSLsplit) to forge certificates on the fly using my trusted CA private key, then forward the requests via the SSLsplit proxy specification to my local address?

Seems like it should work, in theory.  I only have 4 client devices that this will apply to, so trusting the self-signed CA cert is not a big hurdle for me.

Sometimes I feel like I just use this forum to talk myself through these problems.

(Last edited by fecaleagle on 24 Aug 2015, 23:03)

fecaleagle wrote:

Sometimes I feel like I just use this forum to talk myself through these problems.

sometime tolking to yourself helps big_smile
and you never know whos gonna see(need) this post later

(Last edited by makarel on 24 Aug 2015, 22:49)

fecaleagle wrote:

  Nodogsplash does not support redirecting https to the splash page.  I thought this was standard in captive portals,

this will not bypass the invalid certificate warning.  It basically just replicates the scenario I'm already in with the invalid certificate for my captive login page.

coova-chilli directly supports https-redirect as described above, in case, compiled with SSL AND special config.
After install of certificates on clients, as you can do, there should be no warnings, both in nodogsplash and coova.

(Last edited by augustus_meyer on 24 Aug 2015, 23:35)

augustus_meyer wrote:
fecaleagle wrote:

  Nodogsplash does not support redirecting https to the splash page.  I thought this was standard in captive portals,

this will not bypass the invalid certificate warning.  It basically just replicates the scenario I'm already in with the invalid certificate for my captive login page.

coova-chilli directly supports https-redirect as described above, in case, compiled with SSL AND special config.
After install of certificates on clients, as you can do, there should be no warnings, both in nodogsplash and coova.

I see.  Since it appears I can roll my own using SSLsplit, I think I will try that approach, and if it does not work for me, I will go ahead and give Nodogsplash and CoovaChilli a try.  Nodogsplash seems like a bummer, because it requires you to disable the standard firewall, which I have grown very attached to.  I will do some more reading about CoovaChilli.

Thanks for the tip!

(Last edited by fecaleagle on 24 Aug 2015, 23:52)

fecaleagle wrote:

Nodogsplash seems like a bummer, because it requires you to disable the standard firewall,

Coova-chilli does the same, as it is a "Captive Portal" :-)
Beware, lot of different, obsolete info regarding coova-chilli floating around on the web.
Either use http://coova.org/CoovaChilli OR
use linkedin in case of some community/developer support. I am there, too :-)

(Using your own certs on every client definitely is the simplest wa to go in your case.)

I'm trying for weeks to get nodogsplash working.  I only need a simple capture and redirect to a custom page that i host on a USB.  So Coova and wifidog seem to be overhead and even more complex to configure, thats why I picked nodog... But even that is enough to put me on the wrong foot.

If anyone can help me in this tread to join this tread:
https://forum.openwrt.org/viewtopic.php?id=59128
That would be very nice.   I've seen several unanswered posts about nodogsplash and I hope I can help a few people just by walking trough the inner workings of nodogsplash.  What i don't understand is how it actually captures traffic. It's mostlikely 1 simple thing that i'm not being able to see yet.

The discussion might have continued from here.