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

Strange Blocking behavior

Hello Everyone, 

I have strange behavior in my lab, 

My lab topology is simple two different networks directly connected to Fortigate(VM), linux and windows machine. a policy to allow any any has been declared for testing. ping not working, no hits on the policy. 

linux and windows are able to ping their gateways (FG interfaces). 

i tried to reboot FG VM, the ping is succeeded for about 10 seconds after the reboot then failed again, and the policy during these succeeded pings is got some hits for that traffic!!

Any advise ?

 

10 REPLIES 10
Ydaew
New Contributor III

It seems like a bug. 

So we can consider this closed. 

 

Thanks

ede_pfau

Most probably not a bug in FortiOS. 99% of all deployed Fortigates would be causing traffic blocks then.

 

For testing, disable NP offloading on that policy:

conf firewall policy

edit xxx

set auto-asic dis

next

end

 

What do you see in FortiView?

If you don't see any traffic, then it might be discarded because of RPF - make sure you have valid routes to both networks.

As a last resort, use the sniffer:

di de en

di sniffer packet any 'icmp' 4 0 l

 

and see if anything is knocking at the door.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Ydaew
New Contributor III

Actually nothing knocking the door but after rebooting within 10 seconds i can see traffic passing!

no problem with routing since the two networks are directly connected to FW and the hosts are able to ping FW which it their default gateway. 

 

ede_pfau

...and you have disabled ASIC offloading now?

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Ydaew
New Contributor III

No such option available, diag shows some hits

 

1.589553 port1 in 172.16.48.100 -> 192.168.112.100: icmp: echo request
2.590318 port1 in 172.16.48.100 -> 192.168.112.100: icmp: echo request
3.590392 port1 in 172.16.48.100 -> 192.168.112.100: icmp: echo request
4.590471 port1 in 172.16.48.100 -> 192.168.112.100: icmp: echo request
5.589958 port1 in 172.16.48.100 -> 192.168.112.100: icmp: echo request
6.592377 port1 in 172.16.48.100 -> 192.168.112.100: icmp: echo request
7.600332 port1 in 172.16.48.100 -> 192.168.112.100: icmp: echo request
8.608595 port1 in 172.16.48.100 -> 192.168.112.100: icmp: echo request

but still no ping !

tanr
Valued Contributor II

VM won’t have ASICs. And you’re checking ping between your two clients, correct, not the FortiGate? Have you tested exec ping with various source IPs from the FortiGate to the clients? Could it be a VM network config issue?
Ydaew
New Contributor III

Ping from fortigate to clients is working as well as from clients to fortigate, so it couldn't be VM network issue. same scenario tested on another VM and it's working! 

tanr
Valued Contributor II

Assuming the (virtual) machines are directly connected and in their gateway's subnet it shouldn't be a routing issue.  Unless you have some special static or policy routes? 

 

Just in case, what does a tracert show?

 

Could you post the relative security policies (redacted as needed)?

 

 

Ydaew
New Contributor III

traceroute is giving nothing. 

no special static or policy route / as for policy it's only allow any any for testing, nothing special actually. 

100% it's not routing issue, because as i told you before after rebooting the FG VM everything works fine till 10 seconds. 

Thanks for your help 

 

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors