I am not sure if anyone else is facing the same issue as me but i encountered the following after i upgraded the MAG from version 8.0 to 8.1r1.1. The client NC does not seems to work.
The client side showed the following error after the login was successful
"The secure gateway denied the connection request from this client. (nc.window.app.23791)"
and found this error message was showing in the advanced logging on the client NC troubleshooting
"ipcConn recv failed with errno 10053" --> I googled it and found nothing useful
I tried to follow through most of the Juniper KB as suggested but nothing seems work. I also noticed on the MAG that it state that the user have successfully login (Showing the users as an active user.).
I finally reluctantly rollback the software on the MAG to version 8.0, imported the backup configuration and then proceed to uninstall the NC on the client. The client got reconnected back to the MAG (it will install the version 8.0 NC) and everything seems to be working again.
I am wondering if there any extra configuration for version 8.1 that i might have missed out that may have caused this?
Which version of 8.0 did you roll back to.
We just opened a ticket with JTAC for our environment running 8.0r8.1. Pulse users pass all validation and login successfully however the tunnel never establishes. MAG logs show the VPN tunneling session started but never show connected in SSL or ESP transport mode. Pulse client just sits at Connecting.... but never Securing Connection.
Hi Braker,
My rollback version was 8.0r7.1. It seems to me that both the January release (8.1r1.1 and 8.0r8.1) have this issue. The symptons as what you have described is somehow similar to what I have encountered.
1. MAG showing login was success with no error.
2. MAG showing users are active.
3. Client NC prompting an error message. The status kept showing the "connecting" status.
I hope the secure pulse team will take a look at this and resolve this soon.
For me, the problem has the feeling of a resource depletion issue. It did not surface immediately after the upgrade to 8.0r8.1 but things seemed to degrade over time. Since the .1 version of 8.0r8 was released to address an issue with the POODLE vulnerability specific to devices with hardware acceleration enabled, I turned off hardware acceleration on one of my MAGs this weekend thinking maybe the fix is a bit buggy. So far things have been stable however its not clear if it was turning off hardware acceleration or the subsequent reboot that cleared the problem. I recently rebooted my other MAG leaving hardware acceleration enabled. It too is working well...so far.
We have the same issue after upgrading to 8.1R1.1. It happened immediately after the upgrade, so no resource depletion.
Interesting. I am wonder if these are different problems or the same problem with different manifestations depending on code version (8.0r8.1 vs 8.1r1.1), security settings, or user load.
What SSL Options are set under System > Security? We're using 'Accept only TLS'
What transport encryption are you using in the VPN tunneling connection profile? We're using AES128/SHA1
What kind of user load do you have? We've had 2,113 users over the last 24 hours on one box with a max hourly peak of 1,157 users.
It happened to me almost immediately after the upgrade.
Hardware Acceleration Enabled --> no
What SSL Options are set under System > Security? --> 'Accept only TLS'
What transport encryption are you using in the VPN tunneling connection profile? --> AES256/SHA1.
What kind of user load do you have? --> less than 30 active users each time.
I am wondering if the Pulse Secure team are looking into it.
I pushed a ticket through support and they found it to be an issue with the new firmware release and bandwidth management.
If you have enabled bandwidth management and can disable, doing so restores functionality of network connect/VPN Tunneling with 8.1R1.1:
Network-->VPN Tunneling-->Overview. Set both values to 0 under Bandwidth Management.
From our support case:
I reviewed the logs attached to the case and observed as part of tunnel setup, downstream and upstream filters are created. These are only set when bandwidth management is enabled. However, snapshot indicates these filters are not being created properly. Configure user TC upstream filter do_filter called upstream: 1, 4, 1, 4, 6, 255, 172.27.5.255, 3 selector: Match source IP tc_dump_filter: !!!Remnant of size 140 tc_filter_modify: dump_filter failed with error = -1 do_filter failed: couldn't create Failed to set TC upstream filter Error in DHCP allocation/post-allocation
Hi tscalzott, thanks for posting the resolution. (Anyone else tried it yet?) I do have the mentioned feature turned on and because I need to use it, there is no way i am going to upgrade to the latest version for both 8.0 and 8.1 if that is the root cause.
And i also saw a couple of people facing the same issues as us. This makes me wonder why don't they (Pulse Secure since Juniper sold the entire business to them) make it an official annoucement somewhere so that those people don't need to waste their time troubleshooting over it.