Juniper Secure Connect fails to establish a connection without a clear error.

• The connection was working a couple of months ago, but a few weeks ago they found this problem.
• This issue occurs with a single user only; the other users work OK.
• The issue can be reproduced on different laptops, so it's not a problem with the client software.
• The user says they don't remember making any recent configuration changes that could affect this user.
• Certificates and authentication look OK.
• When checking the client logs and SRX message logs, I noticed different and contradicting errors, like authentication failures and successes, for example. Or complaining about the certificate but then accepting the certificate. So there was nothing clear about the root cause of this connection issue.

We found this user was using an old VPN configuration in the past that was never deleted or deactivated after migrating to the new VPN configuration.

Old config:

    gateway remote-vpn-scott {

      ike-policy DYN-POLICY3;

      dynamic {

        user-at-hostname "[email protected]";

        connections-limit 2;

        ike-user-type shared-ike-id;

      }

      external-interface ge-0/0/7.0;

      aaa {

        access-profile scott.smith;

      }

      version v1-only;

    }

    vpn remote-vpn3 {

      bind-interface st0.7;

      ike {

        gateway remote-vpn-scott;

        ipsec-policy DYN-POLICY;

      }

      traffic-selector TS1 {

        local-ip 192.168.171.64/26;

        remote-ip 0.0.0.0/0;

      }

      traffic-selector TS2 {

        local-ip 10.172.172.0/25;

        remote-ip 0.0.0.0/0;

      }

    }

New config:

    gateway remote-vpn-scott-new {

      ike-policy DYN-POLICY3-NEW;

      dynamic {

        user-at-hostname "[email protected]";

        ike-user-type shared-ike-id;

      }

      dead-peer-detection {

        optimized;

        interval 10;

        threshold 5;

      }

      external-interface ge-0/0/7;

      local-address 85.230.120.10;

      aaa {

        access-profile scott.smith;

      }

      version v1-only;

      tcp-encap-profile SSL-VPN;

    }

    vpn remote-vpn3-NEW {

      bind-interface st0.3;

      df-bit clear;

      copy-outer-dscp;

      ike {

        gateway no;

        ipsec-policy no;

      }

      traffic-selector ts-1 {

        local-ip 10.172.172.0/26;

        remote-ip 0.0.0.0/0;

      }

      traffic-selector ts-2 {

        local-ip 10.172.172.64/26;

        remote-ip 0.0.0.0/0;

      }

      traffic-selector ts-3 {

        local-ip 192.168.171.0/26;

        remote-ip 0.0.0.0/0;

      }

      traffic-selector ts-4 {

        local-ip 10.172.172.192/26;

        remote-ip 0.0.0.0/0;

      }

      traffic-selector ts-5 {

        local-ip 192.168.171.64/26;

        remote-ip 0.0.0.0/0;

      }

    }

    profile no {

      description "Scott Smith";

      ipsec-vpn no;

      access-profile scott.smith;

      client-config no;

    }

It seems like Junos was linking the connection attempt to the old config and sometimes the new config (and that's why the logs show successes and failures for the same user).

I believe this is caused by the IKE-ID, which is the same in both VPN configurations. I saw a similar scenario a few months back with a site-to-site IPSec VPN, and the conflict was caused by the IKE-ID being the same in two different VPNs.

Therefore, in these types of scenarios, when we are sure the configuration is correct and the logs don't show us any clear error, it is best to check the config because there might be a config conflict causing confusion for Junos.

If you encounter a similar scenario, it is best to deactivate the old piece of configuration to avoid confusion or deactivate it right after creating the new piece of configuration.