Re: [squid-users] RE: wbinfo_group.pl receives user and domain in wrong format?
On 4/01/2013 10:01 p.m., Laurikainen, Tuukka wrote: Hi, Update: If I change "winbind use default domain = no" the wbinfo_group.pl receives the correct username. This OK, just that the basic auth users now need to include the domain with their username. I still would like to know why wbinfo_group.pl receives the username in form of USER@MY.DOMAIN and not as DOMAIN\USER or just USER as I understand it should. Your understanding of the user name format is wrong. * NTLM auth protocol format is domain\user * Kerberos auth protocol format is user@domain. Both are correct formats for Negotiate authentication user name labels, since Negotiate is a wrapper layer around both auth protocols. Amos
Re: [squid-users] Transparent Mode and WCCP
On 5/01/2013 3:01 a.m., Roman Gelfand wrote: So, the fortigate was configured based on the whitepaper you pointed me to. The unencrypted http traffic works, but what I find is that even though a request from the client arrives on squid via wccp, going back it is routed via standard tcp/ip path. Is that how wccp communication supposed to work with squid or should it come back to the client via wccp? Some bit of clarification here. "WCCP" is a protocol consisting of two packets HERE_I_AM and I_SEE_YOU. The HTTP traffic always goes via GRE protocol interface or layer-2 packet routing via Ethernet interface. The WCCP protocol configuratino in Squid and Cisco determins whether the layer-1 or GRE are used as return method. I think from your earlier posts you are confusing "WCCP" protocol with the name of the interface your config uses (wccp0). Also, NAT is only ever performed on the first packet of any connnection, which will always be an incoming packet arriving from your wccp0 interface in PREROUTING. You did not mention a MASQUERADE rule in the POSTROUTING chain which is the part handling the return packets to the client. Other TCP data packets than that first one seen by NAT table are ESTABLISHED or RELATED state and will go out whatever interface your routing setup is configured to send them out. The thing to remember the Squid box is acting as a router for these packets. Also, https traffic is not working. I am not sure if it is ssl bump that is causing it. Can you see why it wouldn't work? Please, note the same squid configuration works for for both http and https proxy is explicitly specified in the browser. This means only that Squid acting as forward-proxy works, none of the WCCP protocol and interfaces, NAT or HTTP re-interpretation happens. Squid acting as interception proxy is a VERY different beast from regular forward proxy. Amos
Re: [squid-users] Re: Help with Kerberos Configuration
i have tried to get this working, and still have issues. i think it
might be related to my topology. i did add the HTTP/proxy.domain.tld
principal to the keytab on the load balancer, and have the -s
GSS_C_NO_NAME directive in each squid config. the two servers each
have a squid.keytab that has the same principal in it as the load
balancer. in essence, there is 3 copies of the same keytab on 3
boxes.
in looking at the logs, that the load balancer is making requests of
Kerberos on an IP that is not the VIP. log entries below:
2013-01-04T19:11:04.926696-05:00 server krb5kdc[12337]: AS_REQ (4
etypes {18 17 16 23}) 192.168.25.254: ISSUE: authtime 1357344664,
etypes {rep=18 tkt=18 ses=18}, HTTP/proxy.bpk2@bpk2.com for
krbtgt/bpk2@bpk2.com
2013-01-04T19:11:23.710855-05:00 server krb5kdc[12337]: AS_REQ (4
etypes {18 17 16 23}) 192.168.25.254: ISSUE: authtime 1357344683,
etypes {rep=18 tkt=18 ses=18}, HTTP/proxy.bpk2@bpk2.com for
krbtgt/bpk2@bpk2.com
now, the 192.168.25.254 address is the load balancer box, but on the
interface it has on segment with the Kerberos server. The Kerberos
server is one-in-the-same as one of the squid servers being load
balanced. it also happens to be that the load balancer is a router
for several other segments. the load balancer/router device has an
interface of 192.168.37.254 which is on the VIP network, and the VIP
of 192.168.37.1 is also on the load balancer / router. haproxy is
running with a listener on the 37.1 interface as the proxy VIP.
my theory is that i might be trying to do too much with too little,
and that i might have to break up some of the duties that all the
boxes are doing, unless someone can shed some light on what i could be
doing wrong. Please let me know if you further clarification is
needed.
On 8/31/12, Markus Moeller wrote:
> You may need a third entry in the keytab for the VIP. IE will look for a
> HTTP/ ticket.
>
> Regards
> Markus
>
>
> "brendan" wrote in message
> news:1346159765625-4656345.p...@n4.nabble.com...
>>i have two squid instances on two separate servers. each is configured
>>with
>> kerberos auth, and when i point at one or the other, the kerberos auth
>> works
>> fine. when i point to a load balanced VIP, the auth does not work. i
>> found
>> the below and tried the method using the one keytab file for both
>> instances
>> and the -s GSS_C_NO_NAME option in the conf file. this did not work as
>> expected.
>>
>> the load balancing process i am using is the "balance" package for fedora
>> 16. it does a SNAT on all requests it handles. could this be part of why
>>
>> i
>> am having issues? i found a couple of packages that i might be able to
>> use
>> for load balancing in the repos, balance, ipvsadm and haproxy. does
>> anyone
>> have experience/success with any of these or might one be recommended
>> over
>> the others?
>>
>>
>>
>> --
>> View this message in context:
>> http://squid-web-proxy-cache.1019090.n4.nabble.com/Help-with-Kerberos-Configuration-tp4076779p4656345.html
>> Sent from the Squid - Users mailing list archive at Nabble.com.
>>
>
>
>
Re: [squid-users] tcp_outgoing_tos doesn't work in 3.2?
On Fri, 2013-01-04 at 10:05 +0200, John Hay wrote: > On Fri, Jan 04, 2013 at 07:36:35AM +, Andrew Beverley wrote: > > On Fri, 2013-01-04 at 06:31 +0200, John Hay wrote: > > > Looking at a linux man page: > > > > > > http://linux.die.net/man/2/setsockopt > > > > > > I see the same kind of text: > > > > > > Most socket-level options utilize an int argument for optval. For > > > setsockopt(), the argument should be nonzero to enable a boolean option, > > > or zero if the option is to be disabled. > > > > Ah, interesting, I have to admit that I didn't read the Linux man page. > > > > > So maybe it is just luck that the current code does work and all of them > > > actually expects it in an int. :-) > > > > That said, when I was searching the BSD options, I did read somewhere > > that Linux started accepting a char value after a certain kernel > > version. > > > > > I think it started because of hysterical raisins, from the days before > > > function prototypes, but even the examples in recentish rfcs (3493 and > > > 3542) that describe IPv6 usage, use an int in all their examples that > > > will fit in an int. Also a plain int is used and not a int32, probably > > > because a native int is assumed to be the most efficient size. > > > > Interesting - maybe I should have kept it as an int all along :) > > Rereading my own paragraph, maybe an extra comment. What I meant with most > efficient size, was going through the setsockopt call. If you want to store > many of these in an array, a char will be the most space efficient, but > going through the setsockopt() call, a char will not give you any advantage, > if you look at how processors do register and stack operations. Good point - I see what you're saying. Amos - given the (probably) small quantity of TOS configuration values, do you think it's worth changing tos_t back to an int for all operating systems, as it was in v3.1? This reduces the complexity of having different types for different operating systems, saves the overhead of initiating a new value for *BSD each time its used, and as John says it probably doesn't come at much (if any) of a price in terms of memory usage. Andy
Re: [squid-users] Transparent Mode and WCCP
So, the fortigate was configured based on the whitepaper you pointed me to. The unencrypted http traffic works, but what I find is that even though a request from the client arrives on squid via wccp, going back it is routed via standard tcp/ip path. Is that how wccp communication supposed to work with squid or should it come back to the client via wccp? Also, https traffic is not working. I am not sure if it is ssl bump that is causing it. Can you see why it wouldn't work? Please, note the same squid configuration works for for both http and https proxy is explicitly specified in the browser. Thanks again for your help. On Thu, Jan 3, 2013 at 11:37 PM, Eliezer Croitoru wrote: > Hey, > > I have found this: > http://kb.fortinet.com/kb/viewContent.do?externalId=FD30096 > > which pretty much covers what needed to be done. > > WCCP suppose to be a layer 2 interception which TPROXY is the closest thing > for that. > > TPROXY use the same src IP of the client for outgoing traffic based on a > client connection. > > You can try to configure the fortigate device and maybe try to open a ticket > for the FORTI guys in case you dont get it right. > > WCCP works with most catalyst devices I have tried. > There are other ways to intercept traffic and it's only up to the level of > your skills and knowledge. > > It seems like the fortigate is the right place to integrate squid > interception to me. > > I noticed that you didn't configured all squid needed directives to support > auto WCCP service registration. > > Try to do it manually on the fortigate and see the results. > > Best regards, > Eliezer > > > On 1/4/2013 1:22 AM, Roman Gelfand wrote: >> >> Thanks for your help. Please, see attached configuration files and >> topology picture. >> >> I am not using cisco device. I configured fortigate 50b firewall >> wccp service using gre tunnel. In this case, I am using straight >> transparent proxy. I have never used tproxy. >> >> I do have catalyst router which supports wccp2. Should I use that >> instead of the fortigate? >> >> How does using tproxy instead of transparent proxy improves wccp routing? >> >> Thanks again >> >> >> On Wed, Jan 2, 2013 at 4:39 AM, Eliezer Croitoru >> wrote: >>> >>> Based on what you configured you cisco router? what did you configured on >>> your cisco router? >>> What cisco device are you using? >>> >>> did you had the chance to look at: >>> http://wiki.squid-cache.org/ConfigExamples/UbuntuTproxy4Wccp2 >>> >>> please try to share more information on the infrastructure and the whole >>> squid.conf removing only confrontational INFO. >>> >>> Did you had the chance to use TPROXY before? >>> Did you tried to sniff with tcpdump? >>> >>> Eliezer >>> >>> >>> On 1/2/2013 3:38 AM, Roman Gelfand wrote: I use wccp/gre tunnel. Port 80 requests work but 443 don't. I am not sure if this is right, but even though data was received on wccp, no data was transmitted back over wccp. In other words, squid server response was routed back, through eth0 interface, rather than go through wccp0 interface. Is this expected behavior? If not, what do I do to make response go over wccp? my iptable config look like this iptables -t nat -A PREROUTING -i wccp0 -p tcp --dport 80 -j DNAT --to 192.168.5.81:3228 iptables -t nat -A PREROUTING -i wccp0 -p tcp --dport 443 -j DNAT --to 192.168.5.81:3229 and squid.conf wccp2_service dynamic 90 wccp2_service_info 90 protocol=tcp priority=240 ports=80,443 >>> > > -- > Eliezer Croitoru > https://www1.ngtech.co.il > sip:ngt...@sip2sip.info > IT consulting for Nonprofit organizations > eliezer ngtech.co.il
Re: [squid-users] SSL Bump Root Certificate Expiration
http://projects.puppetlabs.com/projects/1/wiki/SSL_in_The_Year2038 32-bit date overflow, same problem as the generic UNIX Y2038 bug. Use 64 bit systems 8-) George William Herbert Sent from my iPhone On Jan 4, 2013, at 1:10 AM, Woon Khai Swen wrote: > Found out the problem > > # openssl req -new -newkey rsa:1024 -days 36500 -nodes -x509 -keyout myCA.pem > -out myCA.pem > > # openssl x509 -in myCA.pem -outform DER -out myCA.der > > Installing myCA.der as root cert shows the validity date from Friday, 4 > January, 2013 4:58:39 PM to Thursday, 4 November, 1976 10:30:23 AM > (1976, not 2113. it can auto back date :O ) > > Still figuring out why this happened, thou. Must be an openssl issue. The > commands are copied directly from squid dynamic cert generation wiki. > > Thanks for the pointer. > > > > -Original Message- > From: Will Roberts [mailto:ironwil...@gmail.com] > Sent: Friday, 4 January, 2013 12:20 PM > To: squid-users@squid-cache.org > Subject: Re: [squid-users] SSL Bump Root Certificate Expiration > > On 01/03/2013 11:16 PM, Woon Khai Swen wrote: >> Dear all, >> >> I found out the self signed ssl root cert for transparent SSL interception >> (SSL Bump + origin cert mimicking + dynamic cert generation) is valid only >> for 365 days max, no matter how many additional days specified in openssl >> cert generation command line. > > Mine's good for 100 years. I'd check your command line arguments. > > --Will
RE: [squid-users] SSL Bump Root Certificate Expiration
Found out the problem # openssl req -new -newkey rsa:1024 -days 36500 -nodes -x509 -keyout myCA.pem -out myCA.pem # openssl x509 -in myCA.pem -outform DER -out myCA.der Installing myCA.der as root cert shows the validity date from Friday, 4 January, 2013 4:58:39 PM to Thursday, 4 November, 1976 10:30:23 AM (1976, not 2113. it can auto back date :O ) Still figuring out why this happened, thou. Must be an openssl issue. The commands are copied directly from squid dynamic cert generation wiki. Thanks for the pointer. -Original Message- From: Will Roberts [mailto:ironwil...@gmail.com] Sent: Friday, 4 January, 2013 12:20 PM To: squid-users@squid-cache.org Subject: Re: [squid-users] SSL Bump Root Certificate Expiration On 01/03/2013 11:16 PM, Woon Khai Swen wrote: > Dear all, > > I found out the self signed ssl root cert for transparent SSL interception > (SSL Bump + origin cert mimicking + dynamic cert generation) is valid only > for 365 days max, no matter how many additional days specified in openssl > cert generation command line. Mine's good for 100 years. I'd check your command line arguments. --Will
[squid-users] RE: wbinfo_group.pl receives user and domain in wrong format?
Hi, Update: If I change "winbind use default domain = no" the wbinfo_group.pl receives the correct username. This OK, just that the basic auth users now need to include the domain with their username. I still would like to know why wbinfo_group.pl receives the username in form of USER@MY.DOMAIN and not as DOMAIN\USER or just USER as I understand it should. Regards, Tuukka -Original Message- From: Laurikainen, Tuukka [mailto:t.laurikai...@ibermatica.com] Sent: Thursday, January 03, 2013 6:50 PM To: squid-users@squid-cache.org Subject: [squid-users] wbinfo_group.pl receives user and domain in wrong format? Hi, I have the following problem with an external acl: The Squid server is configured to authenticate users from AD (Negotiate and NTLM auth both work fine). The problem I have is with an external acl to check group permissions: external_acl_type AD-Groups ttl=10 children=60 %LOGIN /usr/lib/squid3/wbinfo_group.pl Now, debugging the wbinfo_group.pl I can see that: Got USER@MY.DOMAIN AD_GROUP from squid Usuario: USER@MY.DOMAIN User: - USER@MY.DOMAIN- Group: -AD_GROUP- SID: -S-1-5-21-1472344799-869232178-1847928074-74927- GID: -10081- Could not get groups for user USER@MY.DOMAIN Sending ERR to squid It correctly gives OK if the user is just the USER, but why is Squid passing the user in this format USER@MY.DOMAIN? I understand it should strip the domain part off(?)... Wbinfo -t, wbinfo -u, wbinfo -g all work fine. wbinfo -r works too, if the user is given in a correct format (USER or DOMAIN\\USER). smb.conf: [global] interfaces = 127.0.0.1/8 eth0 workgroup = DOMAIN netbios name = squid local master = no realm = MY.DOMAIN security = ads encrypt passwords = yes password server = dc1.my.domain, dc2.my.domain, * load printers = no idmap uid = 1-2 idmap gid = 1-2 winbind enum groups = yes winbind enum users = yes winbind use default domain = yes client use spnego = yes debug level = 2 squid.conf (just the auth lines): auth_param negotiate program /usr/local/bin/negotiate_wrapper --ntlm /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --domain=MY.DOMAIN --kerberos /usr/lib/squid3/squid_kerb_auth -s GSS_C_NO_NAME auth_param negotiate keep_alive off auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --domain=MY.DOMAIN Squid version 3.1.6. Regards, Tuukka
Re: [squid-users] tcp_outgoing_tos doesn't work in 3.2?
On Fri, Jan 04, 2013 at 07:36:35AM +, Andrew Beverley wrote: > On Fri, 2013-01-04 at 06:31 +0200, John Hay wrote: > > Looking at a linux man page: > > > > http://linux.die.net/man/2/setsockopt > > > > I see the same kind of text: > > > > Most socket-level options utilize an int argument for optval. For > > setsockopt(), the argument should be nonzero to enable a boolean option, > > or zero if the option is to be disabled. > > Ah, interesting, I have to admit that I didn't read the Linux man page. > > > So maybe it is just luck that the current code does work and all of them > > actually expects it in an int. :-) > > That said, when I was searching the BSD options, I did read somewhere > that Linux started accepting a char value after a certain kernel > version. > > > I think it started because of hysterical raisins, from the days before > > function prototypes, but even the examples in recentish rfcs (3493 and > > 3542) that describe IPv6 usage, use an int in all their examples that > > will fit in an int. Also a plain int is used and not a int32, probably > > because a native int is assumed to be the most efficient size. > > Interesting - maybe I should have kept it as an int all along :) Rereading my own paragraph, maybe an extra comment. What I meant with most efficient size, was going through the setsockopt call. If you want to store many of these in an array, a char will be the most space efficient, but going through the setsockopt() call, a char will not give you any advantage, if you look at how processors do register and stack operations. John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org
