Source und Destination

Das kommt darauf an.

Du müsstest mal näher beschreiben, welche Daten von Wo nach Wo.

Aus dem Internet ist alles gesperrt. Von Intern ins Internet geht alles.
Zonen sind auch gesperrt, VLAN in eine Zone untereinander sind auch offen.

LAN (intern) > zu extern ist alles offen. Alle Antworte für die Anfragen der internen Clients werden durchgelassen.

Zusätzliche positive Regeln machen kein Sinn. Wenn du Verkehr verhindern willst musst du die Anfragen von innen nach aussen blocken.

Beispiel: Blocken von Pornoseiten für ein Internes Gerät.

Ich hatte Apps genommen. Aber bei IP-Adresse dann so.

Wenn du es für spezielle Geräte, spezielle Anwendung machen möchtest, geht es aber auch hier drüber.

Du solltest den Port bei Destination eintragen.
Ich kenne nicht die Interner der Fw, aber wenn du den Port schon in der Source für ein Gerät sperrst, kommt es mit diesen Port wahrscheinlich nirgendwo hin.

Jedenfalls arbeite so bei mir mit den Webseiten.

Der Source Port ist auf der Seite des Gerätes, welcher das Paket verschickt. Der wird fast immer ausgewürfelt und ist somit nicht fest definierbar... Der Zielport hingegen steht klar fest, denn auf dem lauscht der Dienst...

Also blockiert man in der Regel immer den port bei destination.

Das gilt im Prinzip für jedes normale TCP/UDP Datenpaket, völlig egal von wo nach wo es geschickt wird. Der Destination Port steht immer fest, auch wenn es mal eine Portrange sein kann. Diese ist dann meistens durch die Software vorgegeben (ggf. einstellbar) und auch nicht völlig willkürlich, da muss schließlich was lauschen ansonsten ist das Datenpaket unnütz.

Die ganzen Portlisten, welche im Internet zu finden sind für die "Standarddienste" sind immer auf den Destination Port bezogen. Bei ssh port 22 lauscht per Default der ssh Server eben auf Port 22, was sich in der Regel ändern lässt.

Quote from A.S.T

Habe im LAN IN vor der „Allow established und related“ ein paar Port Block Regeln hinzugefügt um auszuschließen das die von der „Allow established und related“ unter Umständen freigegeben werden macht das Sinn

Ich habe ja das neue Fw-Management. Ich gehe aber davon aus, dass damit "etablierte Verbindungen"gemeint ist. Dies also nur die Verbindungen von außen zugelassen werden, die eine Rückantwort von Anfragen von innen nach außen einbringen. Diese Antworten kommen auf "willkürlichen" Ports im 5-stelligen Zahl.
Grundsätzlich besteht ja von außen immer "Block All Traffic" und "Block Invalid Traffic"
Davor steht dann die Regel "Allow Return Traffic". Diese ist dann für folgende zuständig:

Wenn du eine Webseite aufrufst, erfolgt dies bei https immer mit Port 443 nach draußen. Dieses hat eine Session-Nummer mitbekommen. Dies merkt sich dein Router/Fw und warte auf die Antwort von dieser Destination. Die Antwort kommt auf irgendeinem Port zurück. Damit kann der Router es wieder richtig umsetzen und intern dem passenden Client zuordnen und innerhalb des Clients für die passende Software und diese dann auch wieder dem passenden TAB im Browser. Man kann ja x-Mal YouTube geöffnet haben. Somit ist es wahrscheinlich passender entweder eher Anwendungs-/App-bezogen und Destination-bezogen zu sperren als mit Ports zu arbeiten.

Quote from A.S.T

Habe im LAN IN vor der „Allow established und related“ ein paar Port Block Regeln hinzugefügt um auszuschließen das die von der „Allow established und related“ unter Umständen freigegeben werden macht das Sinn

Ohne Kontext und zu wissen was du da "blockst" nein das macht keinen Sinn. Die "Allow established und related" selber ist dazu da um
die Antworten wieder reinzulassen die vorher auch rausdürfen. Wenn du hier nun statt den Ausgehenden nur die Antworten "Blockst" dann
mag das für "übliche" Dienste wie HTTP funktionieren. Aber draußen ist das Paket. Im falle von UDP reicht das auch um dinge nach draußen
zubekommen....

Genauer währe es Hilfreich zu wissen was dein Ziel ist ist, und was du dafür getan hast. Wage Ausagen wie ich
will "Blocken" helfen da wenig weil es eine recht unscharfe aussage ist.

Quote from phino

Diese Antworten kommen auf "willkürlichen" Ports im 5-stelligen Zahl.

Die Aussage Klingt so als wenn der "Server" sich da was auswürfelt...Denke du meinst das schon Richtig aber nur
um eindeutig zu sagen: Die Antworten kommen zurück auf den Port der sie auch Losgeschickt hat. Das willkürliche passiert hier nur auf dem Client der sagt "Port xxxxx > Port 80 Gib Webseite" und Server sagt "Port 80 > Port xxxxx" Hier bitte.
es Gibt Ausnahmen wie z.B Aktives FTP das einen Extra DatenKanal öffnen will (deswegen gibt es ja auch die FW Helfer dafür die helfen
das zu regeln).

Nice two know: RFC 6335 sieht als "Ephemeral" Ports "49152–65535" Apple nutzen diese auch.
Micorsoft früher auch, aber seit Vista für TCP dann gerne ab 1024. Viele Linuxe (auch Unifi) nutzen
den Bereich 32768-60999

Quote from phino

Dieses hat eine Session-Nummer mitbekommen. Dies merkt sich dein Router/Fw und warte auf die Antwort von dieser Destination

Klingt auch mach mehr als es ist. Das ist mehr oder minder nur eine Tabelle von "Source IP/PORT und Destination IP/PORT"
die sich gemerkt wird zusammen mit "Oh das ist neu(NEW), oh da habe ich schon ne Antwort für (ESTABLISH), oh da gehört zusammen (RELEATED) " Status. Plus einen Zeitstempel um sagen zu können "oh 30 Sekunden kein Traffic, ich vergesse die Verbidung wieder"
(plus e.vt noch Markierungen um ggf in der FW andere Dinge damit zu machen). BEI den üblichen NAT Verbindungen dann halt mit den IP/PORT von Intern und Extern da hier ggf noch der Source Port auf der External Seite Umgeschrieben wird, sollte es schon zufällig eine solchen Eintrag geben. (conntrack -L zeigt die Tabelle auf einem Unifi Router an)