Jump to content
Updated Privacy Statement

Client IPv4 -> Gateway vServer IPv4 -> VDA IPv6: is this possible?


tylital520

Recommended Posts

Hi,

could somebody tell me if this is possible: end user connects to Gateway vServer which has a IPv4 address, and launches an application which is delivered from VDA which is running IPv6. So can I somehow set up CVAD + ADC VPX so that I could deliver both IPv4 and IPv6 Apps and Desktops to end users? I would have separate delivery groups for IPv4 apps and IPv6 apps.

 

If this is possible are there more detailed instructions somewhere about this? I have not been able to find anything.

Link to comment
Share on other sites

Gateway can do ipv4 to ipv6 (or ipv6 to ipv4) for ica proxy and full vpn modes.  It can also do end to end ipv6 for ica proxy mode; not full vpn mode.

 

Most of the gateway articles: are about the vpn vserver on ipv6...but you can have the vpn vserver (gateway) on ipv4, need an ipv6 snip (and route info) and some of hte ipv6 over ipv4 preferences for the backend in the "configure ica proxy stuff).

https://docs.citrix.com/en-us/netscaler-gateway/12/vpn-user-config/receiver-integration/config-ipv6-icaproxy.html

https://docs.citrix.com/en-us/citrix-gateway/13/install/ng-config-ip-addresses-on-ng-con/ng-config-ipv6-for-client-connections-tsk.html

 

This will be about the vda/cvad side.

https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/manage-deployment/ipv6.html

See Diagram : ipv4 or ipv6 clients can talk to gateway.  storefront/vda's can then be ipv6 or ipv4.

 

Client connections via gateway will still be client to vpn vserver (gateway:ipv4) and then proxied to vda (ipv6).  The trick is to make sure the gateway snip to storefront and gateway snip to vda is properly doing ipv6 and name resolutions.  For a mixed environment, you may need an ipv4 and an ipv6 snip.

 

Depending on whether you want your CVAD site (storefront/controllers/vdas) ipv4 only, ipv6 only, or dual-stacked...will determine which of the policy settings you need:

VDA's are configured by a policy to only use ipv6 controller registrations or to use both or ipv4 only. (Policies in this article above.)

Only ipv6 controller registrations and controller registration ipv6 netmask (this will allow controllers to return ipv6 vda addresses)

ipv4 vs ipv6 vda's should be managed as separate delivery groups; but can be managed in same CVAD site. 

 

I know this isn't a complete answer, but it should get you started.  

  • Like 2
Link to comment
Share on other sites

20 hours ago, Rhonda Rowland1709152125 said:

Gateway can do ipv4 to ipv6 (or ipv6 to ipv4) for ica proxy and full vpn modes.  It can also do end to end ipv6 for ica proxy mode; not full vpn mode.

 

Most of the gateway articles: are about the vpn vserver on ipv6...but you can have the vpn vserver (gateway) on ipv4, need an ipv6 snip (and route info) and some of hte ipv6 over ipv4 preferences for the backend in the "configure ica proxy stuff).

https://docs.citrix.com/en-us/netscaler-gateway/12/vpn-user-config/receiver-integration/config-ipv6-icaproxy.html

https://docs.citrix.com/en-us/citrix-gateway/13/install/ng-config-ip-addresses-on-ng-con/ng-config-ipv6-for-client-connections-tsk.html

 

This will be about the vda/cvad side.

https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/manage-deployment/ipv6.html

See Diagram : ipv4 or ipv6 clients can talk to gateway.  storefront/vda's can then be ipv6 or ipv4.

 

Client connections via gateway will still be client to vpn vserver (gateway:ipv4) and then proxied to vda (ipv6).  The trick is to make sure the gateway snip to storefront and gateway snip to vda is properly doing ipv6 and name resolutions.  For a mixed environment, you may need an ipv4 and an ipv6 snip.

 

Depending on whether you want your CVAD site (storefront/controllers/vdas) ipv4 only, ipv6 only, or dual-stacked...will determine which of the policy settings you need:

VDA's are configured by a policy to only use ipv6 controller registrations or to use both or ipv4 only. (Policies in this article above.)

Only ipv6 controller registrations and controller registration ipv6 netmask (this will allow controllers to return ipv6 vda addresses)

ipv4 vs ipv6 vda's should be managed as separate delivery groups; but can be managed in same CVAD site. 

 

I know this isn't a complete answer, but it should get you started.  

 

Hi Rhonda and thank you so much for the reply!

 

