coova / coova-chilli

CoovaChilli is an open-source software access controller for captive portal hotspots.
Other
518 stars 260 forks source link

upload limit bandwidth with xt_coova #340

Open keulu opened 7 years ago

keulu commented 7 years ago

Hi guys,

1 week ago, i noticed that my users connected behind coova are not limitted on upload on my router with openWRT 15.05.1 and coova 1.3.2

this is my device in chilli_query list

CC-25-EF-31-3B-75 192.168.180.2 pass 58ac194800000003 1 2945522 8/31536000 2/900 2010420/0 0/0 0 1 **0%/262144 0%/1048576** http://captive.apple.com/hotspot-detect.html vlan=(null)

My limits are set correctly. When i download someting, i see log about leaky bucket for download, and my limit is well apllied. (Leaky bucket dropping download overflow to CC-25-EF-31-3B-75). it's applied because i see 99%/1048576 great !

But... (and that make me crazy) i can't limit my upload.

this are my confs

`

/etc/config/chilli

config chilli 'public' option radiusnasid 'testacopub' option radiuslisten '10.1.210.254' option radiussecret '**' option radiusserver1 '**' option radiusserver2 '**' option radiusauthport '1812' option radiusacctport '1813' option uamserver 'http://testacopub.***.net' option uamhomepage 'http://splash.***.net' option uamsecret '**' option uamlisten '192.168.180.1' option uamport '3990' option uamanydns '1' option uamaliasip '1.0.0.1' option uamaliasname 'login' option uamlogoutip '1.1.1.1' option nouamsuccess '1' option coaport '3799' option coanoipcheck '1' option tundev 'tun11' option net '192.168.180.0/22' option lease '7200' option dhcpif 'br-if_pub' option dns1 '8.8.8.8' option dns2 '8.8.4.4' option domain '**' option kname 'chillipub' option swapoctets '1' option interval '3600' option ipup '/iwibox/coova/ipup.sh' option ipdown '/iwibox/coova/ipdown.sh' option conup '/iwibox/coova/conup.sh' option condown '/iwibox/coova/condown.sh' option locationname '***' option maxclients '1024' option nowispr1 '1' option nowispr2 '1' option noc2c '1' option rfc7710uri 'http://192.168.180.1:3990/prelogin' option dnslog '/var/log/coova_dns_pub.txt' `

`
INPUT and OUPUT POLICY is ACCEPT by default

Chain FORWARD (policy DROP 1444 packets, 134K bytes) target prot opt in out source destination
ACCEPT all -- tun11 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- tun11
0.0.0.0/0 0.0.0.0/0
ACCEPT all -- br-if_pub 0.0.0.0/0 0.0.0.0/0 coova: name: chillipub side: dest ACCEPT all -- br-if_pub 0.0.0.0/0 0.0.0.0/0 coova: name: chillipub side: source `

I also tried to disable TSO GRO and GSO on my interfaces, but nothing change...

does anyone have an idea, What i'm missing ?

@nzamps I saw that you a pretty active about xt_coova. do you know what my problem is ?

nzamps commented 7 years ago

Interesting, you shouldn't see your download limited at all with xt_coova - it is meant to bypass chilli for authenticated users!

I think one problem is due to your use of a bridge, which incidentally I wouldn't recommend unless you use the 'usetap' option. We use the conup/condown scripts to insert tc and iptables rules to enforce rate limits.

Also, I think the issue is you are not using 2 ip ranges for unauthenticated and authenticated users. With xt_coova you have uamlisten on one range and dynip on the other and xt_coova does a DNAT between the two.

e.g. you could have:

192.168.181.0/24 for unauthenticated 192.168.180.0/24 for authenticated

option uamlisten '192.168.181.1'
option net '192.168.180.0/24'
option dynip '192.168.180.0/24'

and your firewall rules should match the auth range only for xt_coova e.g.

iptables -A FORWARD -d 192.168.180.0/24 -i br-if_pub -m coova --name chillipub --dest  -j ACCEPT
iptables -A FORWARD -s 192.168.180.0/24 -o br-if_pub -m coova --name chillipub --source  -j ACCEPT

iptables -A FORWARD -d 192.168.181.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.181.0/24 -j ACCEPT

Your INPUT rules look like they need some work - you normally have policy DROP and only allow the ports you need e.g. uamport would be:

iptables -A INPUT -d 192.168.181.1/32 -p tcp -m tcp --dport 3990 -j ACCEPT

For more see: http://coova.github.io/mail-archive/chilli/2010-April/001239.html

TBH I'm quite surprised your setup works at all - do users get a splash page ok and can login ? Do you see packet counts when you do:

cat /proc/net/coova/chillipub

You might need to change things around quite a bit to get it to work how it was designed!

Cheers Brian

keulu commented 7 years ago

Hi brian, thanks for your amazing explanation and quick answer

I made a mistake for my iptables. INPUT have a DROP POLICY (my bad...) i didn't wrote all my rules because I have huge rules.

SO if i understand well, limitted download shouldn't work... and i need to limit traffic with TC.

Ok i will try this today. I keep you informed.

keulu commented 7 years ago

well well well...

After a long brain torture, i didn't make it work as desired...

with my original config cat /proc/net/coova/chillipub give something like that when i'm connected

root@OpenWRT:~# cat /proc/net/coova/chillipub mac=CC-25-EF-31-3B-75 src=192.168.180.3 state=1 bin=34517448 bout=0 pin=1856 pout=0 root@OpenWRT:~# cat /proc/net/coova/chillipub mac=CC-25-EF-31-3B-75 src=192.168.180.3 state=1 bin=59539525 bout=0 pin=3265 pout=0 root@OpenWRT:~# cat /proc/net/coova/chillipub mac=CC-25-EF-31-3B-75 src=192.168.180.3 state=1 bin=65916093 bout=0 pin=3638 pout=0

no unauthentified users is here. only authentified.

When i reset all my Forward rules and try yours, i didn't match any rules, can't get my portal or splash and /proc/net/coova/chillipub don't exist or stay empty

in your example, you said

192.168.181.0/24 for unauthenticated 192.168.180.0/24 for authenticated

option uamlisten '192.168.181.1' option net '192.168.180.0/24' option dynip '192.168.180.0/24'

when coova detect my device, he give me a 192.168.180.x address.

Well i think i will reset my work and rebuild from scratch all my confs this Week End.

Ty again

nzamps commented 7 years ago

