<div dir="ltr">Hi,<div><br></div><div>From what I saw with using IP as part of then authentication, it checks which IP the user is connecting to the server from. What I want to check is which public IP of the server the user is connecting to.</div><div><br></div><div>If someone connects to the server's IP address x.x.x.x, I want the outgoing traffic to go through the same IP address x.x.x.x. That's why I put an acl rule for each public IP of the server and specified the tcp_outgoing_address for each of them.</div><div><br></div><div>So, for example, if the server has say 50 public IP address, I want to create an user who will be able to connect to 25 of them and another to another 25.</div><div><br></div><div>I hope this clarifies my original question.</div><div><br></div><div>With regards,</div><div>Sonya Roy.<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 19, 2017 at 5:30 PM, <span dir="ltr"><<a href="mailto:squid-users-request@lists.squid-cache.org" target="_blank">squid-users-request@lists.squid-cache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send squid-users mailing list submissions to<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/<wbr>listinfo/squid-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:squid-users-request@lists.squid-cache.org">squid-users-request@lists.<wbr>squid-cache.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:squid-users-owner@lists.squid-cache.org">squid-users-owner@lists.squid-<wbr>cache.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of squid-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Squid authentication problem (Amos Jeffries)<br>
2. Re: squid 4.0.20 does not recognize ssl-bump option.<br>
(Alex Rousskov)<br>
3. Re: squid 4.0.20 does not recognize ssl-bump option.<br>
(Amos Jeffries)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Mon, 19 Jun 2017 00:56:31 +1200<br>
From: Amos Jeffries <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
Subject: Re: [squid-users] Squid authentication problem<br>
Message-ID: <<a href="mailto:343154ec-dbd6-aa55-f867-216d3c261423@treenet.co.nz">343154ec-dbd6-aa55-f867-<wbr>216d3c261423@treenet.co.nz</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
<br>
On 18/06/17 17:50, Sonya Roy wrote:<br>
> Hi,<br>
><br>
> I am running squid on a server with multiple public IPs and I want<br>
> some users to be able to access the proxy through some of the IPs and<br>
> other users through other IPs.<br>
><br>
> At the moment I have acl rules of the form:-<br>
> acl abcd myip x.x.x.x<br>
><br>
<br>
What you need is an ACL that compares the username to the IP.<br>
<br>
<<a href="http://www.squid-cache.org/Versions/v3/3.5/manuals/ext_file_userip_acl.html" rel="noreferrer" target="_blank">http://www.squid-cache.org/<wbr>Versions/v3/3.5/manuals/ext_<wbr>file_userip_acl.html</a>><br>
<<a href="http://www.squid-cache.org/Versions/v3/3.5/manuals/ext_edirectory_userip_acl.html" rel="noreferrer" target="_blank">http://www.squid-cache.org/<wbr>Versions/v3/3.5/manuals/ext_<wbr>edirectory_userip_acl.html</a>><br>
<<a href="http://www.squid-cache.org/Versions/v3/3.5/manuals/ext_sql_session_acl.html" rel="noreferrer" target="_blank">http://www.squid-cache.org/<wbr>Versions/v3/3.5/manuals/ext_<wbr>sql_session_acl.html</a>><br>
<br>
or the new 'extras' feature for authenticators in Squid-3.5 that lets<br>
them use the IP as part of the auth approval. Though with this the thing<br>
to be aware of is that the IP becomes like a scope for the user login -<br>
the wrong IP being used to login from results in re-auth challenge just<br>
as would be seen if the password was wrong. So use carefully.<br>
<<a href="http://www.squid-cache.org/Doc/config/auth_param/" rel="noreferrer" target="_blank">http://www.squid-cache.org/<wbr>Doc/config/auth_param/</a>><br>
<<a href="http://www.squid-cache.org/Versions/v3/3.5/RELEASENOTES.html#ss2.2" rel="noreferrer" target="_blank">http://www.squid-cache.org/<wbr>Versions/v3/3.5/RELEASENOTES.<wbr>html#ss2.2</a>><br>
<br>
> and for these acl rules I have these tcp_outgoing_address:-<br>
> tcp_outgoing_address x.x.x.x abcd<br>
><br>
<br>
Why limit the outgoing? in HTTP that is independent to the incoming<br>
connection and restricting it will lower performance.<br>
<br>
> And earlier I had proxy_auth acl rules separately, but that allowed<br>
> any authenticated users to be able to access the proxy through any of<br>
> those IPs. Since I wanted some users to be able to use the server<br>
> through some IPs and others through different IPs, I tried this in<br>
> those acl rules:-<br>
><br>
> acl abcd myip x.x.x.x proxy_auth user1<br>
<br>
FTR: that will match the IP address x.x.x.x and the IP address(es) of<br>
the servers with hostnames "proxy_auth" and "user1" in your local DNS.<br>
<br>
Also, the myip ACL is deprecated because it matched different things<br>
based on the traffic type. myportname or localip ACLs are better if you<br>
need to do this at all. Your "squid -k parse" config checks should warn<br>
you about that.<br>
<br>
Amos<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sun, 18 Jun 2017 16:53:15 -0600<br>
From: Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.<wbr>com</a>><br>
To: meym <<a href="mailto:meym@nym.mixmin.net">meym@nym.mixmin.net</a>>, Squid Users<br>
<<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-<wbr>cache.org</a>><br>
Subject: Re: [squid-users] squid 4.0.20 does not recognize ssl-bump<br>
option.<br>
Message-ID:<br>
<<a href="mailto:9e834f7b-b20b-2cb5-e439-3fa0eaf1223e@measurement-factory.com">9e834f7b-b20b-2cb5-e439-<wbr>3fa0eaf1223e@measurement-<wbr>factory.com</a>><br>
Content-Type: text/plain; charset=koi8-r<br>
<br>
On 06/18/2017 09:49 AM, meym wrote:<br>
>> On 06/17/2017 10:09 AM, meym wrote:<br>
>>> Squid Cache: Version 4.0.20<br>
>>> "FATAL: Unknown http_port option 'ssl-bump'."<br>
>><br>
>> Your Squid thinks it was built without OpenSSL support. OpenSSL support<br>
>> is required for SslBump. Examine your ./configure options and output.<br>
<br>
> With libressl actually.<br>
<br>
I do not know what you mean by that remark exactly, but what I said<br>
applies to any library providing OpenSSL API, including LibreSSL. Moreover:<br>
<br>
* Squid does not know anything about LibreSSL. Somebody added the<br>
letters "LibreSSL" to squid.conf.documented, but that was a mistake IMO.<br>
<br>
* Primary SslBump developers do not normally use or test with LibreSSL.<br>
<br>
* LibreSSL provides OpenSSL API so you can tell Squid to use LibreSSL as<br>
if it was OpenSSL, and things should work as well as with OpenSSL itself<br>
if (and only if) LibreSSL does a good job providing that OpenSSL API.<br>
<br>
* LibreSSL does not do a good job providing OpenSSL API and/or Squid<br>
does not do a good job detecting OpenSSL API variations in a<br>
LibreSSL-compatible way (depending on your point of view). See bug #4662<br>
for more details.<br>
<br>
There have been recent improvements in LibreSSL-compatibility area, but<br>
I am not sure those improvements (or the problems) are in your Squid<br>
version and, at any rate, are taking significant additional risks by<br>
using LibreSSL with SslBump. Whether those risks are worth using<br>
something other than OpenSSL is your call, of course.<br>
<br>
Alex.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 19 Jun 2017 21:12:57 +1200<br>
From: Amos Jeffries <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
Subject: Re: [squid-users] squid 4.0.20 does not recognize ssl-bump<br>
option.<br>
Message-ID: <<a href="mailto:999533d5-0efa-8310-d32d-0ac0a10f34cd@treenet.co.nz">999533d5-0efa-8310-d32d-<wbr>0ac0a10f34cd@treenet.co.nz</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
On 19/06/17 10:53, Alex Rousskov wrote:<br>
> On 06/18/2017 09:49 AM, meym wrote:<br>
>>> On 06/17/2017 10:09 AM, meym wrote:<br>
>>>> Squid Cache: Version 4.0.20<br>
>>>> "FATAL: Unknown http_port option 'ssl-bump'."<br>
>>><br>
>>> Your Squid thinks it was built without OpenSSL support. OpenSSL support<br>
>>> is required for SslBump. Examine your ./configure options and output.<br>
><br>
>> With libressl actually.<br>
><br>
> I do not know what you mean by that remark exactly, but what I said<br>
> applies to any library providing OpenSSL API, including LibreSSL.<br>
<br>
To clarify that. This Squid is missing the --with-openssl build option,<br>
which is required both by OpenSSL and any library derived from it.<br>
<br>
see "squid -v" for the details of a specific squid binary. This will now<br>
distinguish between the OpenSSL vs LibreSSL vs other situation.<br>
<br>
<br>
> Moreover:<br>
><br>
> * Squid does not know anything about LibreSSL. Somebody added the<br>
> letters "LibreSSL" to squid.conf.documented, but that was a mistake IMO.<br>
<br>
The mentions of LibreSSL in the current file are for things which were<br>
tested before the recent round of LibreSSL issues. Specifically loading<br>
CA certs from a file. AFAIK that should still be working.<br>
<br>
ssl-bump is correctly not one of those options mentioning it. Also, note<br>
that the fatal error message does not mention any particular library. It<br>
is about lack of support from *any* library in the current build.<br>
<br>
><br>
> * Primary SslBump developers do not normally use or test with LibreSSL.<br>
><br>
> * LibreSSL provides OpenSSL API so you can tell Squid to use LibreSSL as<br>
> if it was OpenSSL, and things should work as well as with OpenSSL itself<br>
> if (and only if) LibreSSL does a good job providing that OpenSSL API.<br>
><br>
> * LibreSSL does not do a good job providing OpenSSL API and/or Squid<br>
> does not do a good job detecting OpenSSL API variations in a<br>
> LibreSSL-compatible way (depending on your point of view). See bug #4662<br>
> for more details.<br>
><br>
> There have been recent improvements in LibreSSL-compatibility area, but<br>
> I am not sure those improvements (or the problems) are in your Squid<br>
> version and,<br>
<br>
They are. Though the release notes still say "This release does not<br>
support LibreSSL" at present since we have had no positive feedback on<br>
anything actually working yet.<br>
<br>
<br>
> at any rate, are taking significant additional risks by<br>
> using LibreSSL with SslBump. Whether those risks are worth using<br>
> something other than OpenSSL is your call, of course.<br>
><br>
<br>
Since the risk here is due to lack of testing... More testing is very<br>
welcome of course. Especially with feedback about what works and what<br>
does not.<br>
<br>
Amos<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/<wbr>listinfo/squid-users</a><br>
<br>
<br>
------------------------------<br>
<br>
End of squid-users Digest, Vol 34, Issue 46<br>
******************************<wbr>*************<br>
</blockquote></div><br></div></div></div>