Hiwe 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.24they
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 WIDMZ = Alternative with Address translation 172.22.240.10 149 to 192.168.244.89 1494
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 followingNatted address of IP 192.168.244.110 ( http://WI/citrix/TEST) - worked fineinternal address of Citrix PS server - 172.22.240.10- expired in transitalt addr of Citrix PS server - 192.168.244.89 - timed out
Yes, the second (non-default) entry in the DMZ settings access methods table would be for source IPs falling within your VPN subnet.
President (MCSE, CCNA, VCP, CCA)
VCIT Consulting - Citrix/Terminal Services Remote Desktop Solutions for SMB
VCIT website My Blog
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!
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.
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.
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??
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.
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.
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..
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?
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...
Hi,Your use case is a little more clear now, I think :-)
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.
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??
Having port 1494 open on the firewall definitely helps
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).
Bldy networks, had told me it was open until i got someone to telnet ...
The VPN subnet being the 192.168.244 address ??
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.