How to Setup Captive portal on OpenWrt with Coova Chilli?

Installing and Using OpenWrt
1

Hey, I'm a newbie to setting up captive portals.

My goal here is to set up a captive portal which would require a username and password to log in and then the user will be granted access to the internet.

I've installed Coova Chilli and edit the /etc/init.d/chilli and /etc/chilli/defaults but nothing happens neither is there any tunnel being created for the guest IP network.

I haven't made any changes in the /etc/init.d/chilli.

But I've made the following changes in /etc/chilli/defaults

HS_WANIF=eth0            # WAN Interface toward the Internet
HS_LANIF=wlan0             # Subscriber Interface for client devices
HS_NETWORK=10.1.0.0        # HotSpot Network (must include HS_UAMLISTEN)
HS_NETMASK=255.255.255.0   # HotSpot Network Netmask
HS_UAMLISTEN=10.1.0.1      # HotSpot IP Address (on subscriber network)
HS_UAMPORT=3990            # HotSpot UAM Port (on subscriber network)
HS_UAMUIPORT=4990          # HotSpot UAM "UI" Port (on subscriber network, for embedded portal)

#OpenDNS Servers
HS_DNS1=208.67.222.222
HS_DNS2=208.67.220.220
###
#HotSpot settings for simple Captive Portal
#
HS_NASID=nas01
HS_RADIUS=localhost
HS_RADIUS2=localhost
HS_UAMALLOW=www.coova.org
HS_RADSECRET=xxxxx    # Set to be your RADIUS shared secret
HS_UAMSECRET=xxxxx     # Set to be your UAM secret
HS_UAMALIASNAME=chilli

I think I'm missing something here!!!

I've installed freeradius3 too and its running but whenever I go to

Pls, guide.

2

Regularly, similar question shows up here on the forum. And regularly I give the following advice:
First, try to get a working coova-chilli installation on real linux, i.e. ubuntu.
And then port to openwrt, to avoid the openwrt"-specialities".
Setting up coova-chilli on real linux is complicated enough, but quite a few docs about it floating on the web.
Steep learning curve, anyway.
For commercial help, PM me.

3

On Ubuntu, we have to setup hostpad services etc...

On OpenWRT its completely different thing very few services.

4

No. The same, in principle. Usually, for openwrt+coova-chilli you will need backend server running freeradius, UAM etc. In case of using ubuntu, you can do this on same machine. Thats the only difference.

5

I've both of the services running!!

6

Bring your system to work on ubuntu, first.
Which will (also) need definition of UAMSERVER, for example.

7

I advice use wifidog captive portal more good. for cloud based managing your router central system use cloudwifizone. cova chill is complicated and very difficult to install. need high storage router space.

8

Wrong.
I even managed to run it on 4MB flash, 32MB RAM.

9

Chilli processes every user data packet in userspace which takes considerably more CPU than the various "dog" based packages which alter iptables to have the kernel distinguish allowed versus not allowed users.

If you are going to use chilli don't do what the OP here did. Configure through /etc/config/chilli not the old environment variable way.

10

Read down comment. Chili need more flash space.

11

Sorry, but I successfully implemented chilli on various openwrt device types. Even on 4/32 limited devices, where it is a bit "tricky". But never with the standard openwrt package approach (/etc/config/chilli deleted), but the old config files approach in /etc/chilli. First of all, because I never used openwrt fw, but simple iptables rules. Which are easier for me to handle. And second, because I sometimes also used "squid intercept/transparent" in combo with chilli. Which requires even more special adaption of the firewall rules. Easier with plain iptables.

12

I'm facing difficulties in iptables rules done for cova-chilli.

Coova chilli working in below setting
Im marking the packets in ebtables then doing dnat the same marked packet in iptables nat table if I set bridge-nf-call-iptables 1

But i'm loosing the tproxy functionality.
Any suggestion to get both. I'm ready to try with nftable if suggested

My ebtables rules are
ebtables -t broute -A ATH1 -p IPv4 -i ath1 --ip-proto tcp --ip-dport 9300 -j mark --mark-set 0x71 --mark-target ACCEPT
ebtables -t broute -A ATH1 -p IPv4 -i ath1 --ip-proto tcp --ip-dport 443 -j mark --mark-set 0x81 --mark-target ACCEPT
ebtables -t broute -A ATH1 -p IPv4 -i ath1 --ip-proto tcp --ip-dport 80 -j mark --mark-set 0xa1 --mark-target ACCEPT

iptables -t nat -A PREROUTING -p tcp --match mark --mark 0xa1/0xff -j DNAT --to-destination localIp:9111
iptables -t nat -A PREROUTING -p tcp --match mark --mark 0x81/0xff -j DNAT --to-destination localIp:8111
iptables -t nat -A PREROUTING -p tcp --match mark --mark 0x71/0xff -j DNAT --to-destination localIp:9111

13

what device and release is this ?

14

This is Openwrt 22.3 & coova-chilli-1.6, bridge router which get Ip from the main router

15

Coova-Chilli has essentially been unmaintained since the departure of the original developer around ~2015. Since then there have been some minor updates and more recently some desperate patching to allow it to at least compile.
To make it work on OpenWrt current versions (22.3 onwards ie the nftables default versions), there are a lot of tricks and fixes you have to come to terms with and implement.

If you really need Coova Chilli, I suggest you take the advice of @reinerotto who uses it commercially.

If you just want a captive portal that works "out of the box" on current OpenWrt, then look at openNDS.

Any captive portal will make use of the client device built in CPD (Captive Portal Detection) to redirect to a web page where the user is presented with some form of login page. This requires DNAT but this only has meaning on a layer 3 router. A "bridge router" will by definition be running at layer 2 and will not do any layer 3 DNAT.

The captive portal needs to be on the "main router".