Rhonda Rowland1709152125

October 25, 2023

If your authentication policy involves a login schema that isn't present on the system, then the next save config will forget the dependency.

Is your snapshot a disk capture or a memory state capture? Is it possible it was a memory state, but you failed to save changes prior to reboot?

Be sure your config is in fact saved prior to reboot. And do a diff of the saved/running config to look for changes. But if possible compare the file state for missing dependent files.

Login Schemas go to /nsconfig/loginschema

Check syslog/nslog for possible error indicators.

Is this appliance in an ha pair and is in fact a secondary member being overwritten by a primary in a different state?

October 25, 2023

What cookie version is configured on your NetScaler: v0 or v1? Check under System > Global Settings, HTTP Parameters (right pane). If v0, change to v1 (possibly a clock difference between test client and ADC; v1 should switch to relative timestamps).

And check your clock date/time/timezone on the NetScaler.

In addition to your storefront timeout, if you are load balancing storefront, what is the cookie persistence timeout? Make it match your session timeout (cookie persistence is 2 min by defaul).

Make sure caching is disabled on ADC while you test.

October 20, 2023

I saw it was the easy answer and I'm glad that was the fix you needed. That's why I mentioned the other things, in case it was something else. But glad you got it fixed regardless. ?

October 20, 2023

I'm going to add some info to what Carl said in case you are treating two separate issues as one issue regarding storefront load balancing. So is your issue the load balancing or the gateway/storefront handoff specifically?

So, for the load balancing, you can test that as an "internal" user without the gateway to make sure it works by point to the storefront fqdn associated to the lb vserver and the store path. LBMethod: LeastConnections, Persistence: Usually SourceIP.

As Carl, pointed out, if you are also using the Gateway to proxy the StoreFront traffic, on the storefront config for the "gateway" integration, you do not use the SNIP, but the GAteway VIP otherwise storefront can't tell the difference between internal users hitting the storefront vip directly (non-gateway users) and the users being proxied gateway to storefront lb vip to storefront as the SNIP is the same in both cases.

If your internal users work against storefront directly, then your load balancing is good.

If your users connecting through gateway is not working, then the issue is on the gateway side.

Also note Gateway sends a probe to the "storefront fqdn" configured in the session policy. And if it can't resolve that name to an IP or otherwise send an outbound probe from the system at all (due to no appropriate snip to reach the storefront vip) then the gateway appliance won't attempt the handoff to storefront for the gateway connections. So post gateway login you get an unavailable service or no destination. You will see this error on the gateway in nslog (not syslog).

October 18, 2023

Sorry for the cs vserver policy hits, the only way I can think to reset the policy hits is to bind and unbind the policy.

IF you have a large number of poicies; using a policy label and bind/unbind it to the vserver might be faster and allow you to preserve your policy priorities within the label. I didn't test this.

Finally, a reboot clears this.

I wish I knew of another way to do this.

October 12, 2023

How are you doing the upgrade? cli, gui, or via adm

What did you mean by communication error on AD?

October 12, 2023

The feature is called Callhome on the Netscaler and is related to the Customer Experience Improvement Program (CEIP).

Usually after upgrade to a build, you'll get the first prompt to disable. Later, you can turn it off/on via the callhome feature of the NetScaler. (It defaults to ON).

https://support.citrix.com/article/CTX231092/netscaler-call-home (describes it and links to other articles.)

In the feature list (advanced feaures in GUI): callhome

cli: disable ns feature callhome

September 20, 2023

To see your stats/policy hits in cli:

show cs vserver <vserver name>

And you will see policy hits and the default destination hits for a given cs vserver.

To clear stats:

Go to Traffic Management > CS VServer > Statistics and see if you can clear stats that way. This should just clear the cs vserver stats and not other vservers. Don't check global or that is all stats on system.

Other methods: You could save and reboot your adc which would clear policy hits Or unbind/rebind the policies to clear stats. (this would not be ideal...I know).

September 20, 2023