I have watched this youtube video at least 10 times to understand better what happens on ADC and CVAD infrastructure when a user logs in and launches an application or desktop: Citrix NetScaler Gateway and StoreFront Integration Whiteboard

 

Here's what I've figured out so far:

 

Based solely on that video I'd assume that from the CVAD infrastructure only the delivery controllers need to have IPv6 enabled. The IPv6 VDA's need to be able to register to the controllers, so that's why the controllers also need to have IPv6 enabled. 

 

But if I understand correctly the communication between ADC, StoreFront, Database and Delivery Controllers can still happen in IPv4? The STA ticket which ADC queries from the Delivery Controller has the IPv6-address of the VDA. So after ADC queries the STA ticket from the Delivery Controller, it uses the IPv6 SNIP to communicate with the IPv6 VDA?

 

If all this is true, then besides the Delivery Controllers, I need to enable IPv6 on the Domain Controllers for the IPv6 name resolution to work. How about when the application is started from a Windows Server which is running IPv6, I think the server needs to communicate with Domain Controllers using IPv6? And when a users profile is loaded from a separate server, that too needs to have both IPv4 and IPv6 enabled?

 

Regarding ADC:

 

I have understood that ADC communicates to DNS & Active Directory via NSIP. If that is the case then I think I need to set IPv6-address to NSIP, because ADC needs to be able to resolve IPv6 DNS records?

 

I guess I also need to set the IPv6 addresses of our Domain Controllers to Traffic Management-> DNS -> Name Servers

 

And I need to create the IPv6 SNIP and add the IPv6 networks to System -> Networks -> Routes -> IPv6

 

It would be really helpful to get someone from Citrix to answer to this. Basically our end users need to be able to launch an app and use it to connect to IPv6 hosts. They still login to our Citrix-infrastructure by using IPv4.

Link to comment
Share on other sites

16 hours ago, tylital520 said:

Based solely on that video I'd assume that from the CVAD infrastructure only the delivery controllers need to have IPv6 enabled. The IPv6 VDA's need to be able to register to the controllers, so that's why the controllers also need to have IPv6 enabled. 

 

That's not exactly what's going on.  If you have VDA that are both IPV4 and IPV6 in one site, then your controllers will need to support BOTH ipv4 and ipv6; the vda's will be on one or the other.

 

There are three main communication flows in an ICA Proxy config:  I.  logon/enumeration, lI.  aunch request, and then III. connection to vda

Phase I communication involves the client to gateway / gateway to storefront and storefront to Controllers (xml brokers):  This is where users authentication, there list of available resources are returned to the client (controller to storefront to gateway to client) and where users end up with list of app/desktop resources in a list in storefront or workspace app.

- During this phase all client comms to are gateway and gateway handles the communication to storefront.  Storefront handled controller comms.

- On the backend VDA's are registering with and providing status/updates to controllers: This is the VDA Registration process between VDAs to Controllers.

 

When a user attempts to launch a resource, (Phase II), then a user's launch request is still client to gateway to storefront to controllers, while the controllers figure which VDA to broker you too. This is returned to storefront who creates the ICA file in gateway/ica proxy mode and embeds the gateway fqdn and the STA ticket info.  The ICA file is then returned from storefront to gateway to user.

 

Phase III begins with the ica file is handed off to the workspace app and the client establishes a connection to the vda (via the gateway.  Client connects to gateway. Gateway redeems sta ticket from controller, and then gateway proxies the client to gateway/gateway to vda traffic.

 

So, if your CVAD environment is ONLY ipv4 (storefront/controllers/vdas) but your users are ipv6, then the user to gateway communication can be ipv6 while gateway to all internal resources (storefront/vdas) and the storefront and vdas to controller communication can be ipv4.  Gateway can do ipv6 to ipv4 translation.

Or vice versa. If the users side is all ipv4 to gateway; but the gateway to storefront/vdas and vdas to controllers is all ipv6.

If the internal CVAD infrastructure is all one thing (all ipv4 or all ipv6), than that is what this article describes as "single stack".  In this case, the VDA's and the controllers will both be all ipv4 or all ipv6.  And the client to gateway is all one type while gateway to internal stuff is the other.

 

So for CVAD to use ipv6 (single stack):  the only thing is you have to tell VDA's to use ipv6 registrations, since they default to ipv4 (so that's a citrix policy) AND you have to have your controllers on ipv6.

 

If your CVAD site will do both ipv4 and ipv6 (dual stack), then there are some considerations.

