My org uses a "zero trust" connectivity product called "Zscaler".  It's effectively a replacement for the VPN we used to use for remote users.

Ever since Zscaler was implemented, there's been periodic connectivity issues with our D3 systems - they're disconnecting a client connection within milliseconds of accepting it.  Recently, this problem has become dramatically worse - to the point where it's affecting business operations.  People in billing aren't able to connect for hours at a time.

It occurred to me today that it might be a licensing problem on the D3 side.  All the problematic connections are being made via MVSP on port 9000.

Because of how Zscaler works, all the connections that travel over the Zscaler network are going to hit our servers from the same IP address.  I'm wondering if D3 isn't seeing that and will start denying connections from the same IP address after the connections reach a certain threshold.  Is this possible?

Right now the problem has descended to finger-pointing.  We're blaming Zscaler and Zscaler is blaming us, and the problem isn't getting solved.

Any suggestions on what solutions I can look at to solve this, or does it just boil down to too many inbound connections from the same IP address?

I should note that while this is happening, we're no where near out of available seats according to MAXUSERS.

Thanks!

g.

Hi Gene,

D3 will only deny connections if there isn't a user license available for the next incoming connection.  However, in Linux (I'm making the assumption that you're referring to a D3/Linux installation) the xinetd configuration can impact the number of incoming connections from a specific IP address.  Check out the /etc/xinetd.conf file and look for the 'per_source' entry.  I believe the default may be 10, not sure.  You can try bumping that up to a higher number or just setting it to UNLIMITED.  Another parameter to check is 'instances' which limits the number of instances of an xinetd-controlled service that can be running at any given time.

Best regards.

Chris, thanks for the suggestion!  the xinetd entry for MVSP already had instances at UNLIMITED, however there was no per_source entry.

xinetd.conf did in fact have per_source set to 10.  I changed that to UNLIMITED and forced a reload.  I let my people know about the update and to give it a shot to see if it works.

Fingers crossed!  (I'm so very glad that I'm spinning up v10.3.4 systems right now and xinetd isn't involved!)

g.