5 Replies Latest reply on Feb 16, 2011 8:28 AM by Dave_Hightower

    At my wits end!  HTTP/HTTPS Proxy services from a Blue Coat Proxy

      Greetings --

       

      My EXTREME apologies if this is covered elsewhere, but google searches, forum searches, and almost complete memorization of the admin guide have not been fruitful...

       

      Or maybe I'm just not seeing it.

       

      We have been directed to implement a network solution where two Bluecoat Proxy Servers are behind two Sidewinders.  The entire internal network (6000+ clients) is not routable;  we have a single class C that is routable, of which I have 62 IPs.

       

      The configuration I'm looking at is either A:

       

      Clients -> 80/443 traffic -> WCCP to the Bluecoats -> Bluecoats NAT (non-routable Burb IP), proxy, accelerate, cache -> Sidewinder (web burb) -> HTTP/HTTPS proxy -> Sidewinder NATs to external Cluster IP (routable) -> Web

       

      Or B:

       

      Clients -> 80/443 traffic -> WCCP to the Bluecoats -> Bluecoats  NAT (non-routable Burb IP), proxy, accelerate, cache -> Sidewinder  (web burb) -> 80/443 Packet Filter -> Sidewinder NATs to external  Cluster IP (routable) -> Web

       

      Hmmm...might be clearer to actually give IPs:

       

      Clients (192.168.X.X) -> Bluecoats (internal 192.168.X.X, external 172.16.80.X) -> Sidewinder (web burb 172.16.80.X, external 140.32.16.X address)

       

      OK, diagram attached.

       

      I realize we are NATing twice -- if I don't, the proxies won't cache (for some reason).

       

      So, my problem:  Outbound traffic flows fine -- well, mostly fine, we get some SSL errors, (Not valid HTTP or SSL negotiation: SSL V2) but those are known...

       

      What I am seeing is hundreds and hundreds of return errors:  For example, an HTTP request goes out (to google.com, for example):

       

      - I see it flowing from the internal network, to the proxies, out the proxies (NATed), to the firewalls, out the firewalls (NAted again), and to the internet.

      - The return packet (going to the external cluster IP) is blocked, through -- error message:

       

      date="Feb 14 13:39:36 2011 MST", fac=f_kernel_ipfilter, area=a_nil_area, type=t_attack, pri=p_major, pid=0, ruid=0, euid=0, pgid=0, logid=0, cmd=kernel, domain=, edomain=, hostname=firewall1, category=policy_violation, event=IPv4 packet discarded by rule, srcip=66.229.40.222, srcport=80, srcburb=External, dstip=140.32.16.3, dstport=9754, protocol=6, rule_name="Deny All",reason="This IPv4 packet was discarded because it matched an IP filter drop or deny rule."

       


      <sigh>

       

      What am I doing wrong?  I have a rule to allow the proxy servers to talk to the internet via the HTTP/HTTPS proxy service on the firewalls...is that not bidirectional?

       

      Is there a better way to do this?

       

      Thanks LOADS for any help you can provide....I am stumped!

       

      Thanks again--

       

      Dave

        • 1. Re: At my wits end!  HTTP/HTTPS Proxy services from a Blue Coat Proxy
          oreeh

          This

          > reason="This IPv4 packet was discarded because it matched an IP filter drop or deny rule."

          indicates you have a discard rule in place that blocks those replies.

          1 of 1 people found this helpful
          • 2. Re: At my wits end!  HTTP/HTTPS Proxy services from a Blue Coat Proxy

            It appears from the audit message attached that you may have changed the "Deny All" rule to drop instead of deny which is known to cause issues. After verifying that it is set to deny, you could run at audit capture at loglevel 4 to find out why your rule is being skipped.

             

             

            Assuming that you are running version 7.x, run these commands-

            cf acl set loglevel=4 cache=off (make sure to set back to 'cf acl set loglevel=2 cache=on' when done troubleshooting)

             

            showaudit -k > audit.http (while this is running, make sure to generate some traffic)

             

            hit ctrl-c to stop the capture.

             

            more audit.http (this will allow you to view the audit. Try and look for "skipped rule A because X did not match Y" type messages and it should help you determine why your rule is not allowing the traffic)

             

            Also opening a support ticket would be a good idea, we troubleshoot situations like this all the time and should be able to help.

             

            -Matt

            • 3. Re: At my wits end!  HTTP/HTTPS Proxy services from a Blue Coat Proxy

              Thanks, I will try that.

               

              Regarding the Proxy/Packet Filter question -- is there a reason/rationale behind choosing one or the other?  Given that the Bluecoats are already doing filtering?

               

              Also, a really basic question -- I assume the HTTP/HTTPS proxies are stateful (if a SYN goes out, a SYN-ACK will be allowed back in) -- yes?  If so, why would the return traffic be blocked -- would I even need a return rule?

               

              I'll turn on the debugging and see what it says.

               

              Regards--

               

              Dave Hightower

              • 4. Re: At my wits end!  HTTP/HTTPS Proxy services from a Blue Coat Proxy

                >Regarding the Proxy/Packet Filter question -- is there a reason/rationale behind choosing one or the other?  Given that the Bluecoats are already doing filtering?

                The http and https proxies are application aware, they know how to look for potentially malicious http or https traffic and can block accordingly. The filter knows nothing about http or https, it simply knows that it is setup to allow traffic on TCP 80 or 443. The http/https proxies would add another layer of security to your environment.

                 

                 

                >Also, a really basic question -- I assume the HTTP/HTTPS proxies are stateful (if a SYN goes out, a SYN-ACK will be allowed back in) -- yes?  If so, why would the return traffic be

                >blocked -- would I even need a return rule?

                All of the proxies are stateful, and the filters are stateful by default. There would be no reason to create a rule to allow the traffic back in. The main reason you would need to allow traffic back in is with other protocol (non-TCP/UDP) packet filters (usually used for passing VPNs through the firewall).

                 

                -Matt

                1 of 1 people found this helpful
                • 5. Re: At my wits end!  HTTP/HTTPS Proxy services from a Blue Coat Proxy

                  Thanks to Matt and Oreeh for the answers -- turns out that I had misconfigured the 80/443 traffic.

                   

                  The SSL errors, now -- those are interesting;  most of them go to home DSL addresses, and appear to be either Skype, or anonymous proxies.

                   

                  Go figure.