Hi all
We have a request for only allow a specific URI of a site.
I take https://store.nintendo.com.hk/70010000038615 for my test.
1. I check denied log to get correct host and URL.path.
2. configure policy to allow this URL.host equals store.nintendo.com.hk and URL.path equals /70010000038615
3. When I test for the link, I found I was denied by URL.path false.
What else I have to configure for allow specific URL.path for a site?
[07/Apr/2021:14:39:58 +0800] "mwgapp4" "-" 192.168.55.20 35.72.94.154 URL.host=store.nintendo.com.hkURL.path=/70010000038615"403 "-" 651 0 "GET https://store.nintendo.com.hk/70010000038615 HTTP/1.1
Solved! Go to Solution.
Hello @cronus.lin,
this could have several reasons such as wrong rule, wrong location of rule or wrong cycle.
For example: If you have a HTTPS site, there is a CONNECT cycle first where MWG only sees the URL host, then CERTVERIFY cycle where MWG still sees only the host and then the GET request where MWG can see full URL including the path.
So if you for example have the block rule below your bypass rule, then it possible blocks directly in CONNECT cycle as your rule cannot match at this time as URL.path was not yet known as SSL scanning must finish at first. In this case, you could make an allow rule to allow CONNECT and CERTVERIFY to let MWG finish SSL scanning like:
Command.Name equals CONNECT OR Command.Name equals CERTVERIFY, Stop Rule Set
When now the request comes in, CONNECT and CERTVERIFY are allowed, then SSL traffic is broken and MWG can see GET request with full URL and then you can filter for URL path and your rule might match.
This is just an example without seeing data. For correct troubleshooting a feedback file and rule trace would be needed to check where something is matching and where note.
As this info is too sensitive for community, I would suggest to open support case with this data attached.
Hello @cronus.lin,
this could have several reasons such as wrong rule, wrong location of rule or wrong cycle.
For example: If you have a HTTPS site, there is a CONNECT cycle first where MWG only sees the URL host, then CERTVERIFY cycle where MWG still sees only the host and then the GET request where MWG can see full URL including the path.
So if you for example have the block rule below your bypass rule, then it possible blocks directly in CONNECT cycle as your rule cannot match at this time as URL.path was not yet known as SSL scanning must finish at first. In this case, you could make an allow rule to allow CONNECT and CERTVERIFY to let MWG finish SSL scanning like:
Command.Name equals CONNECT OR Command.Name equals CERTVERIFY, Stop Rule Set
When now the request comes in, CONNECT and CERTVERIFY are allowed, then SSL traffic is broken and MWG can see GET request with full URL and then you can filter for URL path and your rule might match.
This is just an example without seeing data. For correct troubleshooting a feedback file and rule trace would be needed to check where something is matching and where note.
As this info is too sensitive for community, I would suggest to open support case with this data attached.
Hi @mkutrieba
I add (Command.Name equals CONNECT OR Command.Name equals CERTVERIFY) and my_list, Stop Rule Set before my check rule, my rule for allow specific URL works.
I also test another URL in this web-site, they are blocked by MWG.
Thanks for your reply.
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA