Hi everyone, I am running a RB2011iAS-2HnD with latest router OS version 6.41.2 with latest version of Winbox. I have performed a factory reset to get a fresh start. I am trying to forward a port TCP and UDP for Torrent inbound connections. I have followed port forwarding instructions from several websites. They all say the same thing which is to use a NAT Rule to forward a port. However I cannot get it to work. I am using http://canyouseeme.org/ to test if the port is open. I have tried several other port forwarding test sites as well. They all fail.

I can see that the rule is being honored because each time I run the test, the number of bytes and packets increase. However the rule does not seem to pass the data to my desktop which has a static IP. I have tried disabling the windows firewall but this did not help. I am including a link to my google drive with some images from Winbox. They will show my Firewall filters which are factory defaults and my NAT rules which are factory defaults except for my TCP/UDP rules. I will only show the detail screens for the TCP rule because the UDP rule is identical with a different protocol. I am including a log entry that I am typing by hand so I can replace my WAN IP with X's. Thanks to all for your support...

dstnat: in:ether1 out:(unknown 0), src-mac 00:1b:d5:ff:4b:d9, proto TCP (SYN), 52.202.215.126:48928->XX.XX.XXX.XX:50325, len 60

https://drive.google.com/drive/folders/ ... sp=sharing

I am running 6.41.2 and the only difference between mine (working) and yours is I don't specific an In Interface under General. Not sure of the implications to that. You might also try specifying a source IP address instead, or leave it blank.

Hi Intermod and thanks for your reply. I tried removing the in interface and that did not make it work. I also tried adding a source IP but that did not work either. This is so strange. As I stated, I know the rule is being parsed because the bytes and packets increase with each test. It just fails to send the packet to my desktop machine...

Use Tools->Torch on your LAN interface and check if you see packet to your PC and configured port. Or add this rule and it will log the packet, if it passes through router: If that happens, your config is fine and you need to check settings of PC and torrent software.

Btw, it's much better to run "/export hide-sensitive" in Terminal and post the output, rather than screenshots.

Thanks Sob for your reply. I decided to to add the postrouting rule. The rule does pass. So I am stumped here. I am using qbittorent as my client. It says that my port is not open. I have run the port forward test on multiple websites including grc.com which I have complete faith in. They all say that the port is closed. This has been my method of testing for many years with many different routers. What am I missing here?

Make sure that the program is really listening on given port. Don't trust the program itself, but use something else (netstat, TCPView, ...).

Well I am feeling dumb about now. There is nothing wrong with my rules and the port is forwarding correctly. Testing with any of the available websites will fail. I am not sure why. However I found a nice utility that tells me the port is open. For those who are interested here is the link...

http://www.pcwintech.com/simple-port-tester

From that utility's description:

The trick with testing if your port forwarding is working is to have something on your computer actually listening on the port. If nothing is listening on the port the test will fail no matter what.

Which is kind of obvious. Didn't you have qbittorent running when you were testing it previously?

Hi Sob, Thanks for your help on this. Yes I did have Qbittorrent open when testing. This is really strange. All of the online testers fail. Yet the standalone tester succeeds. I am not sure why this is. I enable the log view in Qbittorrent, the log shows that it is successfully listening on 192.168.88.50 port 50325 UDP. However the graphic status indicator on the status bar, says "Offline, This usually means that qbittorrent failed to listen on the selected port for incoming connections". This contradicts what the log is saying. I think the next step is to find a torrent that folks are actively downloading/uploading. Then I can see if folks are grabbing pieces of the torrent that I have and they do not. I suspect that I will be able to upload pieces to others. If so then I will have to contact the qbittorrent team and find out why the status indicator is wrong. Thanks again for your support.

UPDATE: OK, I have finally found a decent online port scan tester. I has advanced options that allow you to specify what type of scan to perform and also perform a UDP scan. It turns out that qbittorrent does not have to be running to open port 50325 because the scan results are the same. At least I think that is the case because I tested with qbittorrent running, then I shut it down and rebooted my machine and tested with out it running. It would appear that the TCP scan will fail for some scan types and pass for others. However the UDP scan passes for all scan types. I am not sure why this is. I think this explains why the other online testers fail. They are probably only performing a TCP scan with one of the scan types that will not pass the firewall. Here are my results with a link to the online port test page...

Scan Type - TCP - UDP
___________________

connect() - fail - pass
SYN Stealth - fail - pass
NULL Stealth - pass - pass
FIN Stealth - pass - pass
XMAS Scan - pass - pass
ACK Scan - fail - pass
Window Scan - fail - pass

http://www.ipfingerprints.com/portscan.php

TCP and UDP are two different things (but you probably know that), so the log should say something about both (I think TCP is primary for bittorrent, but I'm not completely sure). The log and status indicator are not necessarily contradicting. Listening on <local address>:<port> is one thing, it will always work, unless the port is already used by something else. But if the indicator is based on number of actually incoming connections (if it's more than zero), it also depends on correctly forwarded ports or local firewall. Also just seeing if people download stuff from you won't tell you anything by itself, it works even when you don't have any forwarded ports (just not as well as when you do).