Sorry, haven't been on the forums and was delayed responding.

If you have a vserver on VIP1 (192.168.10.10):80 then you can't create a separate vserver also using the same VIP:Port: 192.168.10.10:80.

Same thing happens with the "sidecar".

You can create two vservers on the same VIP but different ports:

a) add lb vserver lb_vsrv_demo1 http 192.168.10.10 80 ...

b) add lb vserver lb_vsrv_demo2 ssl 192.168.10.10 443 ...

This is fine for the scenario (a) and (b) in the second example.

But if you go back to (b) lb_vsrv_demo2 and try to assign the sidecar for port 80, you are effectively trying to create a "hidden" listener (like a vserver) on the VIP:80 that is now in conflict with the existing HTTP:80 vserver (a) lb_vsrv_demo1.

c) set lb vserver lb_vsrv_demo2 -httpredirectport 80 -httpredirecturl "https://192.168.10.10"

You will get the same message that a "vserver" already exists on that ip/port.

Or the opposite problem, if you created the port 80 sidecar on lb_vsrV_demo2 first and you later tried to create a separate a) lb_vsrv_demo1 on the same vip and port 80, it would say 80 is already in use, and you would have to figure out where. Does that make more sense?

September 2, 2023

On 8/31/2023 at 5:16 AM, Davide Bono said:

Would this policy block also https:\\demo.domain.com/Home/Admin and other subdirectories ? I need to block requests to */Admin and this is the expression I am trying to use

HTTP.REQ.URL.PATH.GET(1).SET_TEXT_MODE(IGNORECASE).EQ("admin")

No. It will not block URLS with format: https://<fqdn>/<other>/Admin

http.req.url.path matches: /<other>/Admin

http.req.url.path.get(1) matches the first path element: <other>

http.req.url.path.get(2) matches the second path element: Admin

First, do you want to block path "/<anything>/Admin"

Or are you trying to account for varying FQDNs: https://<fqdn>/Admin/<otherstuff>

Which would affect the path.get(#) options.

Example 1:

Create a responder policy to drop/reset/ or redirect traffic based on expression:

http.req.url.path.get(2).set_text_mode(ignorecase).eq("Admin")

You can combine with or without FQDN depending on if you bind globally or per vserver.

Other variants, could be to use regex based on expressions.

Alternate example 2:

If you want to block any reference to an Admin directory anywhere in URL path, without worrying about whether it is first or second,

you could also try:

http.req.url.path.set_text_mode(ignorecase).contains("/Admin")

For this example, you may in fact want the leading slash "/".

July 28, 2023

John - yeah, you saw it was the notexists that was the problem.

July 28, 2023

Jens, great job. And let me just say what an incredibly annoying bug to have introduced.

July 28, 2023

A couple of things to consider:

1) Which ADC Firmware?

2) Is this a WEB app or some other protocol (in case other considerations apply).

Next, for something that could affect all Mac but not win/mobile and SSL based, its possibly cert related:

1) either the ssl ciphers in use on the ADC compared to your previous proxy is supporting something the MAC doesn't like or not supporting something required.

2) the cert authority who signed your cert, may not be trusted or be built into the MAC OS, but is in the Win/Android. This may also come down to version of Mac.

Also, clock or sync issues. Cookie type handling (if web again).

If it is a web app, see if different browsers on the Mac (as in not safari have different behaviors). So now is it mac vs. windows or safari vs other browsers.

Is this content that doesn't want to do ssl termination and expected ssl bridge instead? (or end to end ssl) Without know which app/protocol involves its hard to say if this is related. I doubt it but mentioning it.

Trace from the client to the netscaler to see if you have other information.

July 20, 2023

Also, I'm going to apologize for misreading this. I completely missed where you said it was not working AFTER UPGRADE. Implying it was working before (so no misconfiguration issue); and then it stopped after upgrade. I would check to see if your log actions had any classic engine dependencies in them (or advanced syntax that might have deprecated in a few cases).

In which case, recreating the log action may fix the issue.

