I have a number of Mac users complaining about upload performance issues running with the new 6.5R3.1 Network Connect client. I thought they were full of it, but I just ran a test on www.speedtest.com and I see what they are saying. On my same home internet link (and not running the test at the same time) connected to the same SA-6500 cluster, the Mac and Windows PCs get the same download speed of 9.5Mb/s, but the Mac is getting ~140kb/s upload speed while the Windows PC is getting ~2.41Mb/s upload speed. Has anyone else running across this same issue? If so, any ideas on how to fix this problem?
I've seen where enabling client side logging on the SA itself has severly limited upload performance. Check that.
One other thing to see that I am seeing is that the /etc/hosts file updates NC makes as part of it's startup process is not getting removed when NC is stopped. Unsure if that's a problem for you, but it can be problematic in a clustered environment....
This issue has been reported to JTAC. Please open a JTAC case and reference PR (bug) #495124. We are looking to address this issue in 6.5R4 which is slated to be released the second week of April. However, we do need to open a case so we can properly track and give possible workarounds.
Yes, I know it is a bug. Abigail and I have been working on the issue under my case number also. Abigail is working in the lab to reproduce the issue. We also found another bug wih the Mac NC client yesterday with the proxy settings.
I have no performance problems with MAC Leopard 10.5.8 and 6.5R3.1 running on a SA6500 cluster (2 boxes).
I'm using a 5 Mbps ADSL connection to test, I have ran an IPERF test, and it is really nice.
What happened with your case, out of curiosity? We're running 7.1R2, and just discovered Mac upload speeds on Network Connect are completely unusable.
Just to clarify when I say unusable, doing the same file transfer without the VPN: 26 Mbps. With VPN: 500 kbps.
Got help from Juniper TAC. Mac speeds being slow is a known issue, KB19197_. I'm not sure why I didn't find this during my search of the KB. The workaround with ipchains doesn't appear to stick, though, contrary to what the KB article states.