|
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 over the troubleshooting:
Troubleshoot 1:
Perform 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:
# diag sniffer packet any 'host a.b.c.d and x.x.x.x' 6 0 a
(where a.b.c.d is the website ip address and x.x.x.x is the is the internal machine's IP)
# diag sniffer packet any 'host a.b.c.d' 6 0 a
(where a.b.c.d is the website ip address)
Here in this sniffer output, observe whether there is two way flow or only one 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:
diag debug reset
diag debug disable
diag debug flow filter addr a.b.c.d x.x.x.x and
(Where a.b.c.d is the website IP and x.x.x.x is the internal machine's IP.)
diag debug flow show function-name enable
diag debug console timestamp enable
diag debug flow trace start 10000
diag debug enable
Once the commands are entered, reload the website. Once the issue is reproduced, disable debug by executing the following commands:
diag 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:
Now if the traffic is going out of the firewall which can be seen in the sniffer and there is no reply packet:
Verify source NAT is applied on the policy to translate your internal IP to the public IP of your firewall.
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 article for the same.
Technical Tip: Configuring the Firewall Policy Routes.
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.
|
