Tag: World Wide Web
SDWAN Center: Getting “An internal error has occurred” while trying to fetch Virtual path details using the NITRO API Command
Its a day 0 code issue in both UI(Reporting) and APIs for paths and virtual paths when we fetch all attributes and the selected time interval is greater than 1 hour.
There are 3 attributes which have a problem –wan_to_lan_best_one_way_time_max_latency_ms, wan_to_lan_best_one_way_time_min_latency_ms, wan_to_lan_min_jitter_ms
To work around the issue the api should use the attribute filter (where we specify a comma separated list of attributes) and ensure to exclude the above 3 attributes as shown in the below workaround.
Work-Around:
curl -X GET -b cookies.txt “https:// /sdwan_center/nitro/v1/reports/virtual_paths?page=size:650;number:1&filter=last_by:day&attrs=lan_to_wan_bandwidth,wan_to_lan_bandwidth,percent_up_time” -v
Solution:
Issue is fixed in 11.4.1 . Upgrade to 11.4.1 to fix the issue.
Related:
PHP Based SQL Injection To RCE – Nulled and Leak Forums
Related:
Is ‘Internal Server Error’ always a sign that there’s a SQL Injection vulnerability in a site …
Related:
Arbitrary and Remote Code Execution – CompTIA Security+ SY0-401: 3.5
Related:
Citrix Receiver for Web: Error “Cannot complete your request”
1. From test machine ping the base URL and confirm the IP you are getting:
- Case 1: Unable to resolve any IP
- Case 2: Able to resolve Load Balancing VIPs IP
- Browse “Store for Web” using IP address of StoreFront/localhost on StoreFront server and confirm if you are able to login and see resources, check this on all the StoreFront servers
- If you are able to login and see resources then it should be a configuration on LB VIP causing the issue then troubleshooting should be done on NetScaler.
- If you are still getting same error then troubleshooting should be done on StoreFront.
- Case 3: IP resolving to one of the StoreFront’s IP
- Case 4: Incorrect Trusted domain Configured
To resolved: Correct the domain name or select “All Domains” under “Manage Authentication Methods” for NetScaler Passthrough
Troubleshooting StoreFront:
- Ping the base URL from StoreFront servers, each StoreFront server should resolve the base URL to it’s own IP if now then create a host entry (https://support.citrix.com/article/CTX235907).
- Make sure you are able to browse default IIS page as StoreFront is dependent on IIS.
- Make sure that the Default Store was never deleted from the StoreFront server. Deleting the default Store can corrupt StoreFront and we may need to reinstall StoreFront.
- Confirm if StoreFront services are running, Citrix Cluster join service can be in disable state(only works when we add a new server to Server Group).
- Check event viewer on StoreFront server. There can be multiple Receiver for Web events, e.g. “Failed to run discovery” or “Unable to resolve/find URL at 443/80”.
- This can happen because of bindings on IIS. Make sure if the base URL is https then there should be https binding on StoreFront server with valid certificates if not then change base URL to http and confirm you have http/port 80 binding on IIS.
- This can happen because of bindings on IIS. Make sure if the base URL is https then there should be https binding on StoreFront server with valid certificates if not then change base URL to http and confirm you have http/port 80 binding on IIS.
- Check authentication methods in Store> Manage Authentication Methods
- If authentication method available is Username and Password and you have selected Smart Card in Manage Authentication Methods then StoreFront will not find a way to authenticate users and give errors
Related:
Researchers want to make unhackable computer processors
Related:
Printers fail to map with errors when using UPS on Windows Server 20122016
Add “LimitRequestLine 8190” in the next line after the “LimitRequestFieldSize 65535” to the httpd.conf file located at:
C:Program Files (x86)CitrixXTEconf
The LimitRequestLine directive decides the limit on the allowed size of HTTP request line (which contains HTTP Method, URI and Protocol version). Since 8190 is the default value, having it in the httpd.conf file should not make any difference.
Related:
HTML5 Error “Citrix Receiver cannot connect to the server” from external connection
- Under Citrix Policy, go to Policy
- In the middle pane, under Policies, modify an existing policy or create a new policy for external connections.
- In the right pane, click Actions > Edit Policy
- Edit Unfiltered window will appear, then type websock and hit Enter.
- Select WebSock trusted origin server list
- Enter the External URL //this is to allow external URL as a trusted URL
- Click OK
NOTE:
For internal connections, the policy for the web sockets is as follows :
Web Socket Connects – Allowed
Web Socket Port number – Default 8008
Web sockets trusted origin server – default *
The policy is assigned to all objects in the site.
WebSockets trusted origin server list
This setting provides a comma-separated list of trusted origin servers, usually Receiver for Web, expressed as URLs. Only WebSockets connections originating from one of these addresses is accepted by the server.
By default, the wildcard * is used to trust all Receiver for Web URLs.
Related:
Duplicate App Icons on Receiver for Windows
This article is intended for Citrix administrators and technical teams only.
Non-admin users must contact their company’s Help Desk/IT support team and can refer to CTX297149 for more information.
Affected users see multiple stores configured (CCA4-UK, CCA4-UK1, CCA4-UK2 and so on). Receiver was installed via Script or Package and Store is configured via Studio or Delivery Group.