|
Below 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.
Here in this sniffer output, observe whether there is a way flow or only a way flow.
Check if the traffic is reaching the firewall and if it is going out of the firewall or not.
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 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.
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 there is 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.
This article does not cover anything related to website blocking by the UTM filters.
This article covers the traffic flow for the website.
|
