People coming from pfSense or OPNsense know firewalls. The problem is not the knowledge but the model: pf thinks in interfaces with tabs, RouterOS thinks in chains with one list. Skip that difference and you build a rule set that is right on paper and wrong in practice.
Rule order: tabs versus chains
In pfSense every interface has its own tab of rules, read top to bottom for traffic entering that interface. Whatever matches nothing falls into the implicit deny. Floating rules sit apart from that.
In RouterOS there is one filter table with three chains:
input: traffic to the router itself.forward: traffic passing through it.output: traffic the router sends itself.
Order matters inside a chain, and there is no implicit deny. Anything no rule matches is allowed through. The closing drop is a rule you put there yourself and that has to stay there. That is the most dangerous difference of all: a half-finished translation of a pf rule set permits everything instead of blocking everything.
What the tool generates respects that: input ends with drop all not coming from LAN, and forward with drop all from WAN not DSTNATed. See Firewall.
Interface groups become interface lists
What pfSense calls an interface group is an interface list in RouterOS. The generated configuration builds two: WAN and LAN. Rules refer to them with in-interface-list and out-interface-list, which is also what you can pick in the custom filter rules list, including !WAN and !LAN. Add an uplink later and it joins the WAN list, so your rules keep holding.
NAT
- Outbound NAT is the
srcnatchain in RouterOS. The tool usesmasqueradetowards WAN by default; with a fixed public address, pick src-nat with that address. - Port forward is
dst-natin thedstnatchain. Unlike pfSense you do not add a matching filter rule: the closing drop inforwardlooks atconnection-nat-stateand lets forwarded connections through. - NAT reflection is called hairpin NAT here, and is on as soon as you enter a forward.
- 1:1 NAT has no field in the tool. You write that yourself, or put it in the space for custom rules.
DHCP and DNS
DHCP in RouterOS is three things that belong together: a pool, a server on an interface, and a network with a gateway and DNS. The tool writes those three as one unit per LAN or per VLAN. Static mappings become static leases keyed on the MAC address.
The biggest difference is DNS. pfSense runs Unbound by default, a real resolver with host and domain overrides. RouterOS has no resolver but a forwarder with a cache: it passes queries upstream and remembers the answer. You get static records (A, AAAA, CNAME and regexp), DNS over HTTPS towards the upstream, and from 7.15 an adlist for blocking domains. What you do not get is DNSSEC validation on the router itself, and the rest of what Unbound does. See DNS.
pfBlocker has no equivalent. The adlist covers a small part of it; for the rest, address lists with firewall rules are the way, and you fill those yourself.
VPN
| pfSense / OPNsense | In the tool |
|---|---|
| WireGuard | WireGuard, with peers for clients and for site-to-site, including ready-made client configurations |
| IPsec site-to-site | Not as a field; instead WireGuard site-to-site, or GRE/EoIP/IPIP with an IPsec secret. See Site-to-site tunnels |
| IPsec mobile (IKEv2) | IKEv2 road-warrior server with certificates or a pre-shared key |
| OpenVPN | OpenVPN server, with a PPP address pool and users |
| L2TP/IPsec | L2TP/IPsec server, same pool and users |
See WireGuard and Remote access VPN.
Where a hand translation goes wrong
- Forgetting the closing drop. Without that rule your firewall is open. Check with
/ip firewall filter printthat the last rule in every chain does what you think. - Aliases. They become address lists (
/ip firewall address-list). An alias holding ports has no equivalent; split that into separate rules. - Quick. In pf, a rule with
quickstops evaluation. In RouterOS any rule that accepts, drops or rejects ends the chain anyway. Rules that only mark carry on. - Reply-to. Multi-WAN in pf leans on per-rule reply-to. In RouterOS you do that with mangle and routing tables, or with the failover setting on the uplinks. See Multiple uplinks.
- Limiters and schedules. Limiters become queues (see QoS); time-based rules have no field and are done with the scheduler.
- Floating rules across several interfaces. Those become one rule with an interface list, or several rules. Check that you really end up with the same thing.
- Order after pasting. RouterOS appends rules at the end. Paste something later and it lands after your drop, where it does nothing.
There is no import for pfSense or OPNsense
The configurator only reads a RouterOS /export. It cannot read a pfSense or OPNsense config.xml, and there is no automatic translation from pf rules to RouterOS. Build your configuration from your plan: your interfaces and VLANs with their subnets, your NAT rules, and your filter rules in order. It is also a good moment to leave out the rules that have been sitting there for years without a purpose.