• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

SQUID Proxy - How to Bypass proxy for specific URL

Scheduled Pinned Locked Moved General pfSense Questions
3 Posts 2 Posters 9.4k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S
    steve.hills
    last edited by Jun 18, 2014, 12:28 PM

    We are using Squid proxy in transparent mode. Our internal network subnet (10.0.0.0/24) has been segregated such that servers reside in (10.0.0.0/24) and all other users are 10.0.8-11.0/24. With this setup, I am able to configure Squid to Bypass the Proxy for servers.

    We have a team of Web Developers who frequently test sites hosted in Amazon's Cloud. The IPs for these sites change quite frequently, which makes it difficult to bypass the proxy for destination IPs.

    The "cache_deny" directive does not work for us either, as the users frequently "hack" their hosts files so that they can temporarily point a domain to a test server. When Doing this, it appears that squid continues to send the request to the original IP address, instead of the locally entered IP address.

    so for example, if we have a cache deny for www.mytestdomain.com, which is hosted on a server at 54.54.54.54, and we are doing some testing, so hack the hosts file on the developers PC to point that domain to 51.51.51.51, the page that is returned from squid is the original at 54.54.54.54.

    If the same tests are carried out from a server in the "Bypass Proxy for the following Source IPs", then this works ok. Similarly, entering the Destination IPs into the second bypass field works great, but with amazon IPs changing as frequently as they do, this is impractical.

    Is there a way of bypassing the proxy altogether for a specific domain / url?

    1 Reply Last reply Reply Quote 0
    • M
      MindfulCoyote
      last edited by Jun 19, 2014, 7:31 PM

      @steve.hills:

      The "cache_deny" directive does not work for us either, as the users frequently "hack" their hosts files so that they can temporarily point a domain to a test server. […] Is there a way of bypassing the proxy altogether for a specific domain / url?

      Unless I am misunderstanding your question, I think you've answered it yourself? The 'cache deny' directive is matching the domain you are entering. The difference is that pfSense is using DNS to look up the IP address while the end user is using their  'hosts' file (which pfSense has no knowledge of). The answer is to synchronize the DNS between pfSense and the end user so they both agree on the IP addresses. Of course this is normally done by telling the end user not to modify their hosts file otherwise they will experience caching. (Alternatively the end user could request that the DNS be modified. The key is that pfSense and the client need to be receiving the same IP address information.)

      @steve.hills:

      If the same tests are carried out from a server in the "Bypass Proxy for the following Source IPs", then this works ok.

      If asking them not to modify the hosts file or modifying the DNS is impractical, then you already mentioned the next best solution which it to disable the proxy for those particular developers. (Are their IP addresses changing frequently too? If so, perhaps DDNS is called for?)

      Err

      –
      Erreu Gedmon

      Firewalls are hard...
      but the book makes it easier: https://portal.pfsense.org/book/

      1 Reply Last reply Reply Quote 0
      • S
        steve.hills
        last edited by Jul 8, 2014, 1:24 PM

        Thanks MindfulCoyote. You are correct. I am going to create a subnet specific for developers, and bypass the proxy altogether for them. Its the "least worst" solution on this occasion, but we lose the ability to track their behaviour which is a shame.

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
          This community forum collects and processes your personal information.
          consent.not_received