[yet another] simple port forwarding doesn't work?

bcsteeve · Sat May 28, 2016 8:57 am

I know this has been asked a lot, because I see a bunch of threads... none of which ever seem to resolve the issue.

The wiki is pretty clear on how to do this:

/ip firewall nat add chain=dstnat dst-port=8082 action=dst-nat 
protocol=tcp to-address=192.168.1.103 to-port=8082

But it just doesn't work! A tool such as http://www.canyouseeme.org/ shows the port is open... but I can't connect.

I *can* access it ("it" being the web interface for the serice on port 8082 in this example) directly on the LAN (ie. http://192.168.1.103:8082) but not using the WAN IP. Pull this router out and go back to my cheap-o router and it works fine, so it isn't a firewall configuration on the server. It has to be the router. But what? Oh, and I can also access the Mikrotik WebFig from the WAN IP (so I'm not screwing up on the IP).

I'm mostly using default setup. Here is /export:

# may/27/2016 22:55:26 by RouterOS 6.35.2
# software id = 48GP-CXP0
#
/interface bridge
add admin-mac=E4:8D:8C:22:42:40 auto-mac=no comment=defconf name=bridge
/interface ethernet
set [ find default-name=ether1 ] name=01-WAN
set [ find default-name=ether2 ] name=02-OfficePC
set [ find default-name=ether3 ] master-port=02-OfficePC name=03-Server
set [ find default-name=ether4 ] master-port=02-OfficePC name=04-WAP
set [ find default-name=ether5 ] master-port=02-OfficePC name=05-Switch
set [ find default-name=ether6 ] name=06-VoIP-Master
set [ find default-name=ether7 ] master-port=06-VoIP-Master name=07-RainForest
set [ find default-name=ether8 ] master-port=06-VoIP-Master name=08-Sprinkler
set [ find default-name=ether9 ] name=09-Slow3
set [ find default-name=ether10 ] name=10-Slow4
/ip neighbor discovery
set "01-WAN" discover=no
set bridge comment=defconf
/ip pool
add name=dhcp ranges=192.168.1.10-192.168.1.254
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=02-OfficePC
add bridge=bridge comment=defconf interface=06-VoIP-Master
add bridge=bridge comment=defconf interface=sfp1
/ip address
add address=192.168.1.1/24 comment=defconf interface=02-OfficePC network=\
    192.168.1.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=01-WAN
/ip dhcp-server lease
add address=192.168.1.103 comment=Server mac-address=94:DE:80:E2:EF:C4 server=\
    defconf
/ip dhcp-server network
add address=192.168.1.0/24 comment=defconf gateway=192.168.1.1 netmask=24
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.1.1 name=router
/ip firewall filter
add chain=input comment="defconf: accept ICMP" protocol=icmp
add chain=input comment="defconf: accept established,related" connection-state=\
    established,related
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=\
    01-WAN
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add chain=forward comment="defconf: accept established,related" \
    connection-state=established,related
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=01-WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=\
    01-WAN
add action=dst-nat chain=dstnat dst-port=8082 protocol=tcp to-addresses=\
    192.168.1.103 to-ports=8082
/system clock
set time-zone-name=America/Vancouver
/system routerboard settings
set protected-routerboot=disabled
/tool mac-server
set [ find default=yes ] disabled=yes
add interface=bridge
/tool mac-server mac-winbox
set [ find default=yes ] disabled=yes
add interface=bridge

rjscomms · Sat May 28, 2016 11:19 am

Hello,

I'm not an expert but could you humour me and add dst-address=your_WAN_IP in the NAT rule.

I had a funny case where I had what you had, but it was giving me strange results. Putting in the dst-address worked for me at least.

bcsteeve · Sat May 28, 2016 11:30 am

Hello,

I'm not an expert but could you humour me and add dst-address=your_WAN_IP in the NAT rule.

I had a funny case where I had what you had, but it was giving me strange results. Putting in the dst-address worked for me at least.

by "your_WAN_IP" do you mean by public IP? If so, that didn't help.

Shouldn't this be REALLY easy? I mean... simple stuff like this should just work with the out of the box config.

bcsteeve · Sat May 28, 2016 11:50 am

Incidentally, When I click on "Statistics" for the NAT Rule, it shows zero activity when I attempt to connect, which seems to imply that whatever is preventing the connection is occuring upstream of this NAT Rule. I disabled all the Filter Rules (which were default) and that didn't help either. When I use an open port checker, I *do* see activity on the Statistics tab. I'm perplexed how the port tool can see it but nothing else passes.

rjscomms · Sat May 28, 2016 12:45 pm

is the protocol definitely tcp?

rjscomms · Sat May 28, 2016 12:46 pm

painful as it may be, perhaps a reset of the configuration and start again.

bcsteeve · Sat May 28, 2016 8:14 pm

Yes, definitely tcp. Works with my other router with just a simple tcp port forward. I double-checked to be sure I wasn't forwarding "both" or just udp.

LOL @ restart... that's all I've done since getting this Mikrotik. I've spent 2.5 long-hour days GETTING NOWHERE and have probably reset its config to default over 100 times.

I'm starting to wonder if either I have a defect or if there's something wrong with the latest firmware and/or OS version? The first thing I did was update both. Seems crazy I can't get a simple port forward to work. I posted my config and nobody's said anything's wrong with it.

Sob · Sat May 28, 2016 9:39 pm

A tool such as http://www.canyouseeme.org/ shows the port is open... but I can't connect.

Are trying to connect to your public address from same LAN where 192.168.1.103 is? If so, you need hairpin NAT.

bcsteeve · Sat May 28, 2016 9:44 pm

A tool such as http://www.canyouseeme.org/ shows the port is open... but I can't connect.
Are trying to connect to your public address from same LAN where 192.168.1.103 is? If so, you need hairpin NAT.

Well, yes... yes I am. That sounds like it might get me somewhere, thanks.

bcsteeve · Sat May 28, 2016 10:00 pm

Hang on... I *can* connect to the router's WebFig interface using the public IP... so what's the difference?

bcsteeve · Sat May 28, 2016 10:09 pm

I gave it a try and it still doesn't work, although perhaps I'm misunderstanding some of the elements. This is the config that page says to use:

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 \
  dst-address=192.168.1.2 protocol=tcp dst-port=80 \
  out-interface=LAN action=masquerade

I'm sure I change 192.168.1.2 to 192.168.1.103 and dst-port=80 to dst-port=8082 (but thought i'd mention it in case I'm wrong)... I'm less clear on out-interface. I assumed it would be the interface that the server is on, but that failed saying I can't select a slave and it suggested I select the master, which also complained because it is itself a slave of bridge so it suggested I choose that, which I did.

makp · Sat May 28, 2016 10:10 pm

Maybe have a look at your Firewall filter.

As a newbie I am I would start to log firewall rules, and then see if it is the firewall filter.

We have a similar setup I have my webserver on 80, my firewall is - thanks to ZeroByte:

0    chain=input action=accept connection-state=established,related log=no log-prefix="" 

 1    ;;; Blocked Netflix adresser TV stue
      chain=forward action=drop src-address=192.168.1.201 dst-address-list=Blocked Netflix log=no log-prefix="" 

 2    ;;; Adgang til Router fra Interne IP
      chain=input action=accept src-address-list=Interne_IP log=no log-prefix="" 

 3    ;;; Disable ICMP 
      chain=input action=drop protocol=icmp in-interface=internet icmp-options=8:0-255 log=no log-prefix="" 

 4    ;;; Adgang til swich fra WAN
      chain=forward action=drop dst-address=192.168.1.254 in-interface=internet log=no log-prefix="" 

 5    chain=input action=drop log=no log-prefix=""

0 and 5 is basic securing, 2 and 4 is my own magic stuff.

Your filter:

add chain=input comment="defconf: accept ICMP" protocol=icmp

add chain=input comment="defconf: accept established,related" connection-state=\
established,related

add action=drop chain=input comment="defconf: drop all from WAN" in-interface=\
01-WAN

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related

add chain=forward comment="defconf: accept established,related" \
connection-state=established,related

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=01-WAN

The green shouldn't that be the first rule - and have a action=accept.
The one in red shouldn't that be the last rule.
An input chain would not interfere with forward chain
But I dont see any action=accept before drop.

Why do you have the ICMP rule, isnt that enable default

My NAT Table

 0    chain=srcnat action=masquerade out-interface=internet log=no log-prefix="" 

 1    chain=dstnat action=dst-nat to-addresses=192.168.1.42 to-ports=80 protocol=tcp dst-address=X.X.X.X dst-port=80 log=no log-prefix="" 

 2    chain=dstnat action=dst-nat to-addresses=192.168.1.10 to-ports=21 protocol=tcp dst-address=X.X.X.X dst-port=21 log=no log-prefix=""

Have you logged your DROP rules.

bcsteeve · Sat May 28, 2016 10:22 pm

Thanks. As to your "shouldn't" and "why" questions... beats me, ask MikroTik as that's the default setup. I made the order changes you suggested (green first, red last) but it still doesn't work.

I haven't logged, no... I'm not really sure how to effectively do that. I tried "log" checkmark and gave it some prefix, and I found "log" in WinBox but that moves so fast I don't see how it is helpful. I can "freeze" it, but I can't search or even manage to copy it. It must be stored somewhere... I'll keep looking.

[edit: i just now noticed you said "drop rules"... I was silly and turned on for all rules. looking again.]

I also want to mention that I tried downgrading (I randomly chose 6.14) in case this was some issue that crept up with latest... no help.

This is really quite frustrating.

bcsteeve · Sat May 28, 2016 10:24 pm

OK, now logging just DROP rules... I see no drops from my connection attempt.

makp · Sat May 28, 2016 10:30 pm

Sorry I edited my posting when you posted.

OK maybe its because you are missing the "action=accept"

If you dont have any use of the forward rules you made disable them.

Only have these 2 rules enable:

chain=input action=accept connection-state=established,related log=no log-prefix=""
Should be the first and with action=accept

chain=input action=drop log=no log-prefix=""
And the last

This will secure your router.

bcsteeve · Sat May 28, 2016 10:40 pm

OK, so now I have just this:

[admin@MikroTik] > /ip firewall exp
# may/28/2016 12:36:54 by RouterOS 6.35.2
# software id = 48GP-CXP0
#
/ip firewall filter
add chain=input connection-state=established,related
add action=drop chain=input
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=\
    01-WAN
add action=dst-nat chain=dstnat dst-port=8082 in-interface=01-WAN protocol=tcp \
    to-addresses=192.168.1.103 to-ports=8082

Note that it DOES say "accept" in the GUI, so I assume that accept must be the default and that's why it isn't explicit in the first filter above.

It didn't work, but oddly it took a lot longer to think about it before failing. It also failed with a "took to long to respond" instead of the previous "rejected" (or something to that effect)

makp · Sat May 28, 2016 10:40 pm

Your webserver is that on same subnet as the client your using, if so you have to check:

http://wiki.mikrotik.com/wiki/Hairpin_NAT

I have my webserver on a different subnet, and I have enabled the DNS in my RB just for the webserver, to keep traffic LAN traffic inside.

bcsteeve · Sat May 28, 2016 10:42 pm

I already tried SOB's hairpin suggestion... but we can easily prove if that's the problem or not. Can *you* connect? I hesitate publishing my public IP but I don't see a PM feature on here. Is there one?

makp · Sat May 28, 2016 10:49 pm

I haven't seen any PM funktion

But if you client is on the same subnet you need the hairpin.

Have you tried with your mobile phone, that was my approach until I got the correct filters.

bcsteeve · Sat May 28, 2016 10:56 pm

I have no mobile to check with. Can you look above a few posts for my response to sob re: hairpin? I tried it and it didn't help but I wasn't 100% clear on what interface to specify.

makp · Sat May 28, 2016 11:00 pm

I have no mobile to check with. Can you look above a few posts for my response to sob re: hairpin? I tried it and it didn't help but I wasn't 100% clear on what interface to specify.

Give me a moment.

makp · Sat May 28, 2016 11:17 pm

I dont realy know about the bridge thing. But of course if port is a slave its the master you use.

add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.1.103 protocol=tcp dst-port=8082 out-interface=ETHERPORTWITHWEBSERVER action=masquerade

the out-interface is the port you have the webserver on.

I dont use hairpin as I have created a subnet for servers, so you could add an extra subnet and put the server on that.

But you need hairpin and I think that's is why you now experience:

It didn't work, but oddly it took a lot longer to think about it before failing. It also failed with a "took to long to respond" instead of the previous "rejected" (or something to that effect)

You can open developer tool in IE (F12) and look at "Network" when trying to connect to site.

And can you do:

ip firewall nat print
ip firewall filter print
interface print

bcsteeve · Sat May 28, 2016 11:55 pm

OK, I *finally* got this to work... holy cow. 3 days. Yeesh.

You were right, it was the hairpin. The bit I was missing was

/ip firewall nat
add chain=dstnat dst-address=1.1.1.1 protocol=tcp dst-port=80 \
  action=dst-nat to-address=192.168.1.2

I thought they were giving a bit of generic rule there (for normal non-hairping NAT) and then giving the more specific hairpin rule down below.

Once I included that rule too... it worked. However, I have to specify my WAN IP?? That can change at the ISP's whim, so that's no good. I can use 0.0.0.0/0 but is that safe and/or efficient? I thought I could probably eliminated dst-address and instead use in-interface but that didn't work.

The page also implies that the rules could be made more general so I don't have to make rulesets for each exception... can you enlighten me on that?

ie. I'd like to NOT have to specify the WAN IP (as it can change) and I'd rather not make a hairpin rule for each and every forward (but will if necessary, of course)

Thanks.

makp · Sun May 29, 2016 12:19 am

I think your firewall rules where the real culprits dropping traffic and when that was fixed the Hairpin was needed.

Remember:

add chain=input connection-state=established,related
...
New rules goes in here.
..
add action=drop chain=input

And your are not the only one getting gray hair when reading those wikis I hat the same issue and I can see in a lot of the forum post its the same.

To fix the issue, an additional NAT rule needs to be introduced on the router to enforce

Split brain dns could be your fix, enable DNS in router and add the webserver with local IP - remember to update your DHCP with local DNS.

Or see this post:

http://forum.mikrotik.com/viewtopic.php?t=105053

Sob · Sun May 29, 2016 12:21 am

I hope I did not just miss it, but where exactly is your public address? Does your router have it, or is it on another different router/modem and yours is connected behing it?

bcsteeve · Sun May 29, 2016 1:18 am

router has it, why?

bcsteeve · Sun May 29, 2016 1:24 am

OK, so I started over from scratch now that I thought I had it... and I ran into a wall again.

Every "how-to" on port forwarding suggests the same thing, that In. Interface needs to be set to WAN. But when you look at the entry for hairpin, it does not. So my forwarding rules are conflicting with the hairpin. I can drop the In. Interface and then it works. But EVERY port forwarding tutorial has it, and even stresses that leaving it out is a mistake. For example:

(You are telling the router that any traffic coming IN from the internet on port 7000 should follow this rule. If you forget this step, the router will grab ANY traffic on port 7000 and send it to the IP you specify in the next step)

My noobness doesn't quite see why that's a problem... but it made me nervous enough to include it. Should I simply not?

I gave the DNS trick a try, and I thought I had it working... but in the end, it seemed very hit and miss. It worked on one browser but then I tried another and it failed, then back to the original and it worked until I closed/opened and then it failed.

Pulling my hair out lol

bcsteeve · Sun May 29, 2016 2:32 am

Unless someone sees a problem with it, I am satisfied that I have it working now. Thank you VERY much for the assistance. For the record, this is my final working config... tested internally and externally.

/ip firewall filter
add chain=input comment="defconf: accept ICMP" protocol=icmp
add chain=input comment="defconf: accept established,related" connection-state=\
    established,related
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=\
    01-WAN
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add chain=forward comment="defconf: accept established,related" \
    connection-state=established,related
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=01-WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=\
    01-WAN
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address=\
    192.168.1.0/24 out-interface=bridge src-address=192.168.1.0/24
add action=dst-nat chain=dstnat comment="Server Webmin" dst-port=8082 \
    protocol=tcp to-addresses=192.168.1.103 to-ports=8082

Sob · Sun May 29, 2016 2:46 am

Forget my previous question, there are so many port forwarding threads here, I'm getting lost in them...

Back on track, you do not need to set in-interface, but you do want to limit destination in some way. Why? It's more clear when you use some common port number. Imagine you have local webserver and want to make it accessible from internet. If you forward port 80 without limiting the destination, your server will be accessible just fine, but you won't be able to access any other webserver yourself. Because your dstnat rule will catch also your outgoing traffic.

So you want to set:

a) dst-address=<WAN IP> - not good when it's dynamic
b) in-interface=<WAN> - does not work with hairpin NAT
c) dst-address-type=local dst-address=!<router's internal IP> - will match packets going to any address owned by router, except LAN address; you don't necessarily need to exclude internal IP in all cases, only when you want to use service on router itself, which uses same port

