Posted: Fri Jan 29, 2016 1:22 Post subject: Redirect all traffic to local webserver
Hi everyone,
I wonder if anyone has has any suggestions on how to set this up:
I have a Raspberry-PI hosting a small safety information site for a project and I want anyone that connects to the dd-wrt Wifi to get redirected to the local website similar to a hotspot login page. In addition, if they try to access any other website in their browser, they will get redirected to the webserver.
The router is NOT connected to any Internet connection and it's purely used to show safety information..
The setup:
A beasty Linksys 1900AC @ 172.16.0.1
Raspberry Pi @ 172.16.0.2 running nginx on port 80.
Thank you very much for this detailed and explanatory reply eibgrad, much appreciated!
I understand what you mean now, so I guess I have to look into either a proxy or captive portal. Which one would you use in this scenario?
I'm running the website on a Raspberry Pi so I have the ability to install things on that one too.
Also, I had a quick look into the captive portal option inside dd-wrt, but it seems like one of them had a limit of 50 user? I need something that could work up to 500 concurrent connections(worst case).
Anyway, the only way I know of to make this work halfway decently is to use either a proxy server (privoxy, squid, etc.) or captive portal. Both are full-fledged applications that can deal w/ all these caveats.
I had a look into using NoCatSplash which seem to be able to achive what I require, BUT.. upon reading it says that NoCatSplash needs an active internet connection which unfortunatly in not gonna be availible for this setup .. any ideas?
Code:
In order for NoCatSplash to display the splash page, the DD-WRT enabled device must have both of the following:
The more I think about it, I'm not sure even a captive portal will help. At least for the issue of https.
A captive portal is never the target of the user's request. It just gets into the middle of the transaction and requires a login to proceed. Once authenticated, the transaction is allowed to proceed to its *original* target, without changes.
And let's consider the purpose of using https. Besides providing authentication and encryption, it's also meant to prevent MITM (Man In The Middle) attacks.
Well, what you're trying to do here is effectively engineer a MITM attack (albeit for benign purposes). But obviously the protocol doesn't care about your intentions. It's just not going to allow this to happen.
The way this works in business, for example, is they will install their own SSL/TLS certificates in their various own devices using the same domain names as Google, Yahoo, etc., or just one that applies to everything (0.0.0.0/0). The client is forced over a local proxy which then decrypts the SSL/TLS packets, does whatever they want to do w/ the information contained therein (e.g., log it, or perhaps even deny access to the actual target), and the proxy becomes a client of the actual target (Google, Yahoo, etc.) on your behalf using the *real* Google, Yahoo, etc., SSL/TLS certificate.
IOW, the employer engineers a MITM attack by actually messing w/ your clients root certificate store so his own proxy/portal can handle it. But obviously that's only possible when the entity engineering the MITM attack controls the client platform.
So it's a tough problem to solve. The very purpose of https is to thwart the very thing you're trying to do. And when you only control the server side of the connection, your options are very limited. And it's purposely done that way to protect the client.
You're right, wow it's a lot more complex than what I originally expected it to be. but, would it work to setup a captive portal and instead of using a log in page, just show a welcome page with a link that links to this internal website hosten on the PI (pref. with a made up domain name that resolves the local ip of the PI in case the captive splash doesnt show up and they manually could type that andress in the browser)
That sounds like a better plan. If we assume the portal works well enough to get into the middle of any transactions for authentication purposes, then it seems logical to me you could block access to the intended target (unless it just happened to match your intended target, e.g., they added it to Favorites from a prior session) and force the client to change its intentions by providing a link.
Indeed, I will now try to find a solution. Not sure if I will go for the inbuilt dd-wrt captive option or place it on the PI.Thanks for the help!
Hmm... I see a new problem.. It seems like most of the captive portal require a active internet connection to even work.. ie. it won't redirect any request unless an active internet connection is on the wan? What do you guys reckon?
Connect the RPI to the WAN Port, so that traffic to it goes through the router. The router cannot intercept traffic on the LAN.
Thanks Per, I gonna try that!
Currently have some issues..eum.. For some wierd reason, my the WAN port have stopped working on the router so I have to keep switching between my internet connection and to the linksys forth and back. I tried to reset all settings, and I can't even re-flash it to stock or another firmware (uploads 2-5% then it restarts and no flashing done.
I have Lynksys/Cisco WRT310N router running dd-wrt.sp2 (std) and I would like to know if it is possible to setup a captive portal redirection to a URL with an IP address pointing to a server on the LAN side? If so, could you please help me with a configuration example? Thanks for your help.
I'm aware that this project (thread) is already a few months old, but I'll add my two cents...
I've never worked with the captive portal in DD-WRT, but I have worked with the one that comes with pfSense. PfSense is basically a linux distribution that is programmed to be a powerful router, much like DD-WRT, but designed to be installed on a regular PC.
So, if a captive portal can work without internet connection on pfSense, it should be able to work on DD-WRT. Just make sure that ALL necessary files are hosted on a local source that is within the reach of what the user may browse without internet access. Store it on a drive that is connected to your router, or make sure that your RasPI is on the right side of your firewall.
You can even try to make the script so easy that it will authenticate itself (forward to the address that already has the right username and password inside the address line) and than make it forward to your RasPI webserver.
The only thing that will remain is that some users installed safety features on their browsers that will prevent automatic redirects. It usually helps to show a splash page with a little timer that says it will redirect you and with a manual link in case the redirect doesn't work.
For some wierd reason, my the WAN port have stopped working on the router so I have to keep switching between my internet connection and to the linksys forth and back. I tried to reset all settings, and I can't even re-flash it to stock or another firmware (uploads 2-5% then it restarts and no flashing done.