- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Policy doubt
Hello team,
i have a question abount policy match.
I have sniffed packets from fortigate CLI and the result is:
6.891062 port3 in 195.xx.xxx.xx -> 172.xx.xx.xxx: icmp: echo request
7.892226 port3 in 195.xx.xxx.xx -> 172.xx.xx.xxx: icmp: echo request
8.892875 port3 in 195.xx.xxx.xx -> 172.xx.xx.xxx: icmp: echo request
So I created a firewall policy having as source port3 and source ip address 195.xx.xxx.xx and as destination 172.xx.xx.xxx with service ICMP_ALL. But the policy not match.
Any suggestion?
Thanks for the support
Solved! Go to Solution.
- Labels:
-
FortiGate
Created on 10-25-2023 08:55 AM Edited on 10-25-2023 08:56 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For a policy route to work, there need to be a proper route existing toward the same outgoing interface in the routing table.
For examiple, if two 0/0 routes to wan1 and wan2 exist, you can set two policy routes for one group of IPs to use wan1 for like 8.8.8.8/8.8.4.4 and another group of IPs to use wan2 for the same DNS servers.
But if there is only one 0/0 route to wan1, and no route toward wan2, the second group won't be able to reach the DNS servers. It wouldn't be able to use wan1 either because the policy route "sticks" and won't let it follow the 0/0 route.
Toshi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello @luca1994 ,
What are you trying to achieve here ?
This policy you mention is to allow all ICMP traffic.
From sniffer output i see only echo requests. Are you failing to ping ?
Here is a guide how to troubleshoot connectivity issues:
Troubleshooting Tip: First steps to troubleshoot c... - Fortinet Community
If you have found a solution, please like and accept it to make it easily accessible for others.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the sniffer might not be the best way to debug that as it just shows the packets matching it but nothing more.
In this case maybe some flow debug would provide more information.
e.g.:
diag debug enable
diag debug flow filter clear
diag debug flow filter saddr 195.81.187.35
diag debug flow filter daddr 172.16.53.130
diag debug flow trace start 1000
then execute the ping from 195.81.187.35 to 172.16.53.130 and watch the output. It will show you which policy it matches and more details.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello @sw2090 ,
I performed what you described and the result is "reverse path check fail, drop"
id=65308 trace_id=1 func=print_pkt_detail line=5842 msg="vd-root:0 received a packet(proto=1, 195.81.187.35:28234->172.16.53.130:2048) tun_id=0.0.0.0 from port3. type=8, code=0, id=28234, seq=1."
id=65308 trace_id=1 func=init_ip_session_common line=6028 msg="allocate a new session-00cd0ce9, tun_id=0.0.0.0"
id=65308 trace_id=1 func=ip_route_input_slow line=1723 msg="reverse path check fail, drop"
id=65308 trace_id=1 func=ip_session_handle_no_dst line=6114 msg="trace"
So I think there is a problem with the routing
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
You can refer this article https://community.fortinet.com/t5/FortiGate/Technical-Tip-Details-about-FortiOS-RPF-Reverse-Path-For...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello @pbangari ,
I do not have a static route in the routing table to reach 195.81.187.35 but I do have a policy route that already works correctly for traffic concerning the monitoring system.
So in your opinion is it enough to enable asymmetric routing ? By enabling it what impact could I have ?
Thanks for the support
BR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Having a static route should fix this issue, asymmetric routing is not recommended.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @pbangari ,
i have a policy route and ,which from what I know, is processed before the routing table.
The policy route has server 172.16.53.130 as its source and 195.81.187.35 as its destination.
Any another suggestion?
BR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i have configred a static route and now the icmp pass correctly. Which from what I know, the policy route is processed before the routing table.....