Yep, users should get a 192.168.180.x address, the 181.x address is only used by xt_coova (it NATs to it when the user is not authenticated).

I'd try to test without a bridge - e.g. use ethX if available as a bridge can confuse things. Ensure ethX has ip 192.168.180.1/24 (may need to add manually) and the tun or tap (tap for bridge) has 192.168.181.1/24 and you have added all of the INPUT rules for the ports you need and any FORWARD rules for external IPs.

Hope this helps.

keulu commented 7 years ago

hi nzamp,

I've almost done all my new conf but one problem remain.

When i'm not logged, my splash page, portal and all uammallowed/domains works fine. when i'm logged, i can go to the internet. OK great. (without port restriction for now) (/proc/net/coova/chillipub exist and is well powered with bin, bout, pin, pout for my mac)

When i'm not connected, call 192.168.181.1:3990/json/status make an error. the connection was reset. When i click on the connect button, -> connection was reset when i call 192.168.181.1:3990/login?username=xxxx&response=xxxxxxxxxxx&userurl=xxxxxxx -> connection was reset (same for logoff when i'm connected, but it's logout my user with error)

When i'm connected, call 192.168.181.1:3990/json/status work. logoff work too but, don't redirect me to my portal

here are my confs :

cat /etc/config/network

config interface 'loopback'
    option proto 'static'
    option ifname 'lo'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'
    option ipv6 '0'

config interface 'coova'
    option ifname 'tun11'
    option proto 'none'
    option defaultroute '0'
    option peerdns '0'
    option auto '1'
    option force_link '1'
    option delegate '0'
    option ipv6 '0'

config interface 'wan'
    option proto 'dhcp'
    option ifname 'eth0'
    option dns '8.8.8.8 8.8.4.4'
    option ipv6 '0'

config interface 'lan'
    option ifname 'eth1'
    option proto 'static'
    option ipaddr '192.168.180.1'
    option netmask '255.255.255.0'
    option defaultroute '0'
    option peerdns '0'
    option delegate '0'
    option ipv6 '0'
    option type 'bridge'

ifconfig

br-lan    Link encap:Ethernet  HWaddr C0:56:27:B7:FA:0D  
          inet addr:192.168.180.1  Bcast:192.168.180.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2406 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2316 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:351856 (343.6 KiB)  TX bytes:681138 (665.1 KiB)

eth0      Link encap:Ethernet  HWaddr C2:56:27:B7:FA:0D  
          inet addr:192.168.6.62  Bcast:192.168.6.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14872 errors:0 dropped:300 overruns:0 frame:0
          TX packets:9345 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:532 
          RX bytes:2748698 (2.6 MiB)  TX bytes:3288096 (3.1 MiB)
          Interrupt:194 

eth1      Link encap:Ethernet  HWaddr C0:56:27:B7:FA:0D  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2406 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2338 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:532 
          RX bytes:385540 (376.5 KiB)  TX bytes:682150 (666.1 KiB)
          Interrupt:195 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:616 errors:0 dropped:0 overruns:0 frame:0
          TX packets:616 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:42040 (41.0 KiB)  TX bytes:42040 (41.0 KiB)

tun11     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.181.1  P-t-P:192.168.181.1  Mask:255.255.255.0
          UP POINTOPOINT RUNNING  MTU:1500  Metric:1
          RX packets:1956 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1563 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:290155 (283.3 KiB)  TX bytes:496918 (485.2 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:25:9C:13:C8:E7  
          inet6 addr: fe80::225:9cff:fe13:c8e7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:366 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:25568 (24.9 KiB)

wlan1     Link encap:Ethernet  HWaddr 00:25:9C:13:C8:E6  
          inet6 addr: fe80::225:9cff:fe13:c8e6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:368 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:25720 (25.1 KiB)

br-lan is a bridge over eth1, wlan0 and wlan1 but it do exactly the same proglem if i target eth1 and not br-lan

cat /etc/config/chilli

config chilli 'public'
    option radiusnasid 'testacopub'
    option radiussecret 'xxxxxx'
    option radiusserver1 'xxxxxx'
    option radiusserver2 'xxxxxx'
    option radiusauthport '1812'
    option radiusacctport '1813'
    option uamserver 'http://xxxxxx'
    option uamhomepage 'http://xxxxxx'
    option uamsecret 'xxxxxx'
    option uamport '3990'
    option uamallowed 'xxxxx'
    option uamdomain 'xxx,yyy,zzz'
    option uamanydns '1'
    option uamaliasip '1.0.0.1'
    option uamaliasname 'login'
    option uamlogoutip '1.1.1.1'
    option nouamsuccess '1'
    option coaport '3799'
    option tundev 'tun11'
    option dns1 '8.8.8.8'
    option dns2 '8.8.4.4'
    option domain 'iwibox.net'
    option interval '3600'
    option locationname 'test'
    option uamlisten '192.168.181.1'
    option net '192.168.180.0/24'
    option dhcplisten '192.168.180.1'
    option dhcpstart '10'
    option dhcpif 'br-lan'
    option kname 'chillipub'

my simple firewall rules

iptables -t filter -F
iptables -t filter -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -p icmp -j ACCEPT
iptables -A INPUT -d 192.168.181.1/32 -p tcp -m tcp --dport 3990 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8022 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
iptables -A INPUT -i eth0 -d 192.168.180.0/24 -j DROP
iptables -A INPUT -i eth0 -d 192.168.181.0/24 -j DROP
iptables -A INPUT -j DROP

iptables -A FORWARD -d 192.168.180.0/24 -m coova --name chillipub --dest  -j ACCEPT
iptables -A FORWARD -s 192.168.180.0/24 -m coova --name chillipub -j ACCEPT
iptables -A FORWARD -d 192.168.181.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.181.0/24 -j ACCEPT
iptables -A FORWARD -j LOG --log-prefix "IPTables-FORWARD-Dropped: " --log-level 4
iptables -A FORWARD -j DROP

iptables LOG :


Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.587064] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=63 TOS=0x00 PREC=0x00 TTL=63 ID=11788 DF PROTO=UDP SPT=48102 DPT=53 LEN=43 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.587126] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=6231 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.587160] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=63 TOS=0x00 PREC=0x00 TTL=63 ID=11789 DF PROTO=UDP SPT=48102 DPT=53 LEN=43 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.591260] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=11790 DF PROTO=UDP SPT=49571 DPT=53 LEN=47 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.591302] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=11791 DF PROTO=UDP SPT=49571 DPT=53 LEN=47 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.591342] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=61 TOS=0x00 PREC=0x00 TTL=63 ID=11792 DF PROTO=UDP SPT=38401 DPT=53 LEN=41 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.591370] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=61 TOS=0x00 PREC=0x00 TTL=63 ID=11793 DF PROTO=UDP SPT=38401 DPT=53 LEN=41 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.612939] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6232 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=229 RES=0x00 ACK URGP=0 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.613268] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=874 TOS=0x00 PREC=0x00 TTL=63 ID=6233 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=229 RES=0x00 ACK PSH URGP=0 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.674102] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6234 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=251 RES=0x00 ACK URGP=0 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.675123] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6235 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=274 RES=0x00 ACK URGP=0 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.676703] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6236 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=296 RES=0x00 ACK URGP=0 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.677907] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6237 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=319 RES=0x00 ACK URGP=0 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.679175] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6238 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=342 RES=0x00 ACK URGP=0 
Thu Mar  9 12:14:00 2017 kern.warn kernel: [  104.680923] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6239 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=364 RES=0x00 ACK URGP=0 
[...]

