PFSense Firewall (OPNSense) LAN1 naar LAN2 server via WAN-IP

[bjorn_S_]

Momenteel zit ik met de volgende kwestie
Ik ben van dual NAT naar enkel NAT gegaan. De dual nat betrof een simpele firewall met 1 wan-IP en 1 lan-client. de andere firewall met 3 LAN-netwerken.

Nu heb ik (eindelijk) de 1e firewall weg weten te werken dmv. VLAN's toe te passen voor het WAN-IP richting de PFsense (of in mijn geval OPNSense, komt op hetzelfde neer) Firewall.

Nu dan het echte probleem waar ik mee zit na deze verandering:
Ik zit met mijn pc in LAN1, mijn main server zit in LAN1,2 en 3 en mijn Hosting server zit alleen in LAN2.
Sommige onderdelen hangen, vanwege dat deze openbaar staan richting het internet, ingesteld op LAN2.
Deze onderdelen (services als Home Assistant, monitoring tools etc.) zijn gemakkelijk te bereiken via het WAN-IP, evenals alle andere onderdelen van de main server en de hosting server.

Het grootste probleem zit hem in het feit dat mijn pc (die zich in LAN1 bevindt) niet de onderdelen van de main server kan bereiken die in LAN2 zitten via het wan-ip. de onderdelen die in LAN1 zitten werken wel. Mijn firewall zegt het volgende in de logging als hij het verkeer blokkeert:

Interface Time Source Destination Proto Label
LAN Sep 5 12:55:24 192.168.179.2:57942 10.10.0.253:19999 tcp Default deny rule
SERVER_VLAN2 Sep 5 12:55:24 192.168.179.2:57942 10.10.0.253:19999 tcp let out anything from firewall host itself
LAN Sep 5 12:55:24 192.168.179.2:57941 10.10.0.253:19999 tcp Default deny rule

(LAN(1) is 179.X ||| (Server_V)LAN2 is 10.10.0.X)

Zowel de LAN1 als de LAN2 hebben any naar any protocol any aanstaan, en zouden dus niet de boel moeten blokkeren, maar dat lijkt hij dus wel te doen?

Heeft iemand enig idee hoe dit op te lossen en waar de fout in kan zitten?

Indien er de vraag is naar meer inhoud, vraag maar raak.

[bjorn_S_]

[Sendy]

Ik kan er persoonlijk niet veel van begrijpen. Waar zit de router in je netwerk? Is dat dezelfde machine als waar de “firewall” op draait? Hoe wordt je verkeer gerouteerd? Misschien kan je dat verduidelijken?

btw, je plaatje met daarin het ethernet gedeelte én ip gedeelte is heel goed gedaan. Alleen voor ip heb je dus ook routing nodig. Waar in je ip netwerk zitten je hosting server, je main server, je firewall en je router(s)?

[ Voor 35% gewijzigd door Sendy op 05-09-2020 14:06 ]

[Frogmen]

Volgens mij klopt je tekening niet met je beschrijving want ik neem aan dat je PC ook naar het internet mag. Verder lees ik een heel erg complex verhaal die naar mijn gevoel uiteindelijk niet heel veel meer security brengt. Maar dat kan ook door beperkte info. Teken eens het hele plaatje met ook de Opnsense firewall.

[Hennie-M]

Frogmen schreef op zaterdag 5 september 2020 @ 14:30:
Volgens mij klopt je tekening niet met je beschrijving want ik neem aan dat je PC ook naar het internet mag. Verder lees ik een heel erg complex verhaal die naar mijn gevoel uiteindelijk niet heel veel meer security brengt. Maar dat kan ook door beperkte info. Teken eens het hele plaatje met ook de Opnsense firewall.

De firewall draait zo te zien op de unraid server, deze vm heeft vermoedelijk 2 interfaces met untagged vlan 99 en een interface met de andere vlans tagged. De vm's of docker images die op de server draaien hebben waarschijnlijk een untagged interface op vlan2. De clients in vlan1 kunnen de gateway/firewall/router bereiken omdat vermoedelijk deze vm ook in dit vlan zit.


De firewall log die je plaatst is wat onhandig te lezen maar het lijkt er op dat al je verkeer alleen de Default Deny regel raakt. Dus er wordt niet voldaan aan de regels die er boven staan. Welke regels heb je ingesteld om verkeer door te laten en staat je default deny regel wel als laatste regel?

Verder heb ik geen PFSense ervaring dus inhoudelijk kan ik je eigenlijk niet helpen.
Om het makkelijk voor jezelf te maken zou je er voor kunnen kiezen om het vlan nummer in je 3e octet te zetten. 192.168.1.0/24 = vlan1. Lekker duidelijk. het door elkaar gebruiken van verschillende klasse segmenten zorgt niet voor veiligheid, het maakt het alleen onoverzichtelijk.

