cancel
Showing results for 
Search instead for 
Did you mean: 

ALways-on VPN tunnel connectivity

Occasional Contributor

ALways-on VPN tunnel connectivity

Are there any ways to set up a always-on Juniper SSL VPN connectivity in case of some kiosk situations? currently there is maximum session limit configured on the SA/MAG security gateway.

thanks!

ben

11 REPLIES 11
Highlighted
Respected Contributor

Re: ALways-on VPN tunnel connectivity

If you use Pulse Secure with machine auth it should work. You still need to have a session timeout because it is required for the configuration. Please note: the maximum is ~20 years and using machine auth allows for automatic reconnection during reboot.

Occasional Contributor

Re: ALways-on VPN tunnel connectivity

Thanks a lot zanyterp! The 20 years maximum session timeout should be ok for "always-on". Any more info about how to config the automatic reconnection after machine reboot or user login? it's very useful.

ben

Occasional Contributor

Re: ALways-on VPN tunnel connectivity

Does anyone have a comment on how to config. this? I'm looking into machine auth. solutions as well.

Thanks,

Jon

Valued Contributor

Re: ALways-on VPN tunnel connectivity

Here is the general documentation for machine only authentication:

 

http://www.juniper.net/techpubs/en_US/junos-pulse5.0/topics/task/a-c-c-machine-only-machine-auth-con...

Occasional Contributor

Re: ALways-on VPN tunnel connectivity

Yes, and general that is. I've also looked at http://www.juniper.net/techpubs/en_US/junos-pulse4.0/topics/concepts/a-c-c-sa-machine-auth-overview.... -- not to mention the Admin Guide and Pulse manual. I'm getting an error with machine name/password, error 1319 on the pulse client, and in the SA log

"Active Directory authentication server 'Windows servers-AD type' : Received NTSTATUS code 'STATUS_WRONG_PASSWORD' ."

Seems really odd to get this, anyone seen it? The documents say:

*authentication server used by the Pulse connection must be Active Directory/Windows NT for machine name/password authentication

*endpoint must be a member of a Windows domain

*the machine credentials must be defined in Active Directory (maybe this needs more explanation?)

*Pulse connection must be configured so that no prompts are presented during the login process

which seems pretty simple. Anyone have a working system like this?

Valued Contributor

Re: ALways-on VPN tunnel connectivity

This is the general error message it could not authenticate the machine to the DC.  However, this could mean an issue with creating the tunnel as well.  Could you open a case with support and provide the pulse logs?  This should give us more detail why this issue is occurring.

 

Please feel free to provide the case #.

Occasional Contributor

Re: ALways-on VPN tunnel connectivity

About using machine authentication, I found one issue when establishing VPN connectivity using cert authentication, it can only look in the User store, and not the Computer store. It was tested with the latest 8.1R2 and Pulse Client v5.1.2 as well.

Here are test cases:

1> certs are in both user and computer store, authen was success

2> remove cert from user store, and kept cert only in computer store, authen failed

3> remove cert from computer store, and kept cert only in user store, authen was success

Regular Contributor

Re: ALways-on VPN tunnel connectivity

If you want to check the machine store you need to use a host checker policy.

If you just want to use a machine certificate then I think the way to do it would be be to set up a realm restricition with the machine certificate host check and then use an anonymous server for the authentication

Occasional Contributor

Re: ALways-on VPN tunnel connectivity

I've opened a case (2015-0518-0788) on this. So far the word is, machine auth. using just AD (machine name and password) does not work. Checking a machine cert, as opposed to a user cert., works with host checker but on Windows only (we have some domain-joined Macs as well that I want to have machine auth. done on before allowing them VPN access to the LAN.)

I have a call later today to discuss this, so I'll report what I find and the results of my testing (credential provider etc.)