Acrobat DC Licensing Issues when Connecting Through VPN

[bcmbadmin]

Hello Everyone,

This was cross-posted in the licensing forum, but so far no one has responded with any ideas, so trying to post this here as well...

We are running into an issue where random users are losing their Acrobat Pro DC licensing when they are connecting to the VPN through the office.

The connection for the VPN is split tunnel, so Internet traffic is not going through the VPN. Verified DNS services are able to resolve both lm.adobe.io and lm.licensing.adobe.com in and out of the VPN without an issue.

Is there a log file associated with the Creative Cloud app or the Acrobat Pro DC app which will point us to a reason for the licensing being removed?

Fixes that have worked, but are only temporary

1) Logging out and back into Creative Cloud/Acrobat Pro DC

2) Restarting the machine and then logging out and back into the Adobe products
3) Reinstall of the Adobe products

The issue does not happen to everyone, so far out of our 13 users only 6 have reported the problem; while all of them use the VPN on a daily basis.

Thank you!

[ls_rbls]

Is this happening in a virtualized environment?

What operating system are the Clients using?

What Adobe Acrobat version and licesning track is used ?

In any case, you must ensure that users are not using their roaming user account to sign-in in more than one device simultaneously (i.e. like the physical machine and a virtual host simultaneously) or they will get logged off and all the licensing removed.  

Is this happening in  a Named User Licensed environment or serialized?

NOTE: As far as the VPN is concerned if you have other users with the same exact settings, and they're all in the same router segment, I wouldn't pay too much attention to that yet until you can confirm what those other 6 users are doing.

[bcmbadmin]

Thank you for the quick reply,

The users are taking their laptops home from the office, no virtualized infrastructure used for the user environment. For roaming profiles only the users' documents and desktops are redirected, %appdata% is not. Operating system is a mix of Windows 10 1903 through 2004.

Licensing-wise, we are using Adobe Acrobat Pro DC, and whatever licensing is provided through the Adobe admin portal. Users sign into the application to license it.

As for the users with the VPN, they are using the VPN client to dial into the office network from home; tried both the SSL and IPSec dial-in VPNs offered by the firewall. Its a small mixed bag on when the licensing fails to update dynamically when connecting.

[ls_rbls]

Wow. This is as appealing and challenging as it is complex.

I would say to share some logs with Adobe directly so they can look into this.

Here's a direct download link  for the Adobe Creative Cloud Log Collector Tool:

• https://helpx.adobe.com/creative-cloud/kb/cc-log-collector.html

Follow the instructions in that link to collect the logs. 

[bcmbadmin]

Will have to run this tool and see what logs it gathers first before opening a ticket with Adobe; my hunch is there is an issue with DNS resolution for a few moments while connecting, and at that time the software activation is trying to update against lm.adobe.io or lm.license.adobe.com.

If something comes up from this investigation I'll respond here to keep you and the community up to date

[ls_rbls]

+++EDITED REPLY,  Fixed many typos

That is some very good observation right there.

Perhaps you may want to review the logs generated by the firewall/router. And use that information to test a few things out.

If you don't have access to the router you can still collect this information from the operating system firewall using the IN/OUT rules.

For example, you can set a rule just for  those two services to explicitly use  UDP only, OR,use both  UDP/TCP/IP instead of  of TCP/IP only. 

As you may know, UDP is a connectionless state protocol. It sends out the requested information out of  a computer without the three-way-handshake that otherwise would only be present when TCP/IP is employed. 

TCP/IP must always wait for acknowledgement from both of the communicating computers. It also handles error detection and correction when sending/receiving packets (not to mention the wait state and keep alive settings). So, with TCP/IP there's always some type of lag experienced regardless of successful or unsuccessful connections. UDP will never check for this and will not even report back.

In addition, I would also disable Automatic IPv6 from the DHCP settings in the network adapter card (at the client level), disable NetBIOS over TCP/IP, and also force the automatic DHCP to obtain IP addressing for  IPv4 adresses type only.

On the VPN's server side of the house, change the DNS to something faster like Google's public DNS "8.8.8.8" (not secured at all but is very fast)  or Cloudfare DNS "1.1.1.1" (highly secured DNS and very fast). Just for testing purposes, don't use your dedicated line ISP's DNS servers to compare speeds and connection behaviors. 

You may also want to  test these DNS configurations against DNS leaks since a great range of  Web browsers out in the market today doesn't care to disable the WebRTC protocol;  it is actually enabled by default.

When enabled, WebRTC will leak out all DNS queries and also reveal the reserved (private) internal IP address of a computer that is participating on a network.  Not proxifying the WebRTC protocol at the web browser level will leak that computer's internal IP addresses even through the most secured VPNs in the maret today...   I am 100% sure nobody that is in the right secured-networking mindset wouldn't want that.

See  more observations below and check if any of the suggestions work or improve the issue:

• In the case of a VPNs with split tunneling,  you can also use some of the same recommendations  above,  plus, you have to  make sure that the Adaptive LZO compression in both the server and the clients computer is disabled. 

• The splitted tunnel is already encrypted so there's no need to add the LZO compression to an already encrypted configuration. LZO adaptive compression is also phased out in most VPNs and deprecated. Using "default", "automatic", or "None" options are preferred.

• NOTE: Not disabling Adaptive LZO compression  is known to  cause more networking vulnerabilities than secured.

• You also may experience massive lags during the encryption/decryption processing of messages that are handled between the VPN server and the client computers.  It needs to be disable in both the server and the client(s). But if for any reason you need this to remain enabled on the server side, then you must ensure that the client computers also have the adaptive LZO compression enabled.

• In any case, I think the main problem here is that the client computers that need to sign in with their Acrobat is failing  because the currently split tunnel with that VPN is set to not allow Internet traffic.

• From your observation earlier, those computers need access to  both lm.adobe.io and lm.licensing.adobe.com; the split tunnel is obviously not allowing that type of access. This should be checked against the configurations of the clients that are experiencing the issue

• Additionally, the Acrobat version that was installed in the client computers may also conflict if a user decides to open up the Acrobat application and authenticate with (or activate with an AdobeID) in both of the desktops(or laptops) used at home while attempting to also activate Acrobat via the split-tunneled VPN.

I may be wrong in all of this, but it is worth considering all of these observations before you contact Adobe support. They may ask from you what troubleshooting steps have you tried. 

[juliep5774548]

I'm encountering the same issues as of 9/23/2020.  Very frustrating - not getting any resolution.

[susan gleason]

Working remotely, adobe pro is not downloading over company vpn.

[SLSadm2]

As of 11.16.2022 we are also finding this issue cropping up when our users are connecting to the VPN, but when onsite the issue doesn't occur. We found that disconnecting from the VPN, logging out and back in, then reconnecting fixed the issue. Not everyone is experiencing the problem but enough users that we're concerned it may escalate over time.

[Ruby35633421rj3y]

Same issue in 2024...