NAT-Problem: Schnittstelle wird bei der Filterung nicht berücksichtigt.

[imagmbh]

Hallo zusammen,

die kurze Fassung:Ich habe hier das Problem, dass eine NAT-Regel angewandt wird, obwohl die Regel an ein Interface gebunden ist und das Paket auf dem Interface aber gar nicht zu sehen ist.

Das das Setup etwas umfangreicher ist, hier das vollständige Setup:

OPNsense 1: aktuelle OPNsense (OPNsense 22.1.10-amd64)
externes Interface 1 a.a.a.1
externes Interface 2 y.y.y.y/32 (Dummy-IP)
internes Interface 1: b.b.b.2
internes Interface 2: c.c.c.2

Es gibt eine Portweiterleitung von a.a.a.1:80 -> b.b.b.22:80, mit SNAT zu b.b.b.2 explizit an das externe Interface 1 gebunden.

OPNsense 2: OPNsense 21.7.8-amd64
externes Interface 1 d.d.d.3
internes Interface 1: c.c.c.3

Linux-System:
externes Interface 1 d.d.d.4
internes Interface 1: c.c.c.4

Testsystem
Interface c.c.c.5, default route c.c.c.4
hinter der OPNsense1

OPNsense1-ccc ist mit OPNsense2-ccc gebridged.
OPNsense1-yyy ist mit OPNsense2-ddd gebridged.
Über diese Bridge yyy/ddd ist auch das Linuxsystem mit ddd verbunden.
Über die Bridge ccc/ccc ist auch das Linuxsystem mit ccc verbunden.

Wird vom Testsystem die externe Adresse a.a.a.1:80 angesprochen, würde ich erwarten, dass das Paket
 1) auf Grund der default route über die Bridges an das Linux-System läuft,
 2) dort mit der externen IP (d.d.d.4) ins Internet geht,
 3) an der OPNsense 1 an der Adresse a.a.a.1 eingeht
 4) dort mit b.b.b.2 geSNATet wird und zu
 5) b.b.b.22 gelangt.

Ist die Portweiterleitung ausgeschaltet, ist das Datenpaket mit tcpdump genau so zu verfolgen, natürlich bis auf den Schritt der Portweiterleitung.

Ist die Portweiterleitung eingeschaltet, grätscht das SNAT jedoch dazwischen. Schon bevor das Paket über die Bridge läuft findet ein SNAT statt und damit hat das Paket die falsche Quelladresse.

Die Portweiterleitung und das SNAT ist explizit an das externes Interface 1 ddd gebunden, das Datenpaket taucht auf diesem Interface aber gar nicht auf, trotzdem wird geSNATed.

Hat jemand eine Idee, was hier falsch läuft? Wir haben uns temporär geholfen, in dem wir die SNATR-Regel explizit nicht greifen lassen, wenn eine private IP-Adresse betroffen ist (die ja auch einem externen Interface eh nicht auftaucht), aber so ein Workaround sollte doch eigentlich nicht notwendig sein.

Vielen Dank!

Martin

[JeGr]

Hi,

durch die seltsame IP-versteck-Variante mit Buchstaben und für mich nicht greifbare Zahlen, ist das ganze extrem schwer nachzuvollziehen. Ich kann bspw. nicht verstehen, warum die beiden OPNsensen irgendwie gebridged sind miteinander(?) und was das überhaupt bedeuten soll? Warum die beiden Sensen dann noch dazu auf unterschiedlichen Versionen laufen, warum das Linux System überhaupt die Firewall aushebelt indem es in beiden Netzen steht und einen Weg an den FWs vorbei zaubert etc.

Das ist alles so sehr undurchsichtig und macht beim Durchlesen nicht wirklich Sinn, dass es schwer ist, hier jetzt zu sagen "aus genau diesem Grund passiert das".

Was enorm helfen würde wäre ein Netzdiagramm/Plan in irgendeiner Form, damit man das optisch vielleicht besser versteht und noch ein zwei Takte zum "warum" das Setup so ist wie es ist (ist es virtuell? physisch? etc.) denn aktuell fehlt mir da einfach der Anhaltspunkt von dem an ich mich durcharbeiten könnte.

Ich verstehe dass man bei so einem Setup vielleicht keine IPs posten möchte, aber dann wäre es - wenns kritischer ist - vielleicht eh nicht verkehrt, wenn man sich jemand mit als Auditor/Dienstleister mit ins Boot holt, der entsprechend Verschwiegenheit abzeichnet und sich dann das ganze mal richtig sinnvoll ansehen kann. Dazu gibts von diversen Kollegen einschließlich mir gern die Bereitschaft zu.

Ansonsten wie gesagt wäre ein Plan und etwas mehr Details hilfreich um sich da überhaupt mal sinnvoll rantasten zu können

Cheers
\jens

