Traffic Not Passing OPNsense Firewall in Hyper-V: Troubleshooting Steps

Traffic not passing through an OPNsense firewall in Hyper-V is typically caused by incorrect virtual switch configurations, missing VLAN tags on physical NICs, or misaligned subnet definitions within the guest OS. This guide provides a systematic approach to diagnosing these connectivity issues by verifying hardware settings, validating network interfaces, and ensuring proper routing rules are active.

Verify Virtual Switch Configuration

The foundation of any successful VM networking setup lies in the Hyper-V Virtual Switch Manager. If traffic cannot reach the firewall, the first place to look is how the virtual network adapter is connected. Open the Hyper-V Manager and navigate to Virtual Switch Manager. Ensure that your external switch is bound to the correct physical network interface card (NIC) on the host machine. A common mistake is selecting a secondary or disconnected NIC. Furthermore, check the "Allow management operating system to share this network adapter" option. While this is primarily for the host's own connectivity, it ensures the underlying driver stack is functioning correctly. If you are using a nested virtualization setup, ensure that MAC address spoofing is enabled on the virtual switch properties. Without this setting, the OPNsense VM may be blocked from sending frames with source MAC addresses different from its assigned vNIC, causing the upstream router to drop packets immediately.

Check Physical Network and VLAN Settings

If the virtual switch is configured correctly, the issue often resides in the physical network infrastructure. OPNsense requires specific VLAN tagging if your environment uses segmented networks. In the Hyper-V settings for the OPNsense VM, verify that the VLAN ID matches the tag expected by your physical switch ports. If your physical switch port is configured as a trunk port, the VM must send tagged frames. If it is an access port, the frames must be untagged. Mismatches here result in silent packet drops where no error is logged, making diagnosis difficult. Additionally, inspect the physical NIC on the Hyper-V host. Some enterprise switches require specific flow control or jumbo frame settings. While OPNsense generally handles standard MTU sizes well, forcing jumbo frames without consistent support across the entire path can lead to fragmentation issues and dropped packets. Ensure that the physical uplink is not congested or disabled due to error states. You can check the link status and error counters on your physical switch to rule out hardware-level failures.

Validate OPNsense Interface Assignments

Once inside the OPNsense web GUI, the next critical step is verifying interface assignments. Navigate to System > Route Settings or Interfaces > Assignments. Confirm that the WAN and LAN interfaces are correctly mapped to the available virtual network adapters. A frequent error occurs when the VM has multiple vNICs, and the wrong one is assigned to the WAN interface. This results in the firewall having no route to the internet while local traffic might still function partially. Check the IP configuration on each interface. Ensure that the subnet masks align with your physical network design. For example, if your LAN is 192.168.1.0/24, the OPNsense LAN interface must have an IP within that range, such as 192.168.1.1. Incorrect subnet masks can cause the firewall to believe that certain destinations are local when they are not, leading to ARP failures and traffic black holes. Also, verify that the gateway address on the WAN interface points to the correct upstream router IP.

Inspect Firewall Rules and NAT Configurations

Even with perfect cabling and configuration, traffic will not pass if the firewall rules are blocking it. Go to Firewall > Rules and review the LAN and WAN policies. By default, OPNsense allows all traffic originating from the LAN to the WAN. However, if custom rules have been applied, ensure there is an "Allow IPv4" rule at the top of the chain for the relevant interface. Pay close attention to the log icon; enable logging for deny rules to see if traffic is being explicitly rejected. Network Address Translation (NAT) is another common point of failure. Navigate to Firewall > NAT. Ensure that outbound NAT is set to automatic or manually configured to translate internal private IPs to the public WAN IP. If outbound NAT is disabled or incorrectly defined, return traffic from the internet will not know how to route back to the internal clients. Check the translation rules to confirm that the pool of addresses matches your WAN configuration.

Diagnostics and Packet Capture

When visual inspection fails, use built-in diagnostics to isolate the problem. Use the Ping utility within the OPNsense shell or GUI to test connectivity between interfaces. If you can ping the gateway but not external IPs, the issue is likely DNS or NAT-related. If you cannot even ping the gateway, the problem is layer 2 or layer 3 connectivity. For deeper analysis, utilize the Packet Sniffer feature under Diagnostics > Packet Sniffer. Filter by the specific interface and protocol to observe if packets are arriving at the firewall or if they are being dropped before reaching the NIC. Comparing this behavior to other known network issues can provide context. For instance, if you experience similar symptoms where basic connectivity exists but advanced protocols fail, reviewing guides on Unable to traceroute but able to ping can help distinguish between routing table errors and firewall policy blocks. Similarly, understanding how to handle packet drops in other contexts, such as Troubleshooting Dropping Packets in iptables, reinforces the importance of checking intermediate filters and queue disciplines.

Frequently Asked Questions

Why can I ping the OPNsense LAN IP but not the internet?

This usually indicates a misconfigured Gateway or NAT rule. Verify that the WAN interface has a valid default route pointing to your upstream router. Additionally, check the Outbound NAT settings to ensure internal traffic is being translated to the public IP address before leaving the firewall.

How do I enable MAC address spoofing in Hyper-V?

Right-click the OPNsense VM in Hyper-V Manager and select Settings. Under the Network Adapter section, click Advanced. Look for "MAC Address Spoofing" and check the box to enable it. This allows the VM to send frames with different source MAC addresses, which is essential for firewall appliances.

What should I do if OPNsense shows no activity on the WAN interface?

Check the physical connection on the Hyper-V host and the upstream switch port. Ensure the virtual switch is bound to the correct NIC. If the link light is on but no data passes, verify that the VLAN ID in the VM settings matches the physical switch configuration for that port.

Can incorrect DNS settings prevent traffic from passing?

DNS settings do not block raw traffic, but they prevent name resolution. If you can ping an IP address like 8.8.8.8 but not google.com, your DNS servers are unreachable or misconfigured. Update the DNS entries in System > General Setup to use reliable resolvers like 1.1.1.1 or 8.8.8.8.

How does this relate to Docker host networking issues?

While distinct environments, both suffer from NAT and bridge misconfigurations. Understanding Default Network Access to the Docker Host highlights similar principles regarding bridging virtual interfaces and ensuring that traffic flows correctly between isolated networks and the physical world.