Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
mkintexas
New Contributor

Site to Site VPN performance issues 140E (but not 140D)

Folks,

 

We are deploying our first 140E into our environment.  We have a data center with a 500D and a Comcast 1gb Internet circuit.  We have about 100 sites that have anywhere from 25-50mb fiber circuits.  ALL sites with the exception of a new site with a 140E run fine and give me near line speed on throughput.  However this new site does not.  When I start a large copy.  It spikes at about 1.5-2.0MBS but then drops to 350KBS or down to 0.  I have a lab with a 140D so I tested there.  My 140D.  Performance is fine.  Configure a 140E the same way and get the same slow to stall issue.   Phase 1 is AES256 SHA256 as is Phase 2.  

Any ideas?  I do have a case opened with support.

6 REPLIES 6
Toshi_Esumi
Esteemed Contributor III

If other location's 140E and 500D show much better, I would suspect MTU issue from/to the location you see the problem. Try ping with extra large size packets over the tunnel from the location's 140E. It wouldn't go through if that's the issue.

ede_pfau
Esteemed Contributor III

The only difference between the 140D and 140E is that the former has got a 2-core CPU (with HT), and the latter a SoC3, with a less potent CPU (this is an assumption). Make sure the IPsec traffic gets offloaded or the CPU will limit the throughput eventually.

You would like to see

gate # diag npu np6lite npu-feature
                    np_0
------------------- ---------
Fastpath            Enabled
IPv4 firewall       Yes
IPv6 firewall       Yes
IPv4 IPSec          Yes
IPv6 IPSec          Yes
IPv4 tunnel         Yes
IPv6 tunnel         Yes
GRE passthrough     Yes
IPv4 Multicast      Yes

IPv6 Multicast      Yes

gate # diag vpn ipsec stat
All ipsec crypto devices in use:
NP6LITE_0:
    Encryption (encrypted/decrypted)
        null             : 0                0
        des              : 0                0
        3des             : 0                0
        aes              : 638720           575488
        aes-gcm          : 0                0
        aria             : 0                0
        seed             : 0                0
        chacha20poly1305 : 0                0
    Integrity (generated/validated)
        null             : 0                0
        md5              : 0                0
        sha1             : 0                0
        sha256           : 638720           575488
        sha384           : 0                0
        sha512           : 0                0

NPU Host Offloading:
    Encryption (encrypted/decrypted)
        null             : 0                0
        des              : 0                0
        3des             : 0                0
        aes              : 102409           0
        aes-gcm          : 0                0
        aria             : 0                0
        seed             : 0                0
        chacha20poly1305 : 0                0
    Integrity (generated/validated)
        null             : 0                0
        md5              : 0                0
        sha1             : 0                0
        sha256           : 102407           0
        sha384           : 0                0
        sha512           : 0                0

SOC3:
    Encryption (encrypted/decrypted)
        null             : 0                0
        des              : 0                0
        3des             : 0                0
        aes              : 6                98
        aes-gcm          : 0                0
        aria             : 0                0
        seed             : 0                0
        chacha20poly1305 : 0                0
    Integrity (generated/validated)
        null             : 0                0
        md5              : 0                0
        sha1             : 0                0
        sha256           : 6                98
        sha384           : 0                0
        sha512           : 0                0

SOFTWARE:
    Encryption (encrypted/decrypted)
        null             : 0                0
        des              : 0                0
        3des             : 0                0
        aes              : 0                0
        aes-gcm          : 0                0
        aria             : 0                0
        seed             : 0                0
        chacha20poly1305 : 0                0
    Integrity (generated/validated)
        null             : 0                0
        md5              : 0                0
        sha1             : 0                0
        sha256           : 0                0
        sha384           : 0                0
        sha512           : 0                0
that is, figures in the hardware section and very small figures in the CPU (SoC) and software sections.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
mkintexas

Thank you for your reply.   I tried several things with support yesterday.   Here are some observations.  If we disable A/V on the relevant policy throughput is fine.   Also in some cases if we wait it out.  3 minutes after a file copy starts it will pick up from its 0bps and go to normal speed.  So we are narrowing it down to have something to do with A/V.  We have tried both proxy and flow mode to no avail.  This is occurring on two different circuits with two different 140E's   one of the circuits is my lab.  If I move the cables over to the 140D in my lab I have no issues.  So definitely something around the 140E and its A/V engine.   I am going to set up FTP and see if that protocol transfers without issue to determine if it is limited to SMB.

 

Ede.  I will try the diagnostic above.

ede_pfau
Esteemed Contributor III

Ah, anti-virus on SMB. Would have been worth mentioning earlier. IMHO this is 'experimental' as it's only been implemented lately (v5.6??). I'm curious if Support spots a bug there.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
mkintexas

I didn't think about mentioning it since it is running fine on my 140D's.  TAC is collecting packet captures at this point.

mkintexas

Well.  It just gets more interesting.  I have been experimenting with two versions of windows as my source.  It seems copying from a 2008R2 machine gives me much better performance.   But.  If I reboot the 140E my test machine (windows 10)copies at a better speed (no where near what it is supposed to be) but 16-24mbs.  My 2008R2 machine gives me 56-64mbs.  After a few minutes. Attempts to copy again from my test machine start but then drop down to the 355KB and then 0 that it has been doing. I am having much more success with my 2008R2 after a couple of initial hiccups I am getting normal throughput on my 2008R2 machine both to my lab 140E network and a network we have in production in the field.   My win10 machine copies just fine to field machines behind any 1 of my 95-100 140D's.   So seems to be limited to a win10 OS with a 140E with AV ( I tinkered with setting emulator enable and disable under config smb under config antivirus profile. Also tried proxy and flow based inspection mode)

 

Official head scratching has begun.

Labels
Top Kudoed Authors