Messages

Hi everyone,

I wanted to give a quick update to keep you in the loop and respect the great suggestions shared so far. We are actively troubleshooting based on your feedback.

Here is what we checked and the current status:

Regarding the suggestions to trace the packets: We ran tcpdump on the inner firewall's WAN interface. The traffic from the outside world successfully reaches the inner firewall's external interface on the correct port without any changes from the outer firewall.

The issue we hit: When we configure the port forward rules in the inner firewall's web GUI, the interface says "Applied Changes" and successfully writes the lines to the temporary configuration file (/tmp/rules.debug). However, when checking the live kernel rules via root SSH using pfctl -s nat and pfctl -s rules, the output is completely empty. The changes are simply not reflecting in the active pf kernel.

Next Steps: Since the GUI changes are stuck and not being pushed to the operating system, we are currently restarting the configd service via backend and will try to force a rule reload to see if we can get the kernel back in sync.

I will test again right after the reload and update you with the final result. Thank you all for the brilliant guidance so far!

Do you really think it's productive to post the same question at least four times in three languages? Two times in English in different subforums as far as I can see?

You will get part of answers here, part of answers there, instead of a single coherent thread. I recommend you delete all postings but one.

Hi Patrick,

You are absolutely right, and I sincerely apologize for the spammy behavior. I got a bit panicked trying to find a solution to this urgent production issue, but I completely agree that having a single coherent thread is much better.

I have deleted the other threads as per your recommendation. Let's keep only one thread active.

Regarding our issue, we have a Double NAT + Multi-WAN setup with a Thomas Krenn server running OPNsense Business. We are seeing a PASS log on the internal WAN interface but absolutely 0 packets are reaching the internal VLAN interface.

I would highly appreciate any guidance you or the community could provide. Again, sorry for the inconvenience!

Double NAT + Multi-WAN: Port forward packets logged as PASS on WAN but dropped before reaching internal VLAN

Hi everyone,

We are experiencing a frustrating packet-dropping issue in a cascaded (Double NAT) and Multi-WAN environment.

### Our Topology
1. **WANgate (Edge Firewall):** Has public IP on WAN. Port forwards TCP 9449 to LANgate's WAN IP (`10.X.Y.2`).
2. **LANgate (Internal Firewall):**
   - WAN interface IP: `10.X.Y.2` (connected to WANgate's LAN subnet `10.X.Y.0/24`)
   - Multi-WAN configured (has another gateway `WAN_SERVER` active)
   - Port forwards incoming TCP 9449 to an internal QNAP NAS (`10.A.B.121:443`) on an internal interface (`vlanXX` / `10.A.B.1/21` subnet).

### Environment Details
- **OPNsense Version:**    OPNsense 25.10.2_12-amd64
            FreeBSD 14.3-RELEASE-p10
            OpenSSL 3.0.19
Licensed until 2026-09-29
- **Hardware/Platform:**
Bare-metal Thomas Krenn 2U rack server with Intel NICs
Intel(R) Xeon(R) E-2386G CPU @ 3.50GHz (6 cores, 12 threads)
- **Hardware Offloading:**
Disabled (Checksum, TSO, and LRO are all checked/disabled under Interfaces > Settings)


### The Problem
When testing from an external IP, we can see the packets successfully forwarded from WANgate to LANgate's WAN.

On LANgate's Live View logs:
- We see a `PASS` log for `10.X.Y.1` (WANgate LAN) -> `10.X.Y.2:9449` (LANgate WAN).
- **Crucial Detail:** The log entry has an **empty label**, meaning it doesn't seem to trigger the NAT rule itself, but rather falls through to a generic PASS rule.

When running a Packet Capture on LANgate's internal interface (`vlanXX`) filtering for destination host `10.A.B.121` and port `443`, **absolutely 0 packets** are captured.

### What we have tried so far:
1. Checked QNAP's gateway configuration (it is correctly pointed to LANgate `10.A.B.1` with a `/21` mask).
2. Checked QNAP's internal security settings (Allow all connections is active).
3. Created an Outbound SNAT rule on LANgate (Interface: internal, Source: Any, Destination: QNAP IP, Translation: Interface Address) to prevent asymmetric routing issues, but it didn't help.
4. Created a Source NAT (SNAT) on WANgate's LAN so LANgate sees the source as `10.X.Y.1`, but still no packet reaches the internal VLAN interface.

Since we are using Multi-WAN, we suspect this might be related to state-table routing, `reply-to` behavior, or an issue with how OPNsense processes port forwards with multiple gateways active.

Any ideas on why OPNsense receives the packet on WAN but completely silent-drops it before forwarding it to the internal interface?

Thank you in advance!