However, if it worked before upgrade and doesn't work now; it might be a bug and need a support case. Apologies for missing that key point in your post.

July 20, 2023

1) log action must be set in responder/rewrite and the log action must not say "log to nslog" which would put action in /var/nslog/newnslog instead of /var/log/ns.log (syslog).

2) Custom Log Actions must be enabled in the system audit policies, or any syslog audit policy set to log externally.

July 20, 2023

Which firmware?

Are you creating expression in GUI or CLI.

And can you confirm your named expressions are actually "advanced" named expressions?

Swap in maybe something like:

!(http.req.url.path.contains("/demo") || http.req.header("host").contains("somefqdn"))

If it doesn't take this either in the GUI, then it might be a gui bug.

IF this works in GUI, but your named expressions don't, then share your named expression definitions as they may be incorrect?

If this is in the cli, quotes are needed around expressions and there are other things to compare.

July 10, 2023

Originally posted in Citrix tech zone at docs.citrix.com, it moved to the NetScaler docs site here: https://community.netscaler.com/s/article/protect-gateway-waf-bot-aaa

There is a complex but limited WAF integration option for Gateway that includes bot and iprep protection.

Requires specific builds of 12.1 and 13.0 or later to implement. The hardware model isn't really the problem, the trick is your license edition and if it includes appfw/iprep/bot protection features along with gateway or not. And ADC/NS Premium license will likely include these components. Standard/Advanced may not. Gateway only licenses would not.

July 10, 2023

On the StoreFront, when you configure the Gateway definition, there is a point where it asks you for a SNIp, VIP or other, then you need to tell SToreFront what the GATEWAY VPN VSERVER VIP is. VIP is needed instead of SNIP in case you are using your NetScaler to load balance StoreFront too. So look at your vpn vserver (or cs vserver if using unified gateway) and specify the VIP you assigned to your Gateway vserver in this field on the SToreFront when definining the Gateway configuration. StoreFront has to know about Gateway.

The STA is specified on the Gateway, but must point to the CVAD controller acting as the STA. StoreFront must have the same STA listed.

Usually you don't want a single point of failure for SToreFront xml brokers (cvad controller list) or the SToreFront list/Gateway list of STA's (also cvad controllers).

The trustxmlbrokers setting IS NOT needed on the controllers unless you are using smartaccess (gateway passthrough of policies to cvad) or certain advanced authentication methods. It won't necessarily hurt; but its not the reason for your issue either.

July 9, 2023

Note: This is more about CVAD policies than anything else.

1) How to prevent executable file upload through Citrix Workspace for HTML5 in Citrix?

Answer: you can't granularly stop types of files over the file redirection virtual channel. Whether this is HTML5 or native client.

The CVAD session policies can enable/disable file redirection and the types of drives mapped or not mapped. But none of the policies can filter types of traffic.

For native workspace app: You can enable filed redirection (read/write), make it read only client drives (read from client drives into session; but not write out to local client drives), or disable file redirection so no access read or write to client drives are possible in session - session drives only.

For HTML5/ChromeOS clients, you can enable file transfer (on by default), or individually manage upload from client to session, or download to client from session.

However, nothing allows you to limit types of content.

Bottom line: File Redirection and File Transfer policies allow you to enable/disable the virtual channel but NOT control the content within that channel. Firewalls or Antivirus within the vdi would need to screen the "redirected" locations to prevent content you don't want in the new location. Or some other OS/vdi level security would have to limit what you bring in over the virtual channel. The virtual channel itself doesn't have a filter mechanism for this.

File Redirection/File Transfer Policies: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/policies/reference/ica-policy-settings/file-redirection-policy-settings.html

2) Citrix ADC/Gateway cannot filter types of files. Its Smart Control settings can only override available virtual channels and take them away. But it also cannot filter the types of content within the virtual channel.

3) The Web App Firewall also doesn't help here, as the WAF feature protects web content which means web pages like the StoreFront page. The HTML5 client isn't a "web application" in the sense of a web page. And its still an ICA client connection managed like other Workspace Apps/ ICA Proxy connections, so the App Firewall doesnt' apply to the ICA connection piece.

