OPNsense Hub Configuration for Blocking Communication between Two LANs

To block communication between two separate LANs in OPNsense, you must leverage the firewall’s default deny-all policy for traffic originating from one interface and destined for another. By ensuring that no explicit allow rules exist in the firewall policies for these specific interfaces, inter-LAN traffic is automatically dropped at the packet level. This configuration effectively isolates network segments, preventing any direct data exchange between tenants or departments while maintaining their individual internet access through NAT.

Understanding OPNsense Firewall Logic

OPNsense operates on a stateful packet inspection model where rules are processed sequentially from top to bottom. The most critical concept to grasp is the "default deny" behavior. Unlike some consumer-grade routers that might allow all internal traffic by default, enterprise firewalls like OPNsense require explicit permission for traffic to flow between different zones. If you do not create a rule allowing traffic from Lan1 to Lan2, the firewall will simply ignore or drop those packets after evaluating all other rules. This logic applies regardless of whether the two LANs share the same physical switch or are connected via different VLANs, provided they are assigned to distinct interfaces or VLAN tags within OPNsense. The security boundary is defined by the interface assignment rather than physical cabling. Therefore, understanding how interfaces map to these logical zones is the first step in securing your network topology.

Verifying Interface Assignments

Before configuring rules, ensure that each LAN segment is correctly assigned to its own interface. Navigate to Diagnostics > Interfaces Settings in the web GUI. Here, you should see entries for both LAN segments. If you are using VLANs, verify that the parent interface and VLAN ID are correct. Each interface must have a unique IP subnet. For example, 192.168.10.0/24 for Tenant A and 192.168.20.0/24 for Tenant B. If both networks are on the same subnet but separated physically, you would need to implement private VLANs (PVLANs) at the switch level, which is outside the scope of the firewall configuration itself. However, if they are on different subnets, the firewall handles the isolation natively.

Configuring Firewall Rules for Isolation

The core of the solution lies in the Firewall settings. You need to inspect the rules for each LAN interface individually. Go to Firewall > Rules > LAN (or whichever name you assigned to Tenant A’s interface). Look at the existing rules. Typically, you will see an AH (Allow Any) rule at the top, which allows all traffic from this interface to anywhere, including other local interfaces. To isolate this LAN, you must modify or remove this broad allowance. For complete isolation, delete the AH rule if it exists. Instead, add specific rules that only allow what is necessary. Usually, this means allowing DHCP, DNS, and outbound HTTP/HTTPS traffic to the WAN interface. Crucially, do not add any rule that specifies the destination as the other LAN interface or its subnet. If you need to allow management traffic (like SSH or Ping) from a specific admin workstation on Tenant A to Tenant B, you must create a highly specific rule targeting that single source IP and the specific service port, rather than opening the whole subnet.

Implementing the Default Deny Policy

After removing permissive rules, ensure that the final rule on the interface list is set to Deny. In OPNsense, the last rule is often implicitly a deny, but making it explicit improves clarity and auditability. Set the action to Block, leave the protocol as * (any), and set the destination to any. This acts as a safety net. If any misconfiguration occurs, traffic will still be blocked. This approach ensures that even if new services are added to the network, they cannot communicate across the LAN boundary unless explicitly permitted by a new rule. For more detailed guidance on managing interface permissions, you may find value in reviewing OPNsense Firewall Rules Best Practices to understand how rule ordering impacts performance and security.

Testing the Configuration

Once the rules are saved and applied, verification is essential. Use a device on Tenant A’s network and attempt to ping the gateway or any host on Tenant B’s network. The request should time out. Similarly, try to access a shared resource, such as a printer or file server, located on Tenant B. These attempts should fail. Conversely, verify that devices on Tenant A can still access the internet. This confirms that the NAT rules for the WAN interface are functioning correctly and that the isolation is limited strictly to inter-LAN traffic. If connectivity issues persist, check the Status > System Logs > Firewall page. Filter by the source interface (Tenant A) and look for block entries with the destination matching Tenant B’s subnet. These logs confirm that the firewall is actively dropping the traffic as intended.

Handling Exceptions

In some scenarios, you might need to allow specific communication between LANs, such as for a centralized backup server or a shared database. In these cases, create a rule on the source LAN’s interface that targets the specific IP address of the destination server on the other LAN. Define the specific port required (e.g., TCP 3306 for MySQL). Place this rule above the general deny rule but below any restrictive rules. This granular approach maintains security while enabling necessary business functions. For complex routing scenarios involving multiple gateways, consider exploring Advanced VLAN Routing Configurations to ensure your traffic flows correctly before applying firewall restrictions.

Frequently Asked Questions

Will blocking inter-LAN traffic affect internet access?

No, blocking traffic between LAN interfaces does not impact outbound internet access. As long as your rules allow traffic from the LAN interfaces to the WAN interface for protocols like HTTP, HTTPS, and DNS, devices will continue to browse the web normally. The isolation only prevents direct communication between the internal subnets.

How do I allow one specific device to talk to another LAN?

Create a specific firewall rule on the source interface that defines the exact source IP of the device and the destination IP of the target device on the other LAN. Specify the required protocol and port. Ensure this rule is placed higher in the rule order than any blanket deny rules to take precedence.

Can I use aliases to simplify management?

Yes, creating aliases for entire subnets or groups of hosts makes rule management easier. You can define an alias for "Tenant B Subnet" and use it in destination fields. This avoids typing IP ranges repeatedly and makes it easier to update addresses if the network changes.

What happens if I accidentally create a rule allowing all traffic?

If you add an AH (Allow Any) rule at the top of either LAN interface, the isolation will be broken immediately. All traffic from that LAN will be allowed to reach the other LAN. Always review the rule order carefully and test connectivity after making changes to prevent accidental exposure.

Does this configuration work with VLANs?

Yes, this method works identically for VLANs. As long as each VLAN is assigned to a distinct virtual interface in OPNsense with its own subnet, the same firewall rule logic applies. The firewall treats VLAN interfaces just like physical interfaces when processing rules.