Port forwarding not working or something interfering possibly? 12 hrs later.. still don't know.

RouterOS General
1

( This was originally meant as a reply to another forum post regarding the same problem but i'm a total forum noob, I don't think i've actually used one since 2010 or so.) I've looked on these posts (Minecraft Server Port forwarding not working.) among 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.

2

You don’t actually need to add the permissive rule into filter because the last “drop” one in the forward chain ignores dst-nated packets. But if the connection-nat-state=!dstnat wasn’t there, the 88.245 would be the correct address in the permissive rule.

But I can see your WAN (ether1) has a dynamically assigned private IP address, so from where are you trying to connect to the 25565 port? If there is a modem between the client in the internet and your Mikrotik, is the port forwarded also on that modem, or is a 1:1 dst-nat configured there?

You can easily check whether the packets arrive at ether1 by running /tool sniffer quick interface=ether1 ip-protocol=tcp port=25565 in a terminal window and starting the client.

3

Your configuration doesn’t make sense.
Why do you have a forward rule to one IP for the same port number and then a dstnat rule for the same port to a different LANIP???

By the way, only specifics should be in the NAT rule not the forward rule (get rid of the forward rule you made).
However you do need a generic firewall forward rule to allow port forwarding.
There are two typical rules to allow port forwarding.

  1. Router Default Rule (based on allowing everything and ensuring having the right drop traffic rules).
    /ip firewall filter
    add action=drop chain=forward comment=
    “defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat
    connection-state=new in-interface-list=WAN

  2. One many others use (based on dropping everything and only add rules for what is allowed)
    /ip firewall filter
    add action=accept chain=forward comment=“allow port forwarding from WAN”
    connection-nat-state=dstnat connection-state=new in-interface-list=WAN
    add action=drop (drop all else, last rule in forward chain)

4

@anav, the action=accept rule for the forwarded-to dst-address:dst-port would be a fully functional substitution of the generic rule accepting all dst-nated connections if the latter wasn’t there. So the fact that the OP has both in place is not the reason why the connections from outside do not work, therefore there is no point in focusing on this, leaving aside the harsh wording. It does make sense to add a selective rule which does exactly what you need as an analytical step if you are not sure why your setup doesn’t work.

5

Fill your boots Sindy, it doesnt make sense to me but if it does for you …
Personally I have never had much success trying to forward the same port in NAT to different LANIPs (unless one uses port translation of course)

I went down this road before and the first time I posted my port forwarding rule in forward filter vice NAT there was ridicule and derision…
Now I just use forward for the general rule (to allow port forwarding) and put my specifics in the NAT rule, including limiting source address of outside users if possible.

If there is a better way to do this I am all ears…

6

Have you forgotten to put a gateway address on the computer to which we forward(dst-nat) the port ?

7

Let’s take it one by one.

First, the OP is already nervous enough, so the last thing he needs to hear is that what he’s done makes no sense.

So the steps should be

  1. suggest the essential steps to make it work (or at least a way to prove that the root cause of the issue is outside the area he’s spent 12 hours on)
  2. not before it starts working “somehow”, care about the beauty of the solution - exclude specialized rules doing the job of more generic ones or, in worse cases, being evaluated repeatedly where once would be enough.


That’s correct, a particular destination port on a particular destination address cannot be forwarded to multiple internal destination hosts unless you can choose the internal destination host by source address and/or port of the request (which may sound crazy but I had real life situations where I needed that). But the OP doesn’t attempt anything like that, he has just a single to-addresses in the action=dst-nat rule in /ip firewall nat.


Yes, this is possible due to the fact that when you put the selectivity into the individual action=dst-nat rules in /ip firewall nat, you can afford to use a widely open action=accept rule in /ip firewall filter, or make a widely open exception from an action=drop one like the default firewall does, (widely open in terms that it doesn’t check the same protocols, ports and addresses like the connection-nat-state=dstnat rules) because only packets matching those selective rules in /ip firewall nat obtain the attribute connection-nat-state=dstnat. A secondary effect of this approach is that even packets which would eventually come in through WAN with the internal destination address and port already matching the resulting ones after the dst-nat would not be let through because they would miss the connection-nat-state=dstnat match condition.


Sometimes you need to put a selective rule as the very first one to a chain to see whether the packet ever got to that chain. It may not do an actual action (so the action may be passthrough if you want to just see whether the counters grow, or log if you want to see some details about the packet).

8

Thanks for the explanation. Yes I missed the rule inserted for testing purposes (assuming that is what you were getting at) vice a config error.
Port forwarding is usually dirt simple. It only gets complicated when one has mangle rules as well.