Project

General

Profile

Actions

action #122653

closed

QA (public) - coordination #121720: [saga][epic] Migration to QE setup in PRG2+NUE3 while ensuring availability

QA (public) - coordination #116623: [epic] Migration of SUSE Nbg based openQA+QA+QAM systems to new security zones

openQA Project (public) - coordination #122650: [epic] Fix firewall block and improve error reporting when test fails in curl log upload

Ask SUSE-IT network admins to REJECT packets instead of DROP so that we get more clear results size:S

Added by okurz almost 2 years ago. Updated almost 2 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Start date:
2023-01-03
Due date:
% Done:

0%

Estimated time:
Tags:

Description

Motivation

When there is traffic blocked in the network dropped packets cause a lot of confusion, e.g. see #122539. If possible the firewall should be changed to REJECT rather than DROP packets in the hope that this gives more clear error messages

Acceptance criteria

  • AC1: An example command failure due to firewall-rejected (rather than dropped) traffic is shown within the SUSE network

Suggestions


Related issues 1 (0 open1 closed)

Copied to openQA Infrastructure (public) - action #122656: Ask SUSE-IT network admins to *not* block this traffic which we need for tests regarding s390x within SUSE network size:MResolvedokurz2023-01-03

Actions
Actions #1

Updated by okurz almost 2 years ago

  • Target version set to Ready
Actions #2

Updated by okurz almost 2 years ago

  • Copied to action #122656: Ask SUSE-IT network admins to *not* block this traffic which we need for tests regarding s390x within SUSE network size:M added
Actions #3

Updated by livdywan almost 2 years ago

  • Subject changed from Ask SUSE-IT network admins to REJECT packets instead of DROP so that we get more clear results to Ask SUSE-IT network admins to REJECT packets instead of DROP so that we get more clear results size:S
  • Status changed from New to Workable
Actions #4

Updated by okurz almost 2 years ago

  • Due date set to 2023-02-24
  • Status changed from Workable to Feedback
  • Assignee set to okurz

Discussing with lhaleplidis. The firewall supports a TCP_RESET so it depends if the applications handle it properly. The proper way would be to respond with "port unreachable". So maybe we don't want this. lhaleplidis will create a ticket about this so that we should be able to track this.

Actions #5

Updated by okurz almost 2 years ago

  • Due date deleted (2023-02-24)
  • Status changed from Feedback to Rejected

We will either hear about it or not. I don't consider this important enough for me to track within our clogged-up backlog.

Actions

Also available in: Atom PDF