Network firewall

Any custom network can carry a firewall policy: a default verdict for each direction plus an ordered list of rules. MacVisor compiles the policy into the host's packet filter (pf), so enforcement happens on the Mac rather than inside the guest — a guest cannot turn it off, and nothing has to be installed in it.

Open Networks, select a custom network, and switch on Enable Firewall.

Directions are relative to the VMs

Each direction has its own default — Allow or Deny — and every rule names the far end of the flow: the destination for an outbound rule, the source for an inbound one.

Rules

A rule is: enabled, direction, action, protocol, remote CIDR, ports.

• Protocol — Any, TCP, UDP, or ICMP. Ports apply to TCP and UDP only.
• Remote CIDR — 10.0.0.0/8, a bare address such as 192.168.1.50 (treated as /32), or any.
• Ports — a single port (443) or a range (8000-8080). Empty means all ports.

Rules are first-match-wins, top to bottom. Traffic matching no rule falls through to that direction's default. Allow rules are stateful, so replies to a permitted flow are let back through even when the opposite direction defaults to deny. Invalid CIDRs and port ranges are flagged in the editor and skipped rather than loaded.

A common shape — a lab segment that may reach the internet but must not touch the corporate LAN:

with Default outbound: Deny and Default inbound: Deny.

What always stays open

DHCP within the segment, and DNS to the gateway when the DNS proxy is enabled, are permitted regardless of policy. Without them a deny-by-default network would simply stop working — guests would never get an address.

Applying

Apply Firewall Rules… pushes the policies of every network that has a firewall to the host at once, then flushes existing pf state for those subnets so established connections cannot coast on the previous verdict.

The network helper is normally installed during first-run setup, with one administrator password prompt; if it was declined then, the first apply installs it. After that, applying, changing, and removing rules are silent. If macOS holds the helper for approval, turn it on in System Settings → Login Items & Extensions.

The helper keeps the policies it was last given and re-applies them at boot, before anyone logs in, so a restarted host comes back filtered. Remove Enforcement… clears the rules and forgets them, so the next boot comes back unfiltered.

From the command line

mvz networks firewall lab on --outbound deny --allow out:udp:53 --allow out:tcp:443
mvz networks firewall lab --inbound deny
mvz networks firewall lab --clear --deny out:any::10.0.0.0/8 --allow out:tcp:443
mvz networks firewall lab off

A rule is in|out[:tcp|udp|icmp|any[:<ports>[:<cidr>]]] — direction, then protocol, ports, and remote CIDR, each optional from the right. Rules are evaluated in the order given, first match wins, then the direction's default. --clear drops the existing rules before adding the new ones. Changes made from the CLI are enforced while the MacVisor app is running, because the app is what talks to the helper.

Verifying

Show Active Rules… reads back what pf is enforcing right now, including per-rule match counters — the honest answer to "is my rule actually seeing packets". Reading pf requires root, so this asks for an administrator password. The Terminal equivalents:

sudo pfctl -a 'com.apple/900.macvisor.firewall' -sr
sudo pfctl -ss

Limits worth knowing before you rely on it

How enforcement is wired

Rules live in a sub-anchor of pf's com.apple/* namespace, which the stock /etc/pf.conf already evaluates. That means MacVisor never edits pf.conf and never reloads the main ruleset — reloading it would flush the anchors macOS installs for internet sharing and silently break NAT for other networks.

MacVisor sends the helper policy, never packet-filter text; the helper compiles it itself. A user-level process therefore cannot express anything through the helper that the interface could not already express. See Security model.