Jump to content
Welcome to our new Citrix community!

Content switching with TCP Policy


Recommended Posts

Hey!

here the environment:

 

ADC ContentSwitching VServer: 10.10.10.10

DC1: 10.10.10.20 -- Domain: test.lab

DC2: 10.10.10.30 --Domain: test2.lab2

 

Goal:

Case A: Client A: 10.10.10.100 sends a ldap request to 10.10.10.10 with username cn=test1,dc=test,dc=lab

Case B: Client A: 10.10.10.100 sends a ldap request to 10.10.10.10 with username cn=test2,dc=test2,dc=lab2

 

Case A: ADC CS VS sends request to DC1

Case B: ADC CS VS send request to DC2

 

You could understand this like a multiple domain ldap dispatcher.

 

Problem:

I've created two LB for each LDAP server. Then I've created two CS policies with following expression:

 

Policy 1: CLIENT.TCP.PAYLOAD(70000).CONTAINS("dc=test,dc=lab") ---> Goto DC1

Policy 2: CLIENT.TCP.PAYLOAD(70000).CONTAINS("dc=test2,dc=test2") ----> Goto DC2

 

Policy 1 got a priority of 100, Policy 2 got 110

 

No default cs policy in the CS Server.

 

When i try to do a ldapwhoami from a unix machine with a userdn with dc=test,dc=lab, it works and i can see via nsconmsg -d current -g _hits the the first policy got hit.

When i try another attempt with userdn dc=test2,dc=lab2 it doesn't work, but i can see the hit in the console.

 

When i change the priority of the two Policy, the other on works. So it seems like only the first checked Policy can work, the second one not.

I'm thinking is has something todo with the basic funcionality of TCP und the bahavior of the ADC regarding answering TCP requests. 

 

I know it's a bit more specific problem, but maybe somebody sees the error. 

 

Best Regards

CS

 

 

Link to comment
Share on other sites

To confirm what you're saying, for your tests you only ever see the first policy bound first is the one hit regardless of whether content matches or not?

Do you have persistence for CS vserver enabled?  This is a new setting in 13.0 (maybe 12.1) and can cause some fun side effects if you don't know its on.  Can't remember if its under the CS vserver Basic settings or the Traffic Handling section.  Turn off the CS vserver persistence if its on (it can result in subsequent queries following previous cs decisions.)

https://docs.citrix.com/en-us/citrix-adc/current-release/content-switching/persistence-support.html (If sourceip, then after first cs decision is made, all traffic from same client is sent to same cs destination without re-evaluating policy match; which could result in your first priority policy bound when testing from the same client but different base dn.)

 

I know you are using test data, is there any chance that you have an overlap between your actual domain with your policy 1 and policy 2 test, so that the test case matches both criteria regardless of binding order so first match always wins?

In your expressions above:  Is your second policy supposed to be dc=test2,dc=lab2 to match your test case? as opposed to dc=test2,dc=test2 in the expression?

You move from 1&2 to 2&3 parameters in the 2nd policy example which might affect your match.

 

Also, reminder that contains is case sensitive, could that be affecting your comparisons between test cases (and not just the bind order)?

Do you have both the CS and LB feature enabled?

 

Finally is your TCP traffic TCP or TCP_SSL (encrypted)?

Are you going to be doing an authentication profile with the CS vserver?

---

If none of the above apply it may be something with the client.tcp.payload.  Depending on if the authentication is being done at the ADC via an authentication vserver, there might be other ways to extract this info.

 

We'll see if anyone else has an idea.

Link to comment
Share on other sites

12 hours ago, Rhonda Rowland1709152125 said:

To confirm what you're saying, for your tests you only ever see the first policy bound first is the one hit regardless of whether content matches or not?

Do you have persistence for CS vserver enabled?  This is a new setting in 13.0 (maybe 12.1) and can cause some fun side effects if you don't know its on.  Can't remember if its under the CS vserver Basic settings or the Traffic Handling section.  Turn off the CS vserver persistence if its on (it can result in subsequent queries following previous cs decisions.)

https://docs.citrix.com/en-us/citrix-adc/current-release/content-switching/persistence-support.html (If sourceip, then after first cs decision is made, all traffic from same client is sent to same cs destination without re-evaluating policy match; which could result in your first priority policy bound when testing from the same client but different base dn.)

 

