Mix of Flow & Proxy mode Security Profile

[sebastan_bach]

Hi, 

I am finding the new 5.4 documentation little confusing. So I am not sure if can we use mix of security profiles in flow & proxy mode. Like we would like to use App-Control,IPS in Flow mode but web-filtering & AV scanning in proxy mode for maximum security. 

Is this configuration supported. 

Kindly please let me know. 

Regards

Sebastan

[Jeremiah_Jackson]

Thanks for the info in this thread.  This made me realize I am trying to run both Flow and Proxy.  I've been running into memory issues on the firewall.  Which was causing the unit to go into conserve mode. 

[tanr]

I ran a few tests on combining proxy-based AntiVirus and proxy-based Web Filters with (flow only) App Control.

The results were rather different than the documentation.

The 5.4.1 docs at  http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-security-profiles-54/Web_Filter/Advan... state:   Enabling the Web Filter profile to block a particular category and enabling the Application Control profile will not result in blocking the URL. This occurs because proxy and flow-based profiles cannot operate together. To ensure replacement messages show up for blocked URLs, switch the Web Filter to flow-based inspection.   However, in my tests the proxy based Web Filter DID block the URLs it was supposed to, despite having App Control in the same policy.  It even worked correctly with a quota.  So it looks like the "proxy and flow-based profiles cannot operate together" is at least somewhat out of date.

Initially I was concerned that the last sentence from the documentation might be correct.  In my test, though the pages got appropriately blocked by the Web Filter, the user didn't get any message about why they were blocked.

However, once I re-authenticated my user (their policy requires authentication into a user group) they started getting the appropriate HTTP replacement message.

The 5.4.1 docs at http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-security-profiles-54/Application_Cont... say:

Because Application Control uses flow-based inspection, if you apply an additional security profile to your traffic that is proxy-based, the connection will simply timeout rather than display the replacement message. However, Application Control will still function.

To test that, I tried App Control with proxy-mode versions of AV and Web Filter, with flow-mode versions of AV and Web Filter, and without any AV or Web Filter profiles.  At all times I did have IPS and deep SSL Inspection on.  

What I found was surprising: after completely removing AV and Web filters from the policy (and flushing the users DNS), then added them back in, first in their flow mode, then in their proxy mode, everything just worked...

Regardless of whether AV and Web filters are in proxy or flow mode, everything just works.  I correctly get HTTP replacement messages from App Control for browser related games it blocks.  I correctly got HTTP and HTTPS replacement messages from proxy-based Web Filter for the sites it blocks.  It all just works.  

In case this magical functionality had to do with order of which profiles were added I tried removing, then adding back the App Control profile.  Same result still -- it all just keeps working.

I hope this isn't a fluke.  I'll leave the configuration like this for a while and see if it causes other problems.  For the moment, I'm tentatively hopeful that in 5.4.1 I can get away with proxy-mode AV and Web Filters combined with flow-mode Application Control.

[boneyard]

how did your testing work out?

i was looking at the 5.4 life of a packet flow and proxy mode pages. the proxy one is quite weird in my opinion. it goes through the IPS, then for SSL decryption again through IPS before going to the proxy part? why twice the proxy?

those pages add more questions then give answers.

[tanr]

I haven't done much more in-depth testing, but have been observing two different vlan subnets using flow-mode-only app control profiles with proxy-mode web filters.

One has a proxy-mode web filter with quota, and this continues to work correctly when combined with the flow-mode app control as far as I can tell.

The other has a proxy-mode web filter with some web rating overrides.  This may be working incorrectly.  It semi-regularly blocks specific pages that have had their rating overridden.  The logs show the host as the page that should have its rating overridden.  In some of the logs the additional (to the host name) URL is listed as just / but the rating wasn't changed correctly.  In other logs, the additional URL is an .ICO reference and the rating wasn't changed correctly.  I'm not convinced this is a problem with proxy and flow mode, though.  I may just need to add URL variations, or this might be because of other URL's referenced from the page.

I've just moved the FortiGates over to 5.4.2 and will keep scanning logs to see how this goes.

Per the 5.4 Life of a Packet, Proxy Mode diagram, I agree that there seem to be some details missing!

From the comments above the diagram, my guess is that the first IPS in the proxy-mode diagram is like a version of the flow mode IPS Engine (http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-life-of-packet-54/lop-packet-flow-flo...) but specifically NOT running the SSL Decoder, since Proxy mode has its own, more full SSL decryption engine.

[tanr]

Additional question/concern regarding proxy mode and hardware acceleration.

The cookbook article http://cookbook.fortinet.com/nturbo-ipsa/ states:

"Firewall sessions that include proxy-based security profiles or a mixture of flow-based and proxy-based security profiles are never offloaded to network processors and are always processed by the FortiGate CPU."

So a FortiGate using any proxy-based profile will *never* be able to offload to NP4 or NP6.

It also implies that a FortiGate in proxy-mode, even if only using flow-mode profiles, might never by able to offload to NP6 or NP4.  This would be because the proxy engine is used for buffering and SSL decryption when the FortiGate is in proxy-mode, even if all security profiles used for that session are flow-mode (per "Life of a Packet").

