This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos XG 18 MR3 DPI slow download

Hi all,

after going from decrypting HTTPS traffic by proxy to the dpi engine my download performance dropped massivly.

I am on a SG 230 hardware where the XG 18 MR3 is installed on.

Taking the same side downloading an ISO file via HTTPS with proxy and SSL decryption a get 100mbit/s troughput which is the max of my internet connection.

switching to DPI I get arround 16mbit/s. If a start a second, third download an so on I can max out my internet connection.

switching back and forth between proxy and dpi I can always reproduce this.

this happens only to HTTPS sessions with DPI turned on.

The load on the FW is never higher than 20% while testing.

Could there be an issue that DPI is somehow limiing the throughput within a session? No QoS is defined...

I tried different DPI policies and nothing changed the behavior.

Thanks for your help

best



This thread was automatically locked due to age.
Parents
  • This is just the way it is.  Also you get the bonus of it breaking random sites with no idea why or what to do about it.

  • are there any new ideas on this topic?

    I don't think that this is not happening to lot's of other people if this would be a bug?

  • As already written, the download fails after a while. 

  • Why does Sophos only use one core for a download at DPI

    The DPI Engine is based on Snort 2.9.16 which is a single core IDPS (Sophos partially solves this by spawning multiple process and sharing the load between them, but only works with multiple connections).

    Snort 3.1 should resolve this problem since It's fully multi-threaded, but apparently It will take some time until we have It.

    What Rev is your XG 210 ? I didn't expected It to be this slow since Sophos told AES-NI is being used on hardware appliances.


    If a post solves your question use the 'Verify Answer' button.

    Ryzen 5600U + I226-V (KVM) v20 GA @ Home

    XG 115w Rev.3 8GB RAM v19.5 MR3 @ Travel Firewall

  • I can't say anything about the multi or single connections, because I don't know what is meant :-) However, I assume that a normal download is a single connection and thus represents the standard case. If the standard case of DPI isn't covered, DPI is just bad. We have the Rev.3

    XG 210  C23  Rev.3 
  • The XG 210 Rev.3 uses a Intel Celeron G3900, It's a really weak & old CPU, that's probably one of the reasons on why It's so slow.

    Also, just for curiosity, can you SSH in your XG 210, go to advanced shell and give the output of "openssl speed -evp aes-128-cbc" ?

    I want to see If It's actually using AES-Ni on the XG 210.

    Thanks!


    If a post solves your question use the 'Verify Answer' button.

    Ryzen 5600U + I226-V (KVM) v20 GA @ Home

    XG 115w Rev.3 8GB RAM v19.5 MR3 @ Travel Firewall

  • This is the Report of "openssl speed -evp aes-128-cbc" 

    XG210_WP03_SFOS 18.0.4 MR-4# openssl speed -evp aes-128-cbc
    Doing aes-128-cbc for 3s on 16 size blocks: 20565502 aes-128-cbc's in 2.92s
    Doing aes-128-cbc for 3s on 64 size blocks: 6121344 aes-128-cbc's in 2.96s
    Doing aes-128-cbc for 3s on 256 size blocks: 1601184 aes-128-cbc's in 3.00s
    Doing aes-128-cbc for 3s on 1024 size blocks: 404977 aes-128-cbc's in 2.96s
    Doing aes-128-cbc for 3s on 8192 size blocks: 50164 aes-128-cbc's in 2.94s
    OpenSSL 1.0.2u-fips  20 Dec 2019
    built on: reproducible build, date unspecified
    options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr)
    compiler: ccache_cc -m32 -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/srv/jenkins/workspace/OmC/CI_64/staging_dir/target-x86_64_glibc/usr/include -I/srv/jenkins/workspace/OmC/CI_64/staging_dir/toolchain-x86_64_gcc-7.3.0_glibc/usr/include -I/srv/jenkins/workspace/OmC/CI_64/staging_dir/toolchain-x86_64_gcc-7.3.0_glibc/include -znow -zrelro -DOPENSSL_NO_HEARTBEATS -DTERMIOS -fpic -Wa,--noexecstack -O3 -fomit-frame-pointer -Wall -fomit-frame-pointer -Wall -I/srv/jenkins/workspace/OmC/CI_64/staging_dir/target-x86_64_glibc/usr/lib/fips-i386/include
    The 'numbers' are in 1000s of bytes per second processed.
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-128-cbc     112687.68k   132353.38k   136634.37k   140100.15k   139776.70k

    but according to this list "since Sophos told AES-NI is being used on hardware appliances". AES-Ni is supported with the XG210_WP03. The Sophos is not even 1 year old

  • No, openssl isn't using AES-NI on your XG 210, those numbers are too low for the G3900.


    If a post solves your question use the 'Verify Answer' button.

    Ryzen 5600U + I226-V (KVM) v20 GA @ Home

    XG 115w Rev.3 8GB RAM v19.5 MR3 @ Travel Firewall

  • I have no idea, it is in this list (see marking). But I don't care either, Sophos advertises the DPI. With which version should the DPI work without any problems? The XG210 Rev. 3 is the current version that is available for purchase.

  • I have an XG210 Rev2 and my numbers running that openssl test match your Rev3 almost exactly.  Not sure it means anything, just throwing it out there.

  • Hey Prism,

    only the high end Sophos hardware supports AES-NI, XG660 and above according to the specifications.

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • Hi In case you get this fail. Do you see any kind of TLS Issue with this site in the Logviewer? Because on all of my appliances i cannot reproduce this. 

    __________________________________________________________________________________________________________________

Reply
  • Hi In case you get this fail. Do you see any kind of TLS Issue with this site in the Logviewer? Because on all of my appliances i cannot reproduce this. 

    __________________________________________________________________________________________________________________

Children
  • Why are dome`s web-proxy numbers that much higher? 

    according to sophos marketing:

    XG210 Rev 3

    BEDROHUNGSSCHUTZ

    800 MBit/s

    XSTREAM-SSL-ENTSCHLÜSSELUNG

    230 MBit/s

    XG123 Rev 3

    BEDROHUNGSSCHUTZ

    400 MBit/s

    XSTREAM-SSL-ENTSCHLÜSSELUNG

    170 MBit/s

    From my unerstandig XSTREAM = dpi

    And shouldnt webproxy be "bedrohungsschutz" ?

    dome do you have av scanning , ips and web policy off or configured?

  • No, until now I haven't seen a TLS error in the protocol. But I'll test it again on the weekend

  • yes ips and web policy is on, with the av scanning we have a limit of 30mb above it is not scanned. If I set this limit higher, the speed is 20mbits (field test 30PCs are currently working) I will test the exact speed on the weekend

     Limit 30 MB

     Limit increased for the Test 

    
    

    Is there a possibility to also set such a limit for the DPI?