Please explain this odd diagnostic tool behaviour.

No answers, very disappointing. Today the XG started to block access to the coles.com.au site for most users, again. Testing shows DNS does not return a IPv8 address for the site which seems to be the issue. XG cannot test access to IPv6 sites which makes diagnosis very difficult.

Ian

I have identified why coles.co,.au is not accessible from some device on the local network

Further to the diagnostic failure, the same issue occurs with otthe websites, so there is a bug in the diagnostic tool.

Ian

update on connection issue. Disable the wifi for awhile seems to work on most devices.

I am not able to follow you:
The policy tester can do the web proxy rules and the firewall rules. 

You do not have a matching Firewall rule for this traffic. Should there be one firewall rule? 

Because proxy is simply testing itself, solely on the base of "what would the proxy say". 

If you are getting a blocked page, this would be fine, as this is the expected behavior, due no firewall rule in place. 

The issue is there is a firewall rule. I understand what you are asking and see the error of my question.

ian

But an TLS Rule will not allow anything? So can you show us your Firewall Rule, which should allow this? 

You are referring to an issue, your firewall rule is not reflected? 

I don't have any general access SSL?TLS rules, only a couple for specific devices that do not object to SSL/TLS inspection.

The firewall rule using the web proxy works correctly.

Ian

First of all: TLS/SSL Scanning is not involved in this situation. 
The policy tester simply says, your IP has no matching firewall rule for WAN (This particular WAN IP).

If you browse from this IP to the particular WAN IP, do you see a logviewer entry? Can you show us this logviewer entry? 

You hit the nail on the head, that is the issue I am trying to debug as to why the traffic never gets to the firewall. I thought I had the iissue identified but no and i am no closer to working out why it is failing.

I originally thought is was safari and apple wifi, so I change APs, different manufacturer, different SSID and password still failure. I tried direct connection that worked with firefox, now having changed to a larger switch to provide sufficient physical connection I still get failures.

At the moment my wife's mac air has connection to the site using firefox, she needs access to do the online shopping. When it does connect it uses IPv6.

So annoying. Tomorrow I will try a direct connection without the XG being involved.

Ian

I finally caught a packet.

2023-04-09 20:13:59Web filtermessageid="16001" log_type="Content Filtering" log_component="HTTP" log_subtype="Allowed"
fw_rule_id="2" fw_rule_name="General Access 6" fw_rule_section="Local rule"
user="ians-mac14-6" user_group="Bigpond6"
web_policy_id="13" web_policy="My No Games Ads or Explicit Content"
category="Online Shopping" category_type="Unproductive"
url="">www.coles.com.au/favicon.ico" content_type="text/xml" override_token="" src_ip="2403:5814:8482:3201:100::4" dst_ip="2620:1ec:4e:1::32"
protocol="TCP" src_port="49359" dst_port="443"
bytes_sent="428" bytes_received="485" domain="www.coles.com.au"
exception="" activity_name=""
reason="not eligible"
user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15;
rv:109.0) Gecko/20100101 Firefox/111.0" status_code="403" transaction_id=""
referer="">https://www.coles.com.au/" download_file_name=""
download_file_type="" upload_file_name="" u
pload_file_type="" con_id="1825281503" app_name=""
app_is_cloud="0" override_name=""
override_authorizer="" used_quota="0"

I found the answer now that I have been able to capture packets. IPv6 connections fail return a 403, IP4 connections succeed return a 200 and 304.

So the next challenge is to talk to the site and find out why IPv6 connections fail?

Ian