We're newcomers in the Pulse Secure/Juniper Community and technology as well seeking assistance for a resolution of a problem summarized in the subject of this post.
Our desktops/laptops are running Win10 ver 1803 (OS Build 17134.590).
The Pulse secure VPN client installed on the Win10 machines is v. 9.0.2 (1151). We didn't buy Pulse Secure VPN client. We downloaded a copy of it from Pulse Secure's site and we use it with a license that comes by default with the purchase of an SRX 300.
When we restart the SRX gateway error 1453 goes away but it comes back about 12-15 hrs later. We are actively troubleshooting the problem on the Juniper side but we would like to bounce this issue to Pulse Secure Community, just in case someone else has experienced something similar and has an advise/recommendation how to resolve it [request1].
We called Pulse Secure tech support but the moment we tell them we're VPN out to a Juniper hardware product they immediately point us to Juniper tech support.
To the best of your knowledge should we dismiss this as a Pulse Secure related issue and focus on the SRX or Pulse Secure client may be also part of it ? [request 2]
Solved! Go to Solution.
Juniper's JTAC team investigated the SRX300 Gateway, where Pulse Secure VPN client suppose to connect, while the VPN connectivity was failing and found out that it was caused by an over-utilization of its Routing Engine.
Next, we will show the Juniper commands the JTAC engineer ran on the SRX in config mode
user-SRXGateway: run show chassis routing-engine
Routing Engine status:
Temperature 45 degrees C / 113 degrees F
CPU temperature 59 degrees C / 138 degrees F
Total memory 4096 MB Max 983 MB used ( 24 percent)
Control plane memory 2624 MB Max 656 MB used ( 25 percent)
Data plane memory 1472 MB Max 309 MB used ( 21 percent)
5 sec CPU utilization:
User 50 percent
Background 0 percent
Kernel 45 percent
Interrupt 0 percent
Idle 5 percent <---- idle was down to 0% when we initally executed the command at the time the VPN client was failing to connect
Last reboot reason 0x200:normal shutdown
Load averages: 1 minute 5 minute 15 minute
user-SRXGateway: run show system processes extensive | except 0.00
last pid: 49064; load averages: 2.33, 1.67, 1.38 up 3+07:22:08 10:40:48
160 processes: 16 running, 130 sleeping, 2 zombie, 12 waiting
Mem: 304M Active, 144M Inact, 1574M Wired, 385M Cache, 112M Buf, 1572M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
49023 nobody 3 84 0 11600K 5032K ucondt 0 0:01 1.46% httpd <---- was in the low 90% when the VPN client could not connect
Finally he executed
run show security flow session interface st0.21
and that returned a list of pair of communicating IPs, their Session IDs and the Policy Names that allow them.
The overwhelming majority of the records were indicating 3 specific IP addresses trying to aggressively connect to the SRX itself. All IPs were assigned on Hardware in the internal network and there was no config to get accessed externally, via DDNS for example.
Two of those IPs were given to IP power switches [to power up hardware when power from the grid restores after an outage] and the 3rd one on a server.
The IP power switches by design ping 5 different external preset targets every few seconds; if those become unreacheable then they would power-cycle one or both of their AC power outlets according to the user's configuration.
Unexpectedly, the SRX300 logs showed the traffic from the IP power switches wasn't icmp, as expected, but plain http, so the fact it was directed to the SRX raised suspicions of having been hacked, so I removed them from the network.
The server among other SW had 2 very resources intensive network mngt SW [SolarWinds and PRTG Network Monitor] that were hitting the Gateway to extract descriptive network info and stats for reporting purposes.
Both pieces of SW were completely removed [down to the Windows registry level] from the server and the machine was deeply scanned with a couple of AVs to assess/ensure its virus/spyware clean status.
The Juniper engineer also disabled http mngt access on the SRX
[edit system services web-management] <--- config setting he changed
and we agreed not to restart the SRX again but monitor Pulse connectivity daily. So far it has been 6 days and we haven't experienced any Pulse secure VPN outage hoping it'll stay that way.
However, Juniper highly recommends NOT to use Pulse Secure as a VPN client accessing their gateways, especially from Win10 machines [albeit, from personal experience Pulse Secure still works from Win7 and it's pretty stable and reliable].
Instead they propose to use NCP. Below is a KB article about how to set it up on the SRX and a PDF with NCP set up instructions for the Client:
The URLs I'll try to attach on the thread by placing them in text file
I hope the above info is helpful providing enough insight to help others in their troubleshooting efforts.
With lots of help from Juniper's JTAC team we managed to configure NCP client and make it talk VPN to SRX300.
Here's an excerpt of the SRX config specifically for the NCP client-Gateway VPN communication
ALL THE CREDIT FOR WRITING THE EXCERPT BELOW GOES TO THE JTAC TEAM and not me.
set security ike proposal NCP-PROP authentication-method pre-shared-keys
set security ike proposal NCP-PROP dh-group group5
set security ike proposal NCP-PROP authentication-algorithm sha1
set security ike proposal NCP-PROP encryption-algorithm aes-128-cbc
set security ike proposal NCP-PROP lifetime-seconds 86400
set security ike policy NCP-POL mode aggressive
set security ike policy NCP-POL proposals NCP-PROP
set security ike policy NCP-POL pre-shared-key ascii-text juniper123
set security ike gateway NCP-GW ike-policy NCP-POL
set security ike gateway NCP-GW dynamic user-at-hostname "[email protected]"
set security ike gateway NCP-GW dynamic connections-limit 2
set security ike gateway NCP-GW dynamic ike-user-type shared-ike-id
set security ike gateway NCP-GW external-interface ge-0/0/0.0
set security ike gateway NCP-GW aaa access-profile ncp-vpn-profile
set security ike gateway NCP-GW version v1-only
set security ipsec proposal NCP_IPSEC_PRO protocol esp
set security ipsec proposal NCP_IPSEC_PRO authentication-algorithm hmac-sha1-96
set security ipsec proposal NCP_IPSEC_PRO encryption-algorithm aes-128-cbc
set security ipsec proposal NCP_IPSEC_PRO lifetime-seconds 28800
set security ipsec policy NCP_IPSEC_POL proposals NCP_IPSEC_PRO
set security ipsec policy NCP_IPSEC_POL perfect-forward-secrecy keys group5
set security ipsec vpn NCP-IPSEC bind-interface st0.0
set security ipsec vpn NCP-IPSEC ike gateway NCP-GW
set security ipsec vpn NCP-IPSEC ike ipsec-policy NCP_IPSEC_POL
set security ipsec vpn NCP-IPSEC traffic-selector TS1 local-ip 0.0.0.0/0
set security ipsec vpn NCP-IPSEC traffic-selector TS1 remote-ip 0.0.0.0/0
set security zones security-zone trust interfaces st0.0 host-inbound-traffic system-services all
set security zones security-zone trust interfaces st0.0 host-inbound-traffic protocols all
set interfaces st0 unit 0 family inet
set access profile ncp-vpn-profile authentication-order password
set access profile ncp-vpn-profile client test firewall-user password test123
set access profile ncp-vpn-profile address-assignment pool NCP-pool
set access address-assignment pool NCP-pool family inet network 10.1.1.0/24
set access address-assignment pool NCP-pool family inet xauth-attributes primary-dns 18.104.22.168/32
set access firewall-authentication web-authentication default-profile ncp-vpn-profile
Also, do not forget to check the security policies, and confirm there's a policy from Tunnel to Internal resources. Ensure that traffic started is working by checking the encrypted packets flow is increasing by running
# run show security ipsec sa
in order to get the TUNNEL_ID and then run
# run show security ipsec statistics index TUNNEL_ID
to confirm the encypted packets traffic is increasing
The NCP VPN client is VERY robust and connects really fast.
Lastly, if your Juniper Gateways are SRX300s please make sure you buy the Exclusive Entry client for Windows from "https://www.ncp-e.com/en/exclusive-remote-access-solution/vpn-client/#c12977"
I hope this helps someone else in a similar technical deadlock.
Please feel free to close this thread.
The body of network connection error 1453 reads as follows:
Netwrok errors can be caused by temporary conditions such as an invalid URL , a server not available, and so on. Please try the operation again. Restart your system and try the operation again. If the problem persists, contact your network administrator.
Thx for the prompt reply Ray,
I know the error will come back sooner or later. I'll run the collection jobs as soon as I get an opportunity and provide more content for review per your advice.
Please bear with me as I'm working 2 jobs and I'll have to time this exercise properly, i.e., outside regular business hrs, during which Pulse Secure VPN client must work seamlessly per user's expectations.
Thank you for the response.
I understand. Please update the thread once you have the files for review, will wait for your update.
Thx for your comments.
Rest assure, I made an honest effort to get a copy of Pulse Secure version 5.1 but I came out empty handed.
If a ping pong ball had feelings they could match mine when I was literally bouncing from a Juniper tech support call to a Pulse Secure one requesting a copy of ver. 5.1.
Each rep was politely referring me to the other. In the end the Pulse Secure rep recommended a 3-way call which I'll attempt tomorrow evening in hopes we'll find out which Co is more suited to help.
Although I have a verified accnt with both Cos and despite the fact a Juniper URL surfaced from a Google search with a download link to ver5.1 their tech support couldn't help me go past the msg I was getting saying I needed more privileges to download it.
So I dug into our SW depot and I found a copy of ver. 5.2r6.0-b977 which I installed on another Win10 machines and tried VPN out to the SRX, since the VPN connection on the original Win10 machine with Pulse Secure ver 9.x had started failing connecting, but I got the same network connection error 1453.
If, by any chance, you are aware of a web location I can get a copy of ver 5.1 I would appreciate sharing it with me, otherwise I'll try to get one as an outcome of the 3-way call tomorrow night. If the ver. 5.1 test fails then I'll prepare a set of dumps and logs for a deeper technical investigation per Ray's request.
I hope this sounds like a plan. Thank you all for spending time to help us.
More to come.
Thank you all for your reponses,
BLUF: The hunt for Pulse Secure VPN client ver 5.1 over the phone was fruitless
In a nutshell, Juniper requires us to purchase a support contract that would bypass their Tier 1 phone tech support and unlock access to their technical group more suited to discuss VPN technical issues with Pulse Secure's engineers and not front line tech support.
When we login to https://my.pulsesecure.net/ we get on an onboarding pg with 2 choices
1. On-boarding: Customers and Partners
2. On-boarding: Partners enrolled in the "Support Partner Program"
and various text boxes requesting my name, address, phone numb and whether
I am... *
a vADC Customer
not a vADC Customer
At this point we have only 2 choices, either click 1 and get redirected to a pg that requires "Authorization Code from Right To Use (RTU) Certificate or RMA Case Number" I wouldn't have
or fill in my personal info [which is fine], except, when I select any of the vADC customer choice I get prompted for a S/N of Pulse Secure device the system probably assumes I own but I don't.
Either way I'm unable to go forward at my.pulsesecure.net
BLUF: Pulse Secure VPN client ver. 5.1r4.0 doesn't resolve our connectivity issue
As an alternative, I reached out to friends and past colleagues and I got a valid copy of Pulse Secure ver. 5.1r4.0 which I tried this morning receiving the familiar connection error 1453.
@zanyterpthe answer to your Q is yes. Pulse Secure client stays alive for about 12 - 15 hrs and then it drops the connection to the VPN. Concur, the VPN process fails somewhere so we have to monitor it close enough to collect enough info for troubleshooting.
We don't see any way to engage Juniper in this exercise other than purchasing a support contract and take a deep dive with their engineers and get to the bottom of this.
Requesting permission to leave this thread open so we can add more content about this case, mainly to assist others who may have, or will have, the same connectivity issue, but also for the education of the greater community.
Next, I'll share our findings about the format of the auto generated SRX debug logs.