iptables DROP all traffic between ETH0 and br-lan thats ok for me, but, why i'm not enter in thoses rules ? 'cause my SRC in LOG is 192.168.180.11 instead of 192.168.181.11 ?

i missed something ?

thx @nzamps

keulu commented 7 years ago

other strange thing, if i add

iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

i can connect and disconnect from coova (but all internet web site is active) (yeah i know that's normal if i forward all from lan to wan, but logoff/status work and redirect me well...)

strange or absolutly normal ?

nzamps commented 7 years ago

For logout try:

iptables -A INPUT -d 192.168.181.1/32 -p tcp -m tcp --dport 3990 -m coova--name chilli --source -j ACCEPT

keulu commented 7 years ago

not better.

it's like if during nat or unnat, something doing wrong.

when i try to connect, with an new and fresh challenge (after a redir), i'm well redirected to 192.168.181.1:3990/logon (that my web redir) send request to radius got radius response (login ok) got error : the connection was reset refresh (okay, your are connected)

when i try to connect, with an old challenge, i'm well redirected to 192.168.181.1:3990/logon (that my web redir) send request to radius got radius response (login fail) got error : the connection was reset refresh got error : the connection was reset refresh got error : the connection was reset [...]

when i'm connected, call 192.168.181.1:3990/logoff log me out, but don't redirect me.

when i'm not connected, call 192.168.181.1:3990/json/status fail : the connection was reset (work when i'm connected)

i'm really disappointed :cry:

nobody have a working example ?

nzamps commented 7 years ago

Works ok for us but we use external web portals...you could look at that as an option.

keulu commented 7 years ago

i use external portal too

keulu commented 7 years ago

found something strange maybe.

when i try to connect, i saw this in coova log

coova-chilli[670]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=60
coova-chilli[670]: function dhcp_receive_ip()
coova-chilli[670]: Address found
coova-chilli[670]: Resetting connection on port 51352->443
**coova-chilli[670]: dropping packet; not nat'ed**
coova-chilli[670]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=74
coova-chilli[670]: function dhcp_receive_ip()
coova-chilli[670]: Address found
coova-chilli[670]: Resetting connection on port 35067->3990
**coova-chilli[670]: dropping packet; not nat'ed**
coova-chilli[670]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=74
coova-chilli[670]: function dhcp_receive_ip()
coova-chilli[670]: Address found
coova-chilli[670]: Resetting connection on port 35068->3990
**coova-chilli[670]: dropping packet; not nat'ed**

dropping packet; not nat'ed

Here is an other debug.

Start chilli -> ask for json/status not logged / connection was reset -> stop chilli

root@nouvelle-ac-o-test:~# /etc/init.d/chilli start
root@nouvelle-ac-o-test:~# chilli[3847]: (Re)processing options [/var/run/chilli.3847.cfg.bin]
chilli[3849]: running chilli_opt on /var/run/chilli.3847.cfg.bin
chilli[3847]: PID 3847 rereading binary file /var/run/chilli.3847.cfg.bin
chilli[3847]: PID 3847 reloaded binary options file
chilli[3847]: CoovaChilli 1.4. Copyright 2002-2005 Mondru AB. Licensed under GPL. Copyright 2006-2012 David Bird (Coova Technologies). Licensed under GPL. See http://coova.github.io/ for details.
chilli[3847]: chilli_main(7416): clock realtime sec 1489506317 nsec 346554286
chilli[3847]: chilli_main(7422): clock monotonic sec 8419 nsec 871593531
chilli[3847]: TX queue length set to 100
chilli[3847]: Hashlog 8 244 256
chilli[3847]: Net SNDBUF 163840
chilli[3847]: Net RCVBUF 163840
chilli[3847]: device eth1 ifindex 3
chilli[3847]: lo  address family: 17 (AF_PACKET)
chilli[3847]: eth0  address family: 17 (AF_PACKET)
chilli[3847]: eth1  address family: 17 (AF_PACKET)
chilli[3847]: ifb0  address family: 17 (AF_PACKET)
chilli[3847]: ifb1  address family: 17 (AF_PACKET)
chilli[3847]: wlan1  address family: 17 (AF_PACKET)
chilli[3847]: wlan0  address family: 17 (AF_PACKET)
chilli[3847]: lo  address family: 2 (AF_INET)
chilli[3847]: eth0  address family: 2 (AF_INET)
chilli[3847]: eth1  address family: 2 (AF_INET)
chilli[3847]: tun0  address family: 2 (AF_INET)
chilli[3847]: tun11  address family: 2 (AF_INET)
chilli[3847]: dhcp_hashinit(490): hash table size 64 (56)
chilli[3847]: dhcp_sendGARP(338): GARP: Replying to broadcast
chilli[3847]: dhcp_send() len=42
chilli[3847]: dhcp_new(1191): dhcpif (eth1) IPv6 address ::
chilli[3847]: RADIUS client 0.0.0.0:3799
chilli[3847]: chilli_main(7577): Waiting for client request...
chilli[3847]: qnext=0
chilli[3847]: qnext=0
chilli[3847]: RADIUS queue-in id=0 idx=0
chilli[3847]: sending radius packet (code=4, id=0, len=117)

next 1, first 0, last 0
n=  0 id=  0 state=  1 next= -1 prev= -1 1489506327   396387 0
chilli[3847]: RADIUS id=0 sent to 5.39.98.227:1813
chilli[3847]: kmod wrote 2 /

