Project

General

Profile

Actions

action #104730

closed

"Direct Rules" der Firewall greifen nicht mehr.

Added by flacco over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Bug
Target version:
Start date:
2022-01-09
Due date:
2022-01-31
% Done:

100%

Estimated time:

Description

Im Firewall-Setup des invis-Servers haben wir vor einiger Zeit einen Satz an "Direct-Rules" hinzugefügt. Hier die zugehörige XML-Datei:

<?xml version="1.0" encoding="utf-8"?>
<direct>
<!--  <rule ipv="ipv4" table="nat" chain="POSTROUTING" priority="0">-o intern -j MASQUERADE</rule> -->
  <rule ipv="ipv4" table="filter" chain="FORWARD" priority="0">-i vpn -o intern -j ACCEPT</rule>
  <rule ipv="ipv4" table="filter" chain="FORWARD" priority="0">-i intern -o vpn -m state --state RELATED,ESTABLISHED -j ACCEPT</rule>
</direct>

Die hier gesetzten Regeln dienten dazu ein Class-Routing zwischen den Schnittstellen "intern" und "vpn" zu ermöglichen. Beide Schnittstellen sind Teil der Zone "internal". Ohne diese Regel war es nicht möglich via VPN auf Netzwerkkomponenten hinter dem invis-Server zuzugreifen.

Unter openSUSE 15.3 (invis 14.3) scheinen diese Regeln nicht mehr zu greifen.

Vermutlich liegt das daran, dass inzwischen "nftables" anstelle von "iptables" als Firewall-Backend genutzt wird.


Related issues 1 (0 open1 closed)

Related to invisAD-setup - action #54860: Firewall: NAT Rules for inbound Routing via VPN are missing.Closedflacco2019-07-302020-06-01

Actions
Actions #1

Updated by flacco over 2 years ago

  • Related to action #54860: Firewall: NAT Rules for inbound Routing via VPN are missing. added
Actions #2

Updated by ingogoeppert over 2 years ago

Auf https://firewalld.org/documentation/man-pages/firewalld.direct.html Abschnitt Caveats wird auf solche Probleme mit anderen Backends eingegangen:
Schnelle Lösung könnte ein (temporärer) Wechsel auf das bisherige Backend sein (4.). Danach dann eine der besseren Lösungen (1. bis 3.).

Actions #3

Updated by flacco over 2 years ago

Wir sollten uns mit "Rich rules" auseinandersetzen. Wäre vermutlich damals schon der bessere Weg gewesen.

Actions #4

Updated by flacco over 2 years ago

Evt. könnten wir das VPN Interface in diesem Zuge in eine eigene Zone verschieben. z.B. "work". Das sollte auch das Routing vereinfachen, da es dann ja kein Routing zwischen zwei Interfaces einer Zone sondern Routing zwischen zwei Zonen ist.

Actions #5

Updated by flacco over 2 years ago

Neu in firewalld: Intra Zone forwarding: https://firewalld.org/2020/04/intra-zone-forwarding

Actions #6

Updated by flacco over 2 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 90

So einfach kann es sein:

Ich habe die Datei "direct.xml" aus dem Spiel genommen und statt dessen die Zonen-Datei der internen Zone um folgende Zeile ergänzt:

 <forward/>

Danach funktioniert erst mal alles wieder wie gewohnt.

Ob der Aufwand mit einer eigenen Zone dagegen Sinn macht sollten wir noch mal besprechen.

Actions #7

Updated by ingogoeppert over 2 years ago

  • % Done changed from 90 to 100

Nein, wenn das so geht ist das doch Ok. Falls später mal ein Anwendungsfall kommt, in dem eine eigene Zone notwendig ist, können wir das immer noch machen.

Actions #8

Updated by flacco over 2 years ago

  • Status changed from Resolved to Closed

Einverstanden

Actions

Also available in: Atom PDF