Jump to content
Welcome to our new Citrix community!

Cisco ACE to ADC migration - ssl url rewrite location help...


Recommended Posts

Hi all,
I'm currently working on a Cisco ACE (!) to ADC migration and have come across an ACE configuration that I don't quite understand and cis.citrix.com can't cope with either.

It's a straightforward serverfarm configuration listening on 443 except for the ssl url rewrite location part:

action-list type modify http HTTP_MODIFY_ACTLIST
  ssl url rewrite location ".*\.name\.domain\.co\.uk"

ssl-proxy service SSL_PROXY_SERVICE
  key home.name.domain.co.uk.key
  cert home.name.domain.co.uk.crt

policy-map type loadbalance first-match VIP_LB_SERVERFARM
  class default-compression-exclusion-mime-type
    serverfarm SERVER_FARM
  class class-default
    serverfarm SERVER_FARM
    compress default-method gzip
    action HTTP_MODIFY_ACTLIST
  
  class SSL_SRV_HTTPS
    loadbalance vip inservice
    loadbalance policy VIP_LB_SERVERFARM
    loadbalance vip icmp-reply active
    ssl-proxy server SSL_PROXY_SERVICE

 

The behaviour of the ACE serverfarm is that the SSL connection will accept https://home.name.domain.co.uk, but it will also accept any other URL in the format http://<example>.name.domain.co.uk even though the certificate has no SAN and is not a wildcard.  (Normally I would expect multiple 'ssl url rewrite location' entries and to be associated with a creating a Content Switch on the ADC.)

 

Is anyone aware of a method of replicating the above on the ADC side, or is the url rewrite location wildcard a red-herring and it's all client side settings as to whether the SSL connection is successful and the certificate trusted or not?

 

Would appreciate any thoughts,
Thanks!

Link to comment
Share on other sites

The Name to IP mappings is handled by dns.

 

For the URL rewrites, what do you need to occur:

One, is this a redirect or rewrite?

If its just about name to IP mapping, make sure in DNS home.name.domain.co.uk and <other>.name.domain.co.uk are all mapped to the correct VIP.

The ADC won't care if users use one name or another, just use a wildcard or multisan cert to avoid trust issues.  As long as the DNS maps to the VIP, its at the ADC.

 

If users use different names to access the site and you then need to redirect based on the name in use, then we can use responder policies (for redirects from old name to new name) or rewrite policies to preserve the correct host name as needed.  Just need an idea of the scenarios to tell you what to implement.

Individual policies or a stringmap could account for multiple name behaviors.

https://home.name.domain.co.uk 

 

There's just not enough info in the above, to see what they are mapping <value>.name.domain.co.uk to to know whether you need responder or rewrite or how to do that part. 

 

Link to comment
Share on other sites

Hi Rhonda, thanks for the quick response.
Using an alternative certificate is currently out as the customer wants to use like-for-like, and the assumption is that if the ACE could do it (whatever it is), so can the ADC.  There is no owner of the ACE anymore to ask.

Apart from the backend servers and monitor that belong to the serverfarm 'SERVER_FARM', and the class match for a single IP address, the above is the entire ACE config.

(Single IP address bound as per):

class-map match-all SSL_SRV_HTTPS
  2 match virtual-address 192.168.1.1 tcp eq https

So, single certificate, 'home.name.domain.co.uk.crt' with no SAN entries.

DNS is set correctly, in that there are entries all pointing to the single IP 192.168.1.1 e.g:

  • home.name.domain.co.uk
  • home1.name.domain.co.uk
  • home2.name.domain.co.uk

User experience (using the ACE) is user is going to different webpages hosted by the backend serverfarm, E.g.:

  • home.name.domain.co.uk/authentication
  • home1.name.domain.co.uk/article
  • home2.name.domain.co.uk/menu

Users are NOT expected to deviate from that - e.g. they don't go to home2.name.domain.co.uk/authentication

 

I'm assuming the entry ssl url rewrite location ".*\.name\.domain\.co\.uk" on the ACE is enabling this to work with some default rewrite behaviour, but I don't know enough about the ACE command to be sure, and there is no-one left to ask...  

Link to comment
Share on other sites

First, I'm not an ACE expert, but I usually just google the syntax and then figure out what that means on the ADC the few times I've needed to convert between settings. Someone else may have a better idea and welcome to correct me. But from what I've seen, either we don't have a complete view of the config or what you are describing we think we need the ace to do isn't matching the config we can see. (But I did want to qualify my interpretation as I might be off.)

 

My recommendation, is that first you need to break this down into the client-to-LB transaction and the LB-to-server transaction.

And I have a feeling this is where we're not getting the complete view of the transaction and what this ace setting is in fact being described as doing.  

From what I can see, your ace is NOT rewriting URLs or paths, just headers.  

 

Comment on ACE config:

The HTTP_MODIFY_ACTLIST is just rewriting the location header (presumably in responses) to account for the domains. If the ACE is storing the first element of the host from the request and insert that in the response location header, then we would need a rewrite to do that based on the inbound hostname. If its just inserting the value .*.name.domain.co.uk as the location, then that is a simpler rewrite.

 