chilli[3847]: net select count: 1
chilli[3847]: net select count: 2
chilli[3847]: net select count: 3
chilli[3847]: net select count: 4
chilli[3847]: net select count: 5
chilli[3847]: net select count: 6
chilli[3847]: i=0 sz=1
chilli[3847]: i=0 sz=2
chilli[3847]: i=1 sz=2
chilli[3847]: i=0 sz=3
chilli[3847]: i=1 sz=3
chilli[3847]: i=2 sz=3
chilli[3847]: i=0 sz=4
chilli[3847]: i=1 sz=4
chilli[3847]: i=2 sz=4
chilli[3847]: i=3 sz=4

System Interfaces
0) lo (1) ip=127.0.0.1 net=127.0.0.0 mask=255.0.0.0 mac=00-00-00-00-00-00 mtu=65536
1) eth0 (2) ip=192.168.6.62 net=192.168.6.0 mask=255.255.255.0 bcase=192.168.6.255 mac=C2-56-27-B7-FA-0d mtu=1500
2) eth1 (3) ip=192.168.180.1 net=192.168.180.0 mask=255.255.255.0 bcase=192.168.180.255 mac=C0-56-27-B7-FA-0d mtu=1500
4) tun11 (27) ip=192.168.181.1 net=192.168.181.0 mask=255.255.255.0 peer=192.168.181.1 mac=00-00-00-00-00-00 mtu=1500

System Routes
0) dst=0.0.0.0 mask=0.0.0.0 gw=192.168.6.1 dev=eth0 (2)
4) dst=192.168.6.0 mask=255.255.255.0 dev=eth0 (2)
5) dst=192.168.6.1 mask=255.255.255.255 dev=eth0 (2)
6) dst=192.168.180.0 mask=255.255.255.0 dev=eth1 (3)
7) dst=192.168.181.0 mask=255.255.255.0 dev=tun11 (27)
chilli[3847]: Default Route 192.168.6.1
chilli[3847]: Route Interface eth0
chilli[3847]: MAC 4c:9e:ff:7b:02:02
chilli[3847]: net select count: 7
chilli[3847]: net select count: 8
chilli[3847]: radius_timeout(0) 1489506317   398291
next 1, first 0, last 0
n=  0 id=  0 state=  1 next= -1 prev= -1 1489506327   396387 0
chilli[3847]: radius_timeout
next 1, first 0, last 0
n=  0 id=  0 state=  1 next= -1 prev= -1 1489506327   396387 0
chilli[3847]: dhcp_sendCHILLI(170): CHILLI: peer 0 sending 16 bytes
chilli[3847]: dhcp_send() len=30
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=64-00-6A-6E-00-13 dst=C2-56-27-B7-FA-0D prot=0800 2048 len=66

chilli[3847]: dhcp_receive_ip(3739): function 
chilli[3847]: dhcp_receive_ip(3775): Address not found (192.168.180.11)
chilli[3847]: dhcp_newconn(745): DHCP newconn: 00-13-77-4C-F9-CB
chilli[3847]: cb_dhcp_connect(5222): New DHCP request from MAC=00-13-77-4C-F9-CB
chilli[3847]: chilli_connect(5183): New Chilli Connection
chilli[3847]: cb_dhcp_request(4981): DHCP request for IP address 192.168.180.11
chilli[3847]: newip(876): newip 192.168.180.11
chilli[3847]: Requesting new static ip: 192.168.180.11
chilli[3847]: Static IP address not allowed
chilli[3847]: Requesting new dynamic ip: 192.168.180.11
chilli[3847]: cb_dhcp_request(5110): Client MAC=00-13-77-4C-F9-CB assigned IP 192.168.180.11
chilli[3847]: dhcp_receive_ip(4218): dropping packet; unhandled auth state 0
chilli[3847]: radius_timeout(-1) 1489506317   991320
next 1, first -1, last -1
chilli[3847]: radius_timeout
next 1, first -1, last -1
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=C0-56-27-B7-FA-0D dst=00-13-77-4C-F9-CB prot=0800 2048 len=74
chilli[3847]: dhcp_receive_ip(3739): function 
chilli[3847]: dhcp_receive_ip(3775): Address not found (192.168.181.1)
chilli[3847]: dhcp_newconn(745): DHCP newconn: C0-56-27-B7-FA-0D
chilli[3847]: cb_dhcp_connect(5222): New DHCP request from MAC=C0-56-27-B7-FA-0D
chilli[3847]: chilli_connect(5183): New Chilli Connection
chilli[3847]: dhcp_receive_ip(3931): Not for our MAC or broadcast: 00-13-77-4C-F9-CB
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=66
chilli[3847]: dhcp_receive_ip(3739): function 
chilli[3847]: dhcp_receive_ip(3764): Address found
chilli[3847]: tun_encaps(tun11) len=52
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=391
chilli[3847]: dhcp_receive_ip(3739): function 
chilli[3847]: dhcp_receive_ip(3764): Address found
chilli[3847]: tun_encaps(tun11) len=377
chilli[3847]: tun_decaps(idx=0, len=40)
chilli[3847]: cb_tun_ind(2709): sending to : 192.168.180.11
chilli[3847]: dhcp_data_req(5650): adding 14 to IP frame length 54
chilli[3847]: dhcp_send() len=54
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=C0-56-27-B7-FA-0D dst=00-13-77-4C-F9-CB prot=0800 2048 len=66
chilli[3847]: dhcp_receive_ip(3739): function 
chilli[3847]: dhcp_receive_ip(3764): Address found
chilli[3847]: dhcp_receive_ip(3931): Not for our MAC or broadcast: 00-13-77-4C-F9-CB
chilli[3847]: tun_decaps(idx=0, len=40)
chilli[3847]: cb_tun_ind(2709): sending to : 192.168.180.11
chilli[3847]: dhcp_data_req(5650): adding 14 to IP frame length 54
chilli[3847]: dhcp_send() len=54
chilli[3890]: redir_main(3415): Calling redir_getstate()
**chilli[3890]: redir_main(3463): Receiving HTTP Request
chilli[3890]: redir_getreq(2150): The path: json/status
chilli[3890]: redir_getreq(2166): The (json format) path: status
chilli[3890]: redir_getreq(2230): Host: 192.168.181.1:3990
chilli[3890]: redir_getreq(2251): User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
chilli[3890]: redir_getreq(2263): Accept-Language: en-US,en;q=0.5
chilli[3890]: redir_getreq(2214): end of http-request
chilli[3890]: redir_main(3535): Processing HTTP Request
chilli[3890]: redir_main(3887): Processing received request
chilli[3890]: redir_main(4132): ---->>> resetting challenge: c24b86aba5372d8425f17d4ba43128dc
chilli[3890]: redir_getparam(1915): getparam(&callback=)
chilli[3890]: redir_json_reply(1415): sending json: {"version":"1.0","clientState":0,"nasid":"testacopub","challenge":"c24b86aba5372d8425f17d4ba43128dc","location":{"name":"testacopub|bureaurdc"},"redir":{"originalURL":"","redirectionURL":"","logoutURL":"http://192.168.181.1:3990/logoff","ipAddress":"192.168.180.11","macAddress":"00-13-77-4C-F9-CB"}}

