Simple Port Forward Failing

[kojak]

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

[viragomann]

In a port forwarding rule you should state a certain destination address instead of any, WAN address in this case.

However, according to the log, the forwarded traffic is passed out on the MGMT interface. You can sniff the traffic on the interface with the pacekt capture tool (Interfaces > Diagnostic) to investigate this.

Possibly your webserver blocks access from outside of its subnet and you have to allow the access in its firewall.

[kojak]

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:

[kojak]

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.

[Patrick M. Hausen]

Is the external client connected directly to your WAN network instead of "somewhere on the Internet"? If yes, by default OPNsense will send outbound packets from WAN to the WAN gateway and not to the client. To change this set:

Firewall > Settings > Advanced > Disable force gateway