Pfsense blockt was sie will….

Tron

Hallo,

irgendwie habe ich irgendwo einen Denkfehler drin.
Unser Netz sieht folgendermaßen aus

.–---+------------
| externer Server|
'-----+-----'------- WAN 215.75.115.XXX
:
:
:
WAN / Internet
:
: DialUp-Cable-Provider
:
.-----+-------- WAN <dynamisch>| Vdsl Modem|
'-----+--------
| LAN 10.100.100.2
|
|
.-----+-----. WAN 10.100.100.1
| pfSense +
'-----+-----' LAN 192.168.100.254
|
LAN | 192.168.100.0/24
|
.-----+------.
| LAN-Switch |
'-----+------'
|
...-----+------... (Clients/Servers

Nun geht es hauptsächlich um die Verbindung von Clients zu dem externen Server und zurück.

Der externe Server (WAN 215.75.115.XXX) hostet einen Maildienst für uns der natürlich immer Mails annehmen und zustellen soll.
Aus diesem Grund habe ich unter "Firewall" -> "Rules" zwei Rules angelegt auf dem WAN Interface der PfSense Firewall

Die Rules sehen so aus:

Proto Source Port Destination Port Gateway Schedule Description
* Reserved/not assigned by IANA * * * * * Block bogon networks
TCP/UDP * * 215.75.115.XXX 1352 * * Outgoing Mail
TCP * * 192.168.100.101 1352 * * Incoming Mail

Wenn ich in das Firewall log reinschaue sehe ich allerdings das die Pfsense fleissig blockt und das verzögert natürlich
den Mailempfang.

Was mache ich falsch?</dynamisch>

JeGr

Mehreres :) Aber der Reihe nach.

Zuerst die Frage: Muss die doppelte NAT sein? Kann das VDSL Kabelmodem nicht transparent arbeiten? Ansonsten ist das zwar im vorliegenden Fall wenig problematisch, kann es aber später sein bei anderen Protokollen gerade was bspw. FTP und Konsorten angeht.

Als nächstes die Regeln. Was genau versuchst du damit zu erreichen. Du sprichst davon, dass der externe Server mit der 215er Adresse einen Maildienst hostet. Sendet ihr an diesen oder holt ihr von dort Post ab? Mit welchem Protokoll? 1352/tcp hört sich nach Lotus Notes an, also würde ich vermuten, ihr habt lauter Notes Clients hinter der Firewall und den Server im HQ oder sonstwo zentral per IP erreichbar stehen (dass der ohne VPN irgendwo steht ist ne andere Sache, mir wäre es unsympatisch meinen zentralen MailServer per IP erreichbar im Netz zu haben wo meine Mails lagern).

Wenn dieser Server also nicht selbst Daten ZU euch sendet, sind deine Regeln auf dem WAN Interface völlig überflüssig. Die Kommunikationsrichtung ist wichtig, und da ihr scheinbar nur Clients habt und der Server von sich aus eher selten einem Client etwas sendet, sondern dieser das anfordert (von Ausnahmen abgesehen), ist die initiale Verbindung Client->Server und damit würde die Regel das LAN Interface betreffen. Wenn ihr da nichts am Default Setting der Sense geändert habt, ist von LAN->WAN eh alles offen, so dass es hier keiner Änderung bedarf (es sei denn eure Default Policy ist Block all, dann müsst ihr natürlich den Weg aufmachen, aber scheinbar geht es ja aber nur verzögert?).

Dann kommt natürlich noch das Problem des doppelten NATs beim VDSL Modem, denn ich weiß nicht, ob das Ding a) filtert und/oder b) Port Forwarding macht (oder alle Ports einfach an die IP 10.100.100.1 der Sense weiterschießt). Kann also von außen überhaupt etwas bei der Sense ankommen? Und wenn es einen Connect von außen gibt, 1) warum und 2) welchen, dann muss dieser freigeschaltet werden.

Warum deine Regeln beide falsch sind:

auf dem WAN Interface wird nur gefiltert was von außen kommt. Aber: Vom Internet wirst du keine Pakete für 215.75.115.xxx bekommen. Die bekommst du nur abgehend auf dem LAN Interface wenn deine Clients versuchen mit dem Server zu reden. Auf dem WAN kommen die nicht rein (die Sense behandelt Filterregeln auf jedem Interface nur EINgehend, die ausgehenden sind automatisch frei).
Auf dem WAN wirst du keine Pakete für 192.168.100.101 bekommen, die aus dem Internet kommen - weil 192…. nicht geroutet wird. Wenn also nicht gerade dein VDSL Modem versucht mit 192.168.100.101 zu sprechen wird niemand Pakete an diese Adresse senden (können). Es können höchstens Pakete an die WAN Adresse deines VDSLs (dynamisch) kommen, diese würden aber am VDSL Modem aufschlagen, sofern dieses nicht alles einfach platt an die PFSense weitergibt, was es besser sollte (spart dir Ärger). Wenn Pakete an der Sense auf WAN ankommen, dann höchstens adressiert an 10.100.100.1.

Der langen Rede kurzer Sinn:

Erhelle uns, wie die Kommunikationsbeziehung zum Server genau aussieht und wir/ich können/kann dir helfen, das entsprechend zu konfigurieren :)

Tron

Hallo,

grundsätzlich bin ich erstmal beruhigt, denn die Sachen die Du ansprichst haben mich generell auch irritiert.
Ich habe mich dann [[ weil es nicht funktioniert hat wie ich wollte und wie ich das erwartet hatte] dann halt irgendwann dazu verleiten lassen ein paar Sachen auszuprobieren.

@Grey:

Mehreres :) Aber der Reihe nach.
Zuerst die Frage: Muss die doppelte NAT sein? Kann das VDSL Kabelmodem nicht transparent arbeiten? Ansonsten ist das zwar im vorliegenden Fall wenig problematisch, kann es aber später sein bei anderen Protokollen gerade was bspw. FTP und Konsorten angeht.

Tut mir leid es war gestern schon spät, da habe ich den Fehler nicht mehr bemerkt.
Tausche bitte das VDSL modem in der Zeichnung gegen ein Kabelmodem aus.
Diese Konstellation brauch dann meiner Meinung nach diese Konfiguration.

@Grey:

Als nächstes die Regeln. Was genau versuchst du damit zu erreichen. Du sprichst davon, dass der externe Server mit der 215er Adresse einen Maildienst hostet. Sendet ihr an diesen oder holt ihr von dort Post ab?
Mit welchem Protokoll? 1352/tcp hört sich nach Lotus Notes an, also würde ich vermuten, ihr habt lauter Notes Clients hinter der Firewall und den Server im HQ oder sonstwo zentral per IP erreichbar stehen (dass der ohne VPN irgendwo steht ist ne andere Sache, mir wäre es unsympatisch meinen zentralen MailServer per IP erreichbar im Netz zu haben wo meine Mails lagern).

Da hast du Recht.
Das ist ein Domino Server im HQ und dort holen wir von hier aus nur ab.
Wir haben allerdings auch einen Domino Server intern stehen , gegen den der HQ Server repliziert.
Diesen benutzen wir aber aktiv nur im Failoverfall oder generell zum Versenden von Mails (smtp) von intern nach extern.

Ich will es aber nicht zu kompliziert machen.

@Grey:

Wenn dieser Server also nicht selbst Daten ZU euch sendet, sind deine Regeln auf dem WAN Interface völlig überflüssig.
Die Kommunikationsrichtung ist wichtig, und da ihr scheinbar nur Clients habt und der Server von sich aus eher selten einem Client etwas sendet, sondern dieser das anfordert (von Ausnahmen abgesehen), ist die initiale Verbindung Client->Server und damit würde die Regel das LAN Interface betreffen.

Genau das hatte ich mir anfangs auch gedacht.

Da hatte ich diese Regeln auf das LAN interface konfiguriert

Proto Sourc Port Destination Port Gateway Schedule Description
* LAN net * * * * Default LAN -> any
TCP * * 215.75.115.XXX * * LAN -> Domino Essen

Das hatte es leider nicht gebracht, geruckelt hat es dann immernoch beim Mail holen.

@Grey:

