What's new

Solved [SOLUTION] Asuswrt-Merlin 384.19 PortForwarding Not Working To Private Gateway Address

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

garycnew

Senior Member
All:

I've run into an issue on Asuswrt-Merlin 384.19 where creating a PortForward through Advance Settings > WAN > Virtual Server/PortForwarding creates the following iptables (but are not working):

Code:
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -A VSERVER -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.0.1:8888

A test OpenSSL s_client Connection is Refused.
Code:
# openssl s_client -connect 198.91.60.78:443
connect: Connection refused
connect:errno=111

If I bind the application directly to 198.91.69.78:443 instead of 192.168.0.1:8888 it works without issue.

I've confirmed that the destination application is listening on 192.168.0.1:8888, but for some reason the PortForward isn't bridging the Public IP:port and Private:IP:port.

Are there any known issues with Asuswrt-Merlin and PortForwarding?

Your assistance is greatly appreciated.

Respectfully,


Gary
 
did you try to do it via GUI? WAN - Virtual Server / Port Forwarding.
are you sure you should open TCP only, maybe UDP too.

good practice. before you report challenge you should confirm it is not working at last release software as same bug/ issue could be already resolved. 384.19_0 is already 1year old.
 
Any known issues have been addressed in the current 386.4 Alpha 1 builds. :)

Remind me again why you're running such old code today (and still)?
 
Have you checked to make sure AiCloud and/or anything else hasn't bound itself to 443? netstat should show you if something has
 
Have you checked to make sure AiCloud and/or anything else hasn't bound itself to 443? netstat should show you if something has

@Jack Yaz

I've confirmed that nothing else is bound to the Public IP:port (198.91.69.78:443). As I originally stated, I am able to successfully bind the application directly to port 443 (opposed to PortForward from 443 to 8888).

Respectfully,


Gary
 
Are you really forwarding anything? Is 192.168.0.1 your router LAN IP?

@dave14305

Yes... 192.168.0.1 is the router's LAN IP on interface br0. I could try moving it to a different Private IP Address.

Respectfully,


Gary
 
Are you currently using your workaround (binding to the WAN) as I see access to that IP/port is now working?
 
good point, if its something running on the router itself then port forwarding won't work, OP will need to add an ACCEPT rule to INPUT instead

@Jack Yaz

I created the PortForwarding Rule using the WebUI, but I suppose the WebUI assumes that I'm not going to use the router's Private IP Adrress as the destination in the PortForwarding Rule.

Respectfully?


Gary
 
Are you currently using your workaround (binding to the WAN) as I see access to that IP/port is now working?

@ColinTaylor

Yes... I'm still using my lighttpd.postconf alternative to bind lighttpd to only 192.168.0.1:443 instead of 0.0.0.0:443. That's why I'm binding the application internally to 192.168.0.1:8888.

BTW... Good Memory. ;-)

Respectfully,


Gary
 
@ColinTaylor

Yes... I'm still using my lighttpd.postconf alternative to bind lighttpd to only 192.168.0.1:443 instead of 0.0.0.0:443. That's why I'm binding the application internally to 192.168.0.1:8888.

BTW... Good Memory. ;-)

Respectfully,


Gary
Alas, not a memory issue. I was just referring to what you said in post #1, "If I bind the application directly to 198.91.69.78:443 instead of 192.168.0.1:8888 it works without issue."
Code:
# openssl s_client -connect 198.91.60.78:443
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 CN = www.cmoogsb4vol2.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = www.cmoogsb4vol2.net
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:CN = www.cmoogsb4vol2.net
   i:CN = www.7nnzdc7l.com
---
Server certificate
-----BEGIN CERTIFICATE-----
 
Alas, not a memory issue. I was just referring to what you said in post #1, "If I bind the application directly to 198.91.69.78:443 instead of 192.168.0.1:8888 it works without issue."

@ColinTaylor

Correct... Currently, I have the application bound directly.

Respectfully,


Gary
 
All I can say is that it works for me, but I'm using a different version of the firmware.

Also, my forwarding rules only create the DNAT entries. It doesn't create anything in the INPUT chain (I have to do that separately). EDIT Surely the INPUT rule should be for port 8888 not 443?
 
Last edited:
EDIT Surely the INPUT rule should be for port 8888 not 443?

@ColinTaylor

It appears that 443 INPUT rule is associated with something else as it still remains even after disabling PortForwarding. I wonder if that is overriding any subsequent 443 INPUT rules? Do you have a similar 443 INPUT rule by default?

Will you provide a sample of you're PortForwarding Rules as a primer?

Much Appreciated.


Gary
 
Port 443 is normally used by AiCloud as Jack mentioned in post #4. But I don't have anything related to 443 in my iptables, but then I don't have AiCloud enabled.

Have you tried using a different external port, say 444? And test the following rule from the command line (assuming your app is listening on 192.168.0.1:8888):
Code:
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT

P.S. You are testing the connection from the internet and not the LAN?
 
@ColinTaylor @Jack Yaz @dave14305

It appears that it is an issue with trying to PortForward to 192.168.0.1:8888. When I move it to 192.168.0.21:8888 it successfully PortForwards 198.91.60.78:443 => 192.168.0.21:8888.

Is it possible to PortForward from 198.91.60.78:443 => 192.168.0.1:8888 using an ACCEPT in the INPUT chain?

Thanks, again.


Gary
 
See my previous post.

@ColinTaylor

Apologies... I didn't see your post, until after posting my previous question.

The 8888 ACCEPT rule in the INPUT chain did the trick. I am now able to change the PortForwarding Rule back to the 192.168.0.1:8888 destination and successfully connect.

Thank @ColinTaylor @Jack Yaz @dave14305 so much for your assistance in troubleshooting and help resolving the issue, and not taking the easy way out of just suggesting I need to upgrade firmware.

Hopefully, this will assist anyone in the future whom attempts to PortForward on the Private Gateway Address.

Much Respect!


Gary
 
Last edited:

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top