Jump to content
Welcome to our new Citrix community!

Listen Policy on VPN Virtual Server and cant enable DTLS to leverage from EDT protocol


Recommended Posts

What is your listen policy set to on this vserver? If it is set to TCP/SSL only it may prevent enabling DTLS.

 

DTLS cannot be enabled if the vpn vserver has the RDP Proxy or PCOIP settings enabled (under the vpn vservers basic settings).

Expand basic and then the "more" section to see if a listen policy is also present.  

If so, you may have to remove it or adjust it before you can enable DTLS (if the existing expression has a conflict).  I don't know off the top of my head if the issue is whether you can't use listen policy at all with DTLS OR if it is just a conflict with the existing listen policy in place.  

 

Also, after enabling DTLS on an existing vpn vserver that is already created, don't forget to unbind and rebind the ssl cert so it attaches to both the ssl and dtls listeners.

  • Like 1
Link to comment
Share on other sites

Thanks Johannes, Yes I disabled it and it works but I wanted to keep the listen policy. Basically with the listen policy, we didn't need another IP or port or DNS record for the extra Gateways. The user has on entry point and based on their IP, we could redirect them to another gateway that had a different authentication profile. 

Link to comment
Share on other sites

5 hours ago, Blair Muller said:

Thanks Johannes, Yes I disabled it and it works but I wanted to keep the listen policy. Basically with the listen policy, we didn't need another IP or port or DNS record for the extra Gateways. The user has on entry point and based on their IP, we could redirect them to another gateway that had a different authentication profile. 

 

I see. Maybe this could give you an idea how to solve the problem? I am always using n-factor with my deployments.

Link to comment
Share on other sites

But your listen policy isn't doing the redirect, its just restricting when this vip is accessible.... and its limiting your ability to do DTLS in this case.

Try unbinding the listen policy, enabling DTLS and see if you can attach the listen policy afterwards...

But if not, we'll have to move the "listen policy" decision to another feature to handle.

Link to comment
Share on other sites

On 5/4/2020 at 2:51 AM, Johannes Norz said:

 

I see. Maybe this could give you an idea how to solve the problem? I am always using n-factor with my deployments.

Thanks Johannes, I have looked at this method before. I actually like a solution that doesn't require the user to log in, then determine if they need a second authentication.  the solution I had working either showed them on or the other. (Single Factor or NFactor) 

Link to comment
Share on other sites

  • 1 year later...
11 hours ago, Sandy Williams said:

Hi Blair,  I think I've having the same issue as you.. was there ever a better resolution than not using a listen policy?

 

@sandy, I don't know if this option was available when this thread originally posted or not. I don't know if it will solve the problem (If you want to see if someone does have info; I would start a new thread, so you get more eyes on it and then link this thread) for additional reference.  

https://docs.citrix.com/en-us/citrix-gateway/current-release/configure-dtls-virtual-server-using-ssl-virtual-server.html#limitations

(See limitations as bottom of section as well)

 

Original Issue (to the best of my knowledge): user tried to use a listen policy with the vpn vserver; but the listen policy & dtls didn't seem to be supported.  The original listen policy was used to separate two different authentication requirements instead of using an nfactor config instead. (From the brief notes I had on the issue in the thread).

 

Sometime in the 13.0 release, Citrix add the ability to create a DTLS only vpn vserver instead of an ssl vpn vserver that does both ssl and dtls support.  I don't remember if this was available at the time of this post or just not relevant (if it was available.)

Therefore, you can now create a DTLS vserver on the same VIP:PORT (DTLS only) as your SSL vserver (VIP:PORT), but still manage them as separate entities.

Listen policies are still not supported on the DTLS vserver...but if you just need a separate vpn for SSL/TCP traffic separate from the DTLS traffic, might address your scenario.  

I looked briefly at a 13.0.67.x build (as what I had available.)

 

 

Link to comment
Share on other sites

@Rhonda Rowland

Thank you for your response.  I have my Gateway traffic first going through (two) Content Switching VIP's which have the listener policy on them.  Basically as you've described, one directs users to one Gateway VIP and stronger authentication policies while the other has whitelisted IP's for trusted sources.  I disabled the listener policy on them and it let me enable DTLS and verified UDP is working now.  I have a support ticket open with Citrix and was told this:

 

"Hi Sandy, how are you, as per product management team update, they told me this seems to be not tested yet and that they will need to introduce new code lines for future releases about this. I do apologize for the inconvinience here, as I mentioned yesterday , you can engage your citrix sales representative or account manager for a different solution."

 

I might be able to take Content Switching out of the equation and try your suggestion though but its preferable to have EDT available for all user connections.

 

The engineer told me verbally something interesting, that they've had problems with EDT and almost suggested I don't use it.  He said something about firewalls being flooded with traffic and engineering is working on these problems.
 

Link to comment
Share on other sites

FYI - i think the content in your question is unique enough to warrant its own thread for added visibility and to keep the community at large informed. And you might get more info (if you want to bother, of course) :)

 

I don't know why that limit exists except for the fact that they might be assuming the DTLS vpn vserver isn't really standalone and depends on the SSL version.  But you might be able to mitigate that if the AAA integration has the login limits instead of the vpn vserver (or if the login policy can do it instead) - i'm not sure of options here. But apparently the DTLS vpn vserver doesn't quite do everything the ssl vserver does.

 

Sorry, its not helping your scenario more.  I'll have to look at the login limits to see if there is a way to do that at the authe policy level instead of on the vpn vserver instead.

 

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