Hey Community,
I'm trying to port forward 25292/tcp to 192.168.1.111/32. Both source and destination ports are identical. The device is an Unraid 7 server running Docker. The target container is in bridge mode with port 25292/tcp allocated.
In OPNsense, I have created a NAT rule along with the corresponding firewall rule. However, when I try to access http://MY-WAN-IP:25292 from another network using curl, I get the following error:
user@device ~ % curl http://MY-WAN-IP:25292 --verbose
* Trying 0.0.0.0:25292...
* connect to 0.0.0.0 port 25292 from 192.168.2.49 port 57851 failed: Network is unreachable
* Failed to connect to 0.0.0.0 port 25292 after 4018 ms: Couldn't connect to server
* Closing connection
curl: (7) Failed to connect to 0.0.0.0 port 25292 after 4018 ms: Couldn't connect to server
MY-WAN-IP and 0.0.0.0 are just placeholders.
I'm not behind a second NAT (DS-Lite etc).
If it's really trying to connect to 0.0.0.0, maybe you have some DNS filter that's blocking it? It should be trying to connect to your actual WAN IP address.
Speaking of that, usually the destination for the port forward would be "WAN address", not "WAN net".
1. If the 0.0.0.0 is real, then the DNS resolution for MY-WAN-IP does not work.
2. Also, you may be behind CG-NAT.
3. You really tested from outside of your network? Otherwise, you would need NAT reflection enabled.
Sorry, I should have mentioned, that I used MY-WAN-IP and 0.0.0.0 just as Placeholders for real addresses.
I'm sure that I curl'd from outside my network, I checked the IP before.
My carrier is DTAG (fiber), they don't use CG-NAT. My gateway is directly connected to the ONT.
Let me see if changing the destination to ,,WAN address" helps.
The FW live-view screenshot indicates proper rdr and FW pass (despite the use of LAN net).
It seems it was indeed from outside your WAN (80. to 93. rdr log).
Personally, I'd follow up with a packet capture filtering on the destination port to ensure the internal server replied and that the reply makes it out of WAN.
We just had someone try this and the target machine had not set a default route (https://forum.opnsense.org/index.php?msg=227191), thus it did not repond to IPs from outside the LAN. It largely depends on how your docker networking is set up (https://forum.opnsense.org/index.php?msg=223523).
Good news (I guess): Without changing anything it's working again.
Thanks for your help.