Wenn ihr da nichts am Default Setting der Sense geändert habt, ist von LAN->WAN eh alles offen, so dass es hier keiner Änderung bedarf (es sei denn eure Default Policy ist Block all, dann müsst ihr natürlich den Weg aufmachen, aber scheinbar geht es ja aber nur verzögert?).

Das wäre eventuell ein Ansatzpunkt.
Ich habe keine extra Default Policy konfiguriert aber ich habe das System übernommen .
Wo würde man diese Default Policy denn einstellen wenn nicht in rules?

Das mit dem verzögert kann ich damit erklären das wir noch eine Firewall haben die aber nirgends als Standardgw eingestellt ist, daher habe ich sie nicht erwähnt.
Aber ins Internet würde man im Zweifel auch über diese Firewall kommen. (soll aber grundsätzlich alles über Kabel und pfsense laufen)

@Grey:

Dann kommt natürlich noch das Problem des doppelten NATs beim VDSL Modem, denn ich weiß nicht, ob das Ding a) filtert und/oder b) Port Forwarding macht (oder alle Ports einfach an die IP 10.100.100.1 der Sense weiterschießt). Kann also von außen überhaupt etwas bei der Sense ankommen? Und wenn es einen Connect von außen gibt, 1) warum und 2) welchen, dann muss dieser freigeschaltet werden.

Erstes hat sich ja glaube ich erledigt und zu zweiten kann ich sagen das zumindest port 1352 direkt an die 10.100.100.1 weitergereicht wird auf dem Modem.

Zum Rest - wie würde das denn dann vernünftig konfiguriert aussehen?

Tron

Wenn auf dem WAN Interface nur eingehend gefiltert wird ist natürlich alles
klarer und dann ist es auch logisch das die Regel aus 215.X nichts bewirkt.
Von daher schon einmal vielen Dank für die Erleuchtung :-)

Was muss ich konkret tun um dem internen Domino Server(192.16.100.25) zu erlauben sich mit dem Server im HQ zu replizieren?

Ich habe nun angenommen das ich eine Regel auf dem WAN Interface setzen muss die so aussieht:

TCP * * 192.168.100.25 * * Domino Essen - Domino

Leider filtert die Pfsense immernoch die Kontaktaufnahme vom internen Domino zum externen Domino im HQ.

Auszug Firewalllog:
DENY May 18 16:52:49 LAN192.168.100.25:1352 215.75.115.xxx:10905 TCP:S

Was muss ich tun um zu erreichen das die Firewall die Clientzugriffe auf den externen Server nicht mehr blockt?

Auszug Firewalllog:
DENY May 18 17:44:02 LAN192.168.100.101:3212 215.75.115.xxx:1352TCP:R

JeGr

Dein Firewalllog richtig lesen ;) Es steht quasi alles da. Namentlich das Interface: LAN, nicht WAN!

Regel muss aufs LAN Interface, auf dem wohl offenbar keine Default Allow all Regel liegt. Also muss aufs LAN entsprechende Regeln. Um deine Log Auszüge in Regeln zu übersetzen:

Allow, TCP, SOURCE(!) 192.168.100.25, SOURCE PORT (!) 1352, Destination: 215…, Dest. Port ANY
Allow, TCP, SOURCE 192.168.100.101 (SOURCE Port ANY), Destination 215..., Dest Port: 1352

Das sollte dich einen Schritt näher bringen an das was du erreichen willst.

Tron

Ok dann kapier ichs doch noch nicht.
Wie gesagt ich habe nichts verändert auf der FW, daher gibt es eine Regel auf dem LAN Interface die lautet wie folgt:

Allow, TCP, SOURCE LAN Net, SOURCE ANY, Destination:ANY , Dest. Port ANY

Sollte die Regel die beiden die Du gepostet hast nicht vollständig ersetzen können oder verstehe ich da was grundlegend falsch?
Liegt das eventuell an dem doppelten NAT?

Shine

Hi Tron,

Die LAN Regel lässt alles durch, was nach TCP riecht.

In den Firewalllogs kannst du per Klick auf das "Blocked" Symbol erkennen, welche Regel geblockt hat.