Jump to content
Welcome to our new Citrix community!

Assistance in creating the correct policy


Joseph Strauch

Recommended Posts

We have an application that talks to 3 backend servers.  These servers need to handle traffic for 3 different URLs that talk to each other.   So we have backend server 1 (BES1) backend server 2 (BES2) and backend server 3 (BES3)  that I have in a service group.  These 3 servers handle traffic for URL-1 , URL-2, and URL-3 that are all linked together.  So the end user comes into the application initially on URL-1 and then gets redirected to URL-2.  At URL-2 the user is prompted to log into the application and then gets redirected to URL-3.  URL-3 needs to get the auth token that the users got when logging in and validate it so the user can continue into the next part of the application.  

 

The issue I am having is this doesn't work.  The first URL and second URL part work but when the user logs in at URL-2 and is redirected to URL-3 the auth token never makes it to URL-3 and so it just sits there.  Again URL-1, 2 and 3 all reside on the same servers just on different ports so how do I get this to work.  

 

Currently I have 3 separate VIPs created with VIP one listening for URL-1, VIP two listening for URL-2 and VIP three listening for URL-3.  We're working with the application developer and when the application is configured to use the assigned URL it doesn't work.  However when the application is configured to use the server IP address and proper port that each URL is assigned to (i.e URL-1 is port 80, URL-2 is port 5060, URL-3 is port 18057) everything works as expected.  I tried to explain to the app team and developer that using the server IP address and port assignment should work because all the traffic is staying inside the network, however when we use the URL the traffic actually goes out and comes back in, and goes to the next VIP.  

 

So my question is, is there a way to write a policy that would allow us to use only 1 VIP and when it needs to send the user to the next URL do so without having to go out and come back in to the next URL?

 

I uploaded a picture that shows the layout of this setup, hope that helps with the explanation.

 

I hope this makes sense and thanks for any assistance.

URL-BES-Layout.PNG

Link to comment
Share on other sites

Looking at your question from afar, it looks like this is rather an application issue when the user is redirected from URL-2 to URL-3.

Best shot at trying to figure out what is happening, is taking a trace on the ADC, while also monitoring the request/responses in your browser developer tools.

 

There has to be a reason why the user doesn't get the authentication token from URL-2 when being redirected to URL-3.

My first guess would be, is that the token is never sent with the redirect (maybe because of a changing domain, which doesn't really matter when connecting directly to an IP address).

 

 

 

Just to be sure, you are not using AAA are you?

Link to comment
Share on other sites

Jan, the application has an authentication broker that it's using.  That is what provides the token in URL-2 and tries to send it to URL-3 when the user is redirected.  The backend servers are the ones hosting this authentication broker.  I hope that answers your question about AAA and I'll do your suggestion about the trace and see what happens.  We used the developer tools in the web browser and that's how we're seeing that the auth token is never sent.  

Link to comment
Share on other sites

Is this a Web-Application? Maybe you can use a single Content Switching vServer pointing to three non adressable Load Balancing vServer.

 

Use a Listen Policy to get the Content Switching vServer to listen on the needed Ports:

image.thumb.png.33e8aacbc11633144a8a26644f661eb3.png

Expression: CLIENT.TCP.DSTPORT.EQ(8080)||CLIENT.TCP.DSTPORT.EQ(8077)||CLIENT.TCP.DSTPORT.EQ(18057)

 

Then create one Content Switching Policy for each URL pointing to the right Load Balancing vServer:

image.thumb.png.ef0c75bf607a5262feb7e4635bb696aa.png

Expression: HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ("myapp.mydomain.com")

Maybe you need to add the ports here aswell: HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ("myapp.mydomain.com:8080")

image.png.aa578f993877d7a0f25c6b76693ac6e5.png

 

image.png.d04b2c3dfd6f5e7a38f0c0af7018f6a7.png

 

Maybe this helps because only one IP is used for the Content Switching vServer.

 

Link to comment
Share on other sites

In my opinion, changing to a CS vserver with a listen policy won't really change much at this point.

 

If you've used the developer tools in the browser and found the authentication token is never sent to URL-3, there's where the issue is.

If you can confirm the token is received from URL-2 before going to URL-3, there must be a limitation on the cookie in the browser that it doesn't accept URL-3.

 

Might it be possible that the authentication token (stored in a cookie) is limited to the FQDN of URL-2, and not just the domain part? Or that there is some other restriction imposed?

Link to comment
Share on other sites

Guys, thanks for the answers.  The application works and the auth token is passed when we set the application to use the server IP Address and port # representing the URL but doesn't work when we use the URL.  So the token passes but I guess what I need to find is when it's using the URL instead of the IP Address and port is it hanging on the fact that maybe another server is now being sent the request and possibly when using IPs instead the developers are using the same BES all the time.  I'll look into that as well.

 

Thanks Again

Link to comment
Share on other sites

Sounds like the auth cookie is set/bound to the IP like Jan already mentioned:

On 2/1/2021 at 10:08 AM, Jan Tytgat said:

Might it be possible that the authentication token (stored in a cookie) is limited to the FQDN of URL-2, and not just the domain part? Or that there is some other restriction imposed?

 

If using IP the 3 servers have the same cookie domain which is the IP.

if using url you have 3 different FQDNs resulting in an cookie only valid for one url.

 

are you using 3 different URLs or only one with different ports?

 

If it is not possible to get the developers to fix it, you need to add a workaround.

Maybe you can use only one URL with different ports. Or use one URL with different path url/app1 url/app2 ... Or rewrite the cookie domain.

Link to comment
Share on other sites

  • 3 weeks later...

Sorry for the delay in getting back out here, we've been trying to work with the application developers on the issues.  So yes we have 3 different URLs for this application.  We have no persistence on the VIPs as the application supposedly isn't able to handle that or something, the app developers said make sure not to have any persistence set.  

 

So what we still see is that the client request comes in on URL #1 gets told it needs authentication so it is sent to URL#2 for authentication and then when coming back from URL#2 to URL#1 the HTTPS request is getting converted from HTTPS to HTTP.  

 

Now the communication from the VIP to the backend server is not configured to use HTTPS it's using HTTP which is what we were to use so I'm not 100% sure if this is the issue or what.  The application's code it dynamically learned and done for this 1 button's click event and we see an error stating that the application expected HTTPS and was given HTTP.   

 

We did try using a single IP and then a Content switching VIP but that didn't work either.

Link to comment
Share on other sites

So the backend sends a response after authentication that redirects the user to url1 using HTTP but you only have a SSL based LB ?

Than you can rewrite the response from http to https or you can add an additional LB listening on Port 80 for HTTP.

 

But if possible try to change the full communication to SSL so that the backend hopefully will send an HTTPS response because it receives a HTTPS request.

 

13 hours ago, Joseph Strauch said:

We did try using a single IP and then a Content switching VIP but that didn't work either.

 

Sounds like policy misconfiguration or something :-(

 

Link to comment
Share on other sites

  • 2 months later...

Sorry for getting back to this after a while but I wanted to update so that in case someone else has this issue, this might assist them. So the issue wound up being with the application and I have to create a few rewrite policies adding an X-FORWARD-FOR HTTP Header and applying them to the VIP in order for this to work.  So though it took a while to figure it all out, that is what finally worked for us in this case.

 

There were 2 Citrix articles used dealing with the X-FORWARDED-FOR HTTP Header, sorry I didn't write down their CTX KB#.   However if you look up X-FORWARDED-FOR INSERT or REPLACE you probably will find them.  I did it thru the command line as it seemed to work easier, the GUI had issues for some reason.

 

Hope this helps anyone else out there dealing with this issue.

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...