Port forwarding not working

[macfan]

I was running .38_1 and just updated to .41 to be sure that didn't fix it.

I have a Time Warner business class cable modem connection set to bridge mode. I have a AC-68U that has the public IP as wan. I'm using a DDNS service to make that WAN IP available to me as a domain name.

I have a cheap wifi router setup in infrastructure mode that exists to make an ethernet-only device accessible to the network. That device doesn't support DHCP, so has been assigned 192.168.100.25. I have enabled manual assignment and reserved that IP in DHCP.

If I'm on my wifi network, I can access the domain name and port and get my device as expected. But if I'm outside the network, it fails. SSHing to webserver outside my network and trying to connect, curl times out:

[~]# curl -v vpn.artifacturestudios.com:79
* About to connect() to vpn.artifacturestudios.com port 79
* Trying xx.xx.xx.xxx... Connection timed out
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host

I found info on how to check whether the request gets to iptables and it does. It increments when I try to connect, even though it ultimately fails. It increments identically when I make the query from inside the network. Here is the output:

xxxxxxxxx@RT-AC68U:/tmp/home/root# iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 619 packets, 87192 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
135 18795 VSERVER all -- * * 0.0.0.0/0 xx.xx.xx.xxx

Chain INPUT (policy ACCEPT 324 packets, 32307 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 146 packets, 18644 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 147 packets, 18704 bytes)
pkts bytes target prot opt in out source destination
234 15458 MASQUERADE all -- * eth0 !xx.xx.xx.xxx 0.0.0.0/0
0 0 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xd001

Chain DNSFILTER (0 references)
pkts bytes target prot opt in out source destination

Chain LOCALSRV (0 references)
pkts bytes target prot opt in out source destination

Chain VSERVER (1 references)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8008 to:192.168.100.25:80
1 60 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:79 to:192.168.100.25:80
134 18735 VUPNP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain VUPNP (1 references)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:27163 to:192.168.100.36:27163
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:27164 to:192.168.100.36:27164
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:27161 to:192.168.100.60:27161
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:27162 to:192.168.100.60:27162

I've tried many variations of disabling/enabling firewall, port forwarding, dhcp reservations, etc. I created the second port forwarding 79 to see if that helped. Nothing works from the outside. But the same exact domain name works fine from the inside even though it resolves to the external ip. Since I set it to bridge mode, I can't get to the cable modem's admin page. I guess I can try connecting directly to it and see if there is anything there that might be causing it. But it's mounted up high in our shop so not a easy task. Is that my best next step? I tried installing tcpdump, but on 38_1 at least, iPkg gave the error ipkg: can't load library 'libipkg.so.0' which I suspect is because $PATH didn't include the new directories (I had to run it from /jffs/asusware.arm/bin but I wasn't sure how to fix that.

Michael

 

[sinshiva]

hi, a little confused;

0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8008 to:192.168.100.25:80
1 60 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:79 to:192.168.100.25:80

1) i can't say i've ever used a router to forward 2 different ports to the same port on another machine, so that would be the first irregularity to me. (not that i think this wouldn't work, per se)

2) you said you are trying to connect to SSH on the webserver, but you aren't forwarding port 22/tcp, are you running it on port 80 instead? in which case, curl wouldn't be able to communicate, correct? no experience with curl, myself.

[edit/] and forgot to mention; if you forward port 22 to the other device, you may need to move the router's ssh port to something else, even if disabled

 

[macfan]

No, I'm SSHing to an external webserver in order to test whether I can get into my network remotely. I have no need to SSH into my network.

I'm trying to get to a web server running on port 80.

I added the second mapping only for test purposes. My plan was to use port 8008. When that didn't work, I added one for 79 to see if a lower port or simply a rewrite of the config file might fix it. It did not.

The rule seems to exist in iptables, and is apparently getting the request, but for some reason it's going no further. The only difference in the test is whether I'm inside or outside of my local network.

 

[sinshiva]

ok, i think it may be your wireless bridge, then. does port forwarding work for a device directly connected? (either wired or wireless)

 

[macfan]

I did some more testing tonight and learned the following:

- The router acting as bridge is a Edimax EW-7228APn which appears to have no port mapping options regardless of which mode you put it in. I currently have it in infrastructure mode so it connects to my AC66U. I wouldn't think it would require port mapping in that mode though.

- I plugged the Edimax into my laptop via Ethernet and turned off the laptop's wifi and was able to use it as the bridge it's supposed to be.

- In the Asus, I port mapped both the Edimax's admin page and my laptop. I was able to connect to my webserver outside our network, then curl the admin page successfully. I was also able to ssh back into my laptop.

- But when I re-connected my control device, it behaved the same way.

I read somewhere, that iptables won't forward to devices that don't advertise themselves? The device I'm trying to access doesn't seem to support dhcp so has an IP I manually assigned it via its admin page. Is it possible that is the cause? Is there any way to override this behavior in iptables? Or otherwise make the Asus see it as a more interactive device than it is? It's a web controlled relay from this company:
www.controlbyweb.com/webrelay/

Michael

 

[macfan]

So I realized that the IP I reserved on the Asus was associated with the MAC address for the Edimax bridge router. (Oddly, the Edimax claims to use the same MAC for Ethernet and Wifi which doesn't seem possible.) I revised it to what I think is the MAC address for the ethernet control. I tried to confirm via the arp table that it took, but it gets populated with the MAC for the Edimax. I guess that's correct though since the device is behind the Edimax even though it's operating in station infrastructure mode. Edimax doesn't offer ssh access so I can't see what its arp table contains.

The manufacturer for the device said it is very quiet on the network, but they'd see if they could find a way to make it chattier for me. I tried running ping on that IP and while it was running tried to access it remotely. That didn't work, so I'm not sure if it's merely a matter of the device being too quiet for iptables to route to it.

I'm kind of stuck here... any thoughts?

 

[jlake]

I used to experiment a lot with networking stuff (and troubleshoot all my failed experiments). One thing I started doing was to take a long piece or two of Ethernet to try and isolate what the problem was. Nothing beats a direct connect Ethernet for isolating/troubleshooting problems. It will save you hours of spinning your wheels (for $20)


http://www.amazon.com/dp/B000V0IE6G/?tag=snbforums-20

 

[macfan]

So I connected via an alternate method and it still didn't work. After poking around for a while, I eventually traced it to a typo in the settings I entered for the wireless relay device. I had mistakenly entered the gateway as 192.168.1.1 rather than 192.168.100.1. I'm not sure why it worked in every other way. It would have been a lot easier to discover the error if it simply didn't work at all.

Thank you all for your assistance.