Forum Discussion
NimbostratusPortal Resource Definition
I have a portal link which includes a resource defined as follows:
I also have a deny-all ACL as the last entry.
Everything works fine as shown in the following two log entries however the third one is being rejected.
allow ACL: rewrite_/ABC_test_techportal_portal-access:3 packet:
https://servicequal.abc.com/sqp/JsonBridge?method=getCommunitiesByProvince&bean=searchBean&arg=XXX&arg=&rnd=12345 tcp 10.163.101.65:33129 -> 10.134.124.89:443
allow ACL: rewrite_/ABC_test_techportal_portal-access:3 packet:
https://servicequal.abc.com/sqp/images/spacer.gif tcp 10.163.101.65:33137 -> 10.134.124.89:443
reject ACL: /ABC_deny-all-l7_acl:1 packet:
https://servicequal.abc.com/sqp/customer_search.portal;ABC_SQP=hbybWSD!1550!2045?_nfpb=true&_windowLabel=portletInstance_sq_home&_nffvid=/sqp/WEB-INF/jsp/customer_search.faces&_pageLabel=customer_search_portal_page_7_9 tcp 10.163.101.65:33218 -> 10.134.124.89:8443
In each case (including the rejected line), the host name and path matches. Is there a special character in the third URI such as the semi-colon perhaps that is acting as some sort of delimeter? If so, what would I add to the path to allow this to pass?
Thanks
APM 11.5.32 Replies
I notice in the first two you've put "rewrite_", which I assume is the hex-encoded version of the hostname (like rewrite uses).
For Portal ACLs (aka list items), the resource must be accessed via rewrite, not via LTM+APM mode (which is what the third one would be. Can you identify exactly the URL accessed by the client in each of the 3 cases? It could be some issue where the Web App is breaking out of rewrite somehow because of an issue with rewrite, or it could be a split-tunnel rewrite sort of configuration.
Alternatively, if you want to mixup this rewrite and LTM+APM type of access, you could just use plain URL ACLs instead of Port ACLs.
David_GillCirrus
I just realize the problem is the port. I was only looking at the https and did not notice the :8443 at the end of the line.
...customer_search_portal_page_7_9 tcp 10.163.101.65:33218 -> 10.134.124.89:8443Everything works great now.
