2013-03-08 - Re: [GRASE-Hotspot] Running again (squid log issue)
Header Data
From: Paul van Oijen <Pa***n@abnamrocomfin.com>
Message Hash: 996a5b445a2a7a3c83f9dbba99986b9feebc17e162e8de1629129fbdb1069899
Message ID: <CDE0808EBF803548968A157E73EF1A5D16A4FD50A0@nlvwdbacfexc01>
Reply To: N/A
UTC Datetime: 2013-03-08 01:02:17 UTC
Raw Date: Fri, 08 Mar 2013 09:02:17 +0100
Raw message
Hai Tim,
Here the requested info:
iptables -V:
iptables v1.4.12
uname -a:
Linux hotspot 3.2.0-38-generic-pae #61-Ubuntu SMP Tue Feb 19 12:39:51 UTC 2013 i686 i686 i386 GNU/Linux
iptables -L -t mangle:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DROP tcp -- 10.1.0.0/24 10.1.0.1 tcp dpt:3128
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
TCPMSS tcp -- anywhere anywhere tcpflags: SYN,RST/SYN TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
iptables -L -t nat:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere anywhere
Chrs
---------------
10.1.0.0/24 is the net range used by de hotspot to dhcp. The port 3128 is listen by squid, these ports are accepted 3390, 4490, 80(http), 443(https), 22(ssh), etc. All internet traffic (http, no https)are redirect to port 3128.
The iptables are fine, I don't know why not log in access.log.
-----Mensaje original-----
De: Paul van Oijen [mailto:Paul.vanOijen@...]
Enviado el: Jueves, 07 de Marzo de 2013 11:45 a.m.
Para: grase-hotspot@...
Asunto: Re: [GRASE-Hotspot] Running again (squid log issue)
Thanks Hernán,
I checked the iptables but I do not understand a few items...
10.1.0.0/24 is used ??? where does that come from.
Here some detailed info
cat /var/run/chilli.tun0.sh:
iptables -D INPUT -i tun0 -p tcp -m tcp --dport 3990 --dst 10.1.0.1 -j ACCEPT
iptables -D INPUT -i tun0 -p tcp -m tcp --dport 4990 --dst 10.1.0.1 -j ACCEPT
iptables -D INPUT -i tun0 -p tcp -m tcp --dport 80 --dst 10.1.0.1 -j ACCEPT
iptables -D INPUT -i tun0 -p tcp -m tcp --dport 443 --dst 10.1.0.1 -j ACCEPT
iptables -D INPUT -i tun0 -p tcp -m tcp --dport 22 --dst 10.1.0.1 -j ACCEPT
iptables -D INPUT -i tun0 -p tcp -m tcp --dport 2812 --dst 10.1.0.1 -j ACCEPT
iptables -D INPUT -i tun0 -p tcp -m tcp --dport 53 --dst 10.1.0.1 -j ACCEPT
iptables -D INPUT -i tun0 -p tcp -m tcp --dport 3990 --dst 10.1.0.1 -j ACCEPT
iptables -D INPUT -i tun0 -p tcp -m tcp --dport 3128 --dst 10.1.0.1 -j ACCEPT
iptables -D INPUT -i tun0 -p udp -d 255.255.255.255 --destination-port 67:68 -j ACCEPT
iptables -D INPUT -i tun0 -p udp -d 10.1.0.1 --destination-port 67:68 -j ACCEPT
iptables -D INPUT -i tun0 -p udp --dst 10.1.0.1 --dport 53 -j ACCEPT
iptables -D INPUT -i tun0 -p icmp --dst 10.1.0.1 -j ACCEPT
iptables -D INPUT -i tun0 --dst 10.1.0.1 -j DROP
iptables -D INPUT -i eth1 -j DROP
iptables -D FORWARD -i eth1 -j DROP
iptables -D FORWARD -o eth1 -j DROP
iptables -D FORWARD -i tun0 -j ACCEPT
iptables -D FORWARD -o tun0 -j ACCEPT
iptables -D FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -D FORWARD -t mangle -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -D FORWARD -i tun0 ! -o eth0 -j DROP
iptables -D PREROUTING -t mangle -p tcp -s 10.1.0.0/255.255.255.0 -d 10.1.0.1 --dport 3128 -j DROP
iptables -D PREROUTING -t nat -i tun0 -p tcp -s 10.1.0.0/255.255.255.0 -d ! 10.1.0.1 --dport 80 -j REDIRECT --to 3128
iptables -D POSTROUTING -t nat -o eth0 -j MASQUERADE
The last 3 lines should take care of forcing data to the squid port if I am right but why 10.1.0.0/24.
my ifconfig: (striped a bit)
eth0 Link encap:Ethernet HWaddr 00:e0:4c:1f:9b:50
inet addr:192.168.1.80 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::2e0:4cff:fe1f:9b50/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1583768 errors:0 dropped:0 overruns:0 frame:0
TX packets:858271 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1596673044 (1.5 GB) TX bytes:89996844 (89.9 MB)
Interrupt:18 Base address:0x4f00
eth1 Link encap:Ethernet HWaddr 00:18:8b:04:fe:34
inet6 addr: fe80::218:8bff:fe04:fe34/64 Scope:Link
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:864957 errors:0 dropped:0 overruns:0 frame:0
TX packets:1532784 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:97291156 (97.2 MB) TX bytes:1540896545 (1.5 GB)
Interrupt:16
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.1.0.1 P-t-P:10.1.0.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING MTU:1500 Metric:1
RX packets:799007 errors:0 dropped:0 overruns:0 frame:0
TX packets:1503954 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:74906726 (74.9 MB) TX bytes:1511435565 (1.5 GB)
The ipup.sh script
#!/bin/sh
# Custom rules for Hotspot
# TRANS PROXY
# ipt -I PREROUTING -t nat -p tcp -s 10.1.0.0/24 -d 10.1.0.1 --dport 3128 -j DROP
# ipt -I PREROUTING -t nat -i $IF -p tcp -s 10.1.0.0/24 -d ! 10.1.0.1 --dport 80 -j REDIRECT --to 8080
# Redirect to Squid proxy (drop direct attempts to proxy)
ipt -I PREROUTING -t mangle -p tcp -s $NET/$MASK -d $ADDR --dport 3128 -j DROP
ipt -I PREROUTING -t nat -i $TUNTAP -p tcp -s $NET/$MASK -d ! $ADDR --dport 80 -j REDIRECT --to 3128
# Look at using this rule?
# ipt -I PREROUTING -t nat -i $TUNTAP -p tcp -s $NET/$MASK -d ! $ADDR --dport 80 -j DNAT --to 192.168.8.22:3128
# Redirect DNS to local server # Coova Chilli seems to take care of this
# ipt -I PREROUTING -t nat -i $TUNTAP -p tcp -s $NET/$MASK -d ! $ADDR --dport 53 -j REDIRECT --to 53
# ipt -I PREROUTING -t nat -i $TUNTAP -p udp -s $NET/$MASK -d ! $ADDR --dport 53 -j REDIRECT --to 53
# MASQUERADE
# WAS ON
# echo 1 > /proc/sys/net/ipv4/ip_forward maybe set to 0
#
ipt -I POSTROUTING -t nat -o $HS_WANIF -j MASQUERADE
This results in the last 3 lines of the cat /var/run/chilli.tun0.sh output as mentioned above.
iptables -L
#Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere
ACCEPT icmp -- anywhere 10.1.0.1
ACCEPT udp -- anywhere 10.1.0.1 udp dpt:domain
ACCEPT udp -- anywhere 10.1.0.1 udp dpts:bootps:bootpc
ACCEPT udp -- anywhere 255.255.255.255 udp dpts:bootps:bootpc
ACCEPT tcp -- anywhere 10.1.0.1 tcp dpt:3128
ACCEPT tcp -- anywhere 10.1.0.1 tcp dpt:3990
ACCEPT tcp -- anywhere 10.1.0.1 tcp dpt:domain
ACCEPT tcp -- anywhere 10.1.0.1 tcp dpt:2812
ACCEPT tcp -- anywhere 10.1.0.1 tcp dpt:ssh
ACCEPT tcp -- anywhere 10.1.0.1 tcp dpt:https
ACCEPT tcp -- anywhere 10.1.0.1 tcp dpt:http
ACCEPT tcp -- anywhere 10.1.0.1 tcp dpt:4990
ACCEPT tcp -- anywhere 10.1.0.1 tcp dpt:3990
DROP all -- anywhere 10.1.0.1
Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere
TCPMSS tcp -- anywhere anywhere tcpflags: SYN,RST/SYN TCPMSS clamp to PMTU
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
The up.sh scripts
#!/bin/sh
TUNTAP=$(basename $DEV)
UNDO_FILE=/var/run/chilli.$TUNTAP.sh
.........
Blabla blabla
.........
# site specific stuff optional
[ -e /etc/chilli/ipup.sh ] && . /etc/chilli/ipup.sh
The last lines should take care of the start for squid rules....
Maybe someone can shine a lite on this.....
Chrs
Ps What are these ports as they are not active on tcp:
tcp dpt:4990
tcp dpt:3990
------------
It seems as if they had erased the iptables, then gives access to your case without going through the squid service. You should start reviewing it. I hope I have been helpful.
Hernán Lozano
De: Drazen [drazen.zuvela@...]
Enviado el: jueves, 07 de marzo de 2013 06:01 a.m.
Para: GRASE Hotspot General Discussions
Asunto: Re: [GRASE-Hotspot] Running again (squid log issue)
Hi Paul,
I just did try to stop squid. It succeed. Then checked with my android
phone to connect. It went smothly. Internet access was allowed. At the
log page of adminstrator interface I could see connected android, but no
details recorded . What was correct assume.
Just intend to go further with testing, when one real client reported
problem with connection. It was W7 client. I checked personally at his
NB . Connection was alive, but has no acces to the internet.
So, I had to stop any further testing, because of him and also noticed
several iPhones online, all important roles in company, so I stopped
further testing. Squid started again, and everything went in order.
cat /proc/sys/net/ipv4/ip_forward
returned "1"
Sorry can't help you more at the moment.
Drazen
On 7.3.2013 9:32, Paul van Oijen wrote:
> Hai Drazen,
>
> I have no logging whatsoever from the hotspot anymore. Also the show all sessions will not show historic activities. It only show the amount of total data. (that's in the sql)
> On the older version I ran some stats tools using the access.log file from squid. It is in /var/log/squid3/access.log (which now stays empty)
> But it would be good to know if others also simply can turn of squid without any effect (I saw another post which sounds like the same issue).
> Maybe you could test it for me by simply entering 'service squid3 stop' on your hotspot and if any issue rise simply start it again with 'service squid3 start' on my site squid is simply not being used with Grase at the time (since 3.7.7.6)
> It's now just with IP forward. If I disable ipforward than the hotspot stops redirecting requests. You can test that with:
>
> cat /proc/sys/net/ipv4/ip_forward
> if it says 1 its being enabled if 0 its disabled I am sure it would say 1
>
> If you do:
>
> 'echo 0 > /proc/sys/net/ipv4/ip_forward' you would see after a few seconds the hotspot stops.
> Doing 'echo 1 > /proc/sys/net/ipv4/ip_forward' will enabled it again and the hotspot works again after a few seconds
>
> Pity as I liked squid in between (also for scanning and anti adds)
>
> Chrs
>
> -----------
>
> Hi Paul,
> Timothy wrote before about new way of session log displaying and filtering.
> Default view of session page is showing only active ones in new version.
> If no active conns. at the moment , nothing is showed.
> There is a switch to all session view at the top-left edge of session
> log frame. It says "Display All Sessions"
> Try that.
>
> Well, which log file is written actually? That part I don't know because
> ever need it yet.
>
> Rgds.
> Drazen
>
> -----Oorspronkelijk bericht-----
> Van: Paul van Oijen
> Verzonden: woensdag 6 maart 2013 10:21
> Aan: 'grase-hotspot@...'
> Onderwerp: RE: Running again (squid log issue)
>
> Hello,
>
> Just stopped squid3 (service squid3 stop) and to my amazement the hotspot is not even using Squid so all traffic goes directly. (ip forwarding ??) In the old version squid was still used and produced all stats.
>
> Is this indeed been disabled in this release or did something else happen?
>
> Chrs
>
> -----Oorspronkelijk bericht-----
> Van: Paul van Oijen
> Verzonden: dinsdag 5 maart 2013 16:42
> Aan: 'grase-hotspot@...'
> Onderwerp: Running again (squid log issue)
>
> Hello,
>
> Another issues rose.. the hotspot is now running ok but the access.log from squid stays empty.
> If I telnet to port 3128 from the local machine I see an entry but not from end users..
>
> What am I missing....?
>
> Chrs
>
>
Re: [GRASE-Hotspot] Running again (squid log issue)
From: Tim White <timwhite88@gm...> - 2013-03-07 22:13
Hey Paul.
Thanks for all this good debug info. Hopefully you've realized that
nothing should have changed regarding the squid logs. I did recently try
testing my installs, however they are still logging, making it hard to
work out what's different.
Can you also get me the iptables output for the nat and mangle tables.
These are the ones that actually redirect to squid.
iptables -L -t nat
iptables -L -t mangle
Also, what's your kernel version, and your iptables version?
iptables -V
uname -a
> Ps What are these ports as they are not active on tcp:
> tcp dpt:4990
> tcp dpt:3990
These ports are used by Coova Chilli, the are the ports the web
interface communicates over to login and get status details and such.
They should be active, although I'm not sure how you are trying to see
if they are active.
Tim
p.s. I'm away all weekend, so it'll be a few days before I can look at
the debug info and compare to a working setup
http://www.abnamrocomfin.com/maildisclaimer
Thread
-
Return to March 2013
-
Return to “Paul van Oijen <Pa***n@abnamrocomfin.com>”
-
2013-03-08 (Fri, 08 Mar 2013 09:02:17 +0100) - Re: [GRASE-Hotspot] Running again (squid log issue) - Paul van Oijen <Pa***n@abnamrocomfin.com>