By default WAF doesn't integrate directly with the Gateway, though there is an article on integrating WAF with Gateway to add some features to the "Web" portal parts of the Gateway. Its also not going to filter the internals of a virtual channel.

July 8, 2023

On 7/3/2023 at 4:19 PM, Scott said:

Having issues getting storefront to open when authenticating externally via citrix gateway.
I know the authentication attempt itself is doing something because it recognizes the difference between a good and bad password.
Internal access to storefront works without issue.
When attempting to access externally the page rapidly comes to:
Please log on The server met an error. Please try again or contact your administrator

I've attempted recreation of session policy and profile.
I've also setup a max timeout within these as well.
I've enabled clientless access, set the plug-in type, enabled sso to web-applications, set default authorization action to allow, and attempted a couple of different possibilities for Web Interface Address in the Published Applications tab of the profile.

Any assistance would be appreciated. If any particular logs are needed just let me know.

First, which version of Gateway firmware and StoreFront are you using?

So, there's too little details to really troubleshoot the exact issue. But we can go over the essential requirements for Gateway/StoreFront config to help you narrow it down.

Assumptions:

you have one store on StoreFront for both internal and external integration (with and without gateway).
Your gateway is primarily in ICA Proxy only mode.
You have separate FQDNs for Gateway vs. StoreFront access.

On the Gateway,

Gateway FQDN (gateway.demo.com) resolves to Gateway vpn vserver VIP (via public dns). And you have a trusted cert associated.
Authentication policiees (advanced engine?) are bound for your LDAP/AD requirements. If doing more complicated authentication, explain.
You have a session policy/profile defined with the following essential settings (If you used the gateway wizard, you may have two policies for OS/Receiver connections and WB/web browser connections):
- Published Apps Tab: ICA Proxy: ON
- StoreFront Address set to the Store name's web address and StoreFront fqdn (example): https://storefront.demo.com/Citrix/Store-1Web
- SSON Domain: <domain> (Example: demo)
- Under Security tab: Authorization:Allow (needs to be set for all connections, unless you need granular authorizations to restrict who connects where).
- Under <second tab>: Clientless access alone does not support ICA Proxy. The default settings for clientless/vpn client type should be fine. The Passthrough authentication to web should be enabled. But depending on your use of advanced authentication policies (or more complicated authentication scenarios), you might also need a Traffic policy for SSO as well. More than likely the settings you have here are correct, but the first 4 bullet points are the essentials.
Configure the List of STA's and validate the gateway can communicate. STAs must be listed individually and match same STA's in use on StoreFront; cannot point to a lb name on the Gateway.
There are several things to confirm on the communication requirements, which I'll go over after the storefront config summary.

On the StoreFront:

Store Prereqs (confirm store works for internal use, which you already have)
- Create a store.
- Bind a cert.
- Set list of Controllers for XML requests and rest of your settings.
Update Store for gateway authentication. Include explicit and passthrough from gateway on the Store's Authentication methods. Web site will also have gateway integration enabled.
Create Gateway definition:
- Set Gateway display name
- Set Gateway FQDN which matches the name users use to get to Gateway: https://gateway.demo.com
- Set source ip of Gateway to Gateway VIP (not SNIP)
- Set list of STA's: controllers and ports. Make sure list matches what you've configured on Gateway itself.
- Set Callback address. If not using certain advanced features, callback can be blank. If a callback is needed and the storefront can a) resolve gateway fqdn to vip and b) reach the gateway fqdn for communication, the set the callback address to same a Gateway FQDN: https://gateway.demo.com. If previous is not true, and a callback is required, then additional steps are needed to configure callback.
Associate Gateway to Store by configuring Remote Access. For ICA Proxy only, use the first radio button. Once Gateway integration is enabled.
Propagate config changes to all members of StoreFront server group.

Troubleshooting configuration:

