Can't access JSON interface with Xt_Coova

[Philippe2705]

Hi !

I am trying to work with xt_coova module. Everything works fine, except the communication with the JSON interface.

config chilli 'public' option kname chillipub option dynip 10.1.153.0/24 option dhcplisten 10.1.153.254 option radiusnasid 'bureau' option radiuslisten '10.1.153.254' option radiussecret 'zzzzzzz' option radiusserver1 'radius1.xxxxx.net' option radiusserver2 'radius2.xxxxx.net' option radiusauthport '1812' option radiusacctport '1813' option uamserver 'http://bureau.xxxxx.net' option uamhomepage 'https://splash.xxxxx.net' option uamsecret 'zzzzzzz' option uamlisten '192.168.176.1' option uamport '3990' option uamuiport '3991' option uamallowed 'splash.xxxxx.net' option uamdomain 'xxxxx.net' option uamanydns '1' option uamaliasip '2.0.0.2' option uamaliasname 'box' option uamhostname 'splash' option uamlogoutip '2.2.2.2' option nouamsuccess '1' option coaport '3799' option coanoipcheck '1' option tundev 'tun11' option net '192.168.176.0/21' option lease '7200' option dhcpif 'br-if_pub'

My iptables: Chain FORWARD (policy DROP) target prot opt source destination
ACCEPT all -- anywhere 192.168.176.0/21
ACCEPT all -- 192.168.176.0/21 anywhere
ACCEPT all -- anywhere 10.1.153.0/24 coova: name: chillipub side: dest ACCEPT all -- 10.1.153.0/24 anywhere coova: name: chillipub side: source

Actually, the issue is that when the client is authenticated, it can't reach anymore the 192.168.176.1 uamlisten on the tun interface. It is normal but how can I handle the communication with the JSON interface on the 192.168.176.1 address ? Is there a way to force DNAT on the tun interface when the destination address is the uamlisten address ?

Any help is welcome. Thank you

[nzamps]

The rule would need to be on INPUT not FORWARD to have an effect. We have a rule a bit like:

iptables -A INPUT -d 192.168.176.1/21 -p tcp -m tcp --dport 3990 -m coova --name chillipub -j ACCEPT

Actually, I'm a little bit surprised it works how you have it - normally the DHCP and UAMLISTEN ranges are maskable and have the same size so the NAT translation works in chilli.c e.g. 10.10.0.0/20->10.11.0.0/20, 192.168.1.0/24->192.168.2.0/24. If the NAT works then great.

Some more info on David's original post:

https://coova.github.io/mail-archive/chilli/2010-April/001239.html

[Philippe2705]

Actually, if the uamlisten address is not in the same subnet of the 'option net', it doesn't work at all. The configuration from David's original post was the first I tried, but I figured out that the 'option net' range has to be the tun interface range.

'iptables -A INPUT -d 192.168.176.1/21 -p tcp -m tcp --dport 3990 -m coova --name chillipub -j ACCEPT' didn't helped.

Also I noticed that every packet to 192.168.176.1 get no response.

When the user is authenticated, does every packet is 'nated' to the wan interface, which can't reach the tun interface ?

My default INPUT rules are these ones: Chain INPUT (policy DROP) target prot opt source destination
COOVA_INPUT_PUB all -- anywhere anywhere
delegate_input all -- anywhere anywhere

I tried to do an 'iptables -F INPUT' before applying your ip rule, but the result was the same.

Thank you for your help.

[nzamps]

TBH, I never had any real success when using a bridge setup - xt_coova needs 2 x ethernet interfaces (e.g. eth0, eth1) and the ip ranges setup to suit the NAT code in chilli.c. Deviate too far from this setup will lead to major frustration!

[Philippe2705]

Hi !

I tried to have almost the same configuration as David:

config chilli 'public' option net 10.1.0.0/16 option dynip 10.1.0.0/24

option uamlisten 11.1.0.1 
option dhcplisten 10.1.0.1 
option dhcpstart 10
option dhcpif 'br-if_pub'
option kname chillipub
option tundev tun11
usetap '1'

And the iptables: iptables -I INPUT -d 11.1.0.1 -j ACCEPT

iptables -I FORWARD -o eth0.100 --src 10.0.0.0/8 -m coova --name chillipub -j ACCEPT -w iptables -I FORWARD -i eth0.100 --dst 10.0.0.0/8 -m coova --name chillipub --dest -j ACCEPT -w

iptables -I FORWARD --src 11.0.0.0/8 -j ACCEPT -w iptables -I FORWARD --dst 11.0.0.0/8 -j ACCEPT -w

But the issue is the same, can't get the JSON when authorized.

In my configuration, I have 2 ethernet interfaces: br-if_pub and eth0.100.

What is a setup without a bridge ? is there any example that I see ?

Thank you very much

[nzamps]

Have you had a read through #340 ? A few suggestions in that thread.

[Philippe2705]

Yes, I have already seen it.

I figure out that in chilli.conf, "usetap '1'' is ignored, it has to be "option usetap '1'".

While authenticated and not authenticated, I can now get the uamip/json/status. However, I can't connect to the home page anymore. This is confusing.

The client get the 10.1.0.10 address, in the chilli debug mod, I can see that coova tries to make ARP request to the mixed address of the tun interface (11.1.0.1/24) and my dhcp range interface (10.1.0.10/24):

/etc/init.d/chilli startchilli[15157]: cb_tun_ind(2565): arp: ifidx=0 src=1A-64-D4-06-96-9A dst=FF-FF-FF-FF-FF-FF prot=0806 (asking for 11.1.0.10) chilli[15157]: cb_tun_ind(2577): ARP for unknown IP 11.1.0.10 In Wireshark on the tap interface:

The ARP request get no response because the address 11.1.0.10 does not exist. Look like an issue of Coova, or my IP range are wrong ?

br-if_pub has a 10.1.0.0/16 address and tun has a 11.1.0.1/16 address.

In addition many "dhcp_receive_ip(3931): Not for our MAC or broadcast: C2-56-27-B7-FA-0D" in chilli -fd.

Thx again

[Philippe2705]

Hi ! I finally figure out how to make this work with a bridge. Actually, it is not possible normally, and it needs custom scripts to work. The main idea is that when using a bridge, you can't access to the tun interface once authorized. I created a python script which handles json/status and /logout http request, binded on the bridge interface. This service is available at any time by the client, connected or not. Also, it wouldn't work with the usetap option. It would be great that coova handle bridge interfaces directly with xt_coova.

In addition, I noticed that bad iptables rules make coova reply to packets both on the bridge and tun interface, which duplicate and thus reset TCP connections.

It seems to be quite a complicated issue, but it work.

[marouachikaoui]

Hi Phillippe, I have the same issue i can't do a logoff from the captive portal if firewall-app is up. if firewall is down ---> logoff is ok I work like you with a bridge can you help me please , can't get the JSON when authorized ?