pfsense scenario QUESTIONS LVL2 Flashcards
Je hebt twee LAN-interfaces aangemaakt: LAN1 (192.168.10.1/24) en LAN2 (192.168.20.1/24). Je hebt DHCP ingesteld op LAN2 van 192.168.20.50 tot .200. Maar je test-VM krijgt geen IP-adres. De kabel zit goed, interface staat aan. Wat check je als eerste?
Controleer of DHCP-server daadwerkelijk ingeschakeld is op de juiste interface (LAN2), en dat de interface ook daadwerkelijk is toegewezen en enabled in Interfaces > Assignments. Controleer ook of de firewallregel DHCP (UDP poort 67) verkeer toelaat.
Je kan vanaf LAN1 wel een VM op LAN2 pingen, maar andersom niet. Beide interfaces hebben DHCP en de juiste IP’s. Wat ontbreekt er waarschijnlijk?
Een firewallregel op LAN2 die toestaat dat verkeer van LAN2 naar LAN1 mag. Zonder regel blokkeert pfSense het verkeer standaard (default deny policy).
Je hebt een regel toegevoegd op LAN2 om DNS toe te staan (UDP/53), en een regel voor HTTP/HTTPS. Clients kunnen geen websites openen. Wat is een veelgemaakte fout hier?
In de firewallregel moet je bij Advanced > Gateway ‘WAN’ selecteren, anders weet pfSense niet dat verkeer via het WAN moet. Zonder gateway werkt verkeer naar internet niet.
Je schakelt de anti-lockout rule uit op LAN1 en verwijdert per ongeluk ook je enige toegangsregel. Je komt er niet meer in. Wat doe je?
Open de pfSense console via de virtuele omgeving (bv. Proxmox) en voer het commando pfctl -d uit om de firewall tijdelijk uit te zetten. Daarna herstel je de regels via de GUI.
Je maakt een VLAN aan (VLAN 30) op interface em1, maar apparaten krijgen geen IP. Je hebt DHCP ingesteld op de VLAN-interface. Wat kan er mis zijn?
Je moet ook een trunk configureren op de switchpoort waar em1 aan hangt, en zorgen dat VLAN 30 daar toegestaan is. Anders komt het verkeer nooit bij pfSense aan.
Je maakt een gastnetwerk aan op VLAN 50. Je wilt absoluut niet dat gasten LAN (192.168.1.0/24) kunnen bereiken. Welke firewallregel stel je in?
Op de VLAN50-interface: Block regel met:
- Source: VLAN50 net
- Destination: 192.168.1.0/24 Zorg dat deze regel bovenaan staat.
Je hebt een Captive Portal geconfigureerd op VLAN100. Klanten worden niet doorgestuurd naar de loginpagina. Wat kan je vergeten zijn?
Zorg dat DNS en HTTP verkeer wordt toegestaan vóór de captive portal (via regels op VLAN100). Zonder deze kunnen clients geen redirect krijgen.
Clients kunnen pfSense zelf pingen en ook interne hostnames resolven, maar internetwebsites niet. Wat zou een fout kunnen zijn?
Controleer of pfSense een externe DNS-server heeft ingesteld onder System > General Setup. Bijv. 8.8.8.8 of 1.1.1.1.
Op LAN2 wil je enkel 3 apparaten (met statisch IP) internettoegang geven. Hoe doe je dat?
Maak firewallregels aan op LAN2:
- Laat alleen verkeer toe van de drie statische IP’s naar internet.
- Voeg onderaan een Block regel toe met Source: LAN2 net en Destination: any.
Je voegt een regel toe die HTTP toelaat van LAN2, maar verkeer lijkt geblokkeerd. Wat controleer je?
Regels worden van boven naar beneden gelezen. Controleer of er boven jouw regel een andere regel staat die verkeer al blokkeert.
Je switch is goed geconfigureerd, VLAN krijgt IP-adressen via pfSense. Maar je kan niet internetten. Wat zou je missen?
Firewallregels op de VLAN-interface. DHCP werkt zonder firewallregel, maar verkeer wordt standaard geblokkeerd tenzij expliciet toegestaan.
e ziet veel verkeer van 169.254.x.x
Wat doe je?
Dit is APIPA: een IP-reeks die apparaten gebruiken als ze geen DHCP krijgen. Controleer of de DHCP-server werkt en netwerkconnectiviteit in orde is.
Je kan niet pingen tussen twee netwerken. Verkeer werkt wel via HTTP. Waarom werkt ping niet?
ICMP moet expliciet worden toegestaan in firewallregels. Voeg een regel toe met:
Protocol: ICMP
Source: [Netwerk]
Destination: any
Hoe zorg je dat je altijd via LAN2 in pfSense kan komen, zelfs bij firewallfouten?
Laat de Anti-lockout rule aan op LAN2 of maak een statische rule aan die verkeer toestaat van jouw beheerders-IP naar pfSense (this firewall) op port 443.
Je maakt floating rules aan voor LAN1 en LAN2, maar verkeer wordt nog steeds geblokkeerd. Wat is vaak vergeten?
Zet “Quick” aan bij floating rules. Anders worden ze pas later toegepast (als laatste) en kunnen andere regels eerder al verkeer blokkeren.
Je hebt een LAN1 (192.168.10.0/24) en LAN2 (192.168.20.0/24) aangemaakt in pfSense. Beide interfaces hebben DHCP aanstaan en clients krijgen IP-adressen. Maar LAN2-klanten hebben geen internet.
Controleer of op LAN2 een firewallregel staat die DNS (UDP poort 53) naar “any” toestaat. Zonder DNS-toegang werkt internet vaak niet, zelfs als HTTP/HTTPS wel zou mogen.
Je kunt van LAN1 naar LAN2 pingen, maar je kunt geen webpagina’s openen. Er zijn “allow any”-regels op beide interfaces.
Vraag: Waarom werkt webverkeer niet?
Controleer of je regels TCP toestaan voor poorten 80 (HTTP) en 443 (HTTPS), en dat de gateway correct staat. “Allow any” zonder correcte gateway of DNS heeft geen effect voor externe sites.
Je hebt een extra interface toegevoegd (OPT1) voor een gastnetwerk (192.168.30.0/24), maar geen enkel apparaat krijgt verbinding of IP.
Vraag: Wat zijn de drie essentiële stappen die vaak worden vergeten bij het toevoegen van een nieuwe interface?
1 Interface inschakelen via Interfaces > Assignments.
2 DHCP activeren via Services > DHCP Server.
3 Firewallregels toevoegen voor verkeer (bijv. allow any van subnet naar any).
Een server heeft een statisch IP buiten de DHCP-range, maar blijft IP-adressen krijgen via DHCP.
Vraag: Hoe los je dit op in pfSense?
Voeg een statische DHCP mapping toe op basis van MAC-adres. Zo krijgt het apparaat altijd hetzelfde IP dat jij definieert — en valt niet meer onder de dynamische leasepool.
Je schakelt per ongeluk de anti-lockout rule uit op LAN1, en hebt geen rules om verkeer toe te laten naar pfSense zelf.
Vraag: Hoe krijg je weer toegang?
Gebruik consoletoegang via Proxmox of fysiek, log in als root en voer pfctl -d uit om de firewall tijdelijk uit te schakelen. Daarna kun je via de webinterface de regel herstellen.
Een collega zegt dat je altijd de DNS forwarder moet gebruiken.
Vraag: Wat is het verschil en wanneer kies je bewust voor de resolver?
De DNS resolver (unbound) doet zelf lookups vanaf de rootservers, wat veiliger en privacyvriendelijker is. De forwarder stuurt verzoeken direct door (bijv. naar 8.8.8.8). Kies de resolver voor privacy, de forwarder voor snelheid.
Je merkt dat LAN2 apparaten wel LAN1 kunnen bereiken, maar LAN1 niet naar LAN2.
Vraag: Hoe komt dit?
Waarschijnlijk zijn er geen firewallregels op LAN1 die verkeer naar LAN2 toestaan. pfSense laat alleen verkeer toe waarvoor een expliciete regel is.
Je wilt voorkomen dat clients een APIPA (169.254.x.x) IP krijgen.
Vraag: Hoe voorkom je dit in pfSense?
Zorg dat DHCP correct werkt, en maak een firewallregel in de Floating tab om verkeer van 169.254.0.0/16 te blokkeren.
Je hebt een WAN en twee LAN’s, maar enkel LAN1 heeft internet. NAT is automatisch.
Vraag: Wat moet je controleren voor LAN2?
Ga naar Firewall > NAT > Outbound, schakel over naar “Hybrid Outbound NAT” en voeg handmatig een regel toe voor LAN2 met NAT via de WAN-interface.
Je hebt Captive Portal geactiveerd op LAN3, maar na inloggen krijgen gebruikers geen internet.
Vraag: Wat zijn drie mogelijke oorzaken?
Antwoord:
- Geen DNS-regel (UDP 53) in firewall.
- Gateway niet correct ingesteld.
- Geen NAT-regel voor LAN3 via WAN.
Je hebt VLAN10 aangemaakt op een fysieke interface, maar clients krijgen geen IP.
Vraag: Wat moet je checken?
Antwoord: Zorg dat:
- De switchport getagd VLAN10 ondersteunt.
- VLAN10 is toegewezen aan een interface.
- DHCP actief is op deze VLAN-interface.
Je hebt een regel “Allow all” maar bepaalde clients kunnen nog steeds niets.
Vraag: Wat kan dit veroorzaken?
Antwoord: Mogelijke oorzaken:
- De regel staat onder een blokkerende regel.
- De regel staat op de verkeerde interface (bv. WAN i.p.v. LAN).
- Er is een Floating rule die verkeer overschrijft.
Je hebt een poortforward van WAN naar een interne webserver op 192.168.10.100:80, maar extern werkt het niet.
Vraag: Wat zijn drie dingen die je moet controleren?
Antwoord:
1 Firewallregel is automatisch gegenereerd of handmatig toegevoegd.
2 NAT-type is op “Automatic outbound NAT”.
3 Webserver luistert op poort 80 en de router/firewall ontvangt verkeer op WAN-IP.
Je VPN werkt en clients krijgen IP-adressen, maar ze kunnen niets in LAN1 bereiken.
Vraag: Wat ontbreekt?
Je VPN werkt en clients krijgen IP-adressen, maar ze kunnen niets in LAN1 bereiken.
Vraag: Wat ontbreekt?
Je werkt aan een pfSense-configuratie voor een klant met een Proxmox-labomgeving. Ze hebben drie VLAN’s geconfigureerd op een enkele fysieke interface (em1):
VLAN10 = 192.168.10.0/24 (beheer)
VLAN20 = 192.168.20.0/24 (productie)
VLAN30 = 192.168.30.0/24 (gast)
In pfSense zijn alle drie VLAN’s aangemaakt en toegewezen aan hun eigen interface. DHCP is ingeschakeld en clients krijgen correcte IP-adressen. Op elk interface zijn “Allow any to any”-regels toegevoegd. Echter, geen enkel device in één van de VLAN’s kan het internet bereiken.
Je hebt NAT op “Automatic Outbound” laten staan.
Vraag: Wat is de oorzaak van het probleem, en wat is de correcte oplossing?
Hoewel “Allow any” regels aanwezig zijn, maakt pfSense alleen automatisch NAT-regels aan voor interfaces die direct na installatie bestonden. Omdat de VLAN’s later zijn aangemaakt, heeft NAT geen regels gegenereerd voor deze interfaces. Oplossing: ga naar Firewall > NAT > Outbound, kies Hybrid Outbound NAT, en voeg handmatig NAT-regels toe voor elke VLAN-interface via de WAN.
Je hebt op VLAN30 (gastennetwerk) Captive Portal geactiveerd. Gebruikers krijgen na het verbinden keurig het inlogscherm te zien en na succesvolle authenticatie krijgen ze internet. Maar je klant wil ook dat gasten toegang krijgen tot een printer in VLAN20 (IP: 192.168.20.50).
Je voegt een “Allowed IP Address” toe in Captive Portal voor 192.168.20.50, maar na inloggen blijft de printer onbereikbaar. De firewallregel op VLAN30 laat verkeer toe naar VLAN20. DNS en ping naar externe adressen werken wel.
Vraag: Waarom werkt de toegang tot de printer niet en hoe los je dit op?
De “Allowed IP Address” functie van Captive Portal slaat op doelen die zonder authenticatie mogen worden bereikt, niet op bestemmingen voor verkeer nadat iemand ingelogd is. Je moet zorgen dat:
De firewallregel op VLAN30 verkeer naar 192.168.20.50 toestaat.
De printer verkeer terug kan sturen naar VLAN30 (controleer eventueel of deze een firewall heeft).
DNS-resolutie naar de printer werkt of een hosts-bestand wordt gebruikt. De whitelist is dus niet van toepassing na authenticatie, alleen vóór.
e hebt voor een klein kantoor een pfSense-firewall opgezet. Internet werkt, de webinterface is bereikbaar, ping werkt naar externe sites, en gebruikers kunnen gewoon browsen. Maar ze klagen dat hun e-mailclients (bijv. Outlook of Thunderbird) geen verbinding maken met hun mailserver (mail.provider.com). Webmail naar diezelfde provider werkt wel.
Je hebt een “allow all” regel van LAN naar any toegevoegd. DNS lijkt correct te werken. Wat zie je over het hoofd?
Vraag: Wat zou een mogelijke oorzaak zijn en hoe test je dit?
Antwoord:
De meeste e-mailclients gebruiken poorten als 587 (SMTP), 993 (IMAP SSL), of 995 (POP SSL). Sommige firewallregels laten alleen HTTP/HTTPS verkeer door of missen TCP/UDP selectie. Ook kunnen DNSBL of pfBlockerNG het verkeer blokkeren als “mail.provider.com” op een blocklist staat.
Oplossing:
Controleer de firewall logs op geblokkeerd verkeer naar de betreffende poorten.
Voeg een regel toe die expliciet verkeer naar poorten 587, 993, 995 toestaat.
Schakel tijdelijk pfBlockerNG of DNSBL uit om uitsluiting te testen.
Een IT-beheerder activeert logging op alle firewallregels in pfSense, inclusief alle “pass” regels op LAN, WAN en VLAN’s. Na een paar dagen merk je dat pfSense traag is, de GUI is onstabiel en de CPU is 90-100%. Bij het openen van de System Logs zie je duizenden regels per seconde.
Vraag: Wat is hier misgegaan en hoe los je het op zonder logging volledig uit te schakelen?
Logging op “allow all” regels veroorzaakt extreme load, vooral bij drukke netwerken. Oplossing:
Log alleen wat nodig is (bijv. blokkeringsregels of specifieke poorten).
Gebruik Aliases om logging selectiever te maken.
Schakel logging uit bij brede “allow” regels.
Overweeg externe logserver via syslog voor analyse.
Een bedrijf heeft twee WAN-verbindingen (WAN1 en WAN2) en wil via load balancing het verkeer verdelen. Je maakt een Gateway Group met beide gateways op Tier 1. Je wijst deze aan onder System > Routing > Default Gateway IPv4. Failover werkt als één verbinding faalt. Maar wanneer beide verbindingen actief zijn, wordt al het verkeer toch via WAN1 gestuurd.
Vraag: Waarom werkt de load balancing niet en wat ontbreekt er?
Antwoord:
Het instellen van een Gateway Group als default gateway is niet voldoende om load balancing af te dwingen. pfSense gebruikt nog steeds de statische routing tenzij je in de firewallregels expliciet die Gateway Group selecteert.
Oplossing:
Voeg in Firewall > Rules op de LAN-interface een regel toe voor “any to any”, en kies onder “Advanced Options > Gateway” de juiste Gateway Group.
Zorg dat DNS-verkeer ook via de juiste gateway loopt, anders krijg je asymmetrisch verkeer.
