Slow performance with IPSEC Site2Site VPN

[#1]

I have 3 fortigate 50a who is contected to a fortifate200a with IPSEC VPN tunnels. The 3 FG50' s are all on different physical sites and they are connected to 1 Mb SDSL lines. The VPN tunnels are up and runneing and it seems to be working just fine. But when I try to access a Citrix-Server behind the FG200A, performance are very slow. If I " take down" the VPN tunnel and access the Citrix-server directly from Internet, performance are much bether? Is this normal due to IPSEC overhed or could it be a configuration problem or a DSL-line issue?

[rschulz]

Bit unusual. Here is an idea to kick around, while waiting for a better idea - maybe enabling the VPN tunnel has magnified some underlaying connectivity issues. I think the IPSec overhead is 32 bytes to 56 bytes per packet (regardless of packet size). Your system might be transmitting lots of small/fragmented packets which would increase the overhead of IPSec creating the delay. What are your ping times (with/ and without VPN)? Going through the internet option, do you still use the same Gateways/Fortinets ? MTU settings on the WAN I/F ? Are you running all/some services on the Encrypt firewall policy? Encrypt firewall policy on top of list ?

[#3]

Hello, I would like to confirm that MTU settings might help out. I had some kind of similar issues with my VPN connectivity. This happened for 2 customers with 2 totally different firewalls ( all FG60s though ) The setting : - 1 FG 60 at the main office - multiple Linksys firewalls ( mostly BEFSX41 ) hooked up to the FG60 via VPN. I followed the PDF guide on the fortinet KB site to setup the VPN connections. The issue didn' t seem to appear right away but I noticed in the past 2 months some slow down. The slow down was not bothering the users since a lot of their work is done on a server locally in each remote offices. When trying to manage active directoty users and change some group policies on the local stations, things were slow or timing out. Here' s how I figured out what the issue was: I used a tool called RPING that can be found on the ms website. It allows a client workstation anywhere on the network to connect using the RPCs ports necessary for MS Exchange communication with the main server ( our exchange server is in the main office ). The communication were going through but were EXTREMELY slow ( 1 mn to 2 ) Then after reading some posts on the web I used ping : ping -l xxxx servername This allows you to see what is the max MTU you can set to get a good transfer by changing xxxx to any number. If the ping doesn' t go through, the icmp packet size is too big and fragmented if it goes through try to bump it up. Mine was 1472. After trying forcing the MTU on the remote office fwall things wouldn' t work anymore ( VPN would go through ) but nothing else. I setup the MTU on the main office firewall to 1472 and things seem to work fine now. RPING tests were successfull and instantaneous !

[#4]

I think you were on the right track to start. VPN overhead is not much as far as size goes. But, you might want to check the CPU/memory overhead on the Fortigate. It' s the encrypting and decrypting that puts more overhead on the client and the firewall. As far as the firewall is concerened, ever feature you add will add processing delays of some kind. Some will be more noticable than others.

[#5]

If you are using PPPoE on the DSL line, try changing your MTU to something smaller than 1500. Sometimes 1492 works pretty well. You set this in the Network Interface settings of FortiOS 2.80. Secondly, I wonder if it' s a routing issue with respect to the VPN. Is there any indecisiveness in the routing points? And a thought... most Citrix sessions are encrypted, so it seems a bit daft to send them through a VPN to encrypt the encryption. hope that helps. -Jim