Citrix Web Interface and Natted Address, in the Citrix Web Interface forum on BrianMadden.com
Brian Madden Logo
Your independent source for desktop virtualization, consumerization, and enterprise mobility management.

Citrix Web Interface and Natted Address, in the Citrix Web Interface forum on BrianMadden.com

rated by 0 users
Answered (Verified) This post has 1 verified answer | 17 Replies | 3 Followers

Not Ranked
Points 285
PTDPTD posted on Thu, May 7 2009 12:14 PM

Hi
we have users coming in over a firewall from another site to hit

our internal web interface servers.

they can login in using the natted address of 192.168.244.110

( http://WI/citrix/TEST) internal is 172.22.240.24

they can login ok but when they try and fire up an application they get the error message "cannot connect to presentation server, there is no citrix presentation server configured on the specified address.

They only need to get to 1 server CTXSRV001 172.22.240.10  

I have set this up with altaddr of 192.168.244.89 on the WI
DMZ = Alternative   with Address translation  172.22.240.10  149 to 192.168.244.89 1494


The web interface has 3 different access platforms.  These users will only connect to this test site the other 2 sites work fine and point to same data collectors as this does.

I am convinced the Web Interface is set up correctly but would any pointers.
the network traffice on port 1494 iis inbound only, I think this should be in both directions..??????? along with port 8080 for xml???


i got the ports open of firewall to be able to ping and pinged the following

Natted address of IP 192.168.244.110 ( http://WI/citrix/TEST) - worked fine

internal address of Citrix PS server - 172.22.240.10- expired in transit
alt addr of Citrix PS server - 192.168.244.89 -  timed out


below is ICA file from their desk...

[Encoding]
InputEncoding=UTF8

[WFClient]
CPMAllowed=On
ClientName=WI_CBXLdNBvKATSbcHCO
ProxyFavorIEConnectionSetting=Yes
ProxyTimeout=30000
ProxyType=Auto
ProxyUseFQDN=Off
RemoveICAFile=yes
TransparentKeyPassthrough=Local
TransportReconnectEnabled=On
VSLAllowed=On
Version=2
VirtualCOMPortEmulation=Off

[ApplicationServers]
Notepad - Test=

[Notepad - Test]
Address=192.168.244.89:1494
AudioBandwidthLimit=2
AutologonAllowed=ON
BrowserProtocol=HTTPonTCP
CGPAddress=*:2598
ClearPassword=26634CF40503F0
ClientAudio=On
DesiredColor=8
DesiredHRES=1024
DesiredVRES=768
DoNotUseDefaultCSL=On
Domain=\CABE1AF434C713A1
InitialProgram=#Notepad - Test
LPWD=16
Launcher=WI
LocHttpBrowserAddress=!
LogonTicket=26634CF40503F0CABE1AF434C713A1
LogonTicketType=CTXS1
LongCommandLine=
NRWD=16
ProxyTimeout=30000
ProxyType=Auto
SSLEnable=Off
SessionsharingKey=2119128539
StartIFDCD=1241694142315
StartSCD=1241694142315
TRWD=0
TWIMode=On
TransportDriver=TCP/IP
UILocale=en
WinStationDriver=ICA 3.0

[Compress]
DriverNameWin16=pdcompw.dll
DriverNameWin32=pdcompn.dll

[EncRC5-0]
DriverNameWin16=pdc0w.dll
DriverNameWin32=pdc0n.dll

[EncRC5-128]
DriverNameWin16=pdc128w.dll
DriverNameWin32=pdc128n.dll

[EncRC5-40]
DriverNameWin16=pdc40w.dll
DriverNameWin32=pdc40n.dll

[EncRC5-56]
DriverNameWin16=pdc56w.dll
DriverNameWin32=pdc56n.dll

any help/advice would be fantastic  thankss
  • | Post Points: 35

Answered (Verified) Verified Answer

Top 10 Contributor
Points 24,605
Verified by PTDPTD

Yes, the second (non-default) entry in the DMZ settings access methods table would be for source IPs falling within your VPN subnet.

Alan Osborne

President (MCSE, CCNA, VCP, CCA)

VCIT Consulting - Citrix/Terminal Services Remote Desktop Solutions for SMB

VCIT website My Blog

  • | Post Points: 40

All Replies

Top 10 Contributor
Points 48,811

It sounds like a routing problem.  You've got the WI and the PS server's ALTADDR configured for the same subnet. Can you ping the PS server from th WI server?

Why is it called "Common Sense"? It doesn't seem all that common!

  • Post Points: 20
Top 10 Contributor
Points 24,605

I agree. Alternate addressing is handy when you need just a static one-to-one NAT between a public IP on the WAN interface of your firewall and a LAN IP of a single XenApp server. WI address translation is more flexible and accomodates situations where you have a public WAN IP, plus you have users connecting over a VPN or NATted through a DMZ.

Having said that, you might want to look at implementing CSG or a CAG.

Alan Osborne

President (MCSE, CCNA, VCP, CCA)

VCIT Consulting - Citrix/Terminal Services Remote Desktop Solutions for SMB

VCIT website My Blog

  • | Post Points: 5
Not Ranked
Points 285

The firewall performs the NAT.  The WI is used for other locations to use the back end so that all works fine.  It just when the users come through this particular firewall.

 

I can ping the PS servers form the Web Interface no problem.

I have changed the DMZ settings to translated on web interface and left the same  configuration and they still get the same error messgae...

We cant put a CAG or CSG there as the site is treated as "internal"

On the address trnaslations do i just need to put 1494 for the address or 8080 (XML port too) ??

Does the firewall need port 1494 open in BOTH directions??

 

 

 

  • | Post Points: 35
Top 10 Contributor
Points 48,811

You don't need 1494 open in both directions.  if the firewall is doing its job properly, once a request to establish a connection via 1494 comes IN, it should automatically allow whatever port is used to return the connection back OUT.

Why is it called "Common Sense"? It doesn't seem all that common!

  • | Post Points: 5
Top 10 Contributor
Points 24,605

The firewall NATs the packet headers, but it isn't able to NAT the IP address of the target XenApp server that's embedded within the ICA file (generated by the WI). That's why you need to ensure that your WI settings are correct with regards to alternate/translated addressing.

Visit your WI portal from the site that's having problems using Firefox and save the launch.ica file. Open up the launch.ica file in Notepad and review the embedded addresses within it.

Given your situation, you likely need two translation tables in the WI - one to handle the NAT that occurs between the WAN interface of the firewall and the LAN interface and another to handle the NAT that occurs between the interface connected to the problem network and your LAN interface.

 

Alan Osborne

President (MCSE, CCNA, VCP, CCA)

VCIT Consulting - Citrix/Terminal Services Remote Desktop Solutions for SMB

VCIT website My Blog

  • | Post Points: 20
Not Ranked
Points 285

Dan, Alan

Thanks for your help so far

I have removed the altaddr from the server and have set the DMZ setting in the WI site to Alternative

The clients come from 10.45.0.0 /255.255.248.0 to the firewall, they enter http:\\192.168.244.110\Citrix\test, login is fine.

The internal address of server CTXSRV001 172.22.240.10 

In the Address Translations table do I need to enter the following

internal ip - 172.22.240.10 1494 to External IP 192.168.244.110: 1494 (XenApp Server to Firewall)

internal ip - 192.168.244.110: 1494 to External IP 10.45.0.0 1494  (firewall to Public interface)

 

I am getting a little confused so bear with me..

 

 

  • | Post Points: 20
Top 10 Contributor
Points 24,605

In the WI under Manage secure client access -> Edit DMZ settings, you actually want your default access method to be Translated.

The address translation table entries you proposed should be both set to "Client route translation". The translation you proposed for "XenApp Server to Firewall" looks good, the one for "firewall to Public interface" doesn't for two reasons - you've specified a whole subnet for the external IP (10.45.0.0 isn't valid for a single IP) and your using a 10.0.0.0 address range that falls within the private address space.

You need to explain your topology better, specifically how the clients connect in. My current understanding is that you have external users coming in across the Internet and hitting your WAN interface. For the users, your translation table entry would be Internal IP address: 172.22.240.10, Internal port: 1494, External address: ip_of_firewall_WAN_interface External port: 1494

Where else are users coming from?

 

Alan Osborne

President (MCSE, CCNA, VCP, CCA)

VCIT Consulting - Citrix/Terminal Services Remote Desktop Solutions for SMB

VCIT website My Blog

  • | Post Points: 20
Not Ranked
Points 285
PTDPTD replied on Tue, May 12 2009 2:41 PM

Hi alan

The clients come over a VPN to the firewall, which performs the NAT to the 192.168.22.x addresses.  These are the only user who will use this Access Platform, (there are other sites configured on WI but all used for internal use thus avoiding the firewall.

There are the only clients accessing over this firewall.

 

I have removed altaddr from the server so it just uses its internal ip of 172.22.240.10.  ??

I have configured it as client route translation

I am just waiting to get the external IP of the firewall beofre adding that in.

Once I've got that I will try tomorrow, (wed)and come back to you

 

I didn't realise I would need two entries in the table...

 

 

  • | Post Points: 20
Top 10 Contributor
Points 24,605

Hi,

Your use case is a little more clear now, I think :-)

  • Back-end XenApp uses LAN address 172.22.240.110 - please confirm
  • WI server uses LAN address 172.22.240.24 - please confirm
  • LAN users (172.22.240.0 subnet) are connecting to a dedicated "LAN" WI instance on the WI server (172.22.240.24) and everything works
  • VPN users (192.168.244.0 subnet) are connecting to a dedicated "VPN" WI instance (NATted address of 192.168.244.110 - please confirm) and can login; however, applications do not launch
  • There are no users that need to connect across the Internet to the outside interface of the firewall (as would be typical if CSG or a CAG was used)

If your firewall is handling the NAT translation for VPN users (assuming the firewall is the VPN endpoint), then you only need one entry in the address translation table for your "VPN" WI instance:

- Client route translation

- Internal IP address: 172.22.240.89, internal port: 1494

- External IP address: 192.168.244.89, external port: 1494

Essentially, this would be a repeat of the NAT translation rule you should already have in place on your firewall.

I think you were entering the internal and external IP addresses of the WI server - you need to use the LAN subnet address and VPN subnet address of the XenApp server instead. Remember, the point of this entry is so that the WI will edit the IP addresses embedded within the ICA file it generates (which your firewall can't do).

To be honest, I think you would be better off using CSG instead of an IPSEC VPN client connection.

Alan Osborne

President (MCSE, CCNA, VCP, CCA)

VCIT Consulting - Citrix/Terminal Services Remote Desktop Solutions for SMB

VCIT website My Blog

  • | Post Points: 20
Not Ranked
Points 285
PTDPTD replied on Wed, May 13 2009 2:36 PM

alan

 

That worked a treat once I got the firewall team to open up 1494....

 

Users can connect without any problems. 

One last question, if i wanted this web site to be shared with other users (Internal Users who will access direct)

 

Do I, set  DMZ to Direct (default)

 

then add in Alternative..  what do i need to specify here??

 

 

  • | Post Points: 20
Top 10 Contributor
Points 24,605

Hi,

Having port 1494 open on the firewall definitely helps Wink

To use a single WI instance, you would set the default access method in the DMZ settings to Direct, then add a second entry to the client address table specifying your VPN subnet and setting the access method to translated. Then, you would add the appropriate translations previously discussed into the address translation table (Manage secure client access -> Edit address translations).

 

Alan Osborne

President (MCSE, CCNA, VCP, CCA)

VCIT Consulting - Citrix/Terminal Services Remote Desktop Solutions for SMB

VCIT website My Blog

  • | Post Points: 35
Not Ranked
Points 285
PTDPTD replied on Thu, May 14 2009 3:20 PM

BlSmileSmiledy networks, had told me it was open until i got someone to telnet ...

 

The VPN subnet being the 192.168.244 address ??

  • | Post Points: 20
Top 10 Contributor
Points 24,605
Verified by PTDPTD

Yes, the second (non-default) entry in the DMZ settings access methods table would be for source IPs falling within your VPN subnet.

Alan Osborne

President (MCSE, CCNA, VCP, CCA)

VCIT Consulting - Citrix/Terminal Services Remote Desktop Solutions for SMB

VCIT website My Blog

  • | Post Points: 40
Not Ranked
Points 25

Wow great timing. I was having the exact same issue. I knew what the problem was, just not where to fix it. Your information was spot on!  Thanks very much.

--Jason

  • | Post Points: 5
Page 1 of 2 (17 items) 1 2 Next > | RSS