chilli[3890]: redir_write(1477): redir_write(566)**
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=C0-56-27-B7-FA-0D dst=00-13-77-4C-F9-CB prot=0800 2048 len=632
chilli[3847]: dhcp_receive_ip(3739): function 
chilli[3847]: dhcp_receive_ip(3764): Address found
chilli[3847]: dhcp_receive_ip(3931): Not for our MAC or broadcast: 00-13-77-4C-F9-CB
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=60
chilli[3847]: dhcp_receive_ip(3739): function 
chilli[3847]: dhcp_receive_ip(3764): Address found
chilli[3847]: tun_encaps(tun11) len=40
chilli[3890]: _redir_close_exit(3208): close_exit
chilli[3847]: chilli_handle_signal(386): caught 17 via selfpipe
chilli[3847]: _sigchld(316): child 3890 terminated
chilli[3847]: child_remove_pid(138): Freed child process 3890 [[redir]]
root@nouvelle-ac-o-test:~# /etc/init.d/chilli stop
chilli[3847]: radius_timeout(-1) 1489506319     1889
next 1, first -1, last -1
chilli[3847]: radius_timeout
next 1, first -1, last -1

chilli[3847]: chilli_handle_signal(386): caught 15 via selfpipe
chilli[3847]: _sigterm(342): SIGTERM: shutdown
chilli[3847]: CoovaChilli shutting down
chilli[3847]: qnext=1
chilli[3847]: qnext=1
chilli[3847]: RADIUS queue-in id=1 idx=1
chilli[3847]: sending radius packet (code=4, id=1, len=123)

next 2, first 1, last 1
n=  1 id=  1 state=  1 next= -1 prev= -1 1489506329   510388 0
chilli[3847]: RADIUS id=1 sent to 5.39.98.227:1813
chilli[3847]: child_killall(286): pid 3847 killed 3847
root@nouvelle-ac-o-test:~# chilli[3847]: cmdsock_shutdown(109): Shutting down cmdsocket
chilli[3847]: Removing /var/run/chilli.3847.cfg.bin
chilli[3847]: remove(/var/run/chilli.3847.cfg.bin) failed

Chilli send me the json, but i don't get it.

keulu commented 7 years ago

this is my compilation option.

maybe something is missing or not compatible with xt_coova ?

Compiled with 
ENABLE_DEBUG2 
ENABLE_ACCOUNTING_ONOFF 
ENABLE_APSESSIONID 
ENABLE_ACCEPTLANGUAGE
ENABLE_AUTHEDALLOWED 
ENABLE_BINSTATFILE 
ENABLE_CHILLIQUERY 
ENABLE_CHILLIPROXY 
ENABLE_COA 
ENABLE_RADPROXY 
ENABLE_CLUSTER 
ENABLE_DHCPRADIUS 
ENABLE_UAMDOMAINFILE 
ENABLE_EWTAPI 
ENABLE_GARDENACCOUNTING 
ENABLE_IEEE8021Q 
ENABLE_IEEE8023 
ENABLE_IPV6 
ENABLE_JSON 
ENABLE_LARGELIMITS 
ENABLE_LAYER3 
ENABLE_LEAKYBUCKET 
ENABLE_MULTILAN 
ENABLE_MULTIROUTE 
ENABLE_SESSIONID 
ENABLE_SESSIONSTATE 
ENABLE_STATFILE 
ENABLE_TAP 
ENABLE_TCPRESET 
ENABLE_UAMANYIP 
ENABLE_UAMDOMAINFILE 
ENABLE_UAMUIPORT 
ENABLE_USERAGENT 
ENABLE_WPAD 
HAVE_NETFILTER_COOVA 
HAVE_OPENSSL 
USING_IPC_MSG
nzamps commented 7 years ago

You could try without ENABLE_TCPRESET

gbaligh commented 7 years ago

TCP RESET is active by default in the last version, you could not disable it ! You have to change the configure.in file to add the ability to disable the service.

keulu commented 7 years ago

already tried and it result that le log message 'Resetting connection' disapear.

coova-chilli[670]: Resetting connection on port 35067->3990
coova-chilli[670]: dropping packet; not nat'ed

but the log about 'dropping packet; not nat'ed' persist

