[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 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 2>&1` 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 2>&1 fi done echo -n $"Starting $prog: " $SQUID $SQUID_OPTS -f $SQUID_CONF >> /var/log/squid/squid.out 2>&1 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 2>&1 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 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