OpnSense - Vorsicht beim Klonen von Regeln

Hi zusammen,

Wollte mich eigentlich an euch wenden, dass ihr mir helft.
Beim Zusammenstellen der Fotos und beim Vergleich von Regeln ist mir dann doch der Fehler selbst aufgefallen. Ich poste das hier nur noch als Warnung für andere:

Ich habe zwei ROTE IPs und natürlich den server in Grün 10.16.1.1, IP 1 ist …172 und IP 2 ist 173. Die zweite IP ist meine OpnSense, die ich konfiguriert habe, dass sie z.B. 636 per Port forward auf den Server leiten.
Mein grundsätzliches Problem ware: bei port 636 tut alles, alle anderen Ports, die ich konfigureiren wollte, funktionierte nichts, z.B. Port 389, etc. bei dem Belwue-router war alles identisch zu 636 konfiguriert.

So sehen die OpnSense Regeln von außen aus (die zwei unteren sind wichtig)

Ich weiß, dass aus diesen port forwarding unter NAT Regeln dann die WAN-Regeln automatisch erstellt werden, auch dort sind die Regeln scheinbar identisch, außerdem hab ich ein nmap auf einige ports losgelassen (von der …172 aus) um zu schauen, was scheinbar offen ist:

nmap xxxx.173 -p 80,389,443,445,636,3333,9980
...
PORT     STATE    SERVICE
80/tcp   filtered http
389/tcp  filtered ldap
443/tcp  filtered https
445/tcp  filtered microsoft-ds
636/tcp  open     ldapssl
3333/tcp filtered dec-notes
MAC Address: xxxxxx (QEMU virtual NIC)
...

Auch noch die Live-Logfiles der OpnSense waren interessant, die zu diesem nmap gehören:

Man sieht, dass 636,389,445 gleich behandelt werden, 80 und 3333 dagegen nicht, das liegt daran dass ich für die ersten drei Regeln wie oben hatte, für die letzten zwei nicht. Warum 443 gar nicht auftuacht liegt wohl an der OpnSense selbst, weil 443 ja das webinterface der OpnSEnse ist…
Trotzdem sieht man am NMAP output dass nur 636 durchgelassen wird.

Lange Rede, hier ist die Lösung: Beim Clonen der Regeln von 636 auf andere regeln (wie z.B. 389) darf man ganz unten die Filter Association Rule nicht einfach belassen. Wenn man nämlich ok drückt, wird eine angelegt, die irgendwie nicht stimmt, bei mir im Beispiel habe ich jetzt dasselbe wie Port 636 gemacht für Port 12345 und die Association Rule darf nicht so heißen wie angegeben, sondern es muss „pass“ gewählt werden (was bei mir in der Regeln für 636 auch steht).

Kaum macht man es richtig, schon tuts!

VG, Tobias

Hi zusammen,
mit der Aussage „richtig machen“ bin ich mal ein bisschen vorsichtig. Ich stelle nur fest, dass es jetzt damit geht.
Bisher gingen auch alle NAT-Verbindungen von außen mit diesen assoziierten Filterregeln, nur vom eigenen IP-Adressbereich in rot habe ich die Verbindung nicht hingekriegt (außer bei 636 und es ist unklar, warum es dort funktionierte).
Sobald ich jetzt die Regelassoziation auf „Pass“ stelle komme ich auch von innerhalb des IP-Bereichs an die internen Server. Mir ist unklar, wie das NATing funktioniert und warum es jetzt funktioniert.