Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
MattIggo
New Contributor

Fortigate Web Filtering Issue - RegEx

Hi Guys,

 

Trying to build out the fortigate filtering using regular expressions and I can't seem to make them do what I want.

 

We have an implicit deny policy in place so need to allow access to the CRL for microsoft, go daddy etc.

 

I have setup a policy as below:

 

config webfilter profile
    edit "Certificate_Revocation_Check"
            config override
                set ovrd-user-group ""
            end
            config web
                set urlfilter-table 10
            end
            config ftgd-wf
                    config filters
                        edit 1
                            set category 140
                        next
                        edit 2
                            set category 141
                        next
                    end
            end
        set log-all-url enable
    next
end

 

However, All I see are "passthrough".

 

Please can you offer some assistance?

10 REPLIES 10
Dave_Hall
Honored Contributor

Hi Matt.

 

Welcome to the forums.

 

Can you clarify what you mean by passthrough? As in not hitting the firewall policy?  Have you actually applied the web filtering profile to firewall policy?  Can you post a screenshot of the firewall policy in question?  If you have a web filter profile enabled on a firewall policy, you should be able to see "drilled down" session info, similar to the following screenshot (from 5.0.9 firmware)...

 

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
MattIggo

Hi Dave,

 

Yes I can see that, Please see attached screenshot.

 

I will reply in a second with my policy.

 

 

MattIggo

This is my Web Filter Profile

 

 

This is the Policy

 

This is the policy in detail

 

 

Using FortiOS 5.2.2

 

I have a set of profiles setup as shown below: (Not sure this is correct by the way!)

 

ede_pfau
SuperUser
SuperUser

(Not sure this is correct by the way!)
The 'all' address object makes all other addresses oblivious. I'd recommend you define the address spaces of your VLANs, group them and employ that in the policies. 'all' to 'all' is only rarely justified.

 

Just my 2 ct.


Ede


"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
MattIggo

All to All has a perfectly valid reasoning in this deployment.

 

Yes, It should be cleared up "ideally" but first, Functionality....

ede_pfau
SuperUser
SuperUser

I'm not sure you see my point:

if you both specify 'all' and another address as source, that other address will never be looked at. I just want to make you aware of this.


Ede


"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
MattIggo

Hi,

 

I kind of see your point but need some information qualifying if possible?

 

Are you saying the following? Packets come in from ip 1.1.1.1 destined to 2.2.2.2 tcp port 80.

 

The policy says: Permit internal any external any http

 

The incoming IP will match any and then it won't look at the destination? This is completely different to how I see it functioning in real world terms?

 

My understanding of packet flows is: Incoming Interface match

Incoming IP Match

Outgoing Interface match

Outgoing IP Match

Service Match

Permit / Deny

 

Matt

Dave_Hall
Honored Contributor

To be honesty, I can not tell from that firewall policy screen what does what without the column headings.  Also, not sure what the action "passthorough" means -- none of our fgt devices are on the 5.2 firmware path. 

 

Three things:

[ol]
  • The url profile/url filter looks ok. 
  • I agree with edu that the firewall policies could be cleaned up.
  • Web caching is enabled on the fw policy, which I suspect is what causing "grief" -- I know from 4.3.x no firewall policies are not actually hit if the requested object is stored in the cached. [strike](Perhaps this is what is meant by passthrough?)[/strike][/ol]

    Edit: documentation on passthrough action is very lacking.  I loaded 5.2 on a 200D and played around with it, I can see the usual action messages, including passthough.  I'm assuming now it's just the fgt's way of saying the event (url filter allow action) is a hit and now it will "check other web filters". See this post.[strike][/strike]

  • NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

    NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
    mramon79
    New Contributor

    Hi,

     

    in 5.2 is not possible universal reg expresion, here you have the answer from fortinet support to this issue:

     

     

    I have information from developers that this behavior is by desing in
    FortiOS 5.2, and will not be changed. For the performance reasons,
    universal wildcard is no longer supported in URL filter.

    If you want to use the wildcard in the URL filter, you have at least
    specify whether the string is part of the domain name, or path.




    Labels
    Top Kudoed Authors