Messages

[Why did I need to disable reply-to?]

The solution to this problem was to disable reply-to on the firewall.  The final NAT configuration is shown below.

Why did I need to disable reply-to?
I'm not entirely certain, but I believe it's because I'm using a bridge. When I reviewed the reply-to documentation, I understood that reply-to is typically necessary if you have multiple WAN ports configured in a bridge. My setup is actually the reverse: I have a single WAN port and multiple internal ports combined into one bridge (five, to be exact). There are also several VLANs layered on top of this internal bridge, which spans all the ports.

How did I find the solution?
I fiddled with " Filter rule association" and noticed that setting it to "Pass" solved the problem.  A bit of googling after that led me to the reply-to setting and the final solution.

Other Benefits:
Setting the reply-to option also resolved a handshake issue I was experiencing with WireGuard, where clients would connect but never complete the handshake. WireGuard is MUCH more difficult to debug than HTTP because it generates very few logs. By setting up a simple Python HTTP server, I was able to conduct more controlled tests. I hoped that resolving the port forwarding problem would also help me find a solution for WireGuard, and I was correct.

Thanks community!



Final NAT configuration:

• IMPORTANT: In an earlier image I had both the WAN and MGMT networks configured as interfaces.  Do NOT do this as the NAT will get confused if you want to make an outgoing HTTP request on the SAME port as configured the FW is configured to redirect to.  IOW this will fail if issued from the HTTP server (i.e. 10.0.0.14 in my case): curl http://<any host anywhere>:8080 

I discovered that Opnsense offers a packet capture feature directly within its user interface. I performed captures on both my WAN and MGMT interfaces simultaneously, allowing me to trace the packet flow through the NAT, WAN, and MGMT interfaces. In this capture, I am able to observe:

• The incoming SYN packet from the HTTP client at 10.10.20.44 hitting the external IP of the OpnSense firewall 10.10.20.50
• The NAT translating 10.10.20.50:8080 into an internal address of 10.0.0.14:8080
• The internal client, 10.0.0.14, receiving and sending a SYN ACK to 10.10.20.44
• The NAT appears to be converting the internal IP, 10.0.0.14, back to the external IP, 10.10.20.50, in the 4th packet.
• Lots of retries after this...

It looks like the NAT is doing its thing correctly but it is hard to say whether that 4th packet is _actually_ leaving the Opnsense router and egressing onto the 10.10.20.x network.  I am certain that the client is not receiving it because I've run packet captures there as well.

[Packet Trace on the HTTP Server:]

Thank you for the suggestions, but I still haven't had any success. I updated the port forwarding rule to be more specific, as you recommended, and set the destination to "WAN net." I also discovered the useful "Linked rule" feature, which automatically created a non-editable rule in the WAN FW's ruleset.

I also tried broadening the WAN and MGMT rules to allow all TCP traffic in every direction (note the disabled rules), but this didn't resolve the issue. As you suggested, I set up a packet sniffer on the HTTP server and observed traffic reaching the server, 10.0.0.14. The server is responding to the client, 10.10.20.28; however, it appears OpnSense is blocking the replies, since both the client and server are repeatedly attempting retransmissions.

Packet Trace on the HTTP Server:


The NAT with a destination set:


WAN with disabled permissive rules (the MGMT network looks the same).  These permissive rules did not work:

[FW Logs:]

I have an OPNsense router connected to a lab network (10.10.20.1/24) so I can test it before putting it in PROD. The WAN IP of the OPNsense router is 10.10.20.50, and I am trying to forward port 8080 to a host (10.0.0.14) on my OPNsense MGMT network (10.0.0.1/24).

I can see that traffic reaches my OPNsense router and is redirected by NAT to the correct internal IP (10.0.0.14), passing through the WAN and onto the MGMT network. However, I do not see any traffic in the HTTP server's log, and I get no response to my curl request from 10.10.20.28. I have verified that I can successfully curl the HTTP server running on 10.0.0.14 from another host on the 10.0.0.x network. I'm stumped. Here are some screenshots of my setup...

FW Logs:


The NAT:


The WAN


The MGMT Network