Routing Probleme

[ping]

Hallo Ihrs,

mir ist folgendes Aufgefallen. Vielleicht habt Ihr eine Idee.

Das im Diagramm zu sehende Netzwerk funktioniert soweit mit einem anderen Produkt in der ver. 2.3, welches mit Opnsense ersetzt werden soll.  Die Router sind teilweise das andere Produkt und Opnsense in der Version 17.7.
Nach diversen 18.1 Installationen bis hin zu 18.7 rc1 funktioniert die Firewall (FW im Diagramm)  leider nicht so wie sie soll.

Im Live View wird angezeigt das es eine Kommunikation nach draußen gibt (NAT / http und https) also nicht von der FW geblockt wird, jedoch nichts als Antwort „zurückkommt“.

Im Firewall Diagnostics:states dump sehe ich das der State
Syn_sent:closed bzw. closed:sync_sent ist.

Versuche ich jedoch eine web Adresse aus dem nicht gerouteten Netz (192.168.1.0/24) zu erreichen geht alles.

Nur nicht von den „Fremden“  (192.168.10.0/24; 192.168.20.0/24; 192.168.30.0/24; etc.) Netzen die in das Netz, wo die Firewall ist geroutet sind.  Alle Netze sind intern gegenseitig erreichbar. Natürlich sind auf der FW alle Netze und die entsprechenden GW eingetragen.

Nach langem testen bin ich zurück auf die Opnsense version 17.7.5 gegangen. Habe alle nötigen Einstellungen erneut vorgenommen und siehe da es funktioniert alles einwandfrei.

Bei einem update auf 17.7.12_1 funktionierte alles auch ohne Probleme.

Bei einem Upgrade auf 18.1.6 leider nicht mehr. Ohne die Einstellungen verändert zu haben.

Nun ist die Frage wo ist der Unterschied in der Funktionalität der FW / NAT  / Routing?
Übersehe ich etwas in mit der aktuellen Version von Opnsense ?

Mit freundlichem Gruß
Ping

WAN / Internet
 
      .-----+-------.
      |  Gateway |  (whatever-Provider)
      '-----+-------'
             | Offizielle IP
    WAN |
             |
      .-----:-----------.
      |  OPN:sense  |
      |  (FW):          |
      '-----:-----------'
              |             
       LAN |192.168.1.1
              |             
      .-----+---------.
      | LAN-Switch +-------------+----------------------+--------- etc.
      '-----+----------'                 |                             |
             |                               |                             |
       LAN|192.168.1.2      LAN|192.168.1.3    LAN|192.168.1.4
             |                               |                             |
      .-----:------------.       .-----:-----------.      .-----:-----------.
      |  OPN:sense  |       |  OPN:sense |      |  OPN:sense |
      | (Rou:ter)      |       | (Rou:ter)     |      | (Rou:ter)     |
      '-----:------------'       '-----:-----------'      '-----:-----------'
            |                               |                                |             
     LAN |192.168.10.2   LAN |192.168.20.2   LAN |192.168.30.2
            |                               |                               |             
    ...-----+------...         ...-----+------...           ...-----+------...
        (Clients)                  (Clients)                   (Clients)

[mimugmail]

Da gabs irgendeinen Change im NAT .. such mal im Forum nach 18.1 und NAT. Eigentlich sollte das schon gefixt sein, vielleicht wurde da ein altes Setting von 17.7.5 mitgenommen.

[ping]

hallo  mimugmail,

wie gesagt es funktioniert auch nicht mit neu Installiertem 18.1.6.
Ich habe ein weiteres Setup was nicht mehr mit der neuen Version funktioniert.
Bei einer FW war der Speicher defekt.
Neu Installation mit 18.1.6.
Wieder Routing NAT Problem.
Eine FW mit drei Netzwerkkarten. Kein Internet / Surfen aus der DMZ heraus möglich.
Mit 17.7 funktionierte alles, also Internet Zugang vom LAN und der DMZ.

Vielen Dank für deine Antwort und den Hinweis, werde noch einmal genauer schauen ob ich in der Richtung etwas im Forum finde.

Gruß
ping

[ping]

Hi Ihrs,

ich habe folgendes im Forum gefunden
https://forum.opnsense.org/index.php?topic=8000.msg37017#msg37017
Ähnliches Problem.

Durch Umstellung in
Firewall->NAT->Outbound
Von
Automatic outbound NAT rule
hinzu
Hybrid outbound NAT rule.

Dann für das jeweilige Subnet die Berechtigung erlauben.
z.B.
Interface       WAN
Protocol       TCP
Destination Port    http
Translation / target     WAN Address

