Opnsense firewall rules - twee kanten op of alleen inbound?

[SVMartin]

Mijn vraag
Wat ik gewend ben is dat firewalls alleen vereisen om rules aan te maken op basis van waar de connectie wordt geinitieerd. Dus als je VLAN A met Server A hebt en VLAN B met Server B, en je wilt dat server A via http:80 een txt bestandje van een webserver op server B kan downloaden, dan voeg je een regel toe die toestaat dat server A een connectie mag maken naar server B over tcp protocol op poort 80. Dat vervolgens de data van het txt bestandje van server B terug gaat naar Server A hoef je niet te configureren.

Nu heb je in opnsense meerdere interfaces, o.a. voor elk VLAN een. Je moet dan bij het maken van de rules ook nadenken over de direction.

Ik heb in VLAN A een desktop staan, in VLAN B een pihole. Ik heb op de interface van VLAN A de volgende rule aangemaakt:
* interface: vlan A
* direction: in
* protocol: tcp/udp
* source: vlan a net
* destination: pihole (dit is een alias)
* destination port range: dns-dns

Dit werkt, ik kan van de desktop nu een nslookup doen op de pihole.

In de logs zie ik ook netjes dat deze rule gebruikt wordt. Ik zie echter ook direct daarna in de logs dat op interface van VLAN B een outbound pass plaatsvind met als source mijn desktop en als destination de pihole.

Daaruit begrijp ik dat het inbound/outbound plaatje vanuit de documentatie iets complexer is:

inbound -> firewall interface A -> outbound -> inbound -> firewall interface B -> outbound

En dat de outbound standaard toegestaan wordt, maar de inbound niet.

Waarom moet ik dan niet om dit mogelijk te maken ook een pass rule aanmaken voor de inbound van interface B?

Relevante software en hardware die ik gebruik
Opnsense

Wat ik al gevonden of geprobeerd heb
Documentatie gelezen en gezien dat het zo werkt, nu nog begrijpen waarom.. (of erachter komen dat ik iets helemaal verkeerd doe)

[EverLast2002]

OPNsense blokkeert alles wat inkomend is en laat alles door wat uitgaand verkeer is.
Je denkt te ingewikkeld volgens mij.
(of ik begrijp je vraag niet, dat kan ook).

[SVMartin]

Vermoedelijk denk ik ook te ingewikkeld, tenminste: dat hoop ik nog steeds :-)

Nog een voorbeeld waar ik tegenaan loop. Ik heb een intern vlan met vertrouwde devices. Daarin zit mijn workstation (linux) en de smb service van mijn nas (Truenas). Ik heb in opnsense een rule aangemaakt op de 'intern' interface die zegt dat intern alles bij intern mag:

- action: pass
- quick: enabled
- interface: intern
- direction: in
- tcp/ip: ipv4
- protocol: any
- source: intern net
- destination: intern net
- port range: disabled, want any protocol

Nu probeer ik vanaf het workstation de fileshare te mounten via mount.cifs. Ik krijg terug "permission denied". Ik weet wel zeker dat user/pass correct is, maar voor de zekerheid in truenas een password reset gedaan. Helpt niet. Vervolgens in truenas de audit logs en daar zie ik als login result op SMB service gewoon 'success'.

Ik heb dus het vermoeden dat het verkeer naar smb wel slaagt, maar terug van smb naar workstation er iets wordt tegengehouden?

Ik wil nog verder de logging nalopen, misschien komt dat later vanavond nog..

[ThinkPad]

Als apparaten in hetzelfde VLAN zitten dan hoef je geen firewall regels aan te maken, dat verkeer gaat namelijk niet over de firewall.

[EverLast2002]

ThinkPad schreef op dinsdag 14 mei 2024 @ 21:31:
Als apparaten in hetzelfde VLAN zitten dan hoef je geen firewall regels aan te maken, dat verkeer gaat namelijk niet over de firewall.

Dat dacht ik ook, maar in OPNsense kun je zonder firewall regels gewoon in elkaars VLAN komen.
Je moet echt na het maken van VLANs ook firewall regels maken die onderlinge VLAN communicatie blokkeren.
sorry, ik las te snel. Je redenatie klopt als een bus.

[ Voor 6% gewijzigd door EverLast2002 op 14-05-2024 22:20 ]

[EverLast2002]

SVMartin schreef op dinsdag 14 mei 2024 @ 21:24:
Vermoedelijk denk ik ook te ingewikkeld, tenminste: dat hoop ik nog steeds :-)

Nog een voorbeeld waar ik tegenaan loop. Ik heb een intern vlan met vertrouwde devices. Daarin zit mijn workstation (linux) en de smb service van mijn nas (Truenas). Ik heb in opnsense een rule aangemaakt op de 'intern' interface die zegt dat intern alles bij intern mag:

- action: pass
- quick: enabled
- interface: intern
- direction: in
- tcp/ip: ipv4
- protocol: any
- source: intern net
- destination: intern net
- port range: disabled, want any protocol

