Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 26 subscribers
  • Views 1532 views
  • Users 0 members are here
Options
Suggested
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

SD RED 60 Traffic issue

Christopher Rettig

Before the traffic issue the RED SD 60 was disconnects severla times the morning, only a power off solves this issue

I got a customer with a issue depending thr traffic and connection.

He uses a RED SD 60 and XG Firewall 

Typ: XG230

SFOS 18.0.4 MR-4

RED is running on 3.0.004 As an example over the weekend the customer only had 100 KB traffic available through the red, no more...this is really bad performance.

Any ideas? We already replaced the RED device two times through Sophos Support bit it did not changed the isse...Only pull off the power helpf solving this issue temporerarily

Kind Regards

Christopher



This thread was automatically locked due to age.
Parents
  • FormerMember
    0 FormerMember

    Hi ,

    Thank you for reaching out to the Community! 

    Could you please provide the support case numbers by sending a private message? 

    Did this issue start after the firmware update on your firewall? 

    Please share the red logs from your firewall around the time frame the issue occurred. 

    Thanks,

Reply
  • FormerMember
    0 FormerMember

    Hi ,

    Thank you for reaching out to the Community! 

    Could you please provide the support case numbers by sending a private message? 

    Did this issue start after the firmware update on your firewall? 

    Please share the red logs from your firewall around the time frame the issue occurred. 

    Thanks,