Regarding the update, UDP is harder to test. When testing TCP, you either get (or don't) some reply from other side, it's part of protocol, no matter what exactly it's used for. UDP doesn't have that, it depends on the application, if it sends something back or not. So you can reliably tell the difference only between "closed" or "open or filtered", where "closed" means that device send back icmp message about closed port (but with firewalls everywhere, it doesn't happen too often). And "open or filtered" is a little problematic, because it doesn't tell you much.

As suggested before, use Tools->Torch with internal interface and selected port and check if you see traffic in both directions. Or add another logging rule, this time in prerouting and your port number as src-port. Or use packet sniffer on your PC (that's what I usually do, but I understand that it's not what normal people have installed by default).

One could always get a friend to download Nmap and test your WANIP.

(not sure but maybe one can run NMap on an external address, dyndns name that is ones OWN WANIP and check that way??)

Edit: Disregard the above in brackets, thanks to Sob for the clarification below. (how do I do strikeout LOL)

No, you can't just test your own public address from LAN, because then you may be testing completely different firewall rules. E.g. if you have rule to drop all packets from internet with in-interface=<WAN>, it won't apply to packets from LAN, even if they are destined for WAN IP address.

I've looked on this topic and many others, having this same problem but no fix yet. It seems like something else might be wrong, because i've input it several different ways to try to get different results. I'm using an outside source to ping and see if the port is open, it won't open. Have a minecraft server running on port 25565, the default, and it is recognized via localhost or the local IP for this PC. I can connect to it myself locally, but i can't get it to allow other people in. I've watched several videos, and read several forum posts here, and in other forums. I've tried many different things over the last few days to no avail. It's starting to feel like some sort of insane puzzle by now. I've seen people ask for these to be posted so i'm doing the same.

/ip address print detail
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; defconf
address=192.168.88.1/24 network=192.168.88.0 interface=bridge
actual-interface=bridge

1 D address=192.168.1.151/24 network=192.168.1.0 interface=ether1
actual-interface=ether1

/ip route print detail
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
0 ADS dst-address=0.0.0.0/0 gateway=192.168.1.1
gateway-status=192.168.1.1 reachable via ether1 distance=1 scope=30
target-scope=10 vrf-interface=ether1

1 ADC dst-address=192.168.1.0/24 pref-src=192.168.1.151 gateway=ether1
gateway-status=ether1 reachable distance=0 scope=10

2 ADC dst-address=192.168.88.0/24 pref-src=192.168.88.1 gateway=bridge
gateway-status=bridge reachable distance=0 scope=10

/ip firewall export
# may/05/2019 13:23:20 by RouterOS 6.44.3
# software id = 5CX7-V9R4
#
# model = 2011UiAS
# serial number = 556B04D2207A
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=forward connection-state=new dst-address=192.168.1.151 \
dst-port=25565 protocol=tcp
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
disabled=yes in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=\
invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
/ip firewall nat
add action=dst-nat chain=dstnat dst-port=25565 protocol=tcp to-addresses=\
192.168.88.249 to-ports=25565
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=\
out,none out-interface-list=WAN

I reset the settings to default recently and tried to do everything over again. I'm not sure if i'm missing something, but I've also change the IP filter rule to the 88.249 as well and that did not work either. The main thing is, I'm unable to see it when checking ports from outside sources, i've been using Canyouseeme.org and another one that checks for minecraft server status. I've tried disabling my firewall and it didn't seem to make any changes. Tried disabling a few different filters, and masquerade and tried to ping it like that, no result still. After the reset I tried adding the nat rules that are there now. From what i understand the IP filter rule should be the 88.249, and i have done it that way, but in this referenced instance i tried using the router IP. I've yet to see a change from connection timed out. I've spent about 10+ hours now trying to figure out why when I do the nat rule it doesn't work but it seems to solve everyone else's problems. The port just won't seem to open, and i just cant figure it out. I'm not the most tech savvy but i'm usually pretty good at following directions. This particular case is driving me nuts though, this is maybe the 2nd time in my life reaching out to a forum in the hopes someone can help me out. Hoping I'm posting in the right place, maybe i should post a new post? If so, will do if i get no answer.

Either way, main problem is trying to get this port forwarding working, I'm pretty close to going out and just buying a different router to test and see if it's something else that is the problem for sure or not. Gonna post this question and take a short break, before i end up in a padded room.

From what you posted, you have 192.168.1.151 on WAN => it's not public address => nobody can connect to it => no port forwarding for you.

Hi,

I've had the same error message. The problem was, that I'm having another wan connection, and the return traffic wanted to go through that connection.
If I disable the default wan, everything works.

Best

I'm having the same problem.
Port forwarding stopped working on 6.43.4
RB3011UiAS router.

I can see traffic when making an outside request, the NAT rule shows movement, but no access to my user control panel on that port.

dstnat: in:ether1-Gateway out:(unknown 0), src-mac blablablabla, proto TCP (SYN), ............

Any news on this bug?

Hi,

I've had the same error message. The problem was, that I'm having another wan connection, and the return traffic wanted to go through that connection.
If I disable the default wan, everything works.

Best

What do you mean disable the default wan? Not seeing where to do that.

It's extremely unlikely that it would be bug in RouterOS. Better continue with debugging. If your dstnat rule gets some hits, it's good first step. Just follow the packet further, make sure that it passes through router and is sent to target device (Tools->Torch on LAN interface will show you that). Then the internal device must send some response back, you can again see that. It's probably failing at some point, and the solution depends on where exactly.

If you have more than one connection to internet, then port forwarding works only with primary one by default, and you need extra rules to make it work with others.

It appears that you are 'Double-NATted' You can't pass ports through twice, and if you're receiving a Private IP address on your WAN interface, the modem is not passing through.