I'm sorry, I should've sent a picture from the beginning, I suck at explaining things.
It looks like this:
Screenshot from 2019-10-03 02-29-44.png
Exact same rule as the above, except that it rejects and has no gateway selected.
When the firewall is evaluating the traffic since the tunnel would be down and hence it doesn't match anymore, then the traffic would fall on the next rule, and, the next rules says sorry you can't pass.
In the picture, it's a catch all rule, which is very dangerous because it can lock you out, so you need to add yet more rules for services in the firewall (or to other local networks):
Screenshot from 2019-10-03 02-39-35.png
Here, rules are:
is automatically generated, it's disabled on the settings but I keep forgetting. :)
is automatic as well, created by pfBlockerNG
is my actual first rule, it bypasses the firewall completely. It catches all traffic from the alias def_fullchoya.
allows traffic going to internal IP ranges (RFC1918: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16) since the interface address is 10.0.0.1, it therefore allows access to anything on the firewall and other local networks. Shouldn't be that broad though.
allows internal DNS servers to get DNS outside of the tunnel (because it's above the tunnel rule) but in an ordered fashion, i.e; it's a gateway group that goes one by one checking what's [interface] up so DNS queries are region-matched.
blocks all other DNS so clients are forced to get it from the servers specified though DHCP.
allows certain hosts (alias def_fullthrottle) to use the local exit to the Internet at full speed but still use internal DNS (covered by rule 4)
allows servers known to phone home, i.e; Microsoft products (alias bad_kiddies) to get internal DNS and communicate internally with other local hosts (covered by rule 4) but blocks them from actually communicating out.
every other traffic goes through tunnel
safeguard (negate) rule: if tunnel drops, traffic matches this rule rejecting traffic everywhere out. That would include local traffic if it wasn't covered by rule 4.
The way you did it is good too but that I think that would create problems if you're hosting servers as it would block or create asymmetric routing from a remote client's perspective as most VPN services don't let you do port forwarding. In other less confusing words: when you add a rule on an interface, the firewall creates on the background a temporary pass rule for the return traffic on whatever the other interface for as long as the state lives even if there's a rule that blocks the traffic. In my case rule 8.
In all honesty I'm not a hundred on if the floating rule would catch autogenerated rules passing traffic from blocking rule 8 but that's exactly what floating rules are for. They're for complex scenarios and should be avoided at all costs if you're not completely sure what you're doing -- that applies to me, at least. Filtering on the outbound also catches traffic from the firewall itself (complex scenarios) and could get you into a frustrating situation where your tunnel drops and the firewall can't get DNS to bring it up again if you didn't set it correctly.
I made this a few days ago, maybe it can help: https://forum.netgate.com/topic/146714/tunneled-isp-cheat-sheet
:)
