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

Header Data

From: Paul van Oijen <Pa***n@abnamrocomfin.com>
Message Hash: d8b1b522a7b0efa598c6cdc839d0631e707c8a9eabcae5689872c47185d77184
Message ID: <CDE0808EBF803548968A157E73EF1A5D16C7552EAA@nlvwdbacfexc01>
Reply To: N/A
UTC Datetime: 2013-03-21 02:57:06 UTC
Raw Date: Thu, 21 Mar 2013 10:57:06 +0100

Raw message

Hello Tim,

Did you have time to check the info...
Really would like to have squid running again.

Chrs..

-----Oorspronkelijk bericht-----
Van: Paul van Oijen
Verzonden: vrijdag 8 maart 2013 9:02
Aan: 'gr***t@lists.sourceforge.net'
Onderwerp: RE: Running again (squid log issue)

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