VPN File Transfer Problems

notverypunny

@Pete-S remote sites are scattered across Canada and the US. Different ISPs, variety of speeds, same / similar results proportional to the site's connection.

1337

@notverypunny said in VPN File Transfer Problems:

@Pete-S remote sites are scattered across Canada and the US. Different ISPs, variety of speeds, same / similar results proportional to the site's connection.

So the problem isn't the speed itself?

The problem is at the remote site where Server A only get 10% of the speed of Server B?

TX1TGUY

I would suggest looking around on your switch, firewall, and MODEM for your ISP to see if there is any QoS things setup anywhere.

Make sure your ISP speeds are consistent. Also remember, ISP uses Mbps and where file transfer speeds are based on MB/s. One is data speed, other is file speed. So if you have 30Mbps upload you will only see a 3MB/s download on the file transfer speed.

dafyre

Are the FG's Fortigate units?

The last set I used if you enabled anything at all, you'd take a performance hit.

scottalanmiller

If it varies by server at a single site, then the ISP can't be the issue as the ISP can't tell one server from another. It has to be something else.

notverypunny

@dafyre Yes. Fortigate 501E HA pair at the datacenter / main office, a 101E at the largest US site, 81E everywhere else. All on FW 6.0.4....

My current theory is that when the data hits the 501E @ 10G there's something that comes into play to slow things down for the VPN tunnel and it's "throttling" too aggressively. I could understand if I was getting the same results for all DC servers at the remote sites, but that the 10G servers are roughly 10% of the speed consistently over the tunnels...

notverypunny

@scottalanmiller Exactly..... I think my next step is going to be to connect to a unused 1G port on the 501E to see if it's the FG all on it's own that's messing with things.

notverypunny

@dafyre said in [VPN File Transfer Problems](/post/

enabled anything at all, you'd take a performance hit.

Can you elaborate on the "anything at all"?

We've got a couple of prioritization rules in play for SIP, but everything else over the VPN link is disabled.

1337

First off you have to look at the traffic. I assume fortigate has a web interface. So how much traffic goes over the IPSEC tunnel when you transfer a file? How many tunnels do you have? How much traffic goes over the WAN interface?

What's the cpu load on the fortigate when transferring files? If the hardware can't offload the IPSEC don't expect anything near what the specs say. Firewall probably has a very low spec cpu inside. Often openvpn can't be offloaded like ipsec so look at the specs for openvpn on the firewall to get a ballpark figure what you'd get on ipsec that is not hardware offloaded.

Actually looking at Fortigate 101E specs, it can do 250 megabits/s of openvpn. So expect something like that for total throughput over IPSEC if it's not hardware offloaded. Some QoS and packet inspection might cause it to not be able to hardware offload. That is one thing that can cause a severe performance hit like what @dafyre was talking about.

Second, best practice is to run the same ISP for VPN links because you want to be on the same backbone. If you don't, you should expect slower link speeds. You're not going to get 10MB/s over a 100Mbit link or 100MB/s over a 1Gbit link.

For detailed analysis you need to do packet capture to see what is happening. Just as an example I had a problem with one VPN link that turned out to be a LACP problem on the switch.

1337

Anyway, like anything you have to approach it logically so you can eliminate things.

For instance just looking at the link can you run iperf or similar test between the firewalls (on the firewall itself)? Preferably with random data. In that case you can check what your actual vpn link speed is and then if that is slow you can exclude anything that has to do with servers and switches.

notverypunny

Appreciate the insights and advice, but just to be clear, my main point of concern is that I can get up to 10x the speed traversing the same VPN / ISP and network infrastructure when the server is on a 1G copper link in the data center as opposed to when the server is on a 10G fiber link in the data center. I'm fine with disparity from site to site and it's of course to be expected given different ISPs, network conditions and workloads at the different locations.

I've done some iperf based testing on the issue already and have shown that raw wan speeds are acceptable and that I can get substantially more speed on iperf than with file transfer. I've also have seen that iperf on windows is garbage, the speeds are nowhere near what I'm getting on as close as I can get to a like for like comparison with linux.

notverypunny

@Pete-S said in VPN File Transfer Problems:

Just as an example I had a problem with one VPN link that turned out to be a LACP problem on the switch.

Do you recall what the LACP issue was? It's in-play in a couple of points along the path in the data-center.

dafyre

If your servers have Intel or Broadcomm nicks in them, you may want to test disabling VMQ.

1337

@notverypunny It was some kind of configuration error on the switch. I think the server tried to negotiate LACP while the switch didn't reply as it should and thought it was some kind of loop going on. Traffic would pass but intermittently. From the outside it looked like it worked but slower. Looking closer at packet captures there was a lot of unusual packets which is the reason we started to look at the switches. After reconfiguring the port from scratch everything worked, so I don't know exactly what it was.

Dashrender

@dafyre said in VPN File Transfer Problems:

If your servers have Intel or Broadcomm nicks in them, you may want to test disabling VMQ.

I thought that issue was fixed a while ago?

JaredBusch

@Dashrender said in VPN File Transfer Problems:

@dafyre said in VPN File Transfer Problems:

If your servers have Intel or Broadcomm nicks in them, you may want to test disabling VMQ.

I thought that issue was fixed a while ago?

In theory.

dafyre

The newest piece of gear I have is a Dell R730xd (purchased last year) and we had to disable it on that one. Server 2012 R2 as the host OS. I can't remember which NIC it has off the top of my head, but we did disable VMQ on all the network adapters in that system.