So I've configured port forwarding under the NAT/QoS tab and those changes are reflected in the iptables output below (2002/tcp, 1194/UDP but both were tested using both TCP and UDP):
In Administration > Commands, I have the workaround iptables code:
Code:
insmod ipt_mark
insmod xt_mark
iptables -t mangle -A PREROUTING -i ! `get_wanface` -d `nvram get wan_ipaddr` -j MARK --set-mark 0xd001
iptables -t nat -A POSTROUTING -m mark --mark 0xd001 -j MASQUERADE
Like most others with this issues, I'm able to connect to these ports when going from LAN to WAN but the ports are inaccessible from the Internet, which nmap and numerous online port scanners confirmed.
I'm hoping it's not the case, but the port forwarding troubleshooting article mentions doing a 30/30/30 (hard) reset in cases where there's a legitimate iptables issue:
Posted: Sat Dec 20, 2014 19:38 Post subject: Solved
Deleted numerous disabled port forwarding rules, applied settings, and this was enough to get the two remaining port forwarding rules working. Keep the rules clean, otherwise it may disrupt enabled port forwarding.
Well, rebooted the router and port forwarding no longer works again. I'm also running an OpenVPN client in DD-WRT so I changed my internal OpenVPN server to port 1195 since OpenVPN client on DD-WRT was using 1194.
Quote:
update build
tatsuya46, am I not running the newest build for the WNDR3700v4? The link below lists "r25279" as the build, which I'm already running.
When you have problems like this, it's not a bad idea to create your port forwards directly in the firewall script, if only to verify it's not a GUI issue.
Haven't done it this way yet, but will depending what happens after this post.
Quote:
Beware, there’s always the possibility your ISP is blocking ports, esp. the low numbered ones. Try something much high, say 10000 or above
I've confirmed with my ISP that these ports are not blocked, whereas 25, 80, 135-139, 445 are.
Quote:
As far as the port assignments, the destination port of a remote OpenVPN server by your OpenVPN client is irrelevant. That port exists on the *other* system. So there is no conflict w/ having that same port open inbound on your router for your OpenVPN server.
Correct, and coincidentally enough the OpenVPN client on DD-WRT failed at nearly the same time that port forwarding worked for the first time. Had to try.
Quote:
If you're running an OpenVPN server on the primary router, you DON'T port forward! You're not trying to forward from the router's WAN to some other device on the LAN.
I wasn't clear... my OpenVPN server actually is an Ubuntu OpenVPN server on the LAN, with all iptables and routes working. When on wireless, clients connect and head outbound no problem.
The iptables above looks ok to me but I'm fairly new to it. It was mentioned above that I should update the build but it seems like I'm running current. All that aside, I'm not opposed to 30/30/30 but it would be nice to restore from a config, without reintroducing the same issues.
Thanks for that, I got the "425 Security: Bad IP connecting" error and forgot to turn off VPN and retry.
I upgraded to revision 25648 and immediately port forwarding worked (from iOS client first on WLAN, then on 3G). No kidding that a few minutes later, client can't reach the VPN server from 3G but still can on WLAN. On WLAN, client can reach the OpenVPN server IP, LAN server IP, gateway, and outbound.
I've also rebooted the router and client. The port forwarding config and iptables all look unchanged by the upgrade. I'll keep checking but that's what I see so far.
If nothing else it seems iptables are being changed according to GUI config. Also in case it's relevant, following almost any change including the port forwarding reconfig above, I'm forced to reboot the router as the WAN connection drops every time.
My router is different only in that I have an OSSEC HIDS server on the network doing SSH-based logins for file-integrity monitoring. But all it's doing is hashing files, reporting output of netstat, and similar. Not sure if that could interfere as it's basically the same as logging in and running a few shell commands.