All Topics » Pulse Desktop Clients



Pulse connections failing with error 1205 (Failed to setup virtual adapter)


djbnhft
Contributor (0)
Apr 21, 2016 8:51am
Summary. We have been advised to upgrade our MAG4610 from 8.0R4.1 (build 31475) to 8.1 R8.0 so that we can apply the new licenses we have purchased.

We were advised to update our clients first. We have been using 5.0.4.47117.
Clients are configured with two profiles:
– N3, which is a computer account based profile that connects using the AD Computer account when certain network conditions are met (i.e. on UK NHS N3 network)
- External, which is a user account based profile, requiring username, password and secondary authentication using SecurEnvoy.

For devices based on the N3 network the N3 connection is automatically initiated upon workstation boot.
This has been working fine for two years.

After updating to Pulse Secure client 5.1R8 the automatic connection is established – we can see the active session in the “Active Users” on the console. However, it appears that the session is immediately torn down on the client side (The server side still shows the session as active)

The event log shows the sequence of events from the client.
It establishes the session
>>
The connection N3 Profile (ID f99b707a-11f2-4ee6-b5a7-c579c4ff82a2) was established successfully to https://vpn.nhft.nhs.uk/N3 address 10.18.74.110
>>
Connection license evaluation is being deleted from the configuration
>>
The connection N3 Profile (ID f99b707a-11f2-4ee6-b5a7-c579c4ff82a2) encountered an error:
Failed to setup virtual adapter.
Peer address: 10.18.74.110



zanyterp
Pulse Secure Contributor (40)
May 2, 2016 4:34am
If you have not done so, please open a case with support for further investigation.
This sounds similar to something I have heard our team discussing; further information and troubleshooting will be needed.
    djbnhft
    Contributor (0)
    May 3, 2016 9:04am
    Have case open (2016-0420-9504) however this is not progressing....
    I'd appreciate any thoughts or suggestions, this is causing us some operational issues

    Cheers
    David
    zanyterp
    Pulse Secure Contributor (40)
    May 29, 2016 12:36am
    Thank you for the case number.
    i don't know if you have followed up on one of the ideas posited on the case; but there were changes in 5.1R8 that could cause previously authorized versions to no longer be authorized. I am aware of at least one application that had to have permissions readjusted. If you rollback/install the previous version, does it work (I didn't see it in my quick look through the case notes)? Does 5.2R3 show the same behavior?
    Another thing I have seen in one instance is if the MS WiFi Direct adapter is configured & active; can you disable this (if applicable) and test?
    djbnhft
    Contributor (0)
    Jun 2, 2016 12:27pm
    Still no progress regarding 5.1R8
    However, it looks like 5.2R3 does not have the same issue, so we can start testing that and possibly look to use this latest version

    However, we seem to be having an issue with the upgrade... The install sequence hangs around the virtual adapter... The msi log for the install finishes with
    >>
    DIFXAPP: INFO: Installing devices with Id "{FE36527A-8C07-4854-8AF7-BF40E7DF52F7}JNPRVA" using INF "C:WindowsSystem32DriverStoreFileRepositoryjnprva.inf_x86_neutral_d0b901f1feb5a713jnprva.inf".
    DIFXAPP: INFO: Will force install because driver is not better and force flag is set.
    djbnhft
    Contributor (0)
    Jun 2, 2016 12:29pm
    Are there any options/msi PROPERTIES we can specify to avoid this issue e.g. unset this "force flag"?

    I'd appreciate any suggestions

    Thanks

    David
    djbnhft
    Contributor (0)
    Jun 2, 2016 3:12pm
    Not sure why 5.2R3 upgrade keeps hitting the virtual adapter issue, so decided to uninstall previous version automatically prior to installing 5.2.R3
    (uninstall as per https://kb.pulsesecure.net/articles/Pulse_Secure_Article/how-to-uninstall-Pulse-Secure-Desktop-Client-by-using-a-script-via-the-command-line - but need to cater for C:Program Files (x86) for x64 machines too...)

    We're piloting this for a few machines and if OK will look to deploy that version