Nu probeer ik vanaf het workstation de fileshare te mounten via mount.cifs. Ik krijg terug "permission denied". Ik weet wel zeker dat user/pass correct is, maar voor de zekerheid in truenas een password reset gedaan. Helpt niet. Vervolgens in truenas de audit logs en daar zie ik als login result op SMB service gewoon 'success'.

Ik heb dus het vermoeden dat het verkeer naar smb wel slaagt, maar terug van smb naar workstation er iets wordt tegengehouden?

Ik wil nog verder de logging nalopen, misschien komt dat later vanavond nog..

Linux heeft vaak een (eigen) firewall draaien, zit dat niet in de weg?

[Kalculon]

SVMartin schreef op dinsdag 14 mei 2024 @ 21:24:

Nu probeer ik vanaf het workstation de fileshare te mounten via mount.cifs. Ik krijg terug "permission denied"

[...]

Ik heb dus het vermoeden dat het verkeer naar smb wel slaagt, maar terug van smb naar workstation er iets wordt tegengehouden?

Dus je verkeer komt aan bij de SMB server en de reactie daarvan ("permission denied") vindt zijn weg terug. Hier zit je firewall dus niet in de weg. De "permission denied" wordt dus niet tegengehouden en krijg je netjes op je workstation te zien.

Ik weet wel zeker dat user/pass correct is

Ik weet ook vaak zeker dat "alles goed" is, terwijl ik niet het behaalde resultaat haal.
Maar een "permission denied" is ook niet hetzelfde als "bad username or password" en het is logisch dat in de logs op de SMB service een 'success' staat.

Je lijkt succesvol aangemeld, prima. Maar je hebt alleen geen rechten ( "permission denied" )
Dat is niet een fout. Werkt zoals het moet. Waarschijnlijk heb je ergens een ACL anders dan wat je wenst.

[SVMartin]

@ThinkPad. Ik kan inderdaad de pass voor intern naar intern verwijderen en dan heb ik nog steeds tussen de hosts in dat vlan alle toegang.

@EverLast2002 Weet je zeker dat je zomaar van het ene vlan naar het andere vlan kunt komen? Ik heb nu op mijn interne vlan twee rules:
1. je mag naar de pihole in het server vlan op poort 53
2. je mag naar alle ip-adressen die geen lokale netwerken zijn (dus naar het internet)
Daarmee mag ik vanaf intern niet naar m'n dmz of management. Dat lukt niet via web, geen ping of traceroute.

[SVMartin]

Kalculon schreef op dinsdag 14 mei 2024 @ 22:41:
[...]


Dus je verkeer komt aan bij de SMB server en de reactie daarvan ("permission denied") vindt zijn weg terug. Hier zit je firewall dus niet in de weg. De "permission denied" wordt dus niet tegengehouden en krijg je netjes op je workstation te zien.


[...]


Ik weet ook vaak zeker dat "alles goed" is, terwijl ik niet het behaalde resultaat haal.
Maar een "permission denied" is ook niet hetzelfde als "bad username or password" en het is logisch dat in de logs op de SMB service een 'success' staat.

Je lijkt succesvol aangemeld, prima. Maar je hebt alleen geen rechten ( "permission denied" )
Dat is niet een fout. Werkt zoals het moet. Waarschijnlijk heb je ergens een ACL anders dan wat je wenst.

Ik zal nog eens naar die ACL's kijken, misschien zit daar ook nog wel iets in van een source ip? Voordat ik begon met inrichting van de vlan's werkte het prima, dus verwacht (ja, ook een aanname?) niet dat er iets mis zit in de ACL in samba of op disk.

Update: in ieder geval geen hosts allow/deny configuratie, toch nog verder kijken..

[ Voor 3% gewijzigd door SVMartin op 14-05-2024 23:25 ]

[SVMartin]

EverLast2002 schreef op dinsdag 14 mei 2024 @ 22:21:
[...]


Linux heeft vaak een (eigen) firewall draaien, zit dat niet in de weg?

Ook niet aan gedacht, maar helaas na uitschakelen van de lokale firewall zelfde resultaat.

[SVMartin]

Wanneer ik met opzet een foutief wachtwoord invul dan krijg ik ook een permission denied, maar dmesg laat wel degelijk een verschil zien. Deze geeft nu ook 'Status code returned 0xc000006d STATUS_LOGON_FAILURE' aan.

[SVMartin]

Conclusie: inderdaad een probleem met de Share ACL. Die stonden wel ingesteld, maar van elke user die toegang had stond er alleen nog een UUID, niet de naam. Deze zijn dan ergens verlorgen gegaan? Vreemd.. anyway: verwijderd, juiste toegevoegd en het werkt weer!

[Kalculon]

Fijn om toch even later nog altijd een conclusie tegen te komen
En fijn dat je hebt weten op te lossen!