Namensauflösung der Firewall für Hostnamen in Regeln

[h4p4t3]

Hallo zusammen,

nach dem Upgrade auf 18.1 haben wir ein Problem mit der Namensauflösung der Firewall. Diese hat als DNS-Server des Netzwerks eine Fritzbox (über die der Internet-Zugang bereitgestellt wird) sowie einen weiteren internen DNS-Server eingestellt.

Zzt. funktioniert der Zugriff auf einen externen Mailserver nur mit Unterbrechungen. Der externe Mailserver ist über einen Hostnamen bzw. zwei verschiedene IP-Adressen erreichbar. In der Firewall war lediglich der Hostname eingetragen, was bis einschließlich 17.7 auch kein Problem war. Seit dem Upgrade auf 18.1 funktionniert der Mailzugriff nur noch sporadisch. Es zeigt sich, dass die Namensauflösung zwar funktioniert, aber es wird nur zu der einen IP-Adresse aufgelöst. Versucht der Client sich über den Hostnamen mit der anderen IP-Adresse zu verbinden, wird er zurückgewiesen.

Ich habe zur Kontrolle die Regeln aufgesplittet - die erste Regel erlubt den Zugriff über den Hostnamen, die zweite Regel erlaubt den Zugriff über bei die IPs. Eigentlich würde ich erwarten, dass die zweite Regel nicht benötigt wird, das Protokoll der Firewall beweist aber das Gegenteil.

Gibt es hier eine Stellschraube, an der sich drehen lässt?

Dank & Gruß
Jens

[h4p4t3]

Als Ergänzung:

Ein host imap.mail.example ergibt
imap.mail.example is an alias for mail.farm.mail.example.
mail.farm.mail.example has address ###.###.###.124

Der Zugriff auf die *.124-Adresse wird jedoch erst durch die IP-basierte Regel freigegeben, die auf dem Hostname basierende Regel schlägt also nicht an.

[h4p4t3]

Und spätestens jetzt bin ich völlig ratlos:

[h4p4t3]

Ähnliche Effekte im Log treten auch hier auf: https://forum.opnsense.org/index.php?topic=7169.0

Ingrid

[h4p4t3]

Hmm,

kann das niemand nachvollziehen?

Oder habe ich einen gedanklichen Fehler, mangelt es an Informationen ... ?

[JeGr]

Im verlinkten Beitrag bin ich mir nicht schlüssig, ob das wirklich ein block nach einem pass ist, da man die TCP Flags nicht sehen kann. Es ist gut möglich, dass der allow auf ein S Package ging und ein falsches / asymmetrisches Routing zu dem Block danach führt. Dazu bräuchte man aber detailliertere Logs.

@Franco et al: Gibt es eigentlich einen spezifischen Grund, warum in den opnsense firewall logs die Flags nicht mehr in der Übersicht gelistet sind (und auch bei den Details sind keine angegeben)? In so einem Fall wie oben, wäre das durchaus interessant ob das SYN oder FIN/ACK oder sonstwas Pakete sind.

[franco]

Eine Erweiterung ist in Arbeit: https://github.com/opnsense/core/issues/2195

Die Flags sind in den Details, aber nur wenn diese auch gesetzt sind (TCP).


Grüsse
Franco

[JeGr]

> Die Flags sind in den Details, aber nur wenn diese auch gesetzt sind (TCP).

Hmm das ist merkwürdig denn ich habe in der Test VM TCP Blocks, bei denen keine Flags angegeben sind. Das wäre schon recht ungewöhnlich, da das eigentlich hätten SYNs sein müssen. *grübel*

[franco]

Hmpf, da stimmt was nicht. Die Flags sind die TCP Options in der GUI, die Flags tauchen gar nicht auf. Brb...

[franco]

Ein Anfang... https://github.com/opnsense/core/commit/44d4fa90

# opnsense-patch 44d4fa90

Wer die Spezifikation liest ist klar im Nachteil, wenn die Implementation nicht dazu passt.


Grüsse
Franco

[h4p4t3]

So, in der Hoffnung, dass sich etwas durch die anstehenden Updates verändert, habe ich das Thema ausgesessen. Hat leider nicht komplett geholfen. Das Log sieht relativ ok aus, es gibt einige Absurditäten, was die Anzeige der anschlagenden Regel angeht, dass ist mir aber erst mal egal.

Das Grundproblem bleibt. Der Loadbalancer des Providers verteilt die Anfragen für den IMAP- als auch den SMTP-Server auf zwei verschiedene IPs. Die Regel in der Firewall bezieht sich auf die verwendeten CNAMEs. Die Firewall kennt aber immer nur eine der beiden IPs und unterbindet Anfragen der Clients an die jeweils andere IP.

Unter 17.* gab es dieses Problem nicht.

[JeGr]

Was spricht denn dagegen das direkt mit beiden IPs in einem Alias zu machen?
Ansonsten würde ich das mit dem Namen (Hostname) als Alias nochmal testen, eine Regel dazu machen und mit Logging arbeiten und das nochmal genau auslesen aus den Logs, was da schief läuft. Auch wie der CNAME aufgelöst wird von der Firewall könnte einen Unterschied machen. Evtl. lösen die DNSe der Sense den CNAME anders auf?