Jump to content
Welcome to our new Citrix community!

Responder/Rewriter cannot operate on TCP Load Balancer?


ALEX SOKHIN

Recommended Posts

Hello all,

I attempted to manipulate TCP payload by creating a rewrite/respond policies and binding them to a TCP load balancer. This should be supported according to 

https://docs.citrix.com/en-us/citrix-adc/12-1/appexpert/responder.html

 

"Responder supports protocols such as TCP, DNS (UDP), and HTTP. With responder enabled on your appliance, server responses are based on who sends the request, where it comes from, and other criteria with security and system management implications. The feature is simple and quick to use."

 

However, despite the successfully bound policy I didn't see any hits even when the policy had "true" as a condition. Now is the interesting part. Support now tells me that the doc is wrong and neither Responder nor Rewriter can operate with TCP Load balancer.  From the case notes:

 

"The behavior is expected. Responder and Rewrite are application layer features. They do support apps that relay on TCP and UDP layer 4 protocols, hence the options to use them in the expression field, i.e. CLIENT.TCP.DSTPORT.EQ(445).
However, making a TCP LB vServer directs the ADC to ignore app-layer traffic hence these Resp n Rw features will not take place. If you bind the same responder policy to an HTTP LB vServer, for example, it will work.
The documentation -https://docs.citrix.com/en-us/citrix-adc/current-release/appexpert/responder.html - is not clear enough and leaves room for the confusion.
We are submitting feedback on the page to get this updated accordingly."

 

If this is true, I don't understand how nobody caught it since it goes way back. Also, I cannot think of any other means to manipulate traffic for a TCP load balancer if responder and rewriter constructs cannot be used. This seems to be a very far reaching. What's your experience on this?

Link to comment
Share on other sites

The product HAS in fact supported HTTP/TCP/SIP/DNS rewrite policies for several versions depending on which criteria you are looking at or rewriting.  We've done header rewrites for TCP and DNS traffic for a while now.

 

For RESPONDER, traffic originally was HTTP Responder (redirect, custom response, custom import response) and SQL Responder for (MySql/MSSql)  datastream functions.

We now do some DNS responder policies. (We have tcp/dns rewrite and dns responder labs on 13.0 build to prove it in the courseware)

 

What type of responder policy or rewrite policy were you trying to perform on TCP traffic?

For example:  responder and rewrite should work based on TCP criteria on a TCP vserver, but not if you are trying to look at an http.req.url or http.req.header while on a TCP vserver.

 

Is it possible feature support changed - maybe?  But I would be confused by this too.

 

 

 

Link to comment
Share on other sites

Thank you Rhonda, 

I was attempting to use a policy to process SMB2 traffic. The issue was the policy didn't hit even when the expression was simply "true". That's when I opened a support case. The support engineer was surprised that the policy didn't trigger on True (and we tried it a few times and different expressions) and when he escalated I've got the response above that Reponder cannot be used with TCP Load balancer

Alex

Link to comment
Share on other sites

Okay, I know responder can respond (drop/reset/redirect/other) for HTTP/DNS and MYSQL/MSQL database traffic. 

It can likely drop/reset, but not redirect at the TCP level as that's not a redirect that we know.  SMB redirect would likely have to happen as a DSF (DFS?) redirect (in my uninformed opinion)

I *thought* we had more tcp responder capabilities, but I might have been thinking of rewrite at that point.

If you can bind the responder to a tcp object, then the drop/reset action might in fact work depending on criteria, but the redirect for smb is likely something responder doesn't know how to do.

 

I even thought TCP responder was a thing, but had to go back and think about what features TCP REWRITEs do and then realized TCP responder definitely might be limited.

 

 

 

Link to comment
Share on other sites

One of the the policy expressions I was using :

 

CLIENT.TCP.PAYLOAD(500).CONTAINS("string") 

 

and built-in Actions that I tried were NOOP, DROP. That didn;t work so we just tried a very simple policy with expression  "true" and one of those Actions.

Link to comment
Share on other sites

Responder is a limitation then that I wasn't previously aware of.  But is the underlying traffic packet even inspectable by the ADC.  client.ip.src will drop/reset (I believe) but client.tcp.payload may not be inspectable (due to protcol type or traffic behavior) and if result is undefined, the policy can't apply anyway is my guess.  So I think you did in fact find the responder limitation.

Link to comment
Share on other sites

Thank you for the insights Rhonda. If client.tcp.payload is not inspectable at the Responder level I'd think the expression should't be allowed in a policy? Or at least, there should be a reference in the docs? Otherwise, it's very hard to understand what would/wouldn't work. Anyway, do you think the rewriter can pick it up?

Link to comment
Share on other sites

What do you want your policy to do?  

And is the value a TCP Header or TCP packet payload / body content?  What we can see depends on feature and context.

 

Is the underlying SMB traffic actually encrypted so we can't see or interact anyway?

 

Every now and again the answer is the ADC shouldn't be the one doing this decision.

 

For example, if we wanted to rewrite a DNS response or insert a new flag, then DNS rewrite would do it.

For a basic TCP header change, TCP rewrite can do it.

For TCP request or response body changes...it depends.

 

Link to comment
Share on other sites

I want to drop/reset all SMB2 user requests going to a specific network share. So, basically ADC is configured with TCP LB with Windows network share on the backend and user's DNS points to the VIP. SMB2 traffic is not encrypted and I can easily pick up the netshare name when I use Evaluate in the policy, with tcp.payload expression against the actual traffic captured from the user to VIP.

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