Allowing just a few Internet sites onto a Walled-Garden Wi-Fi Network

[TerryC65]

Hi,

At our local Model Town, I've installed a Raspberry Pi 3 running a Webserver (nginx) to serve local content to visitors that log onto an outdoor WiFi Access Point. It works pretty well and is now running during its second season. However, there is one problem; Android devices won't connect to the WiFi (without hassle) if there isn't a path to the Internet. Originally we used a fairly successful hack whereby our Webserver spoofed the Google sites that Android attempt to access to establish that an Internet connection exists. More recent Android versions however are more fussy and required the site to be a fully validated type; not the Self-signing type that we've tried.

The Model Town is a registered charity and the Trustees are not keen to allow visitors unfettered access to the Internet, because of data costs. Some kind of IP Filtering would therefore seem to be the answer. I asked at our local LUG Meeting and SquidGuard was suggested, but presumably any firewall / net filtering solution could be used. I've found several pages on the Internet that give fairly detailed instructions on how to set up Squid Guard, but by following those, we'd end up with a system that allows access to everything except pages that contain Adult content. Not quite what we want!

As I understand it, most firewall / net filtering solutions expect that the clients will be granted access to most things, with restrictions on just a few sites, (eg a business might stop it's employees accessing Facebook or Twitter during working hours perhaps). What we want is diametrically opposite to that. We want our clients to be granted access to nothing except those few sites that Android uses to establish that it is not in a walled garden.

I'm sure that any firewall or net filter can be set up to do that, but my limited skill-set in that area is failing me at the moment; for example, the squid.conf file is very nearly 8000 lines long. On the other hand Squid Guard appears to be a bit simpler and seems to have places where I could list the allowed and barred clients and also the allowed and barred destinations. So if I can wade through squid.conf, I might be able to do something with it. However, before I invest a lot of time in that, I'd like to know:

• Is Squid Guard is the right solution (or as good as any other)?
• Will the physical architecture that I've shown below work?

Webserver_Filter.gif (31.25 KiB) Viewed 2640 times

Obviously, I can add another Pi to run the firewall / net filtration software, but it would be nice to do it on the existing Pi, which is running at low utilisation all the time.

[DougieLawson]

The thing you're looking for is a "captive portal". That way you can give limited or time limited access to the public internets.

https://github.com/nodogsplash/nodogsplash

[TerryC65]

The thing you're looking for is a "captive portal". That way you can give limited or time limited access to the public internets.

That looks very interesting and would appear to do exactly what I want from the little I've found about it on the web including the GitHub Repository.

However....

https://github.com/nodogsplash/nodogsplash

From what I can see, this would normally be run on the router. Presumably, that would mean installation on the ISP provided Office router, (probably not possible) or the use of another router running OpenWRT. Alternatively, since there are Debian instructions, presumably I could compile it to run on a Raspberry Pi. Would that work? Would it work on the architecture I suggested?

[DougieLawson]

https://pimylifeup.com/raspberry-pi-captive-portal/

[TerryC65]

https://pimylifeup.com/raspberry-pi-captive-portal/

I'd literally just found that site.

Thanks. It'll go quiet now while I get my head round all this.

[TerryC65]

Hi,

I've spent quite some time (off and on) grappling with this. The first thing I realised was that before I could get NoDogSplash to work, I would need to set the Pi up as a Wired Router. Maybe it's my Googling skills, but I was unable to find a recent Tutorial on setting up a Raspberry Pi as a wired Router. Most Router posts are about Wi_Fi Routers and the few that I found were at least 5 years old. As a result, I based my configuration on the Wi-Fi Access Point Tutorial which is a precursor to the NoDogSplash one at pimylifeup.

My first attempt resulted in a Router that routed nothing! Investigation using

Code: Select all

ip -s -d -a r

revealed that I had somehow got two default routes and the one with the highest metric was the wrong one. At first, because the problem was related to routes, I assumed that I had introduced the problem when I set up the routing using IP Tables. It took me a while to discover how to delete and / or flush rules from the IP Tables (because simply deleting the file contain the rules didn't change anything).

Then it dawned on me that if deleting all of the routes and rebooting didn't solved the problem, then it probably wasn't iptables that was causing it.

I then stumbled across a 6-year old page (http://qcktech.blogspot.com/) that discussed how to set up a wired router on a Raspberry Pi. The problem being solved was identical (eg AP connected to the RPi's Router port and the other side connected to the ISP's ADSL Router). Unfortunately this method set up the static IP address using /etc/Network/ interfaces, which in the modern versions of Raspbian contains a reference to dhcpcd.conf where I had already done it. Nonetheless I gave it a try and achieved connectivity from the Pi (browser and ping) to the Internet, but not from the AP to the RPi. In the Pi's desktop, the Network icon displays 'Connection to DHCP lost' and no interfaces when hovered over. Here is the config I'm using:

Code: Select all

# interfaces(5) file used by ifup(8) and ifdown(8)

auto lo
iface lo inet loopback

#USB NIC connecting to the Internet
auto eth1
iface eth1 inet dhcp

#Onboard NIC serving as internal gateway
auto eth0
iface eth0 inet static
address 192.168.0.9
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.9

I tried setting the gateway address to the AP instead of the RPi, but to no avail. I also took out the static address entries for eth0 from dhcpcd.conf, but also without luck.

I then studied the man page for dhcpcd.conf, but was unable to see how to exactly replicate the settings in 'interfaces'. It seems to me that the problem might be that I'm conflicting the settings that dhcpcd.conf is adding with those from interfaces, but I can't see where or how to stop it.

I'm at the point of starting again with a clean installation of Raspbian. Does anyone have any thoughts on this, or links to more modern Tutorials?

[TerryC65]

I'm at the point of starting again with a clean installation of Raspbian. Does anyone have any thoughts on this, or links to more modern Tutorials?

In the absence of any suggestions, I've been spending some time trying to sort it out myself; with mixed results. First of all, I stopped trying to use /etc/network/interfaces to define my network after I discovered a post by someone who had hit the same problem.

I then found out how to set the metric of each route and as a result, my dhcpcd.conf file contains:

Code: Select all

interface eth0
static ip_address=192.168.0.1/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
metric 200

interface eth1
metric 100

My file dnsmasq.conf contains:

Code: Select all

interface=eth0       # Use interface eth0
listen-address=192.168.0.1   # Specify the address to listen on
bind-interfaces      # Bind to the interface
server=8.8.8.8       # Use Google DNS
domain-needed        # Don't forward short names
bogus-priv           # Drop the non-routed address spaces.
dhcp-range=eth0,192.168.0.100,192.168.0.250,12h # Ethernet port, IP range and lease time
dhcp-option=3,192.168.0.1

interface=eth1       # Use interface eth1
server=8.8.8.8       # Use Google DNS
domain-needed        # Don't forward short names

Routes to and from the AP and Home router have been set up and now work.

My problem (before I get back to sorting out NoDogSplash), is that the DHCP Server only works if I restart dnsmasq after bootup and then reconnect or reboot the client. I found one other instance of that through Google, but the solution that the guy used was to put the static IP configuration back into /etc/network/interfaces (which caused me so much trouble in the first place).

I realise that I could run a script immediately after boot up to restart dnsmasq, but that seems like a kludge to me. Is there a better way?

[The Traveler]

You might consider is setting up a localized DNS nameserver and point your network router to the its address. By editing the DNS server configs, you can effectively select name resolution for those sites you want, and exclude those you don't. Anyone connecting to your local intranet will only get name resolution via the local router/DNS server combination.

To make it more secure, the router can usually be set up "policies" which define what port traffic is will pass. https://en.wikipedia.org/wiki/List_of_T ... rt_numbers In this way you can "tighten the screws" for anyone who tries to bypass your router via network configs on their client.

Cheers.

[epoch1970]

Remove bind-interfaces. If absolutely necessary, with a systemd-based machine use bind-dynamic.

-z, --bind-interfaces
On systems which support it, dnsmasq binds the wildcard address, even when it is listening on only some interfaces. It then discards requests that it shouldn't reply to. This has the advantage of working even when interfaces come and go and change address. This option forces dnsmasq to really bind only the interfaces it is listening on. About the only time when this is useful is when running another nameserver (or another instance of dnsmasq) on the same machine. Setting this option also enables multiple instances of dnsmasq which provide DHCP service to run in the same machine.

--bind-dynamic
Enable a network mode which is a hybrid between --bind-interfaces and the default. Dnsmasq binds the address of individual interfaces, allowing multiple dnsmasq instances, but if new interfaces or addresses appear, it automatically listens on those (subject to any access-control configuration). This makes dynamically created interfaces work in the same way as the default. Implementing this option requires non-standard networking APIs and it is only available under Linux. On other platforms it falls-back to --bind-interfaces mode.

(Emphasis mine)

[TerryC65]

Remove bind-interfaces. If absolutely necessary, with a systemd-based machine use bind-dynamic.

Many thanks. It seems to work with bind-interfaces removed, so I haven't added bind-dynamic.

[TerryC65]

You might consider is setting up a localized DNS nameserver and point your network router to the its address. By editing the DNS server configs, you can effectively select name resolution for those sites you want, and exclude those you don't. Anyone connecting to your local intranet will only get name resolution via the local router/DNS server combination.

To make it more secure, the router can usually be set up "policies" which define what port traffic is will pass. https://en.wikipedia.org/wiki/List_of_T ... rt_numbers In this way you can "tighten the screws" for anyone who tries to bypass your router via network configs on their client.

Thanks. Setting up a local DNS Server is the next step.

[epoch1970]

Thanks. Setting up a local DNS Server is the next step.

I would suggest you try doing that with dnsmasq. It's quite powerful and simple at the same time.

Code: Select all

address=/google.com/ -> blackholes the whole domain
address=/www. google.com/127.0.0.1 -> resolves www to localhost (blocks) 
address=/www. google.com/192.168.1.1 -> resolves as the rpi

etc...

[TerryC65]

I would suggest you try doing that with dnsmasq. It's quite powerful and simple at the same time.

It's been a while since I posted. I had a number of problems, most of which I have now overcome, and I also had a family holiday that got in the way.

In the end, I only used dnsmasq to set up the DNS Server on the Pi and I removed all the routing that I had set up using iptables commands because nodogsplash covers everything! In its config file I was able to allow only those protocols (UDP and TCP port 53) that were needed to fool the phone into thinking it was on the internet prior to authentication and then port 80 and 443 to the Pi (combined Router and Webserver) to serve the content. It seems to work pretty well.

I now only have one problem. Before I started using nodogsplash, many of the Visitors were having to accept that our WiFi Access Point had no internet access before they could surf to our Home Page. This not very reliable and each version of Android behaved differently as related in the opening post above.

With nodogsplash, the Visitor is presented with a Sign-on Page, which he has to read and then Click 'Continue'. This routes him to the original Home Page and thence to the content. On my wife's Moto G6 Plus (Android 8.0), this works well. On my Moto G5 Plus (Android 7.0), the Home Page is too big and overflows the screen. I suspect this is to do with the built-in webserver that nodogsplash uses, because if I surf to the Home Page with nodogsplash disabled it works correctly. I used nginx for the original content.

Any suggestions on how I can resolve this?

[TerryC65]

Any suggestions on how I can resolve this?

There weren't many suggestions

Anyway, after a few more false starts, I managed to fix my problems by a combination of scaling my web pages and running the code through the W3 Schools Validator https://validator.w3.org.

I must say it was a huge learning experience for me, because my background is in test and systems engineering. However, I got there in the end and it turned out that nodogsplash was exactly the tool for the job. It is designed, of course, to provide a controlled path to the internet for businesses and organisations who want to manage what their customers or employees can do. Conversely, I used it to provide a very limited path to the Internet until the Visitor had authenticated through the Splash Screen and then no path at all; only a path to our local webserver.

I would commend nodogsplash to anyone who wants to do something similar. The config file takes some understanding, (for people like me anyway) but it is very well commented and seems to have all the bases covered. Apart from the login aspects, it is possible to control access to the Internet before and after authentication as noted above, but also to other servers on the same network and to the device itself; which is what I used.

Thanks for all help provided.

[DougieLawson]

Perhaps you should write it all up in markdown and publish it as a simple tutorial on github.io.

You may be able to encourage the Raspberry Pi folks to include that on here at https://raspberrypi.org

[TerryC65]

Perhaps you should write it all up in markdown and publish it as a simple tutorial on github.io.

Hmmm. I may well do that. However, we recently put all of the code and docs for a related project at the WMT into GitLab. I haven't seen a similar tool there.

You may be able to encourage the Raspberry Pi folks to include that on here at https://raspberrypi.org

I did get a much earlier project published in MagPi; using a Pi to control the Lighting in the WMT Model Railway Room. I told them about this project when we originally deployed it, but I suspect they had too much copy at the time. Now the project is a bit more functional, there may well be more interest at Pi Towers or MagPi.