- ipv4 VDA's must be in separate delivery groups (and ideally separate OUs to simplify policy management) from ipv6 VDAs.  Basically, while different vda's can be in the same site; a given VDA (and therefore delivery group) must be ipv4 only or ipv6 only.

- Use the policies to control which delivery groups use ipv4 controller registrations and which vda's use ipv6 controller registrations.

-  In order for storefront/controllers to use ipv6 or ipv4 they will need to be configured with both ipv4/ipv6 ips and routes.

 

Gateway can be configured to handle both ipv4/ipv6 or just a single access only.  Gateway to Storefront / StoreFront to Controller can be "single stacked" for this purpose if you want.  But the VDA to controller communication for registration will be ipv4 only or ipv6 only.  And when those controllers return details to storefront for how to connect, it should report ipv4 or ipv6 based on the vda's registration config.  

 

Client to gateway can be one thing; gateway to vda will depend on whether the vda is ipv4 or ipv6.

 

These are still the best references on the ipv6 and dual stack setup:

https://docs.citrix.com/en-us/citrix-gateway/12-1/vpn-user-config/receiver-integration/config-ipv6-icaproxy.html

https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/manage-deployment/ipv6.html

 

 

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

On 6/19/2020 at 5:04 AM, Rhonda Rowland1709152125 said:

 

That's not exactly what's going on.  If you have VDA that are both IPV4 and IPV6 in one site, then your controllers will need to support BOTH ipv4 and ipv6; the vda's will be on one or the other.

 

There are three main communication flows in an ICA Proxy config:  I.  logon/enumeration, lI.  aunch request, and then III. connection to vda

Phase I communication involves the client to gateway / gateway to storefront and storefront to Controllers (xml brokers):  This is where users authentication, there list of available resources are returned to the client (controller to storefront to gateway to client) and where users end up with list of app/desktop resources in a list in storefront or workspace app.

- During this phase all client comms to are gateway and gateway handles the communication to storefront.  Storefront handled controller comms.

- On the backend VDA's are registering with and providing status/updates to controllers: This is the VDA Registration process between VDAs to Controllers.

 

When a user attempts to launch a resource, (Phase II), then a user's launch request is still client to gateway to storefront to controllers, while the controllers figure which VDA to broker you too. This is returned to storefront who creates the ICA file in gateway/ica proxy mode and embeds the gateway fqdn and the STA ticket info.  The ICA file is then returned from storefront to gateway to user.

 

Phase III begins with the ica file is handed off to the workspace app and the client establishes a connection to the vda (via the gateway.  Client connects to gateway. Gateway redeems sta ticket from controller, and then gateway proxies the client to gateway/gateway to vda traffic.

 

So, if your CVAD environment is ONLY ipv4 (storefront/controllers/vdas) but your users are ipv6, then the user to gateway communication can be ipv6 while gateway to all internal resources (storefront/vdas) and the storefront and vdas to controller communication can be ipv4.  Gateway can do ipv6 to ipv4 translation.

Or vice versa. If the users side is all ipv4 to gateway; but the gateway to storefront/vdas and vdas to controllers is all ipv6.

If the internal CVAD infrastructure is all one thing (all ipv4 or all ipv6), than that is what this article describes as "single stack".  In this case, the VDA's and the controllers will both be all ipv4 or all ipv6.  And the client to gateway is all one type while gateway to internal stuff is the other.

 

So for CVAD to use ipv6 (single stack):  the only thing is you have to tell VDA's to use ipv6 registrations, since they default to ipv4 (so that's a citrix policy) AND you have to have your controllers on ipv6.

 

If your CVAD site will do both ipv4 and ipv6 (dual stack), then there are some considerations.

- ipv4 VDA's must be in separate delivery groups (and ideally separate OUs to simplify policy management) from ipv6 VDAs.  Basically, while different vda's can be in the same site; a given VDA (and therefore delivery group) must be ipv4 only or ipv6 only.

- Use the policies to control which delivery groups use ipv4 controller registrations and which vda's use ipv6 controller registrations.

-  In order for storefront/controllers to use ipv6 or ipv4 they will need to be configured with both ipv4/ipv6 ips and routes.

 

Gateway can be configured to handle both ipv4/ipv6 or just a single access only.  Gateway to Storefront / StoreFront to Controller can be "single stacked" for this purpose if you want.  But the VDA to controller communication for registration will be ipv4 only or ipv6 only.  And when those controllers return details to storefront for how to connect, it should report ipv4 or ipv6 based on the vda's registration config.  

 

Client to gateway can be one thing; gateway to vda will depend on whether the vda is ipv4 or ipv6.

 

