[OPNSENSE] Welke firewall rule laat pakket door

[silentkiller]

Ik heb een Opnsense firewall draaien met verschillende VLANs.
Relevant voor deze vraag:
Prive VLAN 192.168.1.0/24
Server VLAN: 192.168.3.0/24
MGMT VLAN: 192.168.4.0/24

In de server VLAN staat een server (192.168.3.61) met een Adguard docker container als DNS server.
De server heeft ook een tweede (virtuele) NIC met een poot in de MGMT VLAN (voor bv de Omada container)
Door een foutieve configuratie op de server, werd het antwoord verkeer van de DNS server over de MGMT NIC gerouteerd

offtopic:
Ik heb er lang naar gezocht, maar het uitgaand adres voor iptables van de adguard container, is het bridge adres van de container. Dit moet toegevoegd worden aan de routing policy om het verkeer over de IOT nic te routeren. Hier werd de default GTW (MGMT VLAN) gebruikt

Ik ben er maar toevallig achter gekomen, packet capture op de firewall:

Hier zie je dat het antwoord terugkomt over de MGMT VLAN in plaats van over de Server VLAN door de foutieve configuratie.

Ik was verbaasd dat ik dit nooit gemerkt heb en dat het gewoon werkt! In de MGMT VLAN is er zelfs geen rule die verkeer toelaat van MGMT VLAN -> Prive VLAN.

Na wat verder na te denken en proberen te debuggen vond ik met geen enkele logging te enablen het antwoord verkeer terug in de firewall logs.

Ik heb een beetje verder nagedacht en denk dat ik het snap: de Opnsense is natuurlijk een statefull firewall. Voor de DNS query wordt de firewall rule gecheckt in de prive VLAN en een sessie gergistreerd in Opnsense. Het antwoord mag gewoon terug over de firewall.

Mijn vraag: klopt die redenering? Het enige wat ik nog een beetje vreemd vind aan die redenatie: Opnsense weet eigenlijk dat die sessie bestaat tussen een aparaat in de Prive VLAN en de Server VLAN. Het lijkt me dan dat sessies interface onafhankelijk zijn dan? Klopt dit? Ik kan er weinig over terug vinden.

Is het teruggaand verkeer van een sessie ook ergens zichtbaar te maken in de firewall rules live logging? (lijkt me niet omdat hier geen firewall rules worden gecheckt gezien het een antwoord in een sessie is). Is dit ergens anders zichtbaar?

Bedankt alvast!

[EverLast2002]

Ik heb in OPNsense firewall rules aangemaakt om onderling VLAN verkeer te blokkeren.
Bijvoorbeeld VLAN10 kan nooit naar VLAN11 en omgekeerd.
Doe je dit niet dan kunnen al je VLANs elkaar gewoon benaderen.

voorbeeld:
https://www.wundertech.ne...g_the_VLAN_Firewall_Rules

[Kabouterplop01]

Hmm bij pfsense kun je de rules bekijken. Ik kan me niet voorstellen dat dat bij OPNsense niet kan.
Daar moet dit expliciet bij staan.

[silentkiller]

EverLast2002 schreef op vrijdag 7 juli 2023 @ 17:25:
Doe je dit niet dan kunnen al je VLANs elkaar gewoon benaderen.

Dat klopt... voor IPs in de VLAN zelf. Niet voor andere IP's (zoals in mijn geval, een IOT IP in de Server VLAN als source)

De default allow rule laat tratiek toe vanuit 'Server NET' (zie onderstaand plaatje)
Als ik logging opzet op die allow rule, zie ik geen hit in de firewall logging.

(Volgens mij zou hij ook op de default Deny rule moeten komen omdat het source adres uit een andere VLAN komt).

Kabouterplop01 schreef op zaterdag 8 juli 2023 @ 07:32:
Daar moet dit expliciet bij staan.

zie bovenstaand plaatje. Als ik de logging op alle rules opzet (staat op het plaatje af op de laatste rule, I know), zie ik GEEN hit in de firewall logging

De reden waarom ik denk dat de firewall rules voor het teruggaande verkeer niet worden gecheckt, vind je terug op de site van OPNsense zelf:

By default rules are set to stateful (you can change this, but it has consequences), which means that the state of a connection is saved into a local dictionary which will be resolved when the next packet comes in. The consequence of this is that when a state exists, the firewall doesn’t need to process all its rules again to determine the action to apply, which has huge performance advantages.

The use of states can also improve security particularly in case of tcp type traffic, since packet sequence numbers and timestamps are also checked in order to pass traffic, it’s much harder to spoof traffic.

[Kabouterplop01]

ja dat is het inderdaad stateful.
Maar is zeker niet interface onafhankelijk. Een established session, of en UDP stream if you want, gaan dwars door die interface heen en "veroorzaken" een state.
Blijkbaar moet je het dus expliciet blokkeren, zoals @EverLast2002 al beschrijft.