Directly routing traffic between VLANs through the WAN interface is technically impossible for standard RFC1918 private networks because the internet does not route private addresses. To allow communication between isolated network segments, you must configure them on the same local switch or use a site-to-site VPN that encapsulates the traffic securely within the public internet.
The Routing Reality of Private Networks
Many network administrators attempt to connect two separate Local Area Networks (LANs) by treating the Wide Area Network (WAN) as a bridge. This approach fails because of how IP routing works globally. The global internet consists of public IP addresses assigned by Regional Internet Registries. When a packet leaves your router with a source address from a private range like 192.168.1.0/24, it undergoes Network Address Translation (NAT). The router replaces the private source IP with its own public WAN IP.
When a response comes back from the destination, it is addressed to your public IP. The router then translates it back to the original private IP. However, if you are trying to send traffic from VLAN A to VLAN B via the WAN, the packets leave your network, traverse the public internet, and arrive at another provider's network. That external network has no route to your internal 192.168.x.x subnets. It will drop the packets immediately. There is no mechanism for the public internet to deliver a packet destined for a private IP address unless that address is specifically mapped via complex Hairpin NAT, which is generally unstable and insecure for general inter-VLAN communication.
Why Direct WAN Bridging Fails
Attempting to force this connection often leads to significant security vulnerabilities and configuration errors. If you expose internal RFC1918 networks directly to the WAN without proper isolation, you risk allowing malicious actors to probe your internal infrastructure. Standard firewalls like pfSense are designed to block unsolicited inbound traffic from untrusted interfaces (WAN) to trusted interfaces (LAN/VLAN).
Furthermore, asymmetric routing issues arise. If VLAN A sends a request out the WAN, and VLAN B responds, the return path may not match the expected interface rules. This results in dropped connections, timeout errors, and difficult troubleshooting scenarios. As noted in related troubleshooting guides, blocking RFC1918 networks is a critical security feature, not a bug to be bypassed lightly. Bypassing these protections requires deep understanding of stateful inspection and NAT rules, which is rarely suitable for simple inter-VLAN connectivity.
Troubleshooting pFsense: Issues with Blocking RFC1918 Networks for LANCorrect Solution: Layer 2 Switching
The most robust and standard method for allowing traffic between VLANs is to keep them on the same Layer 2 domain. If VLAN A and VLAN B are both connected to the same managed switch, they can communicate seamlessly provided the router allows the traffic. In pfSense, you create different virtual interfaces (CARP or VLAN tags) for each VLAN. You then assign these interfaces to the firewall and create rules permitting traffic between them.
This method keeps all traffic local, reducing latency and avoiding the complexities of WAN routing. It ensures that only authorized ports and protocols are accessible between the segments. For example, you might allow HTTP access from a guest VLAN to a server VLAN while blocking SSH. This is the intended design for multi-VLAN environments and provides the highest level of control and performance.
Alternative Solution: Site-to-Site VPN
If the VLANs are physically separated by distance and cannot share a switch, you must use a Virtual Private Network (VPN). A WireGuard or IPsec site-to-site tunnel creates an encrypted overlay network across the public internet. Both pfSense instances establish a tunnel, and you add static routes on both ends pointing to the remote subnet through the tunnel interface.
This approach treats the WAN as a transport medium rather than a routing destination. The traffic is encapsulated, routed to the peer’s public IP, decapsulated, and then delivered to the local VLAN. This maintains the integrity of private addressing schemes and ensures that data is encrypted in transit. It is the only viable way to connect geographically dispersed private networks securely.
Common Misconfigurations to Avoid
Administrators often try to solve this by creating a second WAN interface or using policy-based routing incorrectly. These methods do not solve the fundamental issue of private address routability. Additionally, ensure that DHCP servers are correctly configured to avoid IP conflicts. Incorrect DHCP settings can lead to devices receiving wrong IP addresses, further complicating connectivity issues.
Troubleshooting DHCP Server Assigning Wrong IP AddressSecurity Implications
Exposing internal services via the WAN is a major security risk. If you must expose a service, use a reverse proxy or port forwarding with strong authentication. Never open unnecessary ports. Regularly audit your firewall rules to ensure that only required traffic is permitted between VLANs. Monitoring logs for unusual activity helps detect potential breaches early.
Frequently Asked Questions
Can I use Port Forwarding to connect two VLANs?
No, port forwarding maps external requests to internal servers, it does not route traffic between two internal subnets. It is used for exposing single services to the internet, not for inter-VLAN communication.
What happens if I ignore the RFC1918 blocking rules?
Ignoring these rules exposes your internal network to the public internet, allowing attackers to scan and exploit vulnerable devices directly. This violates basic network security principles and increases the risk of data breaches.
Is WireGuard better than IPsec for this purpose?
WireGuard is generally faster and simpler to configure for modern setups, but IPsec offers broader compatibility with older hardware. Choose based on your specific performance needs and device support.
Why do my VLANs lose connectivity when I change the WAN IP?
Changing the WAN IP does not affect local VLAN routing if they are on the same switch. If they are disconnected, check your firewall rules and physical cabling, as the issue is likely unrelated to the WAN address change.
Can I bridge two different ISPs to connect VLANs?
Bridging ISPs does not solve the private IP routing problem. You still need a VPN or a direct Layer 2 connection. Using multiple ISPs requires advanced routing policies that do not bypass the fundamental limitations of private addressing.