We are bitten, again! Fortigate as WCCP client as ASA as WCCP server

After much troubleshooting, tracing and head scratching, we found out why!

Unlike Squid, Fortigate as WCCP client can only do GRE return mode.     ASA’s WCCP server implementation, on the other hand, do not support GRE return mode.

Well, Fortigate as WCCP client can also do both L2 forward & return mode, but ASA can't do L2 mode at all.   

So, in essence, **they** don’t talk.     At least, for the time being, you can’t deploy ASA as WCCP server and have Fortigate as WCCP client.

Note: BlueCoat as a WCCP client can do all of those modes, L2, Return directly to client and GRE return.

Other links of interest

- Technical Note: Configuring WCCP interception of HTTP traffic to a squid proxy using GRE tunneling

- BlueCoat SGOS 6.3 or later's WCCP Reference Guide

- http://www.crypt.gen.nz/papers/cisco_squid_wccp.html (I like the diagram there, essentially showing the "direct-to-client" return method.)
- Cisco Catalyst 6500 Series Switches - WCCP Network Integration with Cisco Catalyst 6500: Best Practice Recommendations for Successful Deployments

“….WCCP redirection is supported only on the ingress of an interface. The only topology that the adaptive security appliance supports is when client and cache engine are behind the same interface of the adaptive security appliance and the cache engine can directly communicate with the client, without going through the adaptive security appliance….”

Ref: http://discussions.citrix.com/topic/330307-redirection-fails-when-using-wccp-on-a-cisco-asa/

FortiManager "Out-of-Sync" Diff View's Deficiency

There are a few improvable part of FortiManager, this is one of them.

When changes are made on Fortigate locally, the FortiManager will detect that change and report “Out-of-Sync” state.    This is well and good.

The idea is good, the execution however can still be improved.       

As an administrator, I would want to verify the change I know I have made locally on the device.     

The “View Diff” feature here is just not good enough, I couldn’t see easily what change I have made, because it reported wrongly changes that I didn’t make and changes that simply is because configs are just mis-aligned.

I seriously did not modify 1210 Line(s).

So, as a result, I need to fly “blind”.   Either Accept wrongly or Reject wrongly.  

Simply is very annoying given that the other part of FortiManager handle the “Diff” so brilliantly such as “ADOM Revisions” Diff.

Running Script Against FortiManager's Policy Package

A CLI script can be applied to the Policy Package’s Object as well as Policy Package’s Policy.    

Use the CLI commands as if you are working with the device locally, but if you have VDOM in place, just remove that part.

Instead of using

config vdom

edit “VDOM1”

…list of command…

Simply remove the VDOM reference, and leave the rest of the command.

On the script page, just use “Advanced - Override Script Target” and change the Target to Run on “Policy Package, ADOM Database or Global Policy”.

FortiManager Bug - "+" sign in Web Filtering Profile Name

There is a bug in FortiManager, when ‘+’ sign is used for Web Filtering Profile Name.    “Where Used” function is not working correctly.

Once the plus sign is removed from the profile name, it works correctly.

FortiManager - Import Policy from Device

Why do I need this?

Sometimes it is easier to make change locally on Fortigate.    In my case, I want to create a “ftp-proxy” rule on Fortigate because I seems that the rule cause a problem when install to the device if it is implemented on FortiManager.  

Step by Step

First, lock ADOM

Then, right click on device, select “Import Policy”

Then, select on the VDOM that change has been made, and skip the rest.   Place the policy in a new TEMP POLICY PACKAGE so that it doesn’t mix up with our existing POLICY PACKAGE.  To save space, I won’t show the screen shot of every screen.   I just click next through until finish and click “Skip Remaining”.

After that we can change it the way we like.

If you have created new objects locally on the Fortigate VDOM, it will be imported at this step.

Now, rule #5 is imported as I wish.

From a temporary POLICY PACKAGE “VUFG1_VUWF101” , I just need to COPY & PASTE it into my production POLICY PACKAGE “VU-WEBFILTER-PACKAGE”.

Clean up steps

Now, we need to clean up a few things.

First, place the VDOM back to production POLICY PACKAGE.

Click on Policy & Objects -> YOUR TEMPORARY POLICY PACKAGE -> ‘Install’ Tab -> Right click on your VDOM, then Edit

Select the VDOMs that will use this POLICY PACKAGE.

Remove the VDOM from this temporary POLICY PACKAGE.

And, it will be removed from the list

Check the production POLICY PACKAGE, ‘Install’ Tab, it should be there.

Push to device

Now, the next step is to click on SAVE and then push the revise POLICY PACKAGE to the VDOMs using “Install Wizard”.

Then, on Device tab, it should display “SYNCHRONIZED”

The last step is to simply Unlock VDOM.