Need port forward help please

How do I do that, try to ping the machines in question from another machine in the lan?

Sorry to report, but the same result 18775 is open, 18080 (wireless) is closed.
And no incoming connections on either machine. Rechecked UFW and it says they're open (allow incoming).

It still makes no sense though, why one would show open and the other always closed. Makes me think its something particular to lede or the router. I'm considering trying to go back to my old router with a different firmware, to eliminate if it is a problem with the client machines.

Run a nmap scan from a shell on your computers running Ubuntu.

TCP check:

nmap -sT -p 18775 192.168.1.172
nmap -sT -p 18080 192.168.1.140

UDP check:

sudo nmap -sU -p 18775 192.168.1.172
sudo nmap -sU -p 18080 192.168.1.140

There is no specific reason that wired would work and wireless wouldn't in terms of the port forwarding, so I suspect that the issue is on that wireless host. Or it could be that your ISP blocks that port.

Also, do you have any other routers in the system? Or is the OpenWRT device the only router?

Double check that both of the hosts (that get the forwarding traffic) have the correct IP addresses, and as @mj5030 stated, do an nmap scan from another host on your LAN to make sure it the ports are indeed open on those systems.

What I was referring to earlier about testing the connections internally and externally... it depends on the app itself that would connect through, but let's pretend the port forwarding was pointing to web server on your network (as an example) -- say port 80 to 192.168.1.5 forwarding through from WAN. To test, you would open a web browser and do the following:

  1. From another host on your LAN (say 192.168.1.10), browse to 192.168.1.5 to verify that port 80 is open and that the web service is running and responding in general.
  2. From that same host on your LAN (192.168.1.10), browse to <mydomain.com> or (where <mydomain.com> is replaced by your actual domain name or is the IP address of your WAN port) -- this will verify that your external domain name and/or IP address resolve correctly and that you can connect through the router (this is where the 'hairpin NAT' / 'NAT reflection' comes into play).
  3. Now try to connect from a host outside your network (i.e. on cellular, or any outside network such as work/school/home/friend's home, etc.) using the external IP and/or domain name.

If step 1 fails, you know the problem is with the host(s).
Step 2 may fail if the hairpin NAT isn't working, but if 3 works, port forwarding is okay. But if both 2 and 3 fail, you may have an issue with your router configuration.

I see what you mean, yes I could run a program that would connect to what I need.. from another machine in the network.

I still don't understand why a simple port forward is giving me problems, but I guess I'll try these things and trial and error with another router & firmware.

Until you have done the nmap scan and/or step 1 of my recommendations above, you have not ruled out the possibility that the hosts themselves are not open/responding to the connection requests. Therefore, it may not be the OpenWRT firmware that is at issue here.

That said, if you swap for another router and find that everything works as expected, it would point to a misconfiguration of the OpenWRT router.

You didn't answer a critical question, though...

~$ nmap -sT -p 18775 192.168.1.172

Starting Nmap 7.01 ( https://nmap.org ) at 2018-07-10 22:39 CDT
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.11 seconds
:~$ nmap -pN T:18775 U:18775 192.168.1.172

Starting Nmap 7.01 ( https://nmap.org ) at 2018-07-10 22:39 CDT
Error #486: Your port specifications are illegal.  Example of proper form: "-100,200-1024,T:3000-4000,U:60000-"
QUITTING!
:~$ nmap -sT -p 18775 192.168.1.172

Starting Nmap 7.01 ( https://nmap.org ) at 2018-07-10 22:40 CDT
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.11 seconds
:~$ nmap -sT -p 18080 192.168.1.140

Starting Nmap 7.01 ( https://nmap.org ) at 2018-07-10 22:40 CDT
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.10 seconds
        :~$ sudo nmap -sU -p 18775 192.168.1.172
[sudo] password for  : 

Starting Nmap 7.01 ( https://nmap.org ) at 2018-07-10 22:40 CDT
Nmap scan report for  xxxxx.lan (192.168.1.172)
Host is up (0.00039s latency).
PORT      STATE  SERVICE
18775/udp closed unknown
MAC Address: xxxxxxxx 

Nmap done: 1 IP address (1 host up) scanned in 0.68 seconds
:~$ sudo nmap -sU -p 18080 192.168.1.140

Starting Nmap 7.01 ( https://nmap.org ) at 2018-07-10 22:41 CDT
Nmap scan report for xxxxx.lan (192.168.1.140)
Host is up (0.12s latency).
PORT      STATE  SERVICE
18080/udp closed unknown
MAC Address: xxxxxxxx

Nmap done: 1 IP address (1 host up) scanned in 0.65 seconds

I guess maybe it is the machines? This was all done from a different machine in the LAN, trying to get to the two.

I didn't have the program listening yet.

To answer your other question, I don't have any other routers in the network.

Edit: Here is output from ' ufw status verbose ' on one of the machines (192.168.1.140), similar (but 18775) on the other..

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
46250                      ALLOW IN    Anywhere                  
18080                      ALLOW IN    Anywhere                  
46250 (v6)                 ALLOW IN    Anywhere (v6)     

Just a 'shot in the dark' could it be that ufw is not liking that I have shut off IPv6 in network configurations, and that might be causing problems?

Yup... it is the hosts, not the router.

You'll need to check that the firewall on the hosts is allowing connections (based on the ufw output, seems okay, but I'm not an expert on that), and that the application that will be listening is both running and indeed listening for inbound connections (in general and specifically on that port).

1 Like

I guess I'll be off to post on ubuntu forums then.. or go searching for ufw issues.

1 Like

Have you tried the "easy" step of seeing what ports have listeners on your service hosts?

ubuntu $ netstat -an4

or the like?

1 Like

If that just reports "ESTABLISHED" does it mean that there is incoming traffic to the port I have opened?
Maybe its just the program I'm using (showing no inbound or incoming), that is reporting incoming status incorrectly?

Edit:
I see that it also reports "LISTEN" on 0.0.0.0 and 127.0.0.1 for the port I want.

I guess a way for me to know for sure, as previously stated by someone - is to try to connect to my program from outside my network, I don't really have the means right now to do that though. (Maybe it is ISP blocking?)

Edit 2:
Here is what the program always shows:

not mining, net hash xxx.xx MH/s, v7, up to date, 8(out)+0(in) connections, uptime 0d 0h 3m 47s

Always " 0 in "

sudo netstat --inet -l -p

Shows listening connections using IP protocol, their process names, bound IP, ports and process IDs.

You then need to verify that you opened the firewall. I suggest using the GUI:

sudo apt-get install gufw

The "Report" screen also shows this process information; and also uses an easy black and red display.

In "Report" It shows my port / line as red, but doesn't say incoming .. just an " * " under "Address", and TCP for "Protocol"
I'm not sure what red means yet..

Whoa .. I deleted the rule in Gufw (previously from ufw) and recreated the rule (just in Gufw)
and now incoming !

So is this some bug I should report with ufw?

Well congrats, I was gonna show you how to make the rule by selecting the process on the report screen!

It was probably an error on the command line (fat-finger user error, :rofl: ). It appears to work in the GUI, so you're good.

Red means "firewall opened."

It would also be valuable to know if incoming connections are actually needed by the program(s) you're running. Many current client-server programs only make outgoing connections because of the challenges of guiding their users to manage IPv4 NAT to allow the incoming connections. It may well be that the client you are running connects to the remote server, rather than the remote server needing to be configured to connect to your client(s).

If your client(s) only make outgoing connections, then, in general, no special configuration of your router would be required. It may well be that your ISP is blocking the kind of activity you are trying to run. Many ISPs block SMTP on port 25 for non-business accounts. It would not surprise me that they would block either the ports or the hosts involved as a "service" to their customers.

Well the thing is I'm assuming I need incoming because I plan on trying to connect to the program from outside my network? I'm guessing it will be necessary in this case, otherwise it did seem to work fine (alone) without needing incoming.

Edit: If it is a case , when I try to connect from outside my network and it doesn't work as intended. Then maybe it is ISP blocking.. I'll look into if maybe the program allows for custom ports defined ( I think it does, but i'm not 100% sure yet if I remember seeing that )

I know maybe it doesn't mean much to you guys, but I just wanted to thank you again.
I was struggling with this for a fairly long time.

I'm still thinking it is some bug that I might try to let ufw people know about, because I had been creating and re-creating the rule multiple times with ufw trying to get it to work - i'm just not understanding yet what the root cause was.

1 Like

OK, that makes sense on incoming connections.

tcpdump would let you see if the packets are making it to your router from the outside. The tcpdump-mini package has been sufficient for all my tcpdump needs on OpenWRT.

ip link

will give you the names of the interfaces, such as eth0 or the like (for your WAN). Then

tcpdump -ni eth0 tcp port 12345

or the like will let you see if there is traffic getting to (as well as flowing from) your router (use the proper interface and port in the above).

@jeff thanks for the info on tcpdump-mini

I wish now I could do rate limiting with ufw, but I don't see options for that in Gufw.
Something like:

-A ufw-user-input -p tcp --dport 18080 -m conntrack --ctstate NEW -m recent --update --seconds 6 --hitcount 12 -j ufw-user-limit

But, now I'm fearful if I try that without using Gufw, I'll lose my incoming connections.
I suppose maybe I should try to contact ufw devs or support.

Or, could I rate limit just for that port, somewhere in LEDE ?

Within reason, iptables is iptables. Rate limiting and/or shaping should be possible with the tools on either OpenWRT or on the service host itself.