but now, we didn't have connection reset (with better firewall rules) but the redirection after login or after logout don't work (in fact, it's work but we have to wait approx 1 minute for being redirected). (maybe when coova unnat or nat one ip (180.10) to another (181.10) or found an other route for packet ?)

We found this topic : https://www.brightonchilli.org.uk/pipermail/coovachilli/2016-June/000011.html and it seems that Pierre had this problem.

it works, but not at the first redir.

@gbaligh we use coova 1.3.2

Mon Mar 20 17:28:56 2017 daemon.info coova-chilli[4803]: Successful UAM login from username=2945522 IP=192.168.180.10
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: UPPROT - GETIP
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: kmod wrote 16 +192.168.180.10
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: qnext=210
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: qnext=210
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: RADIUS queue-in id=210 idx=210
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: sending radius packet (code=4, id=210, len=234)
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: RADIUS id=210 sent to 5.39.98.227:1813
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Calling connection up script: /iwibox/conup.sh
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: function dhcp_receive_ip()
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Address found
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: tun_decaps(idx=0, len=52)
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: sending to : 192.168.180.10
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: adding 14 to IP frame length 66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_send() len=66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: caught 17 via selfpipe
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: child 8512 terminated
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Freed child process 8512 [[redir]]
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: function dhcp_receive_ip()
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Address found
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: function dhcp_receive_ip()
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Address found
Mon Mar 20 17:28:56 2017 kern.warn kernel: [29033.237472] IPTables-INPUT-Dropped: IN=eth1 OUT= MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.10 DST=192.168.181.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7168 DF PROTO=TCP SPT=35157 DPT=3990 WINDOW=251 RES=0x00 ACK URGP=0 
Mon Mar 20 17:28:56 2017 kern.warn kernel: [29033.237674] IPTables-INPUT-Dropped: IN=eth1 OUT= MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.10 DST=192.168.181.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7169 DF PROTO=TCP SPT=35157 DPT=3990 WINDOW=251 RES=0x00 ACK FIN URGP=0 
Mon Mar 20 17:28:56 2017 kern.warn kernel: [29033.242233] IPTables-INPUT-Dropped: IN=eth1 OUT= MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.10 DST=192.168.181.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7170 DF PROTO=TCP SPT=35157 DPT=3990 WINDOW=251 RES=0x00 ACK URGP=0 
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: tun_decaps(idx=0, len=52)
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: sending to : 192.168.180.10
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: adding 14 to IP frame length 66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_send() len=66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=1035
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: function dhcp_receive_ip()
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Address found
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=78
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: function dhcp_receive_ip()
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Address found
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: caught 17 via selfpipe
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: child 8513 terminated
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Freed child process 8513 [/iwibox/conup.sh]
Mon Mar 20 17:28:56 2017 kern.warn kernel: [29033.246412] IPTables-INPUT-Dropped: IN=eth1 OUT= MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.10 DST=192.168.181.1 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=7171 DF PROTO=TCP SPT=35157 DPT=3990 WINDOW=251 RES=0x00 ACK URGP=0 

I missing something ?

login successfull, write for kmod, call connup.sh after login (do nothing at this point), DROP 3990 on input (why ?) close connup.sh

why coova drop 3990 on input ? i have this rule

ACCEPT     tcp  --  eth1   *       192.168.180.0/24     192.168.181.1        tcp dpt:3990 coova: name: chillipub side: source

if i had the same rule without kmod, connection reset

nzamps commented 7 years ago

Just comparing with mine: you could take off the "-s 192.168.180.0/24" from that rule and you still need a rule for 3990 for unauthenticated users like: "iptables -A INPUT -d 192.168.181.1/32 -p tcp -m tcp --dport 3990 -j ACCEPT" if you haven't got one...maybe you could list how your rules as they are now?

keulu commented 7 years ago

here is all our rules.

everything work fine, except redirection after login and after logout.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8022 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -d 192.168.181.1/32 -i eth1 -p tcp -m tcp --dport 3990 -m coova--name chillipub --source  -j ACCEPT
iptables -A INPUT -d 192.168.181.1/32 -i tun11 -p tcp -m tcp --dport 3990 -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "IPTables-INPUT-Dropped: "
iptables -A INPUT -j DROP

iptables -A FORWARD -i eth1 -o eth0 -m coova--name chillipub --source  -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m coova--name chillipub --dest  -j ACCEPT
iptables -A FORWARD -i tun11 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun11 -j ACCEPT
iptables -A FORWARD -j LOG --log-prefix "IPTables-FORWARD-Dropped: "
iptables -A FORWARD -j DROP
keulu commented 7 years ago

any idea Brian ? maybe i made a bad openwrt compilation. Package missing or something ?

nzamps commented 7 years ago

Most likely the iptables rules and how your external portal works. Our rules are a little bit different - we use multiple iptables tables with more than one chilli instance so it's not as simple to compare but essentially we don't have rules like:

iptables -A FORWARD -i tun11 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o tun11 -j ACCEPT

Our equivalent would be:

iptables -A FORWARD -d 192.168.181.0/24 -j ACCEPT iptables -A FORWARD -s 192.168.181.0/24 -j ACCEPT

We also have a rule:

iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Otherwise it takes a lot of testing and trial and error...maybe you could try a different external portal and see if it behaves differently?

- brian

irongomme commented 7 years ago

I'm in the same situation, with xt_coova on OpenWRT. Everything works fine, except during redirection after a login or logout action. I have to refresh several time the logoff on logon url to be redirected to captive portal (unless i have "Unable to connect" from the browser). I don't believe it to be an iptables issue, but perhaps I'm wrong ... because, i don't see any log blocking any request.

I'm working with Coovachilli 1.3.2 on linksys WRT-1200AC and OpenWRT Chaos Calmer. If anyone have a clue, it could be awesome !

khmtambi commented 5 years ago

Hi all, I came a bit late but I really want to resume this conversation. As this discussion says that xt_coova kernel module will speed things up for authenticated users. I am having problems running it correctly. I have configured the exact same settings as mentioned above and applied the iptable rules as mentioned in this topic but none have helped me so far. I am using coova 1.4.7 with external captive portal. I have checked that xt_coova is properly loaded into the kernel. need guidance. Thanks in advance!

nzamps commented 5 years ago

Can you dump in here your setup like @keulu did above - chilli config, ifconfig, iptables rules etc and I'll have a look

nzamps commented 5 years ago

I have run a test using our multiple iptables table setup and the same rules without the extra tables and I did notice the issue when NOT using them. Seems there needs to be a short delay between login and the correct iptables rules being hit.

If someone (@keulu ?) can try the above rules but with a couple of changes:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8022 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -d 192.168.181.1/32 -i eth1 -p tcp -m tcp --dport 3990 -m coova --name chillipub -j ACCEPT
iptables -N INPUT_tun11
iptables -A INPUT_tun11 -d 192.168.181.1/32 -i tun11 -p tcp -m tcp --dport 3990 -j ACCEPT
iptables -A INPUT_tun11 -j RETURN
iptables -A INPUT -j LOG --log-prefix "IPTables-INPUT-Dropped: "
iptables -A INPUT -j DROP

iptables -A FORWARD -i eth1 -o eth0 -m coova --name chillipub  -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m coova --name chillipub --dest  -j ACCEPT
iptables -A FORWARD -i tun11 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun11 -j ACCEPT
iptables -A FORWARD -j LOG --log-prefix "IPTables-FORWARD-Dropped: "
iptables -A FORWARD -j DROP

Note: I have moved an INPUT rule to its own iptables table:

deleted

iptables -A INPUT -d 192.168.181.1/32 -i tun11 -p tcp -m tcp --dport 3990 -j ACCEPT)

added

iptables -N INPUT_tun11
iptables -A INPUT_tun11 -d 192.168.181.1/32 -i tun11 -p tcp -m tcp --dport 3990 -j ACCEPT
iptables -A INPUT_tun11 -j RETURN

