Jump to content
Welcome to our new Citrix community!

Migration problem with NGNIX Config to Netscaler ContentSwitch vServer


nlffel439

Recommended Posts

Hi guysI am currently migrating an offloading configuration from a NGNIX to a Netscaler.

 

I have built a CS_vServer that points to the appropriate backend depending on the directory.

Some pages are not easy to migrate because the NGNIX configuration uses "Proxy_set_Header" "X-Forwarded-Route /mypath/ and I don't know how to implement this on the Netscaler with a rewrite policy.

 

 

Example of the NGNIX Config:

 

 

location /mypath/ {
        proxy_set_header Host $host;
        proxy_set_header X-Ssl-Offloaded "on";
        proxy_set_header X-forwarded route "/mypath/";
        proxy_pass http://192.168.0.54/mypath/;
}

Example of the Netscaler Config:

 

add cs vserver www.myurl.com SSL 192.163.0.1 443 
add cs action mypath_CS-Action -targetLBVserver mypath
add cs policy mypath_CS-pol -rule "HTTP.REQ.URL.PATH_AND_QUERY.CONTAINS(\"/mypath\")" -action mypath_CS-Action

The rest of the backend configuration is simply LB Vserver without IP to backend on port 80

 

If I leave out this information, there is only "/" under "href" and the page is not loaded correctly (because CSS files are located in a subdirectory under "mypath", but here must be "href="/mypath".

 

 

Call via NGNIX (page loads correctly))

 

        <title>mypath</title>
        <base href="/mypath/">
        <meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
        <link href="/mypath/assets/css/app.css" media="all" rel="stylesheet" type="text/css"><link href="/mypath/assets/css/app.css" media="all" rel="stylesheet" type="text/css">
<link href="/mypath/assets/fonts/md-icons/material-icons.css" media="all" rel="stylesheet" type="text/css">
<link href="/mypath/assets/fonts/roboto/roboto.css" media="all" rel="stylesheet" type="text/css">
<link href="/mypath/assets/css/print.css" media="print" rel="stylesheet" type="text/css">        <script type="text/javascript" src="/mypath/assets/js/app.js">

 

Call via Netscaler (page is not loaded correctly)

        <title>mypath</title>
        <base href="/">
        <meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
        <link href="/assets/css/app.css" media="all" rel="stylesheet" type="text/css"><link href="/assets/css/app.css" media="all" rel="stylesheet" type="text/css">
<link href="/assets/fonts/md-icons/material-icons.css" media="all" rel="stylesheet" type="text/css">
<link href="/assets/fonts/roboto/roboto.css" media="all" rel="stylesheet" type="text/css">
<link href="/assets/css/print.css" media="print" rel="stylesheet" type="text/css">        <script type="text/javascript" src="/assets/js/app.js"></script>    </head>

It can be seen that the href does not contain the path information when loading via Netscaler.

 

Does anyone know what I am doing wrong or how I can get the configuration to work on the Netscaler?
Many greetings and many thanks 

Link to comment
Share on other sites

It looks like that because you are not passing your headers through then the "/mypath" isn't being included in the return responses so the objects are not being fetched from the correct path.

If the "/assets" stuff is going to vary per "/<path>", then you would need this to occur.

 

So, we just need to have the proper header inserts during the requests so the response contains the correct paths and then if needed you can adjust your cs policies.

 

For this:

location /mypath/ {        

    proxy_set_header     Host $host;        

    proxy_set_header X-Ssl-Offloaded "on";        

    proxy_set_header X-forwarded route "/mypath/";        

    proxy_pass http://192.168.0.54/mypath/; }

 

# NOTE: I'm not sure what your proxy_pass setting is doing in this example, so I've ignored it.

I'm also assuming the nginx is setting these in a request prior to generating a response.

 

rewrite policies to insert headers (be sure to bind with goto "next" for all to apply)

## more than likely your host header already exists from the request that matches user's fqdn of cs vserver

So, we shouldn't need to set the host header unless you are changing the host from the original request.

 

# insert x-ssl-offloaded header (assuming used by backend)

add rewrite action rw_act_inshdr_ssloffload insert_header "X-Ssl-Offloaded" '"on"'

add rewrite policy rw_pol_inshdr_ssloffload true rw_act_inshdr_ssloffload

 

# insert x-forwarded-route;  was there a missing "-" above? If not adjust

add rewrite action rw_act_inshdr_forwardroute insert_header "X-forwarded-route" '"/mypath/"'

add rewrite policy rw_pol_inshdr_forwardroute true rw_act_inshdr_ssloffload

 

You can bind these rewrites directly to your lb vserver "mypath" with the "true" expression so it applies to all requests. (Or we can omit for requests that don't require this header; more info would be needed).   I would recommend you rename you lb vserver to something like lb_vsrv_mypath so you can clearly search config for the vserver vs the policies referencing "mypath" as a string. But update as needed.

bind lb vserver lb_vsrv_mypath -policyName rw_pol_inshdr_ssloffload -priority 100 -gotoPriorityExpression NEXT -type REQUEST

bind lb vserver lb_vsrv_mypath -policyName rw_pol_inshdr_forwardroute -priority 110 -gotoPriorityExpression NEXT -type REQUEST

 

You still might need some tweaks to your  cs policy but this should insert the headers IF the backend uses those headers to compose the return paths.

If we need the ADC to do the response time rewrites that would be slightly different policy implementation.

 

  • Like 2
Link to comment
Share on other sites

  • 4 weeks later...

First of all, I apologize for not getting back to you until now, some unplanned things came up and I couldn't write back earlier.

 

In fact the problem could be solved by providing the header information via the "X-forwarded-route" Policy.

I have never heard of "X-Forwarded-Route" before this issue and have not found anything about it. 

 

Unfortunately, I have not been able to understand why this configuration was built on the NGNIX so at that time. 

Thanks Ronda, for your help :)  
 

 

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