Nun funktioniert die Kommunikation aus den Subnetzen wie unter 17.7.
Das wurde vorher Definitiv nicht benötigt.

Es ist ein heidenaufwand nun alle Regeln doppelt einzugeben.
Einmal auf dem LAN Interface und einmal als outbound NAT Regel.
Ist auch in der neuesten Version 18.7 rc so.
Gibt es dafür einen Grund weshalb es nun so Umständlich ist?

Ich hoffe das Problem tritt nicht auf wenn die Opnsense nur als Router Konfiguriert wird. Da ich dort kein NAT habe.
Werde ich aber im Laufe der Woche testen.
Wenn jemand eine elegantere Lösung für das Problem hat würde es mich freuen davon zu hören.

Danke nocheinmal an mimugmail für den Suchtip

Gruß
ping

[theq86]

PS: pfSense ist nicht Voldemort. Solang alles in geordneten Bahnen geht darf man das ruhig schreiben :-D

[mimugmail]

Du brauchst doch nur eine Outbound NAT Regel und den Rest steuerst du mit ACLs?
Da versteh ich grad das Problem nicht

Mach mal ein Update auf die letzte Version, dann stell auf hybrid. Ganz unten siehst du dann welche Netze automatish genattet werden. Wenn das zusätzliche nicht auftauscht eine manuelle Regel rein.

[ping]

@nasq:
-Namen Pöser Purschen soll man nicht „laut“ ausschreiben

@mimugmail:
-du meinst also einmal alles auf NAT freigeben und per FW Regel erlauben?
-Stimmt so sollte es gehen.
-Letzte Version ist installiert.
-Als automatisch sind nur Netze die auch auf der FW sind aufgeführt. Keine Subnetze.
-Weiterhin erschließt sich mir der Sinn nicht weshalb man das nun so machen muss. Wozu dann noch das -automatische NAT? nur für Physisch am FW anliegende Netze ? Ich will es nur verstehen. Weshalb diese Änderung -hat es eventuell andere Vorteile?


Btw. Habe den Router mit 6 Netzwerkkarten jetzt auch umgestellt und es funktioniert alles. Muss also wirklich eine Sache von dem NAT sein. Was auch immer da geändert worden ist.

Ich hoffe ich komme die Tage noch zu der FW mit der DMZ, da gab es auch dieselben probleme.

Gruß
ping

[mimugmail]

Also im Homebereich macht man das so. Alles was das WAN Interface verlässt wird auch die WAN Adresse genattet. Das dürfte dann per Default für das Net von LAN gelten und bei zusätzlichen manuell rein.

Ich habs aber nicht genau verfolgt weil es für einen der mit der Logik klar kommt sich automatisch erschliesst.
Jedenfalls wenn nicht drin steht kommts rein und gut ists.

[ping]

Hi Ihrs,

@mimugmail:
So wie du das jetzt sagst; dahingehend wurde es geändert. Deswegen war ich so verwundert.

Den Hybrid Modus habe ich bis jetzt nur für aufwendigere Openvpn Verbindungen benutzen müssen. Wo z.B.  von der Außenstelle kein Internet Zugang möglich ist und komplett zurück zur Niederlassung kommen muss ohne NAT an der FW der Außenstelle.

Und JA für daheim passt es

Vorher war es halt anders. Auch bei anderer FW-software.
Mir stellt sich nur die Frage wie sich das System dann mit anderen Komponenten verhält. Sprich muss man nun z.b bei anderen Plugins HA-Proxy, letscrypt auch zusätzliche Einstellungen vornehmen.
Etwas einschalten, ausschalten, erlauben oder gar verbieten? Das werde ich bei den nächsten FW’s mit diesen plugins sehen, die ersetzt werden.

Daß es nicht ganz so einfach ist zeigen die Probleme die andere User damit haben. Mit eingehendem NAT/PF. Mal sehen wohin sich das entwickelt.

Beim Einsatz in der Produktion ist es schon ein Aufwand. Vor allem wenn sich das Verhalten in dieser Art einfach aus nicht ersichtlichem Grund ändert. Deswegen ja mein Interesse daran weshalb es so gemacht worden ist.

Jedes kleine bisschen Wissen über die Software die man Einsetzt hilft eventuell später bei anderen Problemen weiter.

Verstehe mich nicht falsch.
Ist keine Kritik an Opnsense. Die Entwickler Wissen schon was sie tun.  Eventuell ist es für spätere Versionen und deren Ideen auch notwendig das jetzt so umzusetzen.

Ich habe großen Respekt vor allen die Mithelfen das die Software reift und immer besser wird. Auch alle Helfer hier im Forum. Einfach Klasse.

Vielen Dank an Alle an dieser Stelle.

Gruß
ping