How to Access LAN Subnets from Other Subnets with Interzone Firewalling on the Same Router

To access LAN subnets from other subnets while interzone firewalling is active, you must explicitly define a firewall policy that permits traffic between the source and destination zones. This requires configuring both static routes for return traffic and specific allow rules in your firewall’s security policies to bypass default deny behaviors.

Understanding Interzone Firewalling Logic

Interzone firewalling operates on the principle of least privilege. By default, most enterprise-grade routers and next-generation firewalls block all traffic between different security zones unless an explicit rule permits it. When you attempt to ping or connect to a device in Subnet A from Subnet B, the router checks its routing table to determine where to send the packet. If the route exists, the packet reaches the destination interface. However, the firewall engine then evaluates the security policy. If no rule matches the source zone (e.g., LAN_1) and destination zone (e.g., LAN_2), the traffic is silently dropped. This behavior is intentional to prevent lateral movement in case of a compromise. For example, if one subnet is compromised, you do not want attackers to easily scan or attack devices in another subnet. Therefore, achieving connectivity requires two distinct configuration steps: ensuring the network layer knows how to reach the remote subnet, and ensuring the application layer allows the traffic to pass.

Common Misconceptions

A frequent error is assuming that disabling the firewall entirely is the solution. While this grants access, it removes critical protection against threats originating from any connected device. Another common mistake is creating a rule that only allows outbound traffic but forgets to allow the return traffic. Since most firewalls are stateful, they track connections, but initial handshake packets must still match a permit rule in the correct direction.

Configuring Static Routes

Before touching firewall rules, verify that your router knows how to reach the target subnets. In complex topologies with multiple VLANs or physical interfaces acting as separate subnets, the router may not automatically know the path. You need to add a static route that points the destination subnet to the appropriate gateway or interface. For instance, if Subnet B is located behind a specific VLAN interface, you must ensure the router has a route entry for Subnet B's IP range pointing to that interface. Without this, the router will drop the packet at the routing stage before it even reaches the firewall inspection engine. Check your routing table using commands like show ip route on Cisco-style devices or the equivalent menu in pfSense or MikroTik to confirm the path is valid.

Setting Up Firewall Policies

The core of solving this problem lies in the firewall policy. You must create a new rule that explicitly allows traffic from the source zone to the destination zone. The exact location of this setting varies by vendor, but the logic remains consistent.

pfSense Configuration Steps

In pfSense, navigate to Firewall > Rules > [Zone Name]. You cannot simply add a rule to the general WAN or LAN interface if your subnets are defined as separate VLANs or CARP interfaces. Instead, select the specific interface associated with the source subnet. Click Add to create a new rule. Set the Action to Pass. Set the Protocol to Any for testing, or restrict it to TCP/UDP and specific ports for production environments. In the Source field, select the network object corresponding to your source subnet. In the Destination field, select the network object for the target subnet. Save and apply the changes. Remember that pfSense processes rules top-down; place this new rule above any generic deny-all rules that might exist in that interface’s rule set.

MikroTik RouterOS Configuration Steps

MikroTik uses a chain-based filtering system. You typically need to configure rules in the forward chain of the filter table. Open the terminal or the Winbox GUI and navigate to IP > Firewall > Filter Rules. Add a new rule with the following parameters:

• Chain: forward
• Src. Address: The IP range of your source subnet
• Dst. Address: The IP range of your destination subnet
• Action: accept

Ensure this rule is placed before any catch-all drop rules. If you are using NAT, also check the mangle or nat tables to ensure address translation does not interfere with internal-to-internal traffic, although pure inter-VLAN traffic often bypasses NAT depending on your setup.

Verifying Connectivity and Troubleshooting

Once the rules are applied, test the connection from a host in the source subnet to a host in the destination subnet. Use tools like ping or telnet to basic ports. If the ping fails, check the firewall logs. Most modern firewalls log denied packets, which helps identify if the rule is being hit or if a more specific rule below it is blocking the traffic. If the ping succeeds but application services fail, check for ACLs (Access Control Lists) on the destination host itself. Operating systems like Windows have built-in firewalls that may block ICMP or specific service ports regardless of the network-level firewall settings. Refer to guides on isolating computers in public LANs if you encounter unexpected isolation behaviors.

Security Best Practices

While granting access is necessary, always restrict the scope. Avoid using Any as the destination or source in your final rules. Define specific IP ranges and limit protocols to only what is required (e.g., only HTTP/HTTPS or SSH). This minimizes the attack surface. Regularly audit your firewall rules to remove stale entries that are no longer needed. For related configurations, such as handling VPN traffic or accessing PCs under different routers, see our guide on Accessing PC on another subnet under a different router. Additionally, if you are dealing with isolated segments, review How to Best Isolate Computer in Public LAN to understand complementary security measures.

Frequently Asked Questions

Why can I ping the gateway but not the host in the other subnet?

This indicates that routing is working correctly up to the interface, but the firewall is dropping the traffic destined for the specific host IP. Verify that your firewall rule specifies the exact destination subnet or host IP, rather than just allowing traffic to the gateway interface itself.

Does enabling interzone access break my network segmentation?

No, segmentation is maintained by the fact that traffic is only allowed through explicit rules. Unlike bridging all interfaces into one flat network, interzone firewalling ensures that each segment remains logically separate, with controlled "doors" between them. This is far more secure than merging subnets.

What happens if I place the allow rule below a deny-all rule?

The traffic will be blocked because firewalls evaluate rules in order from top to bottom. Once a packet matches a rule, processing stops. If a deny rule appears first, the subsequent allow rule will never be reached for that traffic.

Can I use DHCP reservations to simplify these rules?

Yes, creating dynamic objects based on DHCP leases can make management easier, but static IP addresses are generally preferred for firewall rules to ensure stability. If hosts change IPs frequently, relying on MAC addresses or DNS names in firewall rules may introduce complexity and latency.

Do I need to configure NAT for traffic between two LAN subnets?

Typically, no. Traffic between two internal subnets routed by the same device should remain private and unmodified. NAT is usually reserved for traffic exiting to the internet. Enabling NAT for internal traffic can cause asymmetric routing issues and complicate troubleshooting.