Jump to content
Welcome to our new Citrix community!

Listener Policy \ Odd Behavior


Trey Wessel

Recommended Posts

Good Afternoon,

 

I've got a load-balanced VIP that is configured to allow all  protocols\ports.   I'd like to lock them down to exclude RDP TCP 3389 but still allow access to other services like NTP and DNS. Correct me if I'm wrong but that policy should look like the following.

 

CLIENT.TCP.DSTPORT.EQ(3389).NOT

 

As soon as I add that listener policy I cannot do a DNS lookup using my VIP or an NTP query. I've also tried to allow only the DNS and NTP ports via listener policy but the results are the same.   

 

Has anyone seen this behavior before?

 

 

 

 

 

 

Link to comment
Share on other sites

I have another VIP with a similar config that works correctly with its listener policy. The only difference I see is the working one uses LB VS Service bindings, the one that doesn't work uses a Service Group Binding.  I'll change it around and see what happens. Maybe I answered my own question. 

Link to comment
Share on other sites

Can you share your servicegroup vs service setting?  show ns runningconfig | grep <svcname|svcgname> -i 

Which protocol on the service/servicegroups did you use?

And are your memebers bound to the service group using port * or something else.

It might also be an issue on your lb vserver side, depending on if your vserver is HTTP:80, TCP:*, or other... your lb vserver may not be receiving the UDP traffic, despite your services allowing it. Just some thoughts.

 

If you created your entity with TCP:* and blocked access to TCP:3389, then other tcp ports should work. But your DNS/NTP are UDP based and would still be blocked.

If you created your entity with ANY:* and blocked access to TCP:3389, then it would likely work.

But you might be better off creating a  TCP:* based service/servicegroup with the listenerpolicy and a separate UDP:* based service or servicegroup so you can still do protocol specific handling.  Also, be careful with this kind of listen policy that allows everything but what you exclude. It could grant access to way more than you expected without the filters/controls if you were specifying the exact ip:ports to allow instead.

Link to comment
Share on other sites

15 minutes ago, Trey Wessel said:

I have another VIP with a similar config that works correctly with its listener policy. The only difference I see is the working one uses LB VS Service bindings, the one that doesn't work uses a Service Group Binding.  I'll change it around and see what happens. Maybe I answered my own question. 

 

 

No go on that one. 

Link to comment
Share on other sites

21 minutes ago, Rhonda Rowland1709152125 said:

Can you share your servicegroup vs service setting?  show ns runningconfig | grep <svcname|svcgname> -i 

Which protocol on the service/servicegroups did you use?

And are your memebers bound to the service group using port * or something else.

It might also be an issue on your lb vserver side, depending on if your vserver is HTTP:80, TCP:*, or other... your lb vserver may not be receiving the UDP traffic, despite your services allowing it. Just some thoughts.

 

If you created your entity with TCP:* and blocked access to TCP:3389, then other tcp ports should work. But your DNS/NTP are UDP based and would still be blocked.

If you created your entity with ANY:* and blocked access to TCP:3389, then it would likely work.

But you might be better off creating a  TCP:* based service/servicegroup with the listenerpolicy and a separate UDP:* based service or servicegroup so you can still do protocol specific handling.  Also, be careful with this kind of listen policy that allows everything but what you exclude. It could grant access to way more than you expected without the filters/controls if you were specifying the exact ip:ports to allow instead.

The VIP is ANY Protocol and * Ports. The Services and Service group (tried both) are configured the same. All services TCP \ UDP are working fine now, I know the traffic makes it all the way through, just curious why it's being finicky with this one VIP.  I was able to use the same listener policy on another VIP and it worked as intended.  

 

  I agree with only allowing what I need, This is just a first step, once we verify nothing else uses it we will lock it down.

 

I'll grab the config and post shortly. 

Link to comment
Share on other sites

Maybe its the destination on the backend that is the problem - not running the services you expect or a firewall blocking a port or unexpected acl?  The two vips should behave the same.

 

If you still can't figure it out and it works for one and not the other, then do the "standard" method and create protocol:port specific vips/services (and monitors if needed), so you can see if specific services are or aren't working on the destination. Or run a trace.  

That might let you see its not the NS but the backend.  That's my only  other thought.  Good luck.

Link to comment
Share on other sites

I found a solution.

 

Instead of having one defined VIP for ANY Protocol and ALL Ports I had to create three VIPS (TCP, UDP and DNS), apply the listener policies to limit what is available then bind the same servers to all three VIP with matching port and protocol info.

 

Don't feel like its the best method of doing this but it allows me to do what's needed at this time. 

 

image.thumb.png.059017ffe3af942a574c47ec51f94b87.png

  • Like 1
Link to comment
Share on other sites

5 hours ago, Trey Wessel said:

I found a solution.

 

Instead of having one defined VIP for ANY Protocol and ALL Ports I had to create three VIPS (TCP, UDP and DNS), apply the listener policies to limit what is available then bind the same servers to all three VIP with matching port and protocol info.

 

Don't feel like its the best method of doing this but it allows me to do what's needed at this time. 

 

image.thumb.png.059017ffe3af942a574c47ec51f94b87.png

 

I'm glad you found the solution. I know you said you don't think this is the best method of doing this, but I think you will be better off in the long run as the NetScaler is really limited in what features it can apply to a vserver/services of type ANY:* whereas when you have a specific vserver for TCP|UDP|DNS or even HTTP, you can still do app-specific features where needed. Such as app firewall/cmp/web-specific persistence on HTTP traffic; dns profiles/dns logging and/or tcp_dns handling for dns and tcp_dns vservers/services.

 

Good luck with the rest of your config.

 

 

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