edit2: waarom heb je vlan2 getagged op AP? Je clients leven in vlan1, en die moeten door je firewall heen om bij je services op vlan2 te komen. Je zal hopelijk geen services hosten via wifi en je wil ook niet met je mobile device aanmelden op een apart ssid om bij je services te komen. Je wil dat je clients en gasten in hun vlan door je firewall gaan en zo uitkomen op je vlan2.

[ Voor 28% gewijzigd door Hennie-M op 05-09-2020 14:44 ]

[bjorn_S_]

Frogmen schreef op zaterdag 5 september 2020 @ 14:30:
Volgens mij klopt je tekening niet met je beschrijving want ik neem aan dat je PC ook naar het internet mag. Verder lees ik een heel erg complex verhaal die naar mijn gevoel uiteindelijk niet heel veel meer security brengt. Maar dat kan ook door beperkte info. Teken eens het hele plaatje met ook de Opnsense firewall.

Om misschien iets meer duidelijkheid te geven aan waarom ik 3 verschillende netwerken heb:
- (LAN)/VLAN1: Dit is het netwerk waar alle internet-clients en thuisgebruikers in zitten. En hebben toegang tot internet
- SERVER_VLAN2/VLAN2: Dit is een server netwerk, zit in principe alleen in unraid en ingesteld in de firewall. Hiernaar wordt veelal ge-portforward voor hosting van websites en gameservices. Geen toegang tot internet en geen DHCP.
- IOT/VLAN3: Het IOT netwerk, mag alleen communiceren richting unraid voor Home Assistant. Geen toegang tot internet, maar wel DHCP.
- VLAN99: een poort die begint bij de switch onderaan en die alleen gebruikt wordt door opnsense wan-kant. Deze heeft nu ook een WAN-IP (van ziggo).

Frogmen schreef op zaterdag 5 september 2020 @ 14:30:
Teken eens het hele plaatje met ook de Opnsense firewall.

Je kunt de unraid server vervangen door alleen de firewall, vlan2 vullen met servers en vlan 3 met iot devices. En natuurlijk VLAN1 met de devices zoals afgebeeld.

Hennie-M schreef op zaterdag 5 september 2020 @ 14:39:
De firewall log die je plaatst is wat onhandig te lezen maar het lijkt er op dat al je verkeer alleen de Default Deny regel raakt. Dus er wordt niet voldaan aan de regels die er boven staan. Welke regels heb je ingesteld om verkeer door te laten en staat je default deny regel wel als laatste regel?

Dat is een beetje het vage in de situatie, ik krijg de deny-regel niet achterhaald. En ja default deny is als laatste, zowel op LAN1 als LAN2 (SERVERVLAN2) zit From LAN (en voor servervlan2 FROM SERVERVLAN2) to any, any any any (tijdens deze test in ieder geval wel.)

Hennie-M schreef op zaterdag 5 september 2020 @ 14:39:
Verder heb ik geen PFSense ervaring dus inhoudelijk kan ik je eigenlijk niet helpen.
Om het makkelijk voor jezelf te maken zou je er voor kunnen kiezen om het vlan nummer in je 3e octet te zetten. 192.168.1.0/24 = vlan1. Lekker duidelijk. het door elkaar gebruiken van verschillende klasse segmenten zorgt niet voor veiligheid, het maakt het alleen onoverzichtelijk.

Ja had makkelijker geweest. Dit is ook meer begonnen als een DIY-netwerk en toen zijn subnetten 10.10.0.0/24 en 10.11.0.0/24 erbij gekomen vanwege IOT en de VM's ook de OPNsense is tevens een VM (met virtual nics voor alle 4 de vlan's).

Hennie-M schreef op zaterdag 5 september 2020 @ 14:39:
edit2: waarom heb je vlan2 getagged op AP? Je clients leven in vlan1, en die moeten door je firewall heen om bij je services op vlan2 te komen. Je zal hopelijk geen services hosten via wifi en je wil ook niet met je mobile device aanmelden op een apart ssid om bij je services te komen. Je wil dat je clients en gasten in hun vlan door je firewall gaan en zo uitkomen op je vlan2.

Dit is meer een stuk op switch-niveau. 'Hoet doet niets' op het AP zelf, het is meer een soort worst-case scenario fixing. Mocht je benieuwd zijn hoe de switches geconfigureerd zijn, laat het maar weten dan stuur ik wel foto's van de VLAN-configuratie.

Hennie-M schreef op zaterdag 5 september 2020 @ 14:39:
De firewall draait zo te zien op de unraid server, deze vm heeft vermoedelijk 2 interfaces met untagged vlan 99 en een interface met de andere vlans tagged. De vm's of docker images die op de server draaien hebben waarschijnlijk een untagged interface op vlan2. De clients in vlan1 kunnen de gateway/firewall/router bereiken omdat vermoedelijk deze vm ook in dit vlan zit.

