I had a need to connect mobile devices (ios/android) to an internal citrix web interface to provide citrix applications. However, our security policy did not allow direct layer 3 connections from personal devices, so a Junos Pulse connection and RDP client solution wasn't possible.
After working through a lot of options, we were able to use a pure SA proxy configuration to get this working for us. We are still tuning some of the session options, but I figured I'd post the configuration.
- get a certificate with a SAN host name that will be used by the rewrite proxy. Set up dns to point that host name to your SA. In my configuration I have sa.domain.com an citrix.domain.com as valid SAN dns names in the certificate.
- create dedicated sign-in page at www.domain.com/m
- create dedicated auth realm with a custom sign-in page for mobile devices (it
works with a standard sign in page, but an optimized page looks better)
- create mobile role
> specific UI options for mobile devices
> UI options includes changing the start page to be the internal citrix web client
page (this is so the users don't have to click on the bookmark)
> specific session options for mobile devices (timeouts, etc.)
- created mobile resource profile
> BASE URL = internal citrix web client site (mine is https://remoteaccessweb.internaldomain.com/
> Autopolicy SSO = remote SSO
>> Resource: https://remoteaccessweb.InternalDomain.com:443/Citrix/MetaFrame/auth/login.aspx
>> Post URL: https://remoteaccessweb.InternalDomain.com:443/Citrix/MetaFrame/auth/login.aspx
>> (note the Resource and Post URL will vary based on the version of the citrix web
client being used)
> add in 5 labels (these will vary based on Citrix web client version)
Username user <USER> Not modifiable
Password password <PASSWORD> Not modifiable
Domain domain APSC Not modifiable
LoginType LoginType Explicit Not modifiable
State state LOGIN Not modifiable
(note that we use <PASSWORD> because our one time token password is in the <PASSWORD> variable. If you use your AD domain as your first auth server in the auth realm, you should use <PASSWORD> here)
> Autopolicy Rewrite Options
> use virtual host name (This host name must be a unique host name pointing to the SA. I used a SAN certificate that includes this host name as a valid SSL host name, but I'm sure it would work with a dedicated IP address and certificate).
On client device:
- Citrix receiver | settings | accounts | + | Address: https://sa.yourdomain.com/m |
It wonÕt verify Ð choose manual setupÓ | description: mobile | web interface checked
Use citrix receiver to connect to the app that you set up above. You'll see your sign-in page from the SA. Sign in with your sign-in policies/auth servers. The SA will connect you directly to the internal citrix web client page (if you set the
start page to forward. If not, you'll get the bookmarks page and you can click on the link from the resource profile to get to the citrix web client)
This should allow you to connect through Citrix from mobile devices using the SA as a
rewrite proxy for the citrix web client page.
In our testing so far, connections all work directly from IOS. For Android we have to install firefox for android to make the connections open.
This is really interesting as we have the same issue.. Why use JunosPulse if it's not needed?
Anyway, I cannot get it to work according to your guide, I cannot launch any published applications in Citrix WI at all..
What version of Citrix WebInterface do you use?
I should have spelled out more caveats related to the citrix configuration ...
it only worked when using the old Citrix Secure Gateway (CSG). CSG isn't supported by citrix any more, so this has turned out to be not as good of an option as I had hoped.
When using a newer (supported) version of the citrix Web interface, we are able to make the proxy configuration work from windows (I think because there is a juniper client that loads in windows prior to executing the citrix connection). However, from ipad, it tries to connect to the internal address of the citrix server ... without CSG in the mix, it's not connecting.
So - I'm back to looking for alternatives because we don't want to maintain CSG without support.