These are still the best references on the ipv6 and dual stack setup:

https://docs.citrix.com/en-us/citrix-gateway/12-1/vpn-user-config/receiver-integration/config-ipv6-icaproxy.html

https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/manage-deployment/ipv6.html

 

 

 

 

 

 

 

Thank you once again Rhonda for the detailed explanation!

 

Yes I meant that if I want to use dual-stack IPv4/IPv6 at least the controllers need to have both IPv4 and IPv6 enabled.

 

I was planning to create different delivery groups for IPv6 VDA's and IPv4 VDA's because as you say, the VDA can only use IPv4 or IPv6 not both (Handled with the following policy: "Only use IPv6 Controller registration").

 

I am still wondering whether the StoreFront servers need to have both IPv4 and IPv6 enabled. You write here:

 

Quote

-  In order for storefront/controllers to use ipv6 or ipv4 they will need to be configured with both ipv4/ipv6 ips and routes.

 

But later you write:

Quote

Gateway to Storefront / StoreFront to Controller can be "single stacked" for this purpose if you want

 

So do I need IPv6 only on Controllers (IPv4 and IPv6) and VDA (either IPv4 or IPv6) + ADC SNIP (both IPv4 and IPv6 SNIP)? :)

Link to comment
Share on other sites

So for the controllers piece, the first dependency is then will vda's be ipv4 or ipv6 based.

 

For gateway and storefront, the decision now shifts to the network of the clients making the connection to storefront/gateway and what you want to do.

 