If there is more to the ace config than we see that may affect things, the SSL_PROXY_SERVICE section just binds the cert in use to the proxy.  But no indication if there is also an rserver redirect indicating an http to https redirect. Which would be a responder policy and need to redirect based on the different fqdns received (which is also doable).

 

To confirm though, you should do a network trace or a header trace and confirm what the the client to ACE / ACE to backend transactions look like to make sure what you think you want the ADC to do is meeting all requirements.

 

 

What else doesn't make sense in your scenario as described:

On 12/1/2021 at 6:19 AM, Stuart Griffiths1709161866 said:

The behaviour of the ACE serverfarm is that the SSL connection will accept https://home.name.domain.co.uk, but it will also accept any other URL in the format http://<example>.name.domain.co.uk even though the certificate has no SAN and is not a wildcard.  (Normally I would expect multiple 'ssl url rewrite location' entries and to be associated with a creating a Content Switch on the ADC.)

 

If a user makes a request to   https://<fqdn1>/<stuff> and you want that to be https://<fqdn1>/<stuff> from client-to-lb vserver AND still be the same on the backend https://<fqdn1>/<stuff> on the backend, then there is nothing else needed to be done, depending on what happens to links in the return response (based on which fqdn is used). This is why I think you're going to need the before ACE and after ACE traces to make sure you know what behavior we're trying to implement.

 

The Citrix ADC when load balancing does not care what name users use to get to the ADC (now users' may and we will get there.)

If you want multiple fqdns to be handle as alternate fqdns on the same vserver, and the server is going to return whatever name it gets in return responses (or if it just uses relative paths, then same end result), all you have to do is:

1) map the correct fqdns to vip in dns to ensure name resolution.

2) load balance normally.

 

If users connect to <fqdn2> or <fqdn3> and the backend serer is hardcoing full urls with <fqdn1> and you want to maintain the fqdn that user's originally used, then you would rewrite or url transforms.  But without knowing what exact "before" and "after" states are need its hard to give more guidance here.

 

Back to certs and the client-side request to the lb vserver (the part that doesn't make sense):

However, if you only have a cert issued to a single name (example: <fqdn1>) and not a wildcard OR multisan cert, then any https://<fqdn2> or https://<fqdn3) request will be seen as untrusted by the client as the name they use doesn't match the cert on the lb vserver.  And that's not a load balancer issue direclty; that's a name resolution and cert trust mechanic.

 

Even if we redirect users (already on https) from one fqdn to another, this will be AFTER the ssl handshake reports the cert as untrusted.

 

 

 

 

 

Link to comment
Share on other sites

7 hours ago, Stuart Griffiths1709161866 said:

So, single certificate, 'home.name.domain.co.uk.crt' with no SAN entries.

DNS is set correctly, in that there are entries all pointing to the single IP 192.168.1.1 e.g:

  • home.name.domain.co.uk
  • home1.name.domain.co.uk
  • home2.name.domain.co.uk

User experience (using the ACE) is user is going to different webpages hosted by the backend serverfarm, E.g.:

  • home.name.domain.co.uk/authentication
  • home1.name.domain.co.uk/article
  • home2.name.domain.co.uk/menu

Users are NOT expected to deviate from that - e.g. they don't go to home2.name.domain.co.uk/authentication

 

I'm assuming the entry ssl url rewrite location ".*\.name\.domain\.co\.uk" on the ACE is enabling this to work with some default rewrite behaviour, but I don't know enough about the ACE command to be sure, and there is no-one left to ask...  

 

Now that I re-read this piece (which I did miss), here are some additional thoughts:

Again, though having the users use different FQDN's to reach a single VIP still needs a multi-san cert OR a wildcard cert to avoid ssl issues during the ssl connection. (Assuming ssl)

If users make a request to http and you need to redirect them to the matching https name we can do that too (just not clear in scenario). 

 

If I can clarify the scenario:

Example 1:

User makes a request to:

http://home.name.domain.co.uk/<stuff> and you need the server to modify the URL with the appropriate path modifier:  http://home.name.domain.co.uk/authentication/<stuff>

And insert correct directories (first elements of path) for fqdn1 and fqdn3?

OR

Example 2:

the user is making the request they in fact need:

fqdn1:  http://home.name.domain.co.uk/authentication/<stuff>

fqdn2:  http://home1.name.domain.co.uk/article/<stuff>

fqdn3:  http://home.name.domain.co.uk/menu/<stuff>

 

In Example 2,

- if the traffic arriving at the load balancer has the name and path it needs on the backend, then there is nothing for the ADC to do to the request.

>> The only thing to validate if traffic is https (and not http:// as I used in the example), the cert has to match the name in use if you don't want cert/trust warnings.

- If the user makes a different request client side and it needs to match a specific fqdn/path format server side (without redirecting user), then a rewrite would be used.

- If the links in the response use a server-side fqdn that won't match what users use on the request, then again we might need rewrite or url transform.

- If the fqdn/path in use changes which servers are hit for load balancing, then this would need content switching.

 

But nothing in the ACE config you've shared indicates that regarding the names. The ADC can't solve the cert name issue; the cert has to do that. The only other things the ACE config is doing are header modifications, which the rewrite feature can do.

 

Hopefully that gives you some more info to work with.  I know its still not a complete answer, but I would use a trace of the client to ace and the ace to destination and see what else might be happening.

 

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