(Helaas) ben ik een soort genoodzaakt momenteel om alles over 1 FYSIEKE interface te doen. Ik heb wel aardig wat netwerkkennis en ben daarom ook met VLAN's gaan werken. En netwerk-technisch werkt(e) het.

[ Voor 4% gewijzigd door bjorn_S_ op 05-09-2020 22:48 ]

[Anoniem: 316512]

Je zegt dat any naar any allowed wordt, maar heb je niet óók nog een deny rule ertussen staan? Dat lijkt je log wel te zeggen en een deny rule heeft voorrang op een allow rule.

[bjorn_S_]

Dit krijg ik te zien wanneer ik naar netdata.xxxxxx.nl:19999 ga:


(er staat lan2 to firewall maar dat moet lan1 zijn)




Dit is de port-forward die ervoor zou moeten zorgen dat ik de server zou moeten kunnen bereiken: (merk hieraan op dat het dest. IP 10.10.0.253 is, en mijn PC 192.168.179.2 is.)


geknutseld in paint

[ Voor 3% gewijzigd door bjorn_S_ op 05-09-2020 23:09 ]

[bjorn_S_]

hier nog meer info m.b.t. de firewall deny:

[geenwindows]

wordt de boel ook geblokkeerd als je ipv wan adres, rechtstreeks naar 10.10.0.253:19999 gaat?

[bjorn_S_]

geenwindows schreef op zondag 6 september 2020 @ 12:45:
wordt de boel ook geblokkeerd als je ipv wan adres, rechtstreeks naar 10.10.0.253:19999 gaat?

De pagina wordt wel zichtbaar en refresht/werkt ook gewoon normaal. Wel krijg ik dit in de firewall log te zien:
(192.168.179.2 = PC in LAN1, 10.10.0.253 = unraid server in VLAN2)



Hier wanneer via lan-ip:


hier via url (wan-ip):

[ Voor 123% gewijzigd door bjorn_S_ op 06-09-2020 17:57 ]

[geenwindows]

wat ik bij jou mis is de default Lan to any rule, deze heb ik wel en daarmee heeft LAN alle vrijheid om naar andere vlans te gaan. (tenzij er een block regel boven staat, of vlan dit blokkeerd) in VLAN zelf zijn enkel regels gemaakt dan vlan niet naar LAN mag gaan.
Nu is het wel zo dat ik vanaf dag één met OPNsense WAN en LAN poort, (zelfs unRAID had toen zijn eigen poort) hoe en wat WAN+LAN truck setups weet ik geen raad mee.

Nu weet ik wel dat via wan adres naar een interne server gaan heb ik opgelost door in unbound (dat is mijn interne DNS resolver) een aantal regels gemaakt:

code:

server:
local-zone: "domeinnaam.nl" redirect
local-data: "domeinnaam.nl 86400 IN A 192.168.x.x"
local-zone: "sub.domeinnaam.nl" redirect
local-data: "sub.domeinnaam.nl 86400 IN A 192.168.x.x"

de andere manier is via NAT
(firewall > settings > advanced)
en dan bij Network Address Translation wat doen met de 3 opties, maar hier heb ik geen kennis mee en heb het maar 'opgelost' via DNS.

[ Voor 39% gewijzigd door geenwindows op 07-09-2020 10:59 ]

[bjorn_S_]

geenwindows schreef op maandag 7 september 2020 @ 10:50:
wat ik bij jou mis is de default Lan to any rule, deze heb ik wel en daarmee heeft LAN alle vrijheid om naar andere vlans te gaan. (tenzij er een block regel boven staat, of vlan dit blokkeerd) in VLAN zelf zijn enkel regels gemaakt dan vlan niet naar LAN mag gaan.

Ik heb die LAN to ANY rule volgensmij wel, zie 2e regel in de foto hieronder:

geenwindows schreef op maandag 7 september 2020 @ 10:50:
Nu is het wel zo dat ik vanaf dag één met OPNsense WAN en LAN poort, (zelfs unRAID had toen zijn eigen poort) hoe en wat WAN+LAN truck setups weet ik geen raad mee.

Nu weet ik wel dat via wan adres naar een interne server gaan heb ik opgelost door in unbound (dat is mijn interne DNS resolver) een aantal regels gemaakt:

code:

server:
local-zone: "domeinnaam.nl" redirect
local-data: "domeinnaam.nl 86400 IN A 192.168.x.x"
local-zone: "sub.domeinnaam.nl" redirect
local-data: "sub.domeinnaam.nl 86400 IN A 192.168.x.x"