Can anybody confirm this?  Or hopefully tell me I'm wrong?

Thanks.

[tanr]

To answer my own last post it looks like a 5.4.x FortiGate in proxy-mode, but using only flow-mode profiles for a specific security policy, can still offload to NP6.

I tested this with a proxy-mode FortiGate 300D, with a security policy that had flow-mode AV, flow-mode Web Filter, IPS, etc.  Running "diag sys session list" and filtering for sessions with devices hitting that policy showed a number of npu sessions with the only non-offloaded sessions giving no_ofld_reason: local, which is fine.

Testing this the other way around, with a policy that used proxy-mode AV and proxy-mode Web Filter, I immediately saw sessions that were not offloaded, with reasons that matched:

  no_ofld_reason: redir-to-av

  no_ofld_reason: redir-to-av redir-to-ips   no_ofld_reason: dirty

[hmtay_FTNT]

Hello,

Let me try to clarify some of the answers here to the best of my ability.

>>i was looking at the 5.4 life of a packet flow and proxy mode pages. the proxy one is quite weird in my opinion. it goes through the IPS, then for SSL decryption again through IPS before going to the proxy part? why twice the proxy?

>>Per the 5.4 Life of a Packet, Proxy Mode diagram, I agree that there seem to be some details missing! From the comments above the diagram, my guess is that the first IPS in the proxy-mode diagram is like a version of the flow mode IPS Engine (http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-life-of-packet-54/lop-packet-flow-flo...) but specifically NOT running the SSL Decoder, since Proxy mode has its own, more full SSL decryption engine.

tanr is right here. In flow-based inspection, deep-inspection is done by inline-SSL-decryption, meaning on the IPS Engine itself, whereas in proxy mode, deep-inspection is not done by inline-SSL-decryption but by the proxy. Therefore, after the proxy decrypts the session and obtains the plaintext packets, these packets have to go through the IPS Engine again. Thus, flow-based inspection is quicker than proxy-based.

>>To answer my own last post it looks like a 5.4.x FortiGate in proxy-mode, but using only flow-mode profiles for a specific security policy, can still offload to NP6.   I tested this with a proxy-mode FortiGate 300D, with a security policy that had flow-mode AV, flow-mode Web Filter, IPS, etc.  Running "diag sys session list" and filtering for sessions with devices hitting that policy showed a number of npu sessions with the only non-offloaded sessions giving no_ofld_reason: local, which is fine.

You can do a check to see if your inspection is done through flow-mode or proxy-mode by using the CLI commands, "diagnose debug application wad 99" and "diagnose debug enable".

In the past before you are able to explicitly set the FortiGate in flow-based or proxy-based mode, the way to determine which inspection mode for each policy is through the modules used. The only way to get a flow-based inspection is to have all flow-based module. To get into proxy-based inspection, you need to enable just one module in proxy mode.

In your case where you set the entire FortiGate to proxy-mode with the new setting but modify the Web Filter and AV profiles to "flow-based" inspection, the FortiGate should still do the proxy-based inspection. If you see stuff being printed, then you are going through the proxy. If nothing is printed, the IPS engine handled everything and you are in flow mode. One other way to check from the GUI is if the "Proxy Options" is enabled. If it is, that policy is in proxy-mode.

>>To test that, I tried App Control with proxy-mode versions of AV and Web Filter, with flow-mode versions of AV and Web Filter, and without any AV or Web Filter profiles.  At all times I did have IPS and deep SSL Inspection on.     What I found was surprising: after completely removing AV and Web filters from the policy (and flushing the users DNS), then added them back in, first in their flow mode, then in their proxy mode, everything just worked...   Regardless of whether AV and Web filters are in proxy or flow mode, everything just works.  I correctly get HTTP replacement messages from App Control for browser related games it blocks.  I correctly got HTTP and HTTPS replacement messages from proxy-based Web Filter for the sites it blocks.  It all just works.     In case this magical functionality had to do with order of which profiles were added I tried removing, then adding back the App Control profile.  Same result still -- it all just keeps working.   I hope this isn't a fluke.  I'll leave the configuration like this for a while and see if it causes other problems.  For the moment, I'm tentatively hopeful that in 5.4.1 I can get away with proxy-mode AV and Web Filters combined with flow-mode Application Control.

AV and Web Filter in proxy-mode can work with IPS and Application Control. They are supposed to be able to work together even if they are in different mode. You are correct that if the packet is supposed to be blocked by App Control, you will get a replacement message from App Control and if it is to be blocked by Web Filter, you will get a replacement message by Web Filter. 

[network_inf_op]

Hello,

I run FortiOS v5.6.7 build1653 (GA) on a 500E, and I have set IPS/IDS policy on every policy on a Proxy-Mode VDOM.

The IPS porfile I set on policies, Is a monitor/logging profile with every signature severity turned-ON.

I have no match in Intrusion-prevention log si I worder if IDs/IPS is actualley working!

Thanks A lot