For internal users talking to storefront (without the gateway), will users be ipv4 only, ipv6 only, or both?  (Since the VDA's will be mixed, my guess is your clients may be mixed when talking to storefront).  You can make storefront ipv4 only or ipv6 only if it doesn't impact the client during the client to storefront communication.  I believe you can talk to storefront on one format and it won't impact the client to vda as that will be determined by the ip format returned to the storefront from the controller to build the ica file.

 

Now, if any of your users on the intrnal network can only use ipv4 only vs ipv6, then they might impact the client to storefront communication.

 

For external users coming through gateway, gateway in ica proxy only mode (again not full vpn), can do ipv4 to ipv6, ipv6 to ipv4 translation or end-to-end ipv6.  

So for the client to gateway to storefront flow, do your external users NEED gateway/storefront on ipv6 vs. ipv4.

 

So, the decision comes down from the client device perspective are any of your devices ipv6 only, then you would likely need the gateway/storefront to handle ipv4 and ipv6 prior to the vda connection phases.  If your client devices can do either and its just the vda's driving this decision, then your gateway/storefront can likely be ipv4 beyond the requirements needed to do ivp6 for the vda's.

 

Does that make any sense?

 

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, Rhonda Rowland1709152125 said:

So for the controllers piece, the first dependency is then will vda's be ipv4 or ipv6 based.

 

For gateway and storefront, the decision now shifts to the network of the clients making the connection to storefront/gateway and what you want to do.

 

For internal users talking to storefront (without the gateway), will users be ipv4 only, ipv6 only, or both?  (Since the VDA's will be mixed, my guess is your clients may be mixed when talking to storefront).  You can make storefront ipv4 only or ipv6 only if it doesn't impact the client during the client to storefront communication.  I believe you can talk to storefront on one format and it won't impact the client to vda as that will be determined by the ip format returned to the storefront from the controller to build the ica file.

 

Now, if any of your users on the intrnal network can only use ipv4 only vs ipv6, then they might impact the client to storefront communication.

 

For external users coming through gateway, gateway in ica proxy only mode (again not full vpn), can do ipv4 to ipv6, ipv6 to ipv4 translation or end-to-end ipv6.  

So for the client to gateway to storefront flow, do your external users NEED gateway/storefront on ipv6 vs. ipv4.

 

So, the decision comes down from the client device perspective are any of your devices ipv6 only, then you would likely need the gateway/storefront to handle ipv4 and ipv6 prior to the vda connection phases.  If your client devices can do either and its just the vda's driving this decision, then your gateway/storefront can likely be ipv4 beyond the requirements needed to do ivp6 for the vda's.

 

Does that make any sense?

 

 

 

Yes that absolutely makes sense.

 

Actually all of our end users access via NetScaler Gateway, so none of them connect directly to StoreFront. Only situation where we use direct StoreFront access is when troubleshooting NetScaler issues (trying figure out if it is the netscaler which is causing the issues).

 

The client devices have both IPv4 and IPv6 enabled. There might be some rare occasions where they are using only IPv4. But my plan was to keep the Gateway vServer in IPv4 for now. Of course it might be smart to prepare oneself already for the situation where the client devices are using only IPv6. That is not a mandatory at this point though.

 

Link to comment
Share on other sites

29 minutes ago, tylital520 said:

The client devices have both IPv4 and IPv6 enabled. There might be some rare occasions where they are using only IPv4. But my plan was to keep the Gateway vServer in IPv4 for now. Of course it might be smart to prepare oneself already for the situation where the client devices are using only IPv6. That is not a mandatory at this point though.

I think that's fine as long as the gateway can do the ipv6 to the vda's then the rest should be fine on ipv4. Most external clients will do both anyway.

  • Like 1
Link to comment
Share on other sites

Thanks once again Rhonda for your help. I am in the process of of getting the necessary IPv6 addresses.

 

I realized that I do have users who connect directly to StoreFront. Inside the VDI I have added our Published Applications to the Workspace App in each VDI. I have created a separate Store for this use (Pass-through from Citrix Gateway disabled), and selected the "Show applications view only". 

 

Because the VDI can only be IPv4 or IPv6 I must change this, so that the connection from the VDI goes through NetScaler. Otherwise the end users can launch only IPv4 or IPv6 applications depending on which type of VDI they are using.

 

I was also thinking that the file server hosting the Citrix user profiles must be in IPv6 so that when the end user launches an IPv6 app or desktop, the profile is loaded correctly.

 

I'll let you know how this goes once I am able to start the configuration.

Link to comment
Share on other sites

Hm.  You have more than one option here.

You could make the Tier2 resources published based on client ip range via the delivery group published settings, so only IPv4 resources are advertised to the ipv4 tier1 resource and so on; without needing to route them back through gateway. (Or user group filter if that is a good delineator of who is connecting.)

 

Since your gateway/storefront/controllers can do either, you shouldn't need to do additional config separation if they are brokered to the right tier2 resources dependent on their tier1 vda.  It might simplify your config.

 

Then as long as profiles load in the destination you are connected to you should be fine.

 

 

 

 

  • Like 1
Link to comment
Share on other sites

  • 2 months later...
On 6/30/2020 at 7:55 PM, Rhonda Rowland1709152125 said:

Hm.  You have more than one option here.

You could make the Tier2 resources published based on client ip range via the delivery group published settings, so only IPv4 resources are advertised to the ipv4 tier1 resource and so on; without needing to route them back through gateway. (Or user group filter if that is a good delineator of who is connecting.)

 

Since your gateway/storefront/controllers can do either, you shouldn't need to do additional config separation if they are brokered to the right tier2 resources dependent on their tier1 vda.  It might simplify your config.

 

Then as long as profiles load in the destination you are connected to you should be fine.

 

 

 

 

 

Hi Rhonda,

 

so I finally got around configuring this. Here's what I did:

 

Configured IPv6-addresses to the following servers (running now both IPv4 and IPv6):

Delivery Controllers
Domain Controllers
DHCP (getting IPv6-addresses to VDA's)
Server providing RDS CAL's
Windows KMS-server

 

IPv6-addresses via DHCPv6:
selected VDA's

 

This worked fine when I tested this with a user account from the same Active Directory domain in which our Citrix-servers are members of. So the IPv6 client (no IPv4 in use) was able to register itself to the controllers and I was able to launch the application from the IPv6 VDA.

 

However our end users come via one-way external trust from another Active Directory domain. Their domain controllers are not running IPv6. When I tried to launch the IPv6 application with the external domain credentials I got the following error:

 

"The specified domain does not exist or could not be contacted"

 

So in order to get this to work I think they would need to setup IPv6.

 

BUT, I configured the VDA's to use both IPv4 and IPv6 and even though Citrix says this does not work, it actually does work. The VDA's register themselves to the controllers via IPv4, but also receive IPv6-addresses from DHCPv6, and our end users are able to access both IPv4 and IPv6 addresses via Apps and Desktops.

 

So basically I think I could have just setup the DHCPv6 to assign the clients IPv6-addresses without the need to setup IPv6-addresses to the other components.

 

Here's the official response from Citrix when I asked if I can run both IPv4 and IPv6 on same VDA:

 

Quote

With regards to your query, you can enable either IPV4 or IPV6, not both. If your environment contains both IPv4 and IPv6 networks, you will need separate Delivery Group configurations for the IPv4-only clients and for the clients who can access the IPv6 network. Consider using naming, manual Active Directory group assignment, or Smart Access filters to differentiate users.

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...