Tag Info

Hot answers tagged

3

If you have your squid configured with "--enable-http-violations", check reply-header-replace option. Example: reply_header_replace Server Foo/1.0


2

You can push proxy configuration to the OpenVPN clients. From the OpenVPN Access Server web interface go to Advanced VPN Settings → Server Config Directives and enter the following directive with your proxy ip/port info. push "dhcp-option PROXY_HTTP 111.222.333.44 8118" I am not sure if all OpenVPN clients support this config. But on IOS it works well.


2

I'm afraid it would not be possible to cache it as long as clients are using https to access Windows Update services. Squid acts as a mere tunnel between the customer and HTTPS server so it is motsly unable to inspect what are you requesting and so caching it. You can find more information in the Squid wiki Update: For caching updates perhaps you can take ...


1

Privoxy is an HTTP proxy. What you're trying to do is feed it intact network packets, which I'm 99% sure it's not going to accept that without some very complex mangle rules in iptables. Instead you should expose the proxy to the VPN (seems like it is already), and push it as a DHCP option to your VPN clients. Instructions for doing that via OpenVPN can be ...


1

If you found this answer because Squid is not caching objects that you expect it to, try setting debug_options = ALL,2 in /etc/squid3/squid.conf. Look out for lines like this after the response headers are logged: store.cc(1003) checkCachable: StoreEntry::checkCachable: NO: too big This can be caused by maximum_object_size being set too low (the default ...


1

I got this to work in my environment by querying LDAP for the userPrincipalName instead of sAMAccountName as my squid also returns user@domain.local from Kerberos/NTLM auth. Also be sure to use %20 instead of spaces and when I was specifying the bind DN in my conf file, I used quotes as it had an & in the DN and squidguard was not binding because of ...


1

You are correct that with the REDIRECT, Squid cannot see the original intended destination IP; instead it will resolve the host provided by the client in the Host: HTTP header, which is mandatory in HTTP 1.1.


1

The problem is that the MAC filter rule is processed after accepting it. So it is never reached. What you need to do is change the order of these two lines: -A FORWARD -i eth1.10 -o eth0 -j ACCEPT -A FORWARD -i eth1.10 -p tcp -m tcp --dport 443 -m mac --mac-source 00:60:DD:44:85:43 -j DROP So they become: -A FORWARD -i eth1.10 -p tcp -m tcp ...



Only top voted, non community-wiki answers of a minimum length are eligible