bcsteeve · Sun May 29, 2016 4:06 am

That was *almost* clear to me

When I tried it, I included the !192.168.1.1 and it failed (that is, accessing public IP from LAN on that service fails). Then I tried the exact opposite (without the !) and it worked (public IP from LAN) but fails externally (obviously). It seems to work internally and externally if left blank. So when you say "you don't necessarily need to exclude...", is it true that you CANT exclude if the service isn't on the router itself?

It is somewhat academic at this point, as I doubt I'll ever need to access port 8082 anywhere other than my server... but I'd like to get it setup correctly.

And I do see the "problem"... I can now go to anydomain.at.all:8082 and reach my local server. In a way, that's kind of useful... but I suppose if I did ever have to access anything else on that port in the future I would be confused.

bcsteeve · Sun May 29, 2016 4:22 am

Does it suffice to add this prior to my forwards?

add chain=dstnat dst-address=!192.168.1.0/24 src-address=192.168.1.0/24

My (limited) thinking is that says any traffic that's originating inside the LAN but going outside the LAN should just be accepted. That matches so further entries are ignored, right?

[edit]: Weird... I tested the above and it did what I wanted it to, but then an hour or so later and it fails. I must have had some caching in affect.

Sob · Sun May 29, 2016 5:52 am

Your description of what worked and not sounds a little strange, but maybe it's because it's quite late here and I'm almost asleep.