Children
  • 0 in reply to FormerMember

    Hi,

    the device hangs several times a day, sometimes only in the monring.

    Here are some log excerpts from 23rd february where a disconnect happened at 03:16pm

    red.log

    +++

    Reading REDv2 key from STDIN:
    Tue Feb 23 15:15:56 2021 REDD INFO: Red devices: Connected: 14 Disconnected 2 Enabled: 16 Disabled: 0
    Reading REDv2 key from STDIN:
    Tue Feb 23 15:20:57 2021 REDD INFO: Red devices: Connected: 13 Disconnected 3 Enabled: 16 Disabled: 0
    Tue Feb 23 15:22:47 2021 REDD ERROR: server: Can not do SSL handshake on Socket accept from '62.216.204.46': SSL accept attempt failed because of handshake problems
    Tue Feb 23 15:22:49 2021 REDD INFO: server: New connection from 62.216.204.46 with ID R60001W24MH67C3 (cipher ECDHE-RSA-AES256-GCM-SHA384), rev1

    +++

    syslog.log

    +++

    Feb 23 15:16:23 (none) user.warn kernel: [3396671.669614] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:16:24 (none) user.warn kernel: [3396672.690743] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:16:25 (none) user.warn kernel: [3396673.714730] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:16:26 (none) user.err kernel: [3396674.738685] mm_skb_destructor: it should be called only in case of skb purging on arp failure
    Feb 23 15:16:26 (none) user.err kernel: [3396674.738697] mm_skb_destructor: it should be called only in case of skb purging on arp failure
    Feb 23 15:16:26 (none) user.err kernel: [3396674.738704] mm_skb_destructor: it should be called only in case of skb purging on arp failure
    Feb 23 15:16:30 (none) user.warn kernel: [3396678.704051] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:16:31 (none) user.warn kernel: [3396679.734738] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:16:32 (none) user.warn kernel: [3396680.754763] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:16:33 (none) user.err kernel: [3396681.778697] mm_skb_destructor: it should be called only in case of skb purging on arp failure
    Feb 23 15:16:38 (none) user.warn kernel: [3396686.707907] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:16:39 (none) user.warn kernel: [3396687.730761] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:16:40 (none) user.warn kernel: [3396688.758799] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:16:41 (none) user.err kernel: [3396689.778723] mm_skb_destructor: it should be called only in case of skb purging on arp failure
    Feb 23 15:16:48 (none) user.warn kernel: [3396697.385791] red_rx_crypto: 25 callbacks suppressed
    Feb 23 15:16:48 (none) user.err kernel: [3396697.385791] RX: decryption failed
    Feb 23 15:16:48 (none) user.err kernel: [3396697.385793] reds9: red_rx_done: Decryption failed
    Feb 23 15:16:49 (none) user.info kernel: [3396698.142717] reds16: auto-removing peer 62.216.204.46:45364
    Feb 23 15:16:50 (none) user.warn kernel: [3396698.994704] red_tx_skb: 9 callbacks suppressed
    Feb 23 15:16:50 (none) user.err kernel: [3396698.994705] no peer (tx)
    Feb 23 15:16:50 (none) user.err kernel: [3396698.994706] no peer (tx)
    Feb 23 15:16:50 (none) user.err kernel: [3396699.058706] no peer (tx)
    Feb 23 15:16:50 (none) user.err kernel: [3396699.058711] no peer (tx)
    Feb 23 15:16:50 (none) user.err kernel: [3396699.058714] no peer (tx)

    ++++

    The hanging state at this time took round about six minutes, if i check the syslog.lol at 03:22 (six minutes later) i can see the following:

    +++

    Feb 23 15:22:47 (none) user.err kernel: [3397055.959199] mm_skb_destructor: it should be called only in case of skb purging on arp failure
    Feb 23 15:22:47 (none) user.err kernel: [3397056.105508] no peer (tx)
    Feb 23 15:22:51 (none) user.warn kernel: [3397060.211184] red_tx_skb: 116 callbacks suppressed
    Feb 23 15:22:51 (none) user.err kernel: [3397060.211185] no peer (tx)
    Feb 23 15:22:51 (none) user.err kernel: [3397060.211189] no peer (tx)
    Feb 23 15:22:51 (none) user.err kernel: [3397060.211193] no peer (tx)
    Feb 23 15:22:51 (none) user.err kernel: [3397060.211197] no peer (tx)
    Feb 23 15:22:51 (none) user.err kernel: [3397060.211201] no peer (tx)
    Feb 23 15:22:51 (none) user.err kernel: [3397060.211204] no peer (tx)
    Feb 23 15:22:51 (none) user.err kernel: [3397060.211208] no peer (tx)
    Feb 23 15:22:51 (none) user.err kernel: [3397060.211211] no peer (tx)
    Feb 23 15:22:51 (none) user.err kernel: [3397060.211215] no peer (tx)
    Feb 23 15:22:52 (none) user.warn kernel: [3397060.894044] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:22:52 (none) user.err kernel: [3397060.909566] no peer (tx)
    Feb 23 15:22:53 (none) user.warn kernel: [3397061.907237] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:22:54 (none) user.warn kernel: [3397062.935214] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:22:55 (none) user.err kernel: [3397063.955196] mm_skb_destructor: it should be called only in case of skb purging on arp failure
    Feb 23 15:22:55 (none) user.err kernel: [3397064.346764] RX: decryption failed
    Feb 23 15:22:55 (none) user.err kernel: [3397064.346766] reds16: red_rx_done: Decryption failed
    Feb 23 15:22:56 (none) user.info kernel: [3397064.857950] Autoadd peer 0
    Feb 23 15:22:56 (none) user.info kernel: [3397064.857954] reds16: Auto-adding peer 0 (from 62.216.204.46:45397 to 62.204.174.121:3410)
    Feb 23 15:24:34 (none) user.warn kernel: [3397163.329240] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
    Feb 23 15:24:35 (none) user.warn kernel: [3397164.339400] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL

    +++

    I asked the customer/partner if there has been a firmeare upgrade, but i dont think so.

    Kind regards

    Christopher

  • 0 in reply to Christopher Rettig

    Case numbers has been sent via private message

  • FormerMember
    0 FormerMember in reply to Christopher Rettig

    Hi ,

    Thank you for the update. 

    I've added an internal note on your current support case, and your case has been escalated to the escalation team. 

    Thanks,