Overstappen vanaf pfSense of OPNsense

Wie van pfSense of OPNsense komt, kent firewalls. Het probleem is niet de kennis maar het model: pf denkt in interfaces met tabbladen, RouterOS denkt in chains met één lijst. Wie dat verschil overslaat, bouwt een regelset die klopt op papier en niet in de praktijk.

Regelvolgorde: tabbladen tegenover chains

In pfSense heeft elke interface zijn eigen tabblad met regels, en die worden per interface van boven naar beneden gelezen op verkeer dat binnenkomt op die interface. Wat niet past, valt in de impliciete deny. Floating rules staan daar los van.

In RouterOS is er één filtertabel met drie chains:

• input: verkeer naar de router zelf.
• forward: verkeer dat er doorheen gaat.
• output: verkeer dat de router zelf verstuurt.

Binnen een chain telt de volgorde, en er is geen impliciete deny. Wat geen enkele regel raakt, wordt doorgelaten. De afsluitende drop is een regel die jij daar zelf neerzet en die daar moet blijven staan. Dat is het gevaarlijkste verschil van allemaal: een halve vertaling van een pf-regelset laat alles toe in plaats van alles te blokkeren.

Wat de tool genereert houdt zich daaraan: in input eindigt het met drop all not coming from LAN, en in forward met drop all from WAN not DSTNATed. Zie Firewall.

Interfacegroepen worden interface-lijsten

Wat in pfSense een interface group is, is in RouterOS een interface list. De gegenereerde configuratie maakt er twee: WAN en LAN. Regels verwijzen daarnaar met in-interface-list en out-interface-list, en dat is ook wat je in de lijst met eigen filterregels kunt kiezen, inclusief !WAN en !LAN. Voeg je later een uplink toe, dan gaat hij in de lijst WAN en blijven je regels kloppen.

NAT

• Outbound NAT is in RouterOS de srcnat-chain. De tool zet standaard masquerade richting WAN; heb je een vast publiek adres, kies dan src-nat met dat adres.
• Port forward is dst-nat in de dstnat-chain. Anders dan in pfSense hoef je er geen bijbehorende filterregel bij te maken: de afsluitende drop in forward kijkt naar connection-nat-state en laat doorgestuurde verbindingen door.
• NAT reflection heet hier hairpin NAT, en staat aan zodra je een forward invult.
• 1:1 NAT zit niet als veld in de tool. Dat schrijf je zelf, of je zet het in de ruimte voor eigen regels.

DHCP en DNS

DHCP is in RouterOS drie dingen die bij elkaar horen: een pool, een server op een interface en een network met gateway en DNS. De tool schrijft die drie als één geheel per LAN of per VLAN. Static mappings worden static leases op MAC-adres.

Het grootste verschil zit in DNS. pfSense draait standaard Unbound, een echte resolver met host overrides en domain overrides. RouterOS heeft geen resolver maar een forwarder met cache: hij stuurt door naar een upstream en onthoudt het antwoord. Je krijgt statische records (A, AAAA, CNAME en regexp), DNS over HTTPS naar de upstream, en vanaf 7.15 een adlist voor het blokkeren van domeinen. Wat je niet krijgt is DNSSEC-validatie op de router zelf en de rest van wat Unbound doet. Zie DNS.

pfBlocker heeft geen tegenhanger. De adlist dekt een klein deel ervan; voor de rest zijn adreslijsten met firewallregels de weg, en die vul je zelf.

VPN

Zie WireGuard en VPN voor onderweg.

Waar een handmatige vertaling misgaat

• De afsluitende drop vergeten. Zonder die regel is je firewall open. Controleer met /ip firewall filter print of de laatste regel in elke chain doet wat je denkt.
• Aliases. Die worden adreslijsten (/ip firewall address-list). Een alias met poorten erin heeft geen tegenhanger; die splits je in aparte regels.
• Quick. In pf stopt een regel met quick de evaluatie. In RouterOS stopt elke regel die accept, drop of reject doet de chain sowieso. Regels zonder actie die alleen markeren, gaan verder.
• Reply-to. Multi-WAN in pf leunt op reply-to per regel. In RouterOS doe je dat met mangle en routingtabellen, of met de failover-instelling bij de uplinks. Zie Meerdere uplinks.
• Limiters en schedules. Limiters worden queues (zie QoS); tijdgebonden regels bestaan niet als veld en doe je met de scheduler.
• Floating rules op meerdere interfaces. Die worden één regel met een interface-lijst, of meerdere regels. Reken na of je er echt hetzelfde uitkomt.
• De volgorde na het plakken. RouterOS voegt regels achteraan toe. Plak je later nog iets, dan komt het ná je drop te staan en doet het niets.

Er is geen import voor pfSense of OPNsense

De configurator leest alleen een RouterOS-/export. Een config.xml van pfSense of OPNsense kan hij niet inlezen, en er is geen automatische vertaling van pf-regels naar RouterOS. Bouw je configuratie op uit je plan: je interfaces en VLANs met hun subnetten, je NAT-regels en je filterregels op volgorde. Dat is ook een goed moment om de regels die er al jaren staan zonder doel weg te laten.