- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FG60f: no_ofld_reason: redir-to-ips
Hi,
Does anyone know exactly what it means no_ofld_reason: redir-to-ips???
I have two fortigate 60F, (FGA and FGB) with FortiOS 7.0 but one (FG A)of them has problems inspecting the traffic, i mean that the traffic passes without inspecting the security policies.
Example, if I want to block Torrent or Remote Desktop, the traffic goes through and is not blocked by Application control. This only happens with one of the two fortigates (FG A), in the other (FG B) i can block an application or URL without problems
when I run the command "dig sys session list" the result say in FG A no_ofld_reason: redir-to-ips is constant and it always stays, but in FG B it varies
does it have something to do with it?
FG A says: no_ofld_reason: redir-to-ips (is constant)Fortigate A redir-to-ips
FG B says: no_ofld_reason:
Solved! Go to Solution.
- Labels:
-
FortiGate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After reviewing traffic flow diagram a bit and understanding that the IPS ENGINE encompasses all the traffic inspection(app control, webfilter, av, etc) , I realized that the ipsengine was not running in the "dig sys top", so the restart was carried out through the CLI of ips process via " diagnose test application ipsengine 99".
I was also able to notice that there was a crash:
273: 2022-01-24 10:51:29 ipsengine 07.000.044 crashed 3 times. The latest crash was at 2022-01-24
Now you can see the inspection of packets through FG.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
redir-to-ips/av means that the traffic was not offloaded to the network processor
On the debug flow you may constantly see "send to ips" as well
Packet flow for non-offloaded traffic
Packet flow for offloaded traffic to network processor
Since you don't specify flow/proxy and general policy configuration, please review the below which might assist why traffic is not blocked
Flow-inspection
Proxy-inspection
Comparison of inspection types
For example anti-spam with fortiguard rating specifically will work only on proxy-inspection
below admin guide from version 7
I would start checking if
1. both fortigates are on the latest fortiguard updates
diagnose autoupdate versions
2. Policies are identical in relation proxy/flow inspection, allowed services, protocol options profile and most important certificate inspection ( deep inspection or not )
3. Profile inspection type match the policy inspection type
Cheers,
49 20 77 6F 75 6C 64 20 72 61 74 68 65 72 20 62 65 20 66 69 73 68 69 6E 67 20 72 69 67 68 74 20 6E 6F 77
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hiiii
I have a question??
do you think "ipseengine" has something to do with it?
I'm dinging a lot on the subject and I'm doing "diag sys top" and i can see that the ipsengine is not in one of my FortiGates, (the one that is affected)Forti B (no problem)
Forti A (problem)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After reviewing traffic flow diagram a bit and understanding that the IPS ENGINE encompasses all the traffic inspection(app control, webfilter, av, etc) , I realized that the ipsengine was not running in the "dig sys top", so the restart was carried out through the CLI of ips process via " diagnose test application ipsengine 99".
I was also able to notice that there was a crash:
273: 2022-01-24 10:51:29 ipsengine 07.000.044 crashed 3 times. The latest crash was at 2022-01-24
Now you can see the inspection of packets through FG.