I know you are using test data, is there any chance that you have an overlap between your actual domain with your policy 1 and policy 2 test, so that the test case matches both criteria regardless of binding order so first match always wins?

In your expressions above:  Is your second policy supposed to be dc=test2,dc=lab2 to match your test case? as opposed to dc=test2,dc=test2 in the expression?

You move from 1&2 to 2&3 parameters in the 2nd policy example which might affect your match.

 

Also, reminder that contains is case sensitive, could that be affecting your comparisons between test cases (and not just the bind order)?

Do you have both the CS and LB feature enabled?

 

Finally is your TCP traffic TCP or TCP_SSL (encrypted)?

Are you going to be doing an authentication profile with the CS vserver?

---

If none of the above apply it may be something with the client.tcp.payload.  Depending on if the authentication is being done at the ADC via an authentication vserver, there might be other ways to extract this info.

 

We'll see if anyone else has an idea.

 

The first policy hits if it matches the content, so the matching works, but only if the first one matches. 

So if the Expression CLIENT.TCP.PAYLOAD(70000).CONTAINS("dc=test,dc=lab") is the first one, I can send ldap request with test.lab to dc1

If the Expression CLIENT.TCP.PAYLOAD(70000).CONTAINS("dc=test2,dc=lab2") is the first one, I can send ldap request with test2.lab2 to dc2.

 

The Policies themselves lookes correct und are working.

 

PersistenceType is None in den the CS VS.

 

The TCP traffic is TCP, both on CS and LB

 

 

Link to comment
Share on other sites

2 hours ago, Christopher Stainczyk1709159901 said:

 

The first policy hits if it matches the content, so the matching works, but only if the first one matches. 

So if the Expression CLIENT.TCP.PAYLOAD(70000).CONTAINS("dc=test,dc=lab") is the first one, I can send ldap request with test.lab to dc1

If the Expression CLIENT.TCP.PAYLOAD(70000).CONTAINS("dc=test2,dc=lab2") is the first one, I can send ldap request with test2.lab2 to dc2.

 

The Policies themselves lookes correct und are working.

 

PersistenceType is None in den the CS VS.

 

The TCP traffic is TCP, both on CS and LB

 

 

I took a few screenshots for clarification.

 

good shows a working request, bad a bad request. As you can see the LDAP bind response is missing. 

 

CsPol shows the Binding Policies.

From the screenshots you can see that cs.home -Domain is working, test.lab is not working. If i put the testldap2 policy before the testldap policy, test.lab works and cs.home not. So the connection to the DCs works in general, it's just seems that ADC got a problem in the tcp settings or the settings of the CS-Srv

bad.PNG

good.PNG

CSPol.PNG

CS.PNG

Link to comment
Share on other sites

1) I would try doing the "trace filtered connections peer traffic" on the trace to catch both sides of the client to vserver and snip to service and back again.

 

2) What I'm thinking is that, you might actually need CS persistence.  My tenative guess is that only one of the parts of the transaction contains the bind dn and is content switched, and then after that the other requests don't match anything at all...

Without persistence set, do a single domain test:

This could be tested by doing a test to a single DC by having policy one be hit and then have the default destination send to dc.

Then send traffic for a single domain to the cs vserver and see how many transactions are based on the policy hit and then based on the default destination as unmatched.

 

If for a single domain test, you have some transaction that hit policy1 and others that hit the default destination, then not all related transactions meet your policy criteria.  As only certain requests contain the bind dn.

 

CS persistence may actually help as long as separate domain transactions come from different source ips.

You would have to do your whoami tests from separate test clients, if this is the case.

 

If the issue is in the policy expression then I'm not sure how to correct.  But it feels like the transaction consists of multiple request and the criteria you are using is only in one of the requests and not throughout the related transaction.

 

---

Otherwise, I'm not sure what you are trying to do is going to work.  I'd love to be wrong and have someone else correct me.

 

If you were doing a AAA authentication integration (for web, for example), then using some sort of AAA custom authentication page with domain drop down (or other mechanism) would trigger the appropriate authentication policy that hits Domain1 (lb vserver) vs Domain2 (lb vserver).  So CS wouldn't apply, but the respective authentication attempts would go to the correct domain.

 

How do you envision the the transaction lifecycle with CS?  An example of what you are trying to do may help as maybe there is a different way to do it.

 

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