Summary of events:
- User authentication to gateway.
  - If authe on gateway fails, authe stops and you get an authentication error and you still see the Gateway FQDN with gateway paths listed (Anything other than /Citrix/<StoreNameWeb>).
- After authentication, authorization is confirmed. Session policy or authorization policy must be applied to AAA user or AAA group or set via session policy against the vpn vserver to allow communication. Deny messages may look like gateway succeeds, but you have no access to a connection through the gateway. Syslog will show deny authorization events. (Unlikely this is the problem)
- NetScaler runs an internal probe to confirm the storefront is accessible and IF IT DOESN'T THINK it is, gateway doesn't attempt the ICA Proxy result.
  - This can result in "choices" mode, where the user only sees the options to connect VPN or Clientless. No ICA Proxy option.
  - In choiceless/ICA Proxy only mode, gateway displays a white page and doesn't attempt the passthrough to StoreFront at all.
  - You likely won't see the /Citrix/<Storename> in the path, and still see the Gateway <paths> at this point.
  - I'll add notes on investigating this issue below.
- One the user is authentication and authorized, the gateway forwards the request to the SToreFront Store. if authentication fails here, then you will see the following:
  - URL in browser will show https://gateway.demo.com/Citrix/<storeNameWeb> meaning the gateway was fine with handoff and the error is at SToreFront side.
  - Check storeFront event logs under the Applications > Citrix Delivery Service for more specific details. Might still be an issue with the Gateway authentication policy or sson handoff but the gateway tried to send you to StoreFront, so start with StoreFront events first. Then go back to Gateway syslog.

Investigating if Gateway is failing its storefront probe:

Gateway does an internal probe to the <storefront fqdn> to see if the name resolves to an IP and if the IP is reachable. Even if this IP is a VIP owned by the NetScaler, the NetScaler treats it as an external probe so SNIP must be available for the probe to leave to reach the storefront VIP. If the Gateway cannot do a dns resolution of the storefront fqdn to the vip (hosted locally or not) this can also fail.
- This event is also not seen in syslog, but in nslog.

shell

cd /var/nslog

nsconmsg -K newnslog -d event

nsconmsg -K newnslog -d consmsg

Should be in the "event" log, and look for monitor probe results pointing the <storefront fqdn> you listed in your session policy.

To troubleshoot, Gateway issues with authentication/authorization or other config issues, view syslog:

shell

cd /var/log

tail -f ns.log | grep -v CMD_EXEC

more ns.log | grep -v CMD_EXEC

This will show all events as they occur minus the audited commands as gateway events can include: AAA, TCP, VPN events.

If you get as far as launch requests, storefront issues and sta redemption issues will also show up in syslog.

Final thing if you've checked all the gateway and storefront configs is to run a trace to see where in the process you are.

But issue sounds like session policy isn't actually configured for ICA Proxy, sso handoff issue that might require a traffic policy too, or the storefront probe issue on gateway.

July 6, 2023

Intranet IPs are a range of IPs that you allocate to the vpn vserver so that you can allow each vpn connection a unique backend IP instead of using the usual SNIP for all clients.

The IPs in the intranet IP range must be valid on the network segment the netscaler uses to reach backend resources, unique on the network and not otherwise in conflict with other ip address sources. Be sure they do not conflict with your already assigned SNIPs and NSIP address in use.

Most times the vpn connections can source all traffic using the same SNIP and intranet IPs are not needed.

If using the Gateway to access Citrix VDI's via ICA Proxy, then intranet IPS are not used and the SNIP is required.

User's must be in full vpn mode to use an intranet IP; no supported in either ica proxy or clientless mode.

You mentioned that you are connecting the VPN client from within a virtual machine. Is this a test environment or are you using the vpn within a vm or vdi scenario?

In general, the steps to configure the intranet IPs:

1) Create and allocate a valid subnet range of IPs to use as the intranet IPs. Again, should be valid for the NetScaler to use to for NetScaler to backend communication with enough IPs for each vpn client to consume (on a concurrent basis). Ranges can be allocated per vpn vserver, vpn global, aaa group. Or individual IPs assigned per aaa user (but this is more work and only needed if you require a specific ip per client).

- Verify the subnet does not overlap with your NSIP, SNIPs, or any VIPs alreadys in use on the NetScaler.

2) Create a session policy/profile that enables Intranet IPs:ON and determine if spillover is allowed or not. Should be the Network tab (first tab in the session profile). Spillover:ON allows the SNIP (even though it says MIP) to b used if no more Intranet IPs available. Spillover:OFF disables spillover. If more sessions than you have IPS, they will be denied. If Intranet IPs is off, then ips won't be allocated. Bind session policy to the vpn vserver.

June 28, 2023

If you create the system backup on appliance1, you can download from appliance and extract as a .zip (.tar) can't remember. If password protected you will need the password to extract.

Then you can copy the subfodlers from /nsconfig/<stuff> to /nsconfig/ of the new appliance

Copy the folders from /var/<stuff> to their respective /var/<subfolders>

You can be selective depending on your config.

Once files are copied to the test adc (and again, must not be in conflict or otherwise online as this will duplicate names/ips/etc...), you can reboot the appliance and review your settings.

Otherwise, you have to scrape your config as batch commands (manually) to run as cli commands on new system, but can be done more selectively.

If you care comparing a vpx to vpx, this works well. If you are moving from hardware to virtual, then networking interfaces and other details may be affected. Any setting not recognized is ingored an not applied, so you may end up with dependencies that aren't present.

June 24, 2023

How long did you observe the traffic, once it fell back to roundrobin to determine it wasn't returning to leastconnection?

And are your services going through changes in state and going from UP to DOWN and back again multiple times?

