[squid-users] Squid3.3.10 tcp_outgoing_tos still does work with freeBSD ?
Hi all! We want to use tcp_outgoing_tos with freeBSD 10.0-BETA2. And our test cases is very simple. Here is the related configure. # Squid normally listens to port 3128 acl normal_service_net src 192.168.1.1/32 acl good_service_net src 192.168.2.1/32 tcp_outgoing_tos 0x20 normal_service_net tcp_outgoing_tos 0x00 bad_service_net visible_hostname squid clients--- squid --- router And the 192.168.175.9 is my outgoing address. root@Squid:~ # tcpdump -n -i eth1 -vv src 192.168.175.9 tcpdump: listening on vlan708, link-type EN10MB (Ethernet), capture size 65535 bytes capability mode sandbox enabled 15:52:35.208420 IP (tos 0x20, ttl 64, id 497, offset 0, flags [DF], proto TCP (6), length 533, bad cksum 0 (-8115)!) 192.168.175.9.10902 115.239.210.27.80: Flags [P.], cksum 0xb7c4 (incorrect - 0x7295), seq 2526677121:2526677614, ack 178086541, win 17280, length 493 15:52:35.236238 IP (tos 0x20, ttl 64, id 498, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-8301)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 1860, win 15840, length 0 15:52:35.236385 IP (tos 0x20, ttl 64, id 499, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-8300)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 4740, win 12960, length 0 15:52:35.236396 IP (tos 0x20, ttl 64, id 500, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-82ff)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 7620, win 10080, length 0 15:52:35.236546 IP (tos 0x20, ttl 64, id 501, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-82fe)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 10500, win 7200, length 0 15:52:35.236557 IP (tos 0x20, ttl 64, id 502, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-82fd)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 13380, win 4320, length 0 15:52:35.236571 IP (tos 0x20, ttl 64, id 503, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-82fc)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 16124, win 1576, length 0 15:52:35.237315 IP (tos 0x20, ttl 64, id 505, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-82fa)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x3e83), seq 493, ack 16124, win 17280, length 0 15:52:35.358903 IP (tos 0x20, ttl 64, id 648, offset 0, flags [DF], proto TCP (6), length 541, bad cksum 0 (-7f86)!) 192.168.175.9.10903 115.239.211.11.80: Flags [P.], cksum 0xb8bc (incorrect - 0xca99), seq 1454826059:1454826560, ack 1068107219, win 17280, length 501 15:52:35.362187 IP (tos 0x0, ttl 64, id 649, offset 0, flags [DF], proto TCP (6), length 44, bad cksum 0 (-9029)!) 192.168.175.9.10905 180.149.131.210.80: Flags [S], cksum 0xa838 (incorrect - 0x5376), seq 239622, win 16384, options [mss 1460], length 0 15:52:35.386524 IP (tos 0x20, ttl 64, id 654, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-8175)!) 192.168.175.9.10903 115.239.211.11.80: Flags [.], cksum 0xb6c7 (incorrect - 0x0a4c), seq 501, ack 260, win 17021, length 0 15:52:35.419373 IP (tos 0x0, ttl 64, id 657, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-9025)!) 192.168.175.9.10905 180.149.131.210.80: Flags [.], cksum 0xa834 (incorrect - 0x2fb1), seq 239623, ack 860488872, win 17280, length 0 15:52:35.422048 IP (tos 0x0, ttl 64, id 658, offset 0, flags [DF], proto TCP (6), length 504, bad cksum 0 (-8e54)!) 192.168.175.9.10905 180.149.131.210.80: Flags [P.], cksum 0xaa04 (incorrect - 0xce68), seq 0:464, ack 1, win 17280, length 464 So, it's the tcp_outgoing_tos still has bug in freeBSD or I have some mistake there ?
Re: [squid-users] Re: squid_kerb_group (again)
Hi. On 24.12.2013 20:39, Markus Moeller wrote: Could you tell me which OS , kerberos, ldap and sasl version you use ? It's FreeBSD 10.0-BETA2 amd64 Heimdal Kerberos 1.5.2 cyrus-sasl 2.1.26 openldap-sasl-client-2.4.38 last two are from FreeBSD ports, -sasl- means it's compiled with --with-cyrus-sasl. Thanks. Eugene.
[squid-users] Re: Squid3.3.10 tcp_outgoing_tos still does work with freeBSD ?
And I tested with the same sutation on my Ubuntu server, it works correct :) On Thu, Dec 26, 2013 at 3:59 PM, Ge Jin altman87...@gmail.com wrote: Hi all! We want to use tcp_outgoing_tos with freeBSD 10.0-BETA2. And our test cases is very simple. Here is the related configure. # Squid normally listens to port 3128 acl normal_service_net src 192.168.1.1/32 acl good_service_net src 192.168.2.1/32 tcp_outgoing_tos 0x20 normal_service_net tcp_outgoing_tos 0x00 bad_service_net visible_hostname squid clients--- squid --- router And the 192.168.175.9 is my outgoing address. root@Squid:~ # tcpdump -n -i eth1 -vv src 192.168.175.9 tcpdump: listening on vlan708, link-type EN10MB (Ethernet), capture size 65535 bytes capability mode sandbox enabled 15:52:35.208420 IP (tos 0x20, ttl 64, id 497, offset 0, flags [DF], proto TCP (6), length 533, bad cksum 0 (-8115)!) 192.168.175.9.10902 115.239.210.27.80: Flags [P.], cksum 0xb7c4 (incorrect - 0x7295), seq 2526677121:2526677614, ack 178086541, win 17280, length 493 15:52:35.236238 IP (tos 0x20, ttl 64, id 498, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-8301)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 1860, win 15840, length 0 15:52:35.236385 IP (tos 0x20, ttl 64, id 499, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-8300)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 4740, win 12960, length 0 15:52:35.236396 IP (tos 0x20, ttl 64, id 500, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-82ff)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 7620, win 10080, length 0 15:52:35.236546 IP (tos 0x20, ttl 64, id 501, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-82fe)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 10500, win 7200, length 0 15:52:35.236557 IP (tos 0x20, ttl 64, id 502, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-82fd)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 13380, win 4320, length 0 15:52:35.236571 IP (tos 0x20, ttl 64, id 503, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-82fc)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x7bdb), seq 493, ack 16124, win 1576, length 0 15:52:35.237315 IP (tos 0x20, ttl 64, id 505, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-82fa)!) 192.168.175.9.10902 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect - 0x3e83), seq 493, ack 16124, win 17280, length 0 15:52:35.358903 IP (tos 0x20, ttl 64, id 648, offset 0, flags [DF], proto TCP (6), length 541, bad cksum 0 (-7f86)!) 192.168.175.9.10903 115.239.211.11.80: Flags [P.], cksum 0xb8bc (incorrect - 0xca99), seq 1454826059:1454826560, ack 1068107219, win 17280, length 501 15:52:35.362187 IP (tos 0x0, ttl 64, id 649, offset 0, flags [DF], proto TCP (6), length 44, bad cksum 0 (-9029)!) 192.168.175.9.10905 180.149.131.210.80: Flags [S], cksum 0xa838 (incorrect - 0x5376), seq 239622, win 16384, options [mss 1460], length 0 15:52:35.386524 IP (tos 0x20, ttl 64, id 654, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-8175)!) 192.168.175.9.10903 115.239.211.11.80: Flags [.], cksum 0xb6c7 (incorrect - 0x0a4c), seq 501, ack 260, win 17021, length 0 15:52:35.419373 IP (tos 0x0, ttl 64, id 657, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (-9025)!) 192.168.175.9.10905 180.149.131.210.80: Flags [.], cksum 0xa834 (incorrect - 0x2fb1), seq 239623, ack 860488872, win 17280, length 0 15:52:35.422048 IP (tos 0x0, ttl 64, id 658, offset 0, flags [DF], proto TCP (6), length 504, bad cksum 0 (-8e54)!) 192.168.175.9.10905 180.149.131.210.80: Flags [P.], cksum 0xaa04 (incorrect - 0xce68), seq 0:464, ack 1, win 17280, length 464 So, it's the tcp_outgoing_tos still has bug in freeBSD or I have some mistake there ?
[squid-users] Re: squid proxy kerberos authentication failure. Help!!!
I assume the *s are not in the real file. Can you run a strace against the
auth helper to verify the right keytab is used ?
Markus
flypast wrote in message news:1387953737367-4664034.p...@n4.nabble.com...
Hi Marcus,
Please see my current /etc/init.d/squid file. I had added your suggested
content.
[root@proxy01 ~]# cd /etc/init.d/
[root@proxy01 init.d]# more squid
#!/bin/bash
# chkconfig: - 90 25
# pidfile: /var/run/squid.pid
# config: /etc/squid/squid.conf
#
### BEGIN INIT INFO
# Provides: squid
# Short-Description: starting and stopping Squid Internet Object Cache
# Description: Squid - Internet Object Cache. Internet object caching is \
# a way to store requested Internet objects (i.e., data available \
# via the HTTP, FTP, and gopher protocols) on a system closer to the \
# requesting site than to the source. Web browsers can then use the \
# local Squid cache as a proxy HTTP server, reducing access time as \
# well as bandwidth consumption.
### END INIT INFO
PATH=/usr/bin:/sbin:/bin:/usr/sbin
export PATH
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
if [ -f /etc/sysconfig/squid ]; then
. /etc/sysconfig/squid
fi
# don't raise an error if the config file is incomplete
# set defaults instead:
SQUID_OPTS=${SQUID_OPTS:-}
SQUID_PIDFILE_TIMEOUT=${SQUID_PIDFILE_TIMEOUT:-20}
SQUID_SHUTDOWN_TIMEOUT=${SQUID_SHUTDOWN_TIMEOUT:-100}
SQUID_CONF=${SQUID_CONF:-/etc/squid/squid.conf}
# determine the name of the squid binary
[ -f /usr/sbin/squid ] SQUID=squid
prog=$SQUID
# determine which one is the cache_swap directory
CACHE_SWAP=`sed -e 's/#.*//g' $SQUID_CONF | \
grep cache_dir | awk '{ print $3 }'`
RETVAL=0
probe() {
# Check that networking is up.
[ ${NETWORKING} = no ] exit 1
[ `id -u` -ne 0 ] exit 4
# check if the squid conf file is present
[ -f $SQUID_CONF ] || exit 6
}
start() {
* KRB5_KTNAME=/etc/squid/squid.keytab
export KRB5_KTNAME*
probe
parse=`$SQUID -k parse -f $SQUID_CONF 21`
RETVAL=$?
if [ $RETVAL -ne 0 ]; then
echo -n $Starting $prog:
echo_failure
echo
echo $parse
return 1
fi
for adir in $CACHE_SWAP; do
if [ ! -d $adir/00 ]; then
echo -n init_cache_dir $adir...
$SQUID -z -F -f $SQUID_CONF
/var/log/squid/squid.out 21
fi
done
echo -n $Starting $prog:
$SQUID $SQUID_OPTS -f $SQUID_CONF /var/log/squid/squid.out 21
RETVAL=$?
if [ $RETVAL -eq 0 ]; then
timeout=0;
while : ; do
[ ! -f /var/run/squid.pid ] || break
if [ $timeout -ge $SQUID_PIDFILE_TIMEOUT ]; then
RETVAL=1
break
fi
sleep 1 echo -n .
timeout=$((timeout+1))
done
fi
[ $RETVAL -eq 0 ] touch /var/lock/subsys/$SQUID
[ $RETVAL -eq 0 ] echo_success
[ $RETVAL -ne 0 ] echo_failure
echo
return $RETVAL
}
stop() {
echo -n $Stopping $prog:
$SQUID -k check -f $SQUID_CONF /var/log/squid/squid.out 21
RETVAL=$?
if [ $RETVAL -eq 0 ] ; then
$SQUID -k shutdown -f $SQUID_CONF
rm -f /var/lock/subsys/$SQUID
timeout=0
while : ; do
[ -f /var/run/squid.pid ] || break
if [ $timeout -ge $SQUID_SHUTDOWN_TIMEOUT ]; then
echo
return 1
fi
sleep 2 echo -n .
timeout=$((timeout+2))
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-proxy-kerberos-authentication-failure-Help-tp4663964p4664034.html
Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Problem in access to cache manager
thanks Amos i set cachemgr_passwd none all, even if i remove user and password for cache manager, it doesn't work yet with authenticatin! i searched in bugzilla and didn't find any bug about this problem. On Wednesday, December 25, 2013 1:55 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 24/12/2013 9:35 p.m., ana any wrote: Greeting, I installed squid 3.3.9 on debian, but I don't have access to cache manager with authentication :( If I remove http_access allow authenticated line, then I have access. Here is a part of my config: cache_mgr ad...@example.com cachemgr_passwd MYPASS all auth_param digest program /usr/local/squid/libexec/digest_file_auth -c /home/passwd.htdigest auth_param digest children 5 auth_param digest realm ProxyServer auth_param digest nonce_garbage_interval 5 minutes auth_param digest nonce_max_duration 30 minutes auth_param digest nonce_max_count 50 acl authenticated proxy_auth REQUIRED http_access allow authenticated What's wrong with it?! Any helps would be appreciated. What should be happening is one of: * forward-proxy ports: - your proxy challenges for proxy-auth credentials using Digest and uses your helper to validate those Digest credentials. - when those are presented and accepted, - the cachemgr challenges for www-auth using Basic and uses your cachemgr_passwd settings to validate these Basic credentials. * reverse-proxy ports: - your proxy challenges for www-auth credentials using Digest and uses your helper to validate those Digest credentials. - when those are presented and accepted, - the cachemgr attempts to locate www-auth Basic credentials an fails. (If you were authenticating with Basic for the proxy and the users password matched cachemgr_passwd this might go through as above). * transparent intercept ports - your proxy ignores the request and passes it on to the server upstream. How does the HTTP traffic you are seeing match up with that description? Alternatively could you be hitting one of the bugs which appear to be in Squid Digest implementation? there are a few which result in erroneous rejections. As a workaround you could set cachemgr_passwd none all and rely on the Digest authentication and manager ACL to filter people who are logged in whether they can access the cachemgr or not. Amos
[squid-users] Re: Error using tcp_outgoing_mark
Sorry I'm just back. I don't understand functionality of tcp_outgoing_mark. How it works. how to use. Can I use this feature to set dscp field for every packet leaving squidbox and go to the client? do we need to do something with iptables after set tcp_outgoing_mark tag on squid? -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Error-using-tcp-outgoing-mark-tp4658748p4664052.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Tracing squid 3.1 functions
Not possible because there is none that recognize request protocol. What happens is admin configure squid.conf ports manually, one per protocol type to be recieved. Squid only supports HTTP, HTTPS, ICP, HTCP, and SNMP incoming traffic. The non-HTTP traffic support in Squid is for gatewaying traffic, where Squid makes the outbound connection in FTP/Gopher/HTTP/HTTPS/Wais/ etc so there is no detection or recognizing going on. Sorry, I don't understand. Could you please explain the squid scenario for a FTP request for example? What Amos is saying is that squid assumes the protocols by the incoming port, as per squid.conf configuration and not by any l7 heuristics.
Re: [squid-users] Re: Error using tcp_outgoing_mark
On 27/12/2013 5:32 a.m., yogii wrote: Sorry I'm just back. I don't understand functionality of tcp_outgoing_mark. How it works. how to use. Can I use this feature to set dscp field for every packet leaving squidbox and go to the client? do we need to do something with iptables after set tcp_outgoing_mark tag on squid? tcp_outgoing_mark sets the netfilter MARK value on packets exactly as if iptables/ip6tables/nftables/xtables had done it with a -j MARK rule. The MARK values are specific to the kernel they are set for and do not leave the machine. They have a 32-bit value range where TOS only has 4-bit value range once ECN is accounted for. You can set a MARK value by Squid and have iptables/ip6tables convert that to DSCP values as the packets leave the machine based on other criteria Squid is not aware of. NP: Squid adjusts tcp_outgoing_tos for ECN, so if you want to break ECN and use those bits for TOS values setting a MARK and translating it into a ECN-incompatible TOS value is the way to do that. tcp_outgoing_tos and qos_flows are what set the TOS/Differv values if you want to set them directly. Amos
Re: [squid-users] Tracing squid 3.1 functions
On 26/12/2013 8:22 p.m., m.shahverdi wrote: Not possible because there is none that recognize request protocol. What happens is admin configure squid.conf ports manually, one per protocol type to be recieved. Squid only supports HTTP, HTTPS, ICP, HTCP, and SNMP incoming traffic. The non-HTTP traffic support in Squid is for gatewaying traffic, where Squid makes the outbound connection in FTP/Gopher/HTTP/HTTPS/Wais/ etc so there is no detection or recognizing going on. Sorry, I don't understand. Could you please explain the squid scenario for a FTP request for example? Squid takes the traffic from the client and parses it as HTTP. This will either succeed or fail. There is no recognize logic to prevent the parsing. There is no undo functionality to rewind a transaction once it has started consuming bytes. When an FTP client connects to Squid there are three things which might happen: Scenario 1: FTP client connects to Squid and waits for the FTP server greeting. Squid waits for the client HTTP request. Up to 15mins later the hung connection is aborted. Scenario 2: FTP client connects to Squid and sends the FTP message: USER anonymous Squid parses the HTTP method USER and the URL anonymous. Absence of HTTP/x.x field means HTTP/0.9 protocol backward compatibility is enabled: no mime headers expected, and anything is valid in the body section. At some point in the message handling (probably URL parsing trying to cope with the string anonymous) Squid detects a major error in the message and aborts with an HTTP error message: HTTP/1.1 400 Invalid Request ... The FTP client then aborts because that is invalid FTP syntax. The FTP client software may (or may not) throw up an error about status 0. Scenario 3: FTP client connects to Squid and sends the HTTP request: GET ftp://example.com/ HTTP/1.1 Host: example.com Squid parses and processes the HTTP request. Connecting to the FTP server example.com and and fetching the root directory listing data (using FTP protocol). Generating an HTTP response from that data for the client. Everything is happy. Furthermore is it possible to configure squid in order to redirect unsupported requests instead of displaying error page to the user? Do you know what unsupported requests means? These are three examples of unsupported requests: 1) aaf9w7fkj4h\t/asfwf9\tawd/1\r\nw4vwe:sef34,t2df\n\n 2) Secure * Secure-HTTP/1.4 Host: example.com 3) FIND /smash RDP/1.0 Host: example.com Response-Action: FORWARD-ANY Squid is *incapable* of doing anything proper with unsupported requests simply by fact of not being able to identify what they are saying. Amos
[squid-users] Squid, Firewall TCP RST Flags
Hi, Recently, we had some DDoS type attacks on our servers, so in an attempt to secure our systems, we added some iptables rules, which seems to work quite well on most of our servers. Even on systems dedicated to Squid, all seems to run well. However, one rule in particular seems to catch up a lot of entries in Squid machines, which are almost non-existent on the other non-Squid machines: -A OUTPUT -p tcp -m tcp --tcp-flags RST RST -j OUTRST -m comment --comment OUTPUT: Catch RST pkt -A OUTRST -j LOG --log-prefix OUTRST: -A OUTRST -j DROP -m comment --comment OUTRST: Drop outbound RST From what we have seen, this does not seem to have a detrimental affect on Squid Proxy. But, out of academic interest, we would still like to learn more on why so many RST packets would be generated from the server itself. Can anyone shed some light? Regards HASSAN
