Messages

1

General Discussion / GIF-Interface and changeing or choosing the local address

« on: October 04, 2024, 11:53:35 am »

Hello,

it seems to be impossible to change the local address or the local interface in a GIF-interface to something other than WAN.

I had an gif0-Interface with the WAN-Interface as parent, local address "WAN". Now my internet-traffic will use another interface, called WAN2, the old interface WAN will be disabled. So I tried to change the local address of the gif0 to WAN2 and applied the changes. The problem: In the overview WAN is still shown, if I edit the interface, WAN2 is shown.

I created a new GIF-interface, gif1 with WAN2 as local address: Same behaviour: The overview told me, the address would be WAN, editing says WAN2.

Is it a bug in the user interface or is it not possible to use an other interface than WAN?

Regards

2

23.1 Legacy Series / Confused by Gateway Monitor

« on: July 25, 2023, 03:22:34 pm »

Hello,
I am a little bit confused. I have the following set up: 2 Gateways, one DSL and the second LTE. Both have seperate Routers that have public IP Adresses. So I set up to monitor the external DSL IP Adress, the other router should only have when connected to DSL. It worked until there was a failure and a reconnect. The gateway was marked as down, I could ping the externel IP adress from the consol, also I could access the OPNSense via the external IP Adress but the webinterface showed down.
Am I missing something, shouldn't the Interface be monitored regularly whe I enter an IP adress there?

3

German - Deutsch / Datenpakete werden in Bridge verworfen

« on: July 22, 2022, 09:54:17 pm »

Hallo zusammen,

noch ein Problem mit zwei gebridgeten OPNsense. Sinn: Wir haben zwei Provider an unterschiedlichen Standorten A + B, an beiden Standorten haben wir öffentliche IP-Netzbereiche. Nun steht leider eine Maschine an Standort A, soll aber eine externe IP von Standort B haben. Daher haben wir das externe Interface der OPNsense von Standort A mit einem Opt-Interface der OPNsense an Standort B gebridged und können so die IP des Standorts B an Standort A nutzen.

Server               OPNsense Standort A                      OPNsense Standort B
                     WAN: öff. IP 195.33.21.12/26 
öff. 166.32.43.201----WANBR: ohne weitere öff. IP --------------via Bridge-----WAN: öff. 166.32.43.200
     Netzmaske 24                                             Netzmaske 24                                           
                     privates LAN 10.1.61.1/24
 
                     Testmaschine: 10.1.61.17
                     Ping an 166.32.43.201

Das vtnet2-Interface und das WANBR-Interface bilden auf der OPNsense A die Bridge0
                     
1. Schritt: Testmaschine 10.1.61.17->166.32.43.201
2. Schritt: OPNsense A, LAN-Interface: 10.1.61.17->166.32.43.201
3. Schritt: OPNsense A, WAN-Interface: 195.33.21.12->166.32.43.201
4. Schritt: OPNsense B, WAN-Interface: 195.33.21.12->166.32.43.201
5a. Schritt: OPNsense A, WANBR-Interface TAP-Interface: 195.33.21.12->166.32.43.201
5b. Schritt: OPNsense A, Bridge0-Interface: 195.33.21.12->166.32.43.201
5c. Schritt: OPNsense A, vtnet2-Interface: nichts mehr zu sehen

Auf der OPNsense A gibt es sowohl für das WANBR-Interface als auch für das vtnet2-Interface "alles erlauben" Firewall-Regeln.

Mein Problem: Warum wird das Datenpaket im Bridge-Code verworfen?

Ein Ping von anderer Stelle im Internet funktionert.

Auch ein Ping von der OPNsense A aus funktionert, mit tcpdump ist in Schritt 5a und 5b dasselbe zu sehen (also 195.33.21.12->166.32.43.201, da ja auch die OPNsense A mit der Adresse 195.33.21.12 ins Netz geht), aber nun gibt es auch einen Schritt
5c. Schritt: OPNsense A, vtnet2-Interface: 195.33.21.12->166.32.43.201

Viele Grüße

Martin
 

4

German - Deutsch / Re: NAT-Problem: Schnittstelle wird bei der Filterung nicht berücksichtigt.

« on: July 22, 2022, 09:08:35 pm »

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

5

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

« on: July 21, 2022, 05:22:24 pm »

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

6

21.1 Legacy Series / Re: Bug or feature: selection all / no interfaces in a floating rules

« on: April 20, 2021, 05:13:00 pm »

Thanks for your answer and your hint!

7

21.1 Legacy Series / Re: Bug or feature: selection all / no interfaces in a floating rules

« on: April 19, 2021, 04:06:49 pm »

It was tested from a host in the WAN-Subnet.

8

21.1 Legacy Series / [SOLVED] Bug or feature: selection all / no interfaces in a floating rules

« on: April 16, 2021, 05:20:04 pm »

Hello,

we found an irritating beaviour: Creating a floating rule and selecting the the correct interface (WAN) or all interfaces for the the rule (e.g. IN-Rule for Port 443 for configuration) results in a non-accessibility of the configuration page. Explicit selecting none interfaces ("Select Interfaces ...") results in the desired behavior, the configuration page ist accessible from the WAN-side.

We find this behavior illogical, is it a bug or a feature?

Martin