See if it helps and I can think of a better solution.

khmtambi commented 5 years ago

Can you dump in here your setup like @keulu did above - chilli config, ifconfig, iptables rules etc and I'll have a look

Hi, Thank you very much for your kind consideration. With the help given here I have achieved what I wanted and I am getting like wired speeds and coova chilli running merely at 20%. What failing me was the FORWARD rule in defaults section of openwrt firewall. when I changed it from REJECT to DROP it started to work!

But there is one really odd thing I am facing may be this has to do with my configurations. I am using an external portal. The portal is opening fine but when I signin after authentication I get redirected to 11.1.0.1(my UAMLISTEN IP)

http://11.1.0.1:3990/logon?username=aaaa&password=bbbb&userurl=http%3A//externalcp.com/cp/success/1/40577/%3Fredirect_url%3Dhttps%3A//www.facebook.com/events/1651381694952629/&redir=http%3A//externalcp.com/cp/success/1/40577/%3Fredirect_url%3Dhttps%3A//www.facebook.com/events/1651381694952629/&WISPrVersion=2.0

This is the url I am getting and the connection is reset. However the internet is working fine!

khmtambi commented 5 years ago

here is my configuration:

THIS FILE IS AUTOMATICALLY GENERATED

cmdsocket /var/run/chilli.br-lan2.sock unixipc chilli.br-lan2.ipc pidfile /var/run/chilli.br-lan2.pid net 10.1.0.0/255.255.0.0 uamlisten 11.1.0.1 uamport 3990 dhcpif br-lan2 uamallowed "www.coova.org,externalco.com11.1.0.1 omitted uamanydns lease "3600" kname "chilli" dhcplisten "10.1.0.1" dynip 10.1.0.0/255.255.255.0 statip 10.1.1.0/255.255.255.0 dhcpstart "10" domain "lan" dns1 "8.8.8.8" dns2 "8.8.4.4" wwwdir /etc/chilli/www wwwbin /etc/chilli/wwwsh uamuiport 4990 uamdomain omitted locationname "My HotSpot" radiuslocationname "My_HotSpot" radiuslocationid "isocc=,cc=,ac=,network=Coova,"

iptable rules are that of /etc/chilli/up.sh. no custom rules added.

nzamps commented 5 years ago

Rather than using up.sh for iptables you should try a variation of the rules mentioned above/earlier. The rules in up.sh are not complete for xt_coova use.

khmtambi commented 5 years ago

Rather than using up.sh for iptables you should try a variation of the rules mentioned above/earlier. The rules in up.sh are not complete for xt_coova use.

ok. I am going to disable the up.sh script and use the above mentioned rules. should I include some of these rules in conup.sh?

nzamps commented 5 years ago

Not in conup.sh - that is run when a session is authorized. You could backup up.sh and put all the rules into that instead of the script code in there now.

khmtambi commented 5 years ago

Hi @nzamps I have been out for quite some time.

I have tested these rules at first they didn't seem to work and I didn't get any redirection... but then I changed the

iptables -A FORWARD -i eth1 -o eth0 -m coova --name chillipub  -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m coova --name chillipub --dest  -j ACCEPT
iptables -A FORWARD -i tun11 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun11 -j ACCEPT

and removed the -o argument and the redirection worked. but the problem of connection reset is still there... so far as in the above conversation I have tested a few things:

-disabled the TCPRESET -compiled coova chilli with JSON

I am always stuck at this page with the error: the connection is reset/ http://11.1.0.1:3990/logon?username=971506961351&password=04ec1c1ade97a875&userurl=http%3A//www.xxxxxx.xxx/cp/success/1/40577/%3Fredirect_url%3Dhttps%3A//www.facebook.com/events/1651381694952629/&redir=http%3A//www.xxxxxxxxx.xxx/cp/success/1/40577/%3Fredirect_url%3Dhttps%3A//www.facebook.com/events/1651381694952629/&WISPrVersion=2.0

there is also one more thing

when I type http://11.1.0.1:3990/ the page it shows is that too many redirects...

Really appreciate any help...

nzamps commented 5 years ago

Have you tried the multiple chains idea above?

iptables -N INPUT_tun11
iptables -A INPUT_tun11 -d 11.1.0.1/32 -i tun11 -p tcp -m tcp --dport 3990 -j ACCEPT
iptables -A INPUT_tun11 -j RETURN

iptables -A INPUT -i tun11 -j INPUT_tun11

In my previous message I missed that last rule to force the chain jump.

khmtambi commented 5 years ago

