-
-
-
Collect a Citrix Diagnostic Facility (CDF) Trace at System Startup
-
Virtual IP and virtual loopback
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Virtual IP and virtual loopback
Important:
- Windows 10 Enterprise multi-session doesn’t support Remote Desktop IP Virtualization (Virtual IP) and we don’t support Remote Desktop IP Virtualization or virtual loopback on Windows 10 Enterprise multi-session.
- Remote Desktop IP Virtualization (Virtual IP) isn’t supported on cloud-hosted machines. For more information, see Microsoft documentation.
Remote Desktop IP Virtualization and virtual loopback features are supported on Windows Server 2016, Windows Server 2019, and Windows Server 2022 machines. These features do not apply to Windows desktop OS machines.
The Microsoft Remote Desktop IP Virtualization address feature provides a published application with a unique dynamically assigned IP address for each session. With the Citrix virtual loopback feature, you can configure applications that depend on communications with localhost (127.0.0.1 by default) to use a unique virtual loopback address in the localhost range (127.*).
Certain applications, such as CRM and Computer Telephony Integration (CTI), use an IP address for addressing, licensing, identification, or other purposes that require a unique IP address or loopback address. Other applications might bind to a static port, so attempts to launch additional instances of an application in a multiuser environment fail because the port is in use. For such applications to function correctly in a Citrix Virtual Apps environment, a unique IP address is required for each device.
Remote Desktop IP Virtualization and virtual loopback are features independent of each other. You can use either or both.
Administrator action synopsis:
- To use Microsoft Remote Desktop IP Virtualization, enable and configure it on the Windows server. (Citrix policy settings aren’t needed.)
- To use Citrix virtual loopback, configure two settings in a Citrix policy.
Remote Desktop IP Virtualization (Virtual IP)
When Remote Desktop IP Virtualization is enabled and configured on the Windows server, each configured application running in a session appears to have a unique address. Users access these applications on a Citrix Virtual Apps server in the same way that they access any other published application. A process requires Remote Desktop IP Virtualization in either of the following cases:
- The process uses a hard-coded TCP port number
- The process uses Windows sockets and requires a unique IP address or a specified TCP port number
To determine if an application needs to use Remote Desktop IP Virtualization addresses:
- Obtain the TCPView tool from Microsoft. This tool lists all applications that bind specific IP addresses and ports. For more information on TCPView, see Microsoft documentation.
- Disable the Resolve IP Addresses feature so that you see the addresses instead of host names.
- Launch the application and use TCPView to see which IP addresses and ports the application opens and which process names are opening these ports.
- Configure any processes that open the IP address of the server, 0.0.0.0, or 127.0.0.1.
- To ensure that an application does not open the same IP address on a different port, launch another instance of the application.
How Microsoft Remote Desktop (RD) IP virtualization works
-
Virtual IP addressing must be enabled on the Microsoft server.
For example, in a Windows Server 2016 environment, from Server Manager, expand Remote Desktop Services > RD Session Host Connections to enable the RD IP Virtualization feature and configure the settings to dynamically assign IP addresses using the Dynamic Host Configuration Protocol (DHCP) server on a per-session or per-program basis. For more information on configuring Remote Desktop IP Virtualization, see Microsoft documentation.
-
After enabling the feature, at session startup, the server requests dynamically assigned IP addresses from the DHCP server.
-
The RD IP Virtualization feature assigns IP addresses to remote desktop connections per-session or per-program. If you assign IP addresses for multiple programs, they share a per-session IP address.
-
After an address is assigned to a session, the session uses the virtual address rather than the primary IP address for the system whenever the following calls are made:
bind¸closesocket¸connect
,WSAConnect
,WSAAccept
,getpeername
,getsockname
,sendto
,WSASendTo
,WSASocketW
,gethostbyaddr
,getnameinfo
,getaddrinfo
.
When using the Microsoft IP virtualization feature within the Remote Desktop session hosting configuration, applications are bound to specific IP addresses by inserting a “filter” component between the application and Winsock function calls. The application then sees only the correct IP address to use. Any attempt by the application to listen for TCP or UDP communications is bound to its allocated virtual IP address (or loopback address) automatically. Any originating connections opened by the application originate from the IP address bound to the application.
In functions that return an address (such as GetAddrInfo()
, which a Windows policy controls), if the local host IP address is requested, Remote Desktop IP Virtualization looks at the returned IP address and changes it to the Remote Desktop IP Virtualization address of the session. Applications that attempt to get the IP address of the local server through such name functions see only the unique Remote Desktop IP Virtualization address assigned to that session. This IP address is often used in subsequent socket calls, such as bind or connect. For more information about Windows policies, see RDS IP Virtualization in Windows Server.
Often, an application requests to bind to a port for listening on the address 0.0.0.0. When an application does this and uses a static port, you can’t launch more than one instance of the application. The Remote Desktop IP Virtualization address feature also looks for 0.0.0.0 in these call types. It changes the call to listen on the specific Remote Desktop IP Virtualization address, which enables more than one application to listen on the same port on the same computer because they’re all listening on different addresses. The call is changed only if it is in an ICA session and the Remote Desktop IP Virtualization address feature is enabled. For example, if two instances of an application running in different sessions both try to bind to all interfaces (0.0.0.0) and a specific port (such as 9000), they’re bound to VIPAddress1:9000 and VIPAddress2:9000 and there’s no conflict.
Virtual loopback
Enabling the Citrix Remote Desktop IP Virtualization loopback policy settings allows each session to have its own loopback address for communication. When an application uses the localhost address (default = 127.0.0.1) in a Winsock call, the virtual loopback feature simply replaces 127.0.0.1 with 127.X.X.X, where X.X.X is a representation of the session ID + 1. For example, a session ID of 7 is 127.0.0.8. In the unlikely event that the session ID exceeds the fourth octet (more than 255), the address rolls over to the next octet (127.0.1.0), to the maximum of 127.255.255.255.
A process requires virtual loopback in either of the following cases:
- The process uses the Windows socket loopback (localhost) address (127.0.0.1)
- The process uses a hard-coded TCP port number
Use the virtual loopback policy settings for applications that use a loopback address for interprocess communication. No additional configuration is required. Virtual loopback has no dependency on Virtual IP, so you do not have to configure the Microsoft server.
- Virtual IP loopback support. When enabled, this policy setting allows each session to have its own virtual loopback address. This setting is disabled by default. The feature applies only to applications specified with the Virtual IP virtual loopback programs list policy setting.
- Virtual IP virtual loopback programs list. This policy setting specifies the applications that use the virtual IP loopback feature. This setting applies only when the Virtual IP loopback support policy setting is enabled.
Related feature
You can use the following registry settings to ensure that virtual loopback is given preference over virtual IP. This feature is called preferred loopback. However, proceed with caution:
- Use preferred loopback only if both Virtual IP and virtual loopback are enabled. Otherwise, you might have unintended results.
- Editing the registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix can’t guarantee that problems resulting from the incorrect use of the Registry Editor can be solved. Use the Registry Editor at your own risk. Be sure to back up the registry before you edit it.
Run regedit on the servers where the applications reside.
- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\VIP
- Name: PreferLoopback, Type: REG_DWORD, Data: 1
- Name: PreferLoopbackProcesses, Type: REG_MULTI_SZ, Data: <list of processes>
Share
Share
In this article
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.