ICA Connection Stuck at “Connection in Progress” on StoreFront

When you capture a network trace while the endpoint is attempting to connect over the ICA session, you will notice a TCP-SYN retransmissions on 2598 for that server.

The VDA has two network cards: Legacy and Synthetic. The ICA file which the endpoint receives, is listing an IP Address of the Legacy Adapter (which is non-routable from external network). Hence the ICA connection fails.

We would ideally like to have an address in the ICA file which is reachable from the Internet and the Legacy network adapter is required to communicate with the PVS server initially, mostly in the same subnet. If over the legacy network adapter, we disable Gateway and attempt to connect again, this time ICA should come up with the synthetic adapter’s address.

As per the PVS design, PVS Legacy NIC should have a 169.x.x.x address post the bootup completion. PVS uses the Synthetic network adapter for the communication with the PVS server.


  • No Related Posts

WSS Agent

I need a solution

We have recently deployed the Web Security Service and deployed the Unified Agent 4.11 (Windows 7) and WSS AGent 6.1.1. However when we add domains and IP addresses to be bypassed on the portal, the rules dont appear to take effect with the domain names still appearing in the user traffic and the egress adddress still coming from Symantec. Is this standard behaviour for the agents or can anyone advise as to what we are doing wrong?



  • No Related Posts

Blacklisted IP Address creating problem

I do not need a solution (just sharing information)


we have been experiencing problems with our mail server for a while, as it has been blacklisted by Symantec.

We are constantly checking our IP address ( and it is considered with good reputation everywhere, except on Symantec.

Our customers keep complaining that their clients don’t receive their emails and we don’t understand why our server keeps being blacklisted.

Every day we use the IP reputation investigation tool, but everytime we check it again is blacklisted again and it doesn’t give us any reason.

Please help us removing our IP address from your blacklist or give us any hint on how to fix this problem.

Thank you in advance.

Andrea Crescimone



ShareConnect Firewall Configuration

Covers Citrix SaaS products involving our servers as of August 2016

ShareConnect is configured to work outbound through ports 8200, 80 or 443.

In a restricted environment, port 8200 can be set up for outbound connections. ShareConnect does not require any inbound connections. Connections outbound via port 8200 are optimal, although connections through ports 80 and 443 can also be used.

For most firewall or proxy systems, we recommend specifying a whitelist of DNS addresses for Citrix services so outbound connections can be made. The list of Citrix domains ShareConnect utilizes includes (but is not limited to) the following:


Important Note: Changes to the firewall configuration are generally discouraged because our IP ranges and those of our provider networks need to be periodically audited and modified, creating additional maintenance to your network. These changes are necessary to continue to provide the maximum performance for ShareConnect.

If your firewall includes a content or application data scanning filter, this may cause blocking or latency, which would be indicated in the log files for the filter. To address this problem, verify the below IP ranges will not be scanned or filtered by specifying exception IP ranges that will not be filtered. If your security policy requires you to specify explicit IP ranges, then configure your firewall to limit port 8200 or 80 or 443 and IP addresses to only the Citrix ranges and those of our provider networks given below.

Citrix server / Datacenter IP addresses for use in firewall configurations

Equivalent specifications in 3 common formats
Citrix Assigned

Range by Block
Numeric IP

Address Range
Netmask Notation CIDR Notation
Block 1 –
Block 2 –

Citrix scales its services into third-party cloud and carrier networks for improved performance. This comes in the form of shorter software download times and Datacenters geographically closer to more regions for better in session performance.

To explicitly whitelist IP addresses in order to ensure that the ShareConnect software may download properly, please refer to:

IP ranges for the content delivery network (CDN)

To explicitly whitelist the IP Addresses for ShareConnect in-session communications, please refer to:

IP ranges for software communications

For your convenience, we have included a list of IP addresses for Datacenters in use by ShareConnect. Please note that new Datacenters may be added or existing Datacenters may be removed dynamically to ensure performance. While we strive to keep this documentation up to date, if it is critical to have all potential IP addresses explicitly whitelisted it is recommended that you whitelist the IP addresses linked above for screen sharing.

Citrix server / Datacenter IP addresses for use in firewall configurations

ShareConnect Software Communications
Domain Name Numeric IP



How to authorize public IP addresses to navigate in WI Cloud

I need a solution

Good afternoon,

I’ve been trying for two months for Symantec support to help me enable some public IP addresses so they can navigate through the tenant we have licensed. It has been an odyssey and they send me as ping-pong between customer care, support and presale.

Does anyone know how to enable IP addresses so that the PCs that are leaving through these can use the isolation services ..?

Another feature we need is to enable authentication for the users who are going to use it.

We do not have any kind of proxy so the proxy will be the same WI through the PAC file.




Users are kicked back to the login screen after submitting credentials for SecureHub

Check the relevant Session Policy/Profile to ensure that the Accound Services Address setting is not using an IP address.

If so, change Account Services Address on Netscaler gateway session profile (Published Applications tab) to use the FQDN for MDM:Port.

This is going to be bound on the relevant session policy/profile bound to the Netscaler Gateway, or AAA Group/User. It could also be bound globally.


Solution to repeat “Traffic has been blocked from this application: Host process for Windows Services (svchost.exe)”

I do not need a solution (just sharing information)

I surfferd this issue (or inconvenience) for a while.

Sometime, the Symantec Endpoint Protection client (14.0.RU1.MP2)  installed on my computer poped up a warning message “Traffic has been blocked from this application: Host process for Windows Services (svchost.exe)” repeatly. After seveeal days, it disappeared. Suddenly it appeared again in some day.

My computer was in private network ( and SEP client was managed by a centralized SEPM server.  Everytime I checked the SEP traffic log in my computer and found,  it usually pointed these alerts came from the SEPM firewall rule “Block uPnP Discovery” to block outgoing UDP traffice from my computer to remote UDP port 19000, after several successful “Allow UPnP Discovery from private IP addresses” records . I didn’t understand why I enable “Allow UPnP Discovery from private IP addresses” but it didn’t work well.  didn’t want to disable “Block uPnP Discovery” rule in risk and it didn’t cause big problem, so I usually tolerated little inconvenices caused.

Ten days ago, I got news that SEP 15 was released. So I checked what’s new is SEP15 and known issues are fixed here. https://support.symantec.com/us/en/article.howto12… .  I noticed the issue# SEP-50901 on the page, it states ” The default rule Allow UPnP Discovery from private IP addresses caused too many blocked events. ….”.

An idean hit me that my issue might be same or similiar to issue# SEP-50901, so I took manual modification based on its instruction. After my Firewall policy modification and SEP client received the updated policy, the annoying messages didn’t bother me anymore. YES, this solution not only applies to SEPv15 but also SEPv14

Instead of modifying “Allow UPnP Discovery from private IP addresses rule” directly, I copied and pasted it as duplicated policy. I renamed the duplicated policy and revised it, then make it active.

Below are actions you could take to to modify the Allow UPnP Discovery from private IP addresses rule:

  1. Go to the Firewall policy, and under the Firewall Rules list, select the Allow UPnP Discovery from private IP addresses rule.

  2. In the Edit Firewall Rule dialog box, select Hosts.

  3. Edit each host entry so that the host type is Source.

  4. Go to the Services page and change the existing default entry from Local/Remote to Source/Destination.

  5. Remove 1900 from Source Port field and add 1900 to the Destination Port field.

  6. Select Save > Submit.

  7. Save the policy.