2013-03-07 - Re: [GRASE-Hotspot] Running again (squid log issue)

Header Data

From: “Lozano, Hernán” <hl***o@cetsa.com.ar>
Message Hash: cbb7dbcb2770b240cfe723d21fa74bb4caedbebc0520981f1ab793a043157cf3
Message ID: <5919C439564D8D459BA8D5076AF6DD7C0CBCC588@PromiExchMBX01.prominente.com.ar>
Reply To: <CDE0808EBF803548968A157E73EF1A5D16A4FD5005@nlvwdbacfexc01>
UTC Datetime: 2013-03-07 09:54:49 UTC
Raw Date: Thu, 07 Mar 2013 16:54:49 +0000

Raw message 

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:Pa***n@abnamrocomfin.com] 
Enviado el: Jueves, 07 de Marzo de 2013 11:45 a.m.
Para: gr***t@lists.sourceforge.net
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
>
>

http://www.abnamrocomfin.com/maildisclaimer


------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Grase-hotspot mailing list
Gr***t@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/grase-hotspot

Thread