Terribly slow SSL VPN

[#1]

I set up my SSL VPN and am able to auth and roam around all the shares on the network from home but it is ridiculously slow. I copied a 100MB file from a mapped share to my desktop and it took about 35 minutes. That share happens to be a public FTP folder so I used Firefox to navigate to the folder and downloaded the same file in about 10 minutes. I also compared network speed tests before and after connecting with the VPN client. Before it was about 3/1.5 and after it was .4/.1...Is anyone else having issues like this?

[mbrowndcm]

So you' re seeing rates or 100MB file: FTP = 10 minutes SMB over SSL-VPN = 35 minutes Are you using the web applet or utilizing tunnel-mode and Linux/Windows' SMB clients? If you' re utilizing Linux/Windows' SMB client, I' d be curious what your throughput to the server is. Try running iperf server (iperf -s)on the SMB server and iperf client on the SMB client (iperf -c SMB_Server). I' d then move onto testing the throughput against the other encryption key algorithms; all the while watching CPU and Memory utilization on your Fortigate. Thanks, Matt

[rwpatterson]

I don' t know who your ISP is, but Cablevision systems will throttle your bandwidth WAY back if they feel you have a server on their network (ask me how I know...). Transferring a large file or files (like I used to do to the photo lab I worked for) fits the pattern of a ' server' and they cut me down at the knees. Why I' m a FIOS customer now. My two cents

[#4]

Yes you are correct Matt. I am just using the tunnel mode between Windows only machines. Both the server and the remote client have business class internet connections with 6/2 each. I did a test on the client machine to see what the tunnel did to my throughput. I ran a speed test with and with out the VPN connected and with the VPN connected I lost about 60% of my speed. I currently dont have split tunneling enabled because I cant seem to find anything in the worthless documentation on configuring that part and get an error message when I try to enable it. I tried using lower and higher encryption settings but it didnt change anything. RE: Bob...my ISPs on either end dont care about the servers since they are both business class with 6/2 on both ends.

[rwpatterson]

One thing I did on my tunnels to attempt to speed them up was to lower the tcp-mss value to 1400 so that there would be no packet fragmentation over the SSL link. It did seem to help as well as save some memory on my 60Bs. There is about 72 bytes for the IP header as well as the SSL stuff, so 1400 was a safe number.

[mbrowndcm]

I did a test on the client machine to see what the tunnel did to my throughput.

To where did you do you test? Point-to-point using iperf? Or did you test to the internet meaning: Option 1: VPN Client>Internet (6 up/2 down)> Fortinet> Internet (6 up/2 down)> Bandwidth testing server/site or Option 2: VPN Client (not connected)>Internet (6 down/2 up)> Bandwidth testing server/site AKA This is a little difficult to explain in text... Internet bandwidth test tunneling through VPN: 6Mbit-overhead>6Mbit-overhead>2Mbit>6Mbit>2Mbit-overhead Anyway... use iperf to test throughput... use hrping to test latency... What you need is a piece of software that transfers a file and give you time of the operation... creatfil.exe (not a typo) is a tool that will make a file, but doesn' t give you a T0+ time stamp. iometer is a little crazy for this situation. maybe xcopy or robocopy have a switch that' ll give you time? First thing you should do is test with iperf. You' ll be quite sad what the throughput actually is... how many hops? no QoS over the internets :( Are you using the same isp? While not connected, run a tracert or a pathping to see how many hops you' re going through. If it' s the same ISP, the traffic may not leave their network. We use Cogent in NYC and will be using Cogent in Geneva, Switzerland; Cogent said that it won' t leave their network. Let me know how it goes. I' d be interested in an average of ten runs from both sides. Good luck, Matt

[#7]

Matt, I had all traffic being tunneled through the VPN (since I cant make the split tunneling work) and just ran about 15 network speed tests at several different websites. Ill look in to that utility you mentioned. Bob, Ill give that a try too. Is it normal to have this slow of download speed via SSL VPN? Is IPSec faster?

[mbrowndcm]

As Bob stated, if your TCP Maximum Transmission Unit is too large, lowering it will cut out the overhead on the Fortigate adjusting it (even though it' s safe to say your router is adjusting it). Usually MTU size on the internet is 1472. See determining your MTU (it' s really easy). Test MTU both to a host on the other side of the VPN, and to the internet (I would expect them to both be 1472, since both are traversing the Internets). Here' s some more points that I think you need to concentrate on: 1) Your internet bandwidth is going to be slow while tunneling over the VPN. 2) To solve this, configure split tunnel. 3) You seem to be actually concerned with SMB efficiency, which includes bandwidth, throughput and latency. Concentrate on making this more efficient, or simply determining if it is inefficient; because it doesn' t seem that you' ve solidly determined this yet. I' m on the edge of my seat over here. Let me know how it goes, Matt

[#9]

I lowered the MTU a bit and am about to test it out. You will have to forgive my ignorance, but I dont know anything about ipref. I keep trying to configure the split tunneling but I get that error about split destination invalid in policy or something. The main point of using VPN for my users is to download and upload large files that are on our file servers. Glad you are keeping entertained over there :)

[#10]

The results are still the same with the lower MTU. Im not sure if split tunneling would make it faster or not. The remote machine isnt doing anything else but this so there shouldnt bee too much additional traffic being forced through the VPN tunnel.