[imagmbh]

Hallo Jens und danke für die Antwort.

Ich hatte die Buchstaben gewählt, weil ich es eigentlich einfacher machen wollte. Scheint nach hinten los gegangen zu sein. Ich versuche es mit Zahlen bildlicher darzustellen.

Der Hintergrund: Wir haben an mehreren Standorten die selben privaten IP-Bereiche, im Beispiel die 10.1.33, die mittels Bridging und den beiden OPNsense gekoppelt sind. Das klappt auch recht gut. Die Linux-Maschine ist das Gateway für die privaten Netzen, weil je nach Routing in andere private Netze recht grausame Firewall-Regeln greifen müssen. Die Linux-Maschine ist beim Problemfall jedoch nicht betroffen, da im Problemfall das Paket dort gar nicht ankommt.

Der Aufbau ist wie folgt:

Netzwerkplan:


                    rev.Proxy (Ziel)
                      10.1.82.11
                          |
Testclient (Quelle) - OPNsense1    -    TAP-Verbindung -   OPNsense2    -   Linux
   10.1.33.172       195.33.21.12                         166.32.43.17     166.32.43.200
   def. Route:        10.1.82.1
   10.1.33.1                                                                10.1.33.1
                          |                                                      |
                          L------------------- Internet -------------------------J


Anfrage: 10.1.33.172 -> 195.33.21.12:443

Soll-Datenfluss des Paketes:
1. Station: Quellrechner --- 10.1.33.172 -> 195.33.21.12:443, GW: 10.1.33.1
2. Station: OPNsense1 priv. eingeh. Interface (10.1.33.2) --- 10.1.33.172 -> 195.33.21.12:443
3. Station: OPNsense1 TAP-Interface  (vtnet3 + bridge0 + vtnet3TAP) --- 10.1.33.172 -> 195.33.21.12:443
4. Station: OPNsense2 TAP-Interface  (OpenVPN-TAP-Interface + Bridge + priv. ausgeh. Interface) --- 10.1.33.172 -> 195.33.21.12:443
5. Station: Linux-Maschine (IP 10.1.33.1), eingeh. Interface: 10.1.33.172 -> 195.33.21.12:443
6. Station: Linux-Maschine, ausgehendes Interface: 166.32.43.200 -> 195.33.21.12:443
7. Station: OPNsense1 (von oben), WAN-Interface mit der externen IP 195.33.21.12: 166.32.43.200 -> 195.33.21.12:443
8. Station: OPNsense1, priv. Interface (10.1.82.1) zum Proxy : 166.32.43.200 -> 10.1.82.11.443
9. Station: Proxy-Server, eing. priv. Interface: 166.32.43.200 -> 10.1.82.11.443

Der Datenfluss erfolgt auch so, wenn diese Portweiterleitungsregel aktiv ist:
Schnittstelle    Protokoll    Adresse    Ports    Adresse    Ports    IP    Ports    Beschreibung
WAN    TCP    ! T33 Netzwerk    *    WAN Adresse    443 (HTTPS)    10.1.82.11    443 (HTTPS)    rproxy

Das heißt, die Portweiterleitung greift nur, wenn
 a) Das Paket auf der WAN-Schnittstelle eingeht und
 b) das Paket NICHT aus dem 10.1.33.0/24er Netzwerk kommt.

Meines Erachtens nach ist die Bedingung b) eigentlich überflüssig. Da die WAN-Schnittstelle die externe Schnittstelle ist, darf das Paket mit der Paketabsenderadresse 10.1.33.172 auf der Schnittstelle nicht auftauchen, die b)-Bedigung ist also immer erfüllt.

Wenn ich die b)-Bedingung jedoch weglasse, also diese Regel nehme:
WAN    TCP    *    *    WAN Adresse    443 (HTTPS)    10.1.82.11    443 (HTTPS)    rproxy

Wird der reale Datenfluss falsch:
1. Station: Quellrechner --- 10.1.33.172 -> 195.33.21.12:443, GW: 10.1.33.1
2. Station: OPNsense1 priv. eingeh. Interface (10.1.33.2) --- 10.1.33.172 -> 195.33.21.12:443
3a. Station: OPNsense1 TAP-Interface (vtnet3 + bridge0) --- 10.1.33.172 -> 195.33.21.12:443
3b. Station: OPNsense1 TAP-Interface  (vtnet3TAP) --- 10.1.33.172 -> 10.1.82.11:443

Das heißt, die Portweiterleitungs-NAT-Regel hat innerhalb der Bridge zugeschlagen, obwohl das Interface, auf dem die Filterregel greifen soll, gar nicht beteiligt ist. Das Datenpaket nimmt den kürzesten Weg zum Ziel, darf diesen Weg aber nach Routing gar nicht nehmen.

Viele Grüße

Martin