Guest User!

You are not Sophos Staff.

  • I will understand this as support for QUIC in the DPI Engine is at least mentioned on the backlog and you will continue to review this. Sounds great and fine for me ^^

    Thanks!

  • old issue warmed up? I've seen that in the past with, over a year ago on some old v18.0 versions.

    the white or the blue button?

    the machine is in 18.5 mr4

    an other machine shows a bit more text and correct buttons. same source FW....

  • I have a XGS2300 HA-CLuster in active passive with 7 remote connections connected via SD-RAD 60. And one IPsec Site2Site-Tunnel connected to a cloud server. Any packet (ping is enough) from any network behind a RED to this cloud server or from the cloud server back will break the RED connection and force it to reconnect. Disbaled TLS1.2 for RED, re-created one og the RED interfaces, re-created the site2site Tunnel to tunnel-based, rebooted the firewall, set RED-Tunnel from Standard-split to standard-unified nothing works. Has anyone else experienced this?

  • I have a XGS2300 HA-CLuster in active passive with 7 remote connections connected via SD-RAD 60. And one IPsec Site2Site-Tunnel connected to a cloud server. Any packet (ping is enough) from any network behind a RED to this cloud server or from the cloud server back will break the RED connection and force it to reconnect. Disbaled TLS1.2 for RED, re-created one og the RED interfaces, re-created the site2site Tunnel to tunnel-based, rebooted the firewall, set RED-Tunnel from Standard-split to standard-unified nothing works. Has anyone else experienced this?

  • fixed it by disabling IPsec acceleration....

  • Anyone seen this error migrating config after upgrading from SFOS 18.5.4 MR-4-Build418

    Database is upgrading to dbv19.003
    Check migration for version dbv19.003
    Applying migration for version dbv19.003
    1513 :send_data_to_listener: write error 'Network is unreachable'
    Cleaned up nasm directories using mv/rm
    Database is upgrading to dbv19.004
    Check migration for version dbv19.004
    Applying migration for version dbv19.004
    1520 2022-09-11 21:19:52.449 GMTERROR: update or delete on table "tblrootcainfo" violates foreign key constraint "tblvpncertificate_caid_fkey" on table "tblvpncertificate"
    1520 2022-09-11 21:19:52.449 GMTDETAIL: Key (companyid)=(54) is still referenced from table "tblvpncertificate".
    1520 2022-09-11 21:19:52.449 GMTSTATEMENT: delete from tblrootcainfo where caname in ('Lets_Encrypt_r3','AC_RAIZ_FNMT_RCM_SERVIDORES_SEGUROS','GlobalSign_Root_R46','GlobalSign_Root_E46','GLOBALTRUST_2020','ANF_Secure_Server_Root_CA','Certum_EC_384_CA','Certum_Trusted_Root_CA','TunTrust_Root_CA','HARICA_TLS_RSA_Root_CA_2021','HARICA_TLS_ECC_Root_CA_2021','vTrus_ECC_Root_CA','vTrus_Root_CA','ISRG_Root_X2','A_Trust_Root_07','DigiCert_RSA4096_Root_G5','DigiCert_SMIME_RSA4096_Root_G5','DigiCert_TLS_ECC_P384_Root_G5','DigiCert_TLS_RSA4096_Root_G5','DigiCert_SMIME_ECC_P384_Root_G5','DigiCert_CS_RSA4096_Root_G5','DigiCert_Client_RSA4096_Root_G5','DigiCert_Client_ECC_P384_Root_G5','DigiCert_ECC_P384_Root_G5','DigiCert_CS_ECC_P384_Root_G5','GlobalSign_Secure_Mail_Root_E45','GlobalSign_Secure_Mail_Root_R45','GlobalSign_Client_Authentication_Root_R45','GlobalSign_Client_Authentication_Root_E45','GlobalSign_Code_Signing_Root_E45','GlobalSign_Document_Signing_Root_R45','GlobalSign_Document_Signing_Root_E45','GlobalSign_Code_Signing_Root_R45','GlobalSign_Timestamping_Root_R45','Autoridade_Certificadora_Raiz_Brasileira_v10','DVV_Gov._Root_CA_G3_ECC','DVV_Gov._Root_CA_G3_RSA','HARICA_Code_Signing_RSA_Root_CA_2021','HARICA_Client_ECC_Root_CA_2021','HARICA_Client_RSA_Root_CA_2021','HARICA_Code_Signing_ECC_Root_CA_2021','Microsoft_Identity_Verification_Root_Certificate_Authority_2020','I.CA_Root_CA_ECC_12_2016','Telia_Root_CA_v2','Izenpe.com');
    psql:/_conf/DB/dbv19.004/corporate.sql:68: ERROR: update or delete on table "tblrootcainfo" violates foreign key constraint "tblvpncertificate_caid_fkey" on table "tblvpncertificate"
    DETAIL: Key (companyid)=(54) is still referenced from table "tblvpncertificate".
    /bin/psql -1 -p 5432 -U pgroot -q -d corporate -f /_conf//DB/dbv19.004/corporate.sql Failed
    /bin/sh /_conf//DB/dbv19.004/migration.sh Failed
    UPDATE 1
    Stopping database

    488 2022-09-11 21:19:55.104 GMTLOG: received fast shutdown request
    488 2022-09-11 21:19:55.105 GMTLOG: aborting any active transactions
    491 2022-09-11 21:19:55.105 GMTLOG: shutting down
    491 2022-09-11 21:19:55.736 GMTLOG: database system is shut down
    2022-09-11 21:19:56.143 GMT : Database stopped after 1 seconds
    applymigration.sh exited with 1
    2022-09-11 21:20:22.672 GMT: Before mountconf unmount

    Thanks

  • Hi and

    Have you any news for the poor spam recognition on v18.5 MR3 / v19.0 and versions above?

  • This is the last answer I got from the support:

    "Development has sent a proposal for handling "bulk" messages and change how the spam classification works in the MTA mode. After the proposal is approved by both Product Management and Labs, we schedule this new feature for an MR Release."

    They will get back to me this week, so at least there's some hope I guess.

  • Thanks for your effort and sharing your information!