When you set dst-address, it's simple test for packet's destination. So if you have dst-address=192.168.1.1, then it will match only those going to 192.168.1.1, nothing else. If you have dst-address=!192.168.1.1, where "!" means "not", then it will match anything except 192.168.1.1. Plus there are always other conditions in effect if set, like port, but that's obvious. Also don't forget dst-address-type=local, it's the main thing that solves the "it catches too much" problem, because it matches only addresses on the router itself (any of them, no matter which interface has them), nothing external. It's all you need for your "non-standard" port. You need to exclude router's internal address (192.168.1.1) from that only if you want to use to connect to some service on router, e.g. web administration.

Traffic from LAN to LAN is kind of unusual, because normally with simple LAN with only one subnet, all hosts communicate directly with each other, traffic does not go through router. But it should be safe to allow it. But allowing traffic happens in forward chain. You last dstnat rule would probably not do anything noticeable, it would take anything coming from LAN range to somewhere else and accept it, preventing further rules in dstnat chain doing something else with it.

bcsteeve · Sun May 29, 2016 6:41 am

Your description of what worked and not sounds a little strange, but maybe it's because it's quite late here and I'm almost asleep.

It was strange. Either I had something messed up or else browser or DNS caching or something was throwing me off. I now have it set as you advised, and it is working. I tested on another computer to be sure it wasn't some local caching and it still worked. External also works. random.domain:8082 doesn't work, so it all seems good.

Thanks again for your help and patience.

[yet another] simple port forwarding doesn't work?

[yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Re: [yet another] simple port forwarding doesn't work?

Who is online