de andere manier is via NAT
(firewall > settings > advanced)
en dan bij Network Address Translation wat doen met de 3 opties, maar hier heb ik geen kennis mee en heb het maar 'opgelost' via DNS.

toon volledige bericht

Ik heb de dns regel toegevoegd, en werkt. Het stomme is serieus dat de firewall nog blijft komen dat hij mijn pc's ip toestaat, maar ook weer blokkeert. Ik krijg geen pagina te zien met de hostname, maar wel met het IP?
Zou het misschien de fout zijn van unraid die meerdere IP's heeft en dan dit ziet?:

[PC]: requesting connection 10.10.0.253:19999
[Unraid]: connection received from 192.168.179.2 for 10.10.0.253:19999, waarom kom jij uit een ander, voor mij bekend, subnet? (met name gebaseerd op dit:)

[Unraid]: reply xxxxxxx via 10.10.0.253 ip of 192.168.179.253 ip
[Firewall]: Berichtgeving onjuist, blokkeren.


Een mogelijke oplossing zou zijn om alle docker-containers een eigen IP te geven, zou wel een heleboel aanpas- en controleerwerk zijn.

Ik zou ook niet precies weten hoe je het betreffende ip per subnet kan wijzigen. (serverlan moet tevens wel nog bij unraid kunnen evenals het LAN netwerk)

[geenwindows]

Mijn default LAN to any rule ziet er toch anders uit:

(naast de 4 Automatically generated rules en een dns redirect regel heb ik geen andere regels ingesteld voor LAN)
unRAID kun je ook toevoegen aan een vlan. je kunt ook enkel containers of VM koppelen aan een vlan.

[bjorn_S_]

geenwindows schreef op maandag 7 september 2020 @ 17:12:
Mijn default LAN to any rule ziet er toch anders uit:
[Afbeelding]
(naast de 4 Automatically generated rules en een dns redirect regel heb ik geen andere regels ingesteld voor LAN)
unRAID kun je ook toevoegen aan een vlan. je kunt ook enkel containers of VM koppelen aan een vlan.

Unraid heeft de vlans ingesteld, en daar kunnen de dockers ook aan gekoppeld worden. De regel die jij had staan heb ik ook toegepast, maar heeft geen verandering gemaakt.
Ik gok dat het dan iets is in Unraid wat het niet snapt dan ofzo, en zal dan maar de docker containers allemaal een eigen IP moeten toewijzen om 'raar'/onjuist gerouteerd verkeer te voorkomen.

[geenwindows]

je kunt ook kijken naar een dual NIC pcie kaartje, creëer je een scheiding tussen unRAID en OPNsense

[bjorn_S_]

geenwindows schreef op dinsdag 8 september 2020 @ 19:17:
je kunt ook kijken naar een dual NIC pcie kaartje, creëer je een scheiding tussen unRAID en OPNsense

Dat is een hele goeie, eens kijken of ik wat kan vinden met pcie x1 met 2x 1gigabit poorten.. heb namelijk geen andere x2 of hoger meer beschikbaar.

Ik gok dat de kaarten die op Ali Expr. staan waarschijnlijk niet voldoen/ onveilig zijn?

[geenwindows]

dual nic en pcie x1 zijn zeer zeldzaam...
anders een single nic en de trunck behouden. (die zijn hier via pcicewatch te vinden.)
kaarten van ali heb ik geen ervaring mee, heb enkel een SAS kaart in gebruik die uit Hongkong komt (ebay)

zolang je maar niet aan de gang gaat met die usb krengen, het zal vast werken maar 'goed' is het 2e. > bouw dan zelf een nieuw systeem voor opnsense...

[bjorn_S_]

geenwindows schreef op woensdag 9 september 2020 @ 13:29:
dual nic en pcie x1 zijn zeer zeldzaam...
anders een single nic en de trunck behouden. (die zijn hier via pcicewatch te vinden.)

Dat zou ook een werkende oplossing zijn denk ik zo. Dan geef ik aan OPNSense de nic, en maak ik daar de vlan's op aan. Zo zal de communicatie tussen unraid en OPNSense denk ik een stuk beter verlopen.
Ook zal ik mijn manier van docker installaties aan moeten passen ipv alleen maar Unraid's IP te gebruiken.

Ik zal ook nog even aanvullen dat ik heb gemerkt dat, door alles via 1 poort te doen, ook performance niet helemaal soepel verloopt (dubbel zoveel load op de NIC doordat het verkeer heen en weer gaat (van opnsense richting unraid)). En dat probleem zal dan ook opgelost moeten zijn.

Jammer dat de oorzaak niet echt achterhaald kon worden, maar ik denk dat ik zo weer een goed plan heb om alles netwerk-technisch recht te trekken/ te verbeteren.

Enorm bedankt voor de hulp! @geenwindows