Least connection fallsback to round robin by default for the next: (# of services * 100 requests)* # of PPE. If you have 2 services, the next 200 lb decisions not covered by persistence will be handled round robin, which will distribute across the 2 services and then it should exit to least connection afterwords. # of PPE is number of packet processing engines, which may be more than 1 if you more than one packet processing CPU allocated (for vms or number of cores for physical). So it might go longer.

However, each time the VSERVER changes state, or a service goes from down to UP, it will go back to roundrobin. It will still achieve distribution and avoid certain "blackhole" issues.

Also, if your connections are imbalanced, are your users connecting to the lb vserver for horizon directly? or Are the users connecting from the Gateway, so all the users are coming from the one gateway source instead? Did session connect while a service was down, so all the existing users will reaming on the working service, until persistence expires and new lb decisions need to be made.

June 24, 2023

If you are using the backup made from the system backup command (or in the GUI under system backup) that particular backup can only be imported/restored on the ADC appliance that made it. It can't be used as a "restore from backup" to bring a new system up to a given state.

You can extract the backup, and restore the individual files to the new ADC. Be aware that you will create ip conflicts so be sure your test adc is fully isolated from the network.

June 24, 2023

Your original description is that you wanted to change the HOST portion only, but the actual example changes host AND path elements.

Also, remember, if you are using REWRITE on a REQUEST to change the HOST it only changes the host portion as it leaves the ADC to the backend server and will not result in a new destination other than the lb services attached to the lb vserver. If the user needs to go from old host to new host, then it should be a RESPONDER redirect instead of a REWRITE - which is likely NEEDED for the http:// to https:// portion in your example. If this is a rewrite to change links in response body, then the responder may not be needed.

Once we figure out the URL modification, I'll give you some examples, and then you can figure out if you need Responder only, Rewrite only, or a responder redirect for host with a separate rewrite for path. Depending on the problem you really need to solve.

Also, if you are using URL TRANSFORM and not just REWRITE then I'll note that below as well. (It was unclear in your description, but your policy detail seems to imply URL TRANSFORM in use). You can't use backreferences in a regular rewrite action like that; but in a URL TRansform you would be able to reference a pattern in one field in another.

----

For this specific examples:

From OLD URL: http://example:9080/forms/anon/org/app/b006aa54-1737-43c9-8a03-a2cb0be9113c/launch/index.html?form=F_StudyLeave&id=6c29a26d-960d-4b88-8803-a664d723a312

Into NEW URL: https://newexample.fqdn.com/apps/secure/org/app/secure/org/app/b006aa54-1737-43c9-8a03-a2cb0be9113c/launch/index.html?form=F_StudyLeave&id=6c29a26d-960d-4b88-8803-a664d723a312

NOTE: if I misinterpreted your public (OLD URL)/private (NEW URL), we can switch these. Just figured I'd give you something to work with. Again, the exact scenario was vague enough I didn't want to guess.

Generalized, you need:

From OLD URL: http://<oldfqdn1>/<path1>/<rest of orig path> into https://<newfqdn2>/<path2>/<rest of orig path>

Though you could aslo resule the "/org/app" as the start of the new path after "secure"... I'll base it off of this.

So, remember, http.req.url doesn't usually see the entire URL with host portion. It only sees the target of the GET or POST which is usually /<path and query>.

Host and protocols aren't usually exposed here. So a rewrite targeting http.req.url may not be able to modify your host or protocol. You can use a trace or a proxy between adc and server to see what the rewrite actually generates request time.

In reality, I think you either need a Responder redirect to go from http://<oldfqdn1:9080> to https://<newfqdn2> and the path changes OR a Responder to redirect the host portion, and the rewrite to handle the path changes after the initial redirect. It depends on if you want the users to see the path changes or not.

So I'm going to mock this up as a RESPONDER redirect first, and then maybe a Responder Redirect followed by a REWRITE for paths.

Example 1: Responder only (complete redirect of all URL changes in response to the original request). Also hardcoded path changes based on url examples.

RESPONDER Action: REDIRECT

Value (for gui): "https://newexample.fqdn.com" + "/apps/secure/org/app/secure/org/app" + http.req.url.path_and_query.after_str("/forms/anon/org/app")

RESPONDER Policy: (bound to a vserver that is listening to the http://<oldfqdn:9080> ip/port>

Expression: http.req.header("host").set_text_mode(ignorecase).eq("example:9080") && http.req.url.path.set_text_mode(ignorecase).startswith("/forms/anon/org/app")

CLI for reference:

add responder action rs_act_redirecturl1 redirect "\"https://newexample.fqdn.com\" + \"/apps/secure/org/app/secure/org/app\" + http.REQ.URL.PATH_AND_QUERY.AFTER_STR(\"/forms/anon/org/app\")" -responseStatusCode 302
add responder policy rs_pol_redirecturl1 "http.REQ.HEADER(\"host\").SET_TEXT_MODE(ignorecase).EQ(\"example:9080\") && http.REQ.URL.PATH.SET_TEXT_MODE(ignorecase).STARTSWITH(\"/forms/anon/org/app\")" rs_act_redirecturl1

Example 2: URL TRANSFORM Example (since I saw your backreference attempt):

URL Transform Action:

REQUEST URL From: (http://example:9080)(/forms/anon/org/app)(.*)

REQUEST URL Into: https://newexample.fqdn.com/apps/secure/org/app/secure/org/app$3

RESPONSE URL From: (https://newexample.fqdn.com)(/apps/secure/org/app/secure/org/app)(.*)

RESPONSE URL Into: http://example:9080/forms/anon/org/app$3

CLI version:

add transform action urlt1 urlt_rewriteurlsecure 10
set transform action urlt1 -priority 10 -reqUrlFrom "/demo" -reqUrlInto "/demo2" -resUrlFrom "/demo2" -resUrlInto "/demo1"

If you really did mean REWRITE or RESPONDER + REWRITE instead of URL TRANSFORM post back, and I can try to rework it. But hopefully these two examples help you figure out what you need.

Forums

Articles

Labs

Videos

TechZone

Citrix Community Articles

Events

Profiles

Posts posted by Rhonda Rowland1709152125