|
The following describes an understanding of how packet flow works for website reachability before troubleshooting this issue.
As soon as the user enters the URL in the browser, the first DNS lookup will happen for that website. Once the website is resolved, the request will pass to the specific website IP, and a response will come from that website.
Below shows the troubleshooting:
Troubleshoot 1:
Perform a DNS lookup on the internal host machine for the problematic website to verify it is resolving, and take note of the IP address.
Troubleshoot 2:
Once the DNS lookup happens, focus on traffic flow.
If both local DNS and global DNS have the same resolution, run the following sniffers:
diagnose sniffer packet any 'host x.x.x.x' 6 0 l <----- Where x.x.x.x is the internal machine's IP.
diagnose sniffer packet any 'host a.b.c.d' 6 0 l <----- Where a.b.c.d is the website IP address.
To stop the debug, use the command ctrl+c
Here in this sniffer output, observe whether there is a two-way flow or only a one-way flow. Check if the traffic is reaching the firewall and if it is going out of the firewall or not.
Conduct a policy lookup (Reference: Technical Tip: Firewall policy lookups) from the GUI: Policy & Objects --> Firewall Policy --> Policy Match to view the expected policy match and result/action. If it matches the implicit deny, review the expected and cross-reference the traffic details from the debug flow below.
From the sniffers, if traffic is reaching the firewall LAN interface and not going out of the WAN interface, it means the firewall could be blocking the traffic.
To confirm this, run these commands:
diagnose debug reset
diagnose debug disable
diagnose debug flow filter addr a.b.c.d <----- Where a.b.c.d is the website IP.
diagnose debug flow show function-name enable
diagnose debug flow show iprope enable
diagnose debug console timestamp enable
diagnose debug flow trace start 10000
diagnose debug enable
Once the commands are entered, reload the website. Once the issue is reproduced, disable debug by executing the following commands:
diagnose debug disable <----- To disable debug.
In the resulting logs, observe which firewall policy it is matching. If no policy is matched, an error such as 'denied by forward policy check' will appear. If the above error is seen, create a firewall policy for this.
Note: The debug flow with the command "diagnose debug flow show iprope enable" will displays the internal FortiGate functions involved in packet processing during a debug flow. When enabled, it shows the code of each function that the packet passes through. The description of each code and group is described in: Technical Tip: iprope policies group.
Troubleshoot 3:
If the traffic is going out of the firewall, which can be seen in the sniffer, and there is no reply packet:
Verify that source NAT is applied on the policy to translate the internal IP to the public IP of the firewall.
Check in Forward Traffic logs by filtering the source and destination IP (of the website) if there are send and receive bytes. If the number of bytes is zero, this means that no reply was received from the destination. In Forward Traffic logs, it can also be verified if a reset packet is sent by the client or server.
If this is verified, test with a different browser/machine on the same internal network. If the issue persists, it could be an ISP issue. Try to connect to a different ISP or try to route traffic to the second route using the policy route. Use this KB article for the same: Technical Tip: Configuring the Firewall Policy Routes
In case of a single ISP link, bypass FortiGate and connect the laptop directly to the ISP router to identify if the issue is the same.
This step is to isolate the issue caused by the ISP. These steps are important for website troubleshooting.
If bypassing the FortiGate is not an option, examining the IP reputation can assist in identifying whether the IP is blacklisted or marked as SPAM for any questionable activity. Most of the time, website administrators build security access lists to prevent blacklisted IP addresses from accessing their servers.
Links where to check the IP reputation:
AntiSpam Service
This article does not cover anything related to website blocking by the UTM filters.
This article covers the traffic flow for the website.
Related document:
Technical Tip: Firewall Policy Lookups
|
