IP Address Lookup

[btozer]

Hi, I'm new to working with Fortigate and hoping someone can help me with a trouble-shooting a blocked IP address.  I'm told by our alarm monitoring company that an outbound IP (v4) address is blocked at a particular site.  They have a primary and secondary IP address.  They can ping the secondary, but not the primary.  From another site, I can successfully ping both addresses from my desktop.  What's the best way to test the IP address and determine what policy is blocking it, then make the necessary changes.

Thank You

Bill

[akumar02]

Hello @btozer ,

YOu can run the following debugs on Fortigate and initiate the Ping for that IP. It will show you which Policy is blocking. 

diag debug dis
diag debug flow trace stop
diag debug flow filter clear
diag debug reset
di de console timestamp en
diag debug flow filter addr x.x.x.x <------------ source or destination IP address 
diag debug flow filter proto 1
diag debug flow show iprope enable
diag debug flow show function-name enable
diag debug flow trace start 90
diag debug enable

[akumar02]

Also, this Article will be helpful:
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-First-steps-to-troubleshoot-connecti...

[Genobaseball10]

I may have to ask more questions before giving suggestions. But I'm assuming the alarm company is trying to reach their IPv4 address through the WAN. Correct me if I'm wrong. If this is the case, is their a VIP mapping a public IP to the private IP? Are they using a VPN to get into the network? Are you seeing any logs showing blocked traffic for the destination IP address? If so that will tell you the policy blocking the traffic.

[Toshi_Esumi]

I'm assuming the IPs they're trying to reach is the primary/secondary wan interface IPs from your ISPs, and you have VIPs for the security panel or whatever the devices are.

Then the first thing you need to do is to see if the problem is at your FGT or inbetween the security company and the FGT by sniffing their packets at the primary interface.
If it's hitting the FGT, you can proceed with those debagging methods like @akumar02 suggested.
If it's not hitting, you need to ask them to trace route from their end to see where the blockage is.

Toshi

[btozer]

Thanks everyone for your guidance.  Prior to reading Akumar's diag instructions above, I had found a pretty good video that walks through some similar commands, but note a few things:

The alarm company has advised that the system is using UDP and it looks like this isn't quite as easy to test as ICMP, but that being said, I was able to trigger the diag messages using our phone system when calling site to site  (the alarm company wasn't readily available to troubleshoot).  However, my experience is such that the test was not consistent.  I setup the diag as follows and called from my office phone to the far end site which generated two separate trace IDs.  Then I tried the same call again and again, but even after clearing the trace and walking through the exact same commands it still did not yield new results.  So, I logged completely out of the CLI console, logged out of Fortigate, logged back in and setup the same diag which produced the expected two trace IDs.  I repeated this cycle (logging out and back in) at least four times.  On one occasion, the diag still did not work after logging out and back in.  I'll try to find some time today to revisit the diag testing with the additional parameters.

Thanks again for all of your help thus far.

Fortigate (global) # diag debug flow filter proto 17

Fortigate (global) # diag debug flow filter addr 10.23.16.2

Fortigate (global) # diag debug flow filter
vf: any
proto: 17-17
host addr: 10.xx.xx.xx-10.xx.xx.xx
Host saddr: any
Host daddr: any
port: any
sport: any
dport: any

Fortigate (global) # diag debug console timestamp enable

Fortigate (global) # diag debug flow trace start 2

Fortigate (global) # diag debug enable

Fortigate (global) # 2024-03-27 08:11:54 id=20085 trace_id=38 func=print_pkt_detail line=5822 msg="vd-root:0 received a packet(proto=17, 10.xx.xx.xx:46750->10.xx.xx.xx:46986) from SiteA_to_SiteB. "
2024-03-27 08:11:54 id=20085 trace_id=38 func=init_ip_session_common line=5993 msg="allocate a new session-3b432e9d"
2024-03-27 08:11:54 id=20085 trace_id=38 func=vf_ip_route_input_common line=2615 msg="find a route: flag=04000000 gw-172.xx.xx.xx via port29"
2024-03-27 08:11:54 id=20085 trace_id=38 func=fw_forward_handler line=811 msg="Allowed by Policy-267:"
2024-03-27 08:11:54 id=20085 trace_id=38 func=ipd_post_route_handler line=490 msg="out port29 vwl_zone_id 0, state2 0x1, quality 0.
"
2024-03-27 08:11:54 id=20085 trace_id=39 func=print_pkt_detail line=5822 msg="vd-root:0 received a packet(proto=17, 10.xx.xx.xx:46750->10.xx.xx.xx:46986) from EC_to_BSS. "
2024-03-27 08:11:54 id=20085 trace_id=39 func=resolve_ip_tuple_fast line=5903 msg="Find an existing session, id-3b432e9d, original direction"
2024-03-27 08:11:54 id=20085 trace_id=39 func=npu_handle_session44 line=1217 msg="Trying to offloading session from SiteA_to_SiteB to port29, skb.npu_flag=00000400 ses.state=00010204 ses.npu_state=0x02000000"
2024-03-27 08:11:54 id=20085 trace_id=39 func=ip_session_install_npu_session line=359 msg="npu session installation succeeded"
2024-03-27 08:11:54 id=20085 trace_id=39 func=fw_forward_dirty_handler line=397 msg="state=00010204, state2=00000001, npu_state=02000400"
2024-03-27 08:11:54 id=20085 trace_id=39 func=ipd_post_route_handler line=490 msg="out port29 vwl_zone_id 0, state2 0x1, quality 0.

[btozer]

Brief update and question.  I walked through Akumar's diag commands (I only set flow trace start to 4).  After making the phone call the traces were as expected, but a second phone call did not produce any further traces.  So, I repeated Akumar's diag commands without logging out of the CLI and was able to repeat the same trace results.

So, which CLI command will clear and/or re-initiate the trace again?

Thank you.

Bill

[Toshi_Esumi]

If you run

# diag debug flow trace start 2
It would capture the first two sessions, then stops capturing. Once it stopped you just need to run the same command to repeat with the same filter. But we usually run to capture like 10 - 20 sessions at least.
# diag debug flow trace start 20
@akumar02's original post shows to capture 90 session.

Toshi

[btozer]

Thanks Toshi.  I'll check give it a try later.

[Toshi_Esumi]

Also, the flow trace shows it's offloading the session. You won't be able to see any further packet flows on the same session. If you want to continue seeing them, you have to disable offloading on the policy #267.
# set auto-asic-offload disable.

Also, if you see the packets arriving at the interface in the flow debugging, it's working. But when it's not working the packets might not be arriving, then it wouldn't show in the flow debug. That's why I said you just need to keep sniffing when the outside parties try to ping, then if you see not arriving, it's not a FGT issue but a problem before reaching the FGT's interface.

Toshi