No... :(

No improvement. I think it is related to something else. because you see when this happens i.e. after I get the splash page correctly and get authenticated with ACCESS-ACCEPT packet the TCP RESET happens, I click on the url bar and just highlight the url and press enter... but this time the same url opens. and redirects to the Url defined in USRURL parameter... I dont think it is related to iptable rules... its more related to some sort of delay or something.

has it got to do anything with chilliController.js and some other files in the www folder?

appreciate your help man!

nzamps commented 5 years ago

Could possibly be conntrack messing up the tcp session when chilli stops DNAT'ing the packets after STATE is set to 1 (auth).

If you have access to the iptables extension xt_CT can you maybe experiment with disabling conntrack for the uamport:

iptables -t raw -A PREROUTING -p tcp --dport 3990 -j CT --notrack
khmtambi commented 5 years ago

I tried the above command. first I didn't have the module raw not loaded. but then i compiled and the command ran. but then I didnt' even get the first redirection. there was no splash page with this.

nzamps commented 5 years ago

Hmmm that's a shame...worked ok for me. Have you ever tried a tap instead of a tun interface? We always use tap (--usetap) and I wonder if the behaviour changes in any way ?

khmtambi commented 5 years ago

Hmmm that's a shame...worked ok for me. Have you ever tried a tap instead of a tun interface? We always use tap (--usetap) and I wonder if the behaviour changes in any way ?

I am using bridged interface like br-lan2 and I have used tap as you suggested. using this option with kname=chilli is not working and I dont get the splash page. but when I drop kname and use it without kernel module it works. in this case the iptable rules are from up.sh

would it be possible if I open my device and you can connect and see for yourself where I am doing wrong? I add all your rules (modified to my own interface and ip address maping) in up.sh

really banging my head off the wall on this one... :(

khmtambi commented 5 years ago

I am having the following logs

chilli[2889]: chilli_connect(5183): New Chilli Connection
chilli[2889]: cb_dhcp_request(4981): DHCP request for IP address 10.1.0.11
chilli[2889]: newip(876): newip 10.1.0.11
chilli[2889]: Requesting new static ip: 10.1.0.11
chilli[2889]: Static out of range (10.1.0.11)
chilli[2889]: Requesting new dynamic ip: 10.1.0.11
chilli[2889]: cb_dhcp_request(5110): Client MAC=A4-4E-31-5B-F1-F4 assigned IP 10.1.0.11
chilli[2889]: dhcp_set_addrs(3667): ARP Entry: 10.1.0.11 -> A4-4E-31-5B-F1-F4
chilli[2889]: dns_copy_res(201): It was a dns record type: 1 class: 1
chilli[2889]: dns_copy_res(209): DNS: www.googleapis.com
chilli[2889]: dhcp_receive_ip(4218): dropping packet; unhandled auth state 0
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dns_copy_res(201): It was a dns record type: 1 class: 1
chilli[2889]: dns_copy_res(209): DNS: clientservices.googleapis.com
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dns_copy_res(201): It was a dns record type: 1 class: 1
chilli[2889]: dns_copy_res(209): DNS: clientservices.googleapis.com
chilli[2889]: Received RADIUS packet id=0
chilli[2889]: Freeing RADIUS packet
chilli[2889]: RADIUS queue-out id=0 idx=0
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dns_copy_res(201): It was a dns record type: 1 class: 1
chilli[2889]: dns_copy_res(209): DNS: github.com
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dhcp_receive_ip(4104): Broadcasted UDP to port 137
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dhcp_receive_ip(4104): Broadcasted UDP to port 137
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dhcp_receive_ip(4104): Broadcasted UDP to port 137
chilli[2889]: cb_tun_ind(2565): arp: ifidx=0 src=52-54-91-29-83-43 dst=FF-FF-FF-FF-FF-FF prot=0806 (asking for 11.1.0.11)
chilli[2889]: cb_tun_ind(2577): ARP for unknown IP 11.1.0.11
iptables v1.6.2: unknown option "--cstate"

I am using the following rules:

iptables -t raw -A PREROUTING -p tcp --dport 3990 -j CT --notrack
iptables -A INPUT -m conntrack --cstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -d 11.1.0.1/24 -i br-lan -p tcp -m tcp --dport 3990 -m coova --name chilli -j ACCEPT
iptables -A INPUT -d 11.1.0.1/24 -i br-lan -p tcp --dport 3990 -j ACCEPT
iptables -A INPUT -d 11.1.0.1/32 -i tap0 -p tcp -m tcp --dport 3990 -j ACCEPT

ipt -A FORWARD -i $DHCPIF -m coova --name $KNAME -j ACCEPT
ipt -A FORWARD -o $DHCPIF -m coova --name $KNAME --dest -j ACCEPT
ipt -A FORWARD -i $TUNTAP -j ACCEPT
ipt -A FORWARD -o $TUNTAP -j ACCEPT

I am not getting the splash page at all with tap :(

nzamps commented 5 years ago

Ahhh bridged - we never had any real success with bridged interfaces and xt_coova. We run our chilli instances on separate devices ("controllers") without WiFi etc. Are you able to try a tap interface without a bridge - like just on eth1 and see ?

khmtambi commented 5 years ago

so are you saying that with bridge it is not possible?

nzamps commented 5 years ago

No, just saying we had issues with iptables and bridging so we don't set it up that way. I'm trying to work out the differences from ours to try to isolate the problem.

khmtambi commented 5 years ago

Hi man. I got it working with your iptable rules. there was a bit of mistake i was making. your rules work just fine! One thing I still am unable to do is bandwidth control. my RADIUS is sending bandwidth limit to each user but with xt_coova I am unable to get the bandwidth from RADIUS in conup or condown script. I am able to get the called station id. but not the bandwidth.Below are the attribues I called in the conup script WISPR_BANDWIDTH_MAX_DOWN= COOVACHILLI_BANDWIDTH_MAX_DOWN= RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN= RADIUS_ATTR_COOVACHILLI_BANDWIDTH_MAX_DOWN=

Please help

nzamps commented 5 years ago

I think your Radius parameter to return is RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN and you access this from scripts as WISPR_BANDWIDTH_MAX_DOWN. Check you are using these.

khmtambi commented 5 years ago

but in radius I am sending as WISPr-Bandwidth-Max-Down as well as CoovaChilli-Bandwidth-Max-Down. both are working without xt-coova I have checked. but with xt-coova I am not getting these parameters in conup. should I change the radius parameter to RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN and see?

nzamps commented 5 years ago

yep send RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN

khmtambi commented 5 years ago

ok. but I dont think this is defined anywhere in freeradius is it?

nzamps commented 5 years ago

Not sure but you could test it by setting defbandwidthmaxdown in the chilli.conf. This should return in the script as WISPR_BANDWIDTH_MAX_DOWN (defbandwidthmaxdown sets the same var as RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN).

khmtambi commented 5 years ago

@nzamps bro I did set defbandwidthmaxdown in chilli.conf and the variable WISPR_.. is 0 while RADIUS_ATTR.. is null. its just empty

nzamps commented 5 years ago

Hang on, what's in your Radius packet - if RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN is being sent as null then defbandwidthmaxdown will be overridden with 0.

khmtambi commented 5 years ago

Hang on, what's in your Radius packet - if RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN is being sent as null then defbandwidthmaxdown will be overridden with 0.

nothing is working. i am unable to get anything as it is still showed as 0

reinerotto commented 5 years ago

Before grabbing into this "Can of Worms", called xt_coova: Besides bandwidth_limit not working, how about download_limit ? I suspect, not working, too, correct ?

xewonder commented 5 years ago

Hi man. I got it working with your iptable rules. there was a bit of mistake i was making. your rules work just fine! One thing I still am unable to do is bandwidth control. my RADIUS is sending bandwidth limit to each user but with xt_coova I am unable to get the bandwidth from RADIUS in conup or condown script. I am able to get the called station id. but not the bandwidth.Below are the attribues I called in the conup script WISPR_BANDWIDTH_MAX_DOWN= COOVACHILLI_BANDWIDTH_MAX_DOWN= RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN= RADIUS_ATTR_COOVACHILLI_BANDWIDTH_MAX_DOWN=

Please help

Hey,

Could you please give me a hand with the IP rules? I am totally stuck!