Trying (and failing) at port forwarding.

LearningCurve · Sun Oct 04, 2015 9:45 am

I'm trying to set up port forwarding for a media server/browser app between my phone and my desktop. (Emby, in case you're wondering.)

I've used the following command based on advice I've seen in the forums for a dynamic IP:

/ip firewall nat add chain=dstnat dst-port=8096 action=dst-nat protocol=tcp dst-address-type=local to-addresses=192.168.88.253 to-ports=8096

Unfortunately, when I try to check for the open port at http://www.canyouseeme.org/, I get a timeout - as in, the port isn't open.

I'm wondering if my firewall rules (that I also found around here somewhere a couple months back when I first got this router) are interfering with the attempt to forward port 8096?

[admin@MikroTik] > /ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; Disallow weird packets
      chain=input action=drop connection-state=invalid log=no log-prefix="" 

 1    ;;; Allow LAN access to the router itself
      chain=input action=accept connection-state=new in-interface=bridge-local log=no log-prefix="" 

 2    ;;;  ^^ that originated from LAN
      chain=input action=accept connection-state=established log=no log-prefix="" 

 3    ;;;  ^^ that originated from LAN
      chain=input action=accept connection-state=related log=no log-prefix="" 

 4    ;;; Allow ping ICMP from anywhere
      chain=input action=accept protocol=icmp log=no log-prefix="" 

 5    ;;; Disallow anything else
      chain=input action=drop log=no log-prefix="" 

 6    ;;; Disallow weird packets
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

 7    ;;; Allow LAN access to move through the router
      chain=forward action=accept connection-state=new in-interface=bridge-local log=no log-prefix="" 

 8    ;;;  ^^ that originated from LAN
      chain=forward action=accept connection-state=established log=no log-prefix="" 

 9    ;;;  ^^ that originated from LAN
      chain=forward action=accept connection-state=related log=no log-prefix="" 

10    ;;; Disallow anything else
      chain=forward action=drop log=no log-prefix=""

Can someone point out what I'm doing wrong here?

Sun Oct 04, 2015 10:37 am

Accept port 8096 in forward chain.

LearningCurve · Sun Oct 04, 2015 11:38 am

Do I create a new rule? Do I alter one of the existing rules? There are five rules there that say chain=forward. Could you be more specific?

TomosRider · Sun Oct 04, 2015 12:22 pm

Yes, create a new rule with action accept on those ports.

ditonet · Sun Oct 04, 2015 3:50 pm

Accept port 8096 in forward chain.

Yes, create a new rule with action accept on those ports.

This advice is useless, because DST-NAT occurs before 'forward' chain firewall rules.
Look at packet flow diagram:
http://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Remove this part of your DST-NAT rule:

dst-address-type=local

HTH,

LearningCurve · Sun Oct 04, 2015 7:36 pm

That hasn't changed anything. Port 8096 is still closed to the outside world.

As it stands, the NAT rule now looks like

chain=dstnat action=dst-nat to-addresses=192.168.88.253 to-ports=8096 protocol=tcp dst-port=8096 log=no log-prefix=""

And my firewall rules are unchanged.

mikeone33 · Sun Oct 04, 2015 8:52 pm

I am having the same problem. Dynamic IP and just cannot get port forwarding to work at all. Extremely frustrating.

LearningCurve · Sun Oct 04, 2015 10:18 pm

I should add to all this that every port seems to be closed based on what I see at http://www.yougetsignal.com/tools/open-ports/

Port 80, Port 8080, Port 110... Using their Common Port scan, everything is closed to the outside world.

ulysses · Sun Oct 04, 2015 10:30 pm

jarda wrote:
Accept port 8096 in forward chain.

TomosRider wrote:
Yes, create a new rule with action accept on those ports.

This advice is useless, because DST-NAT occurs before 'forward' chain firewall rules.

This is a great advise, since it won't work without an accepted forward. If you look at the diagram, you will see that because[/] dst-nat occurs before routing, the packet gets new dest address and then is considered a forward packet during the route decision phase, and follows the forward path, including the forward filter chain

Another point to clarify to the TS is that the accept rule should be before any other forward rules in the chain, otherwise it will have no effect

LearningCurve · Sun Oct 04, 2015 10:39 pm

I dropped the following in at #7

 chain=forward action=accept protocol=tcp dst-address-list=192.168.88.253 src-port=8096 dst-port=8096 log=no log-prefix=""

It doesn't work.

ditonet · Sun Oct 04, 2015 11:05 pm

since it won't work without an accepted forward

Unfortunately, you are wrong.

the packet gets new dest address and then is considered a forward packet during the route decision phase, and follows the forward path, including the forward filter chain

No, packet is directly send to host specified in DST-NAT 'to-addresses' parameter.
I have a plenty of routers in customers' offices and lot of DST-NAT rules.
They work properly without 'allow' rule in 'forward' chain.

HTH,

ditonet · Sun Oct 04, 2015 11:27 pm

@LearningCurve
Does DST-NAT rule's counters increase when you check it with 'yougetsignal.com'?
Maybe your ISP block access to this port?

HTH,

LearningCurve · Sun Oct 04, 2015 11:34 pm

No. Nothing is getting through at all.

It's not my isp. They don't block anything.

Mon Oct 05, 2015 6:35 am

Looks like firewall behaviour could be a question of opinion. Unfortunately my experience is that without explicit accepting rule in forward chain no packets are forwarded just because I have general drop on the end of each chain. Dst natted packets including. If the counters are not rising during the access test, there is firewall configuration error or just the packets didn't reach the routers port from some reason. Many isps say something but do other things. Maybe they are not blocking anything, just do a nat too...

Mon Oct 05, 2015 6:38 am

If you are testing a firewall rule, put it on the first position to see if it works or not.

LearningCurve · Mon Oct 05, 2015 7:31 am

If you are testing a firewall rule, put it on the first position to see if it works or not.

I tried that with both the firewall rule and the NAT rule. No change.

I think there's more going on here than just that. As I've said, every common port appears closed to the outside.

Is there maybe a different set of firewall rules I should be using, rather than the ones I have listed above?

Mon Oct 05, 2015 8:17 am

Put ip firewall export here. What ros version are you running? Make a proof that isp is not blocking anything.

Mon Oct 05, 2015 8:23 am

Be sure you have connection tracking enabled and running.

LearningCurve · Mon Oct 05, 2015 8:55 am

It is, but I don't see where that's getting me. I have a few things running right now, so there's literally hundreds of connections to my PC (along with several each to my mobile and my wife's laptop).

ditonet · Mon Oct 05, 2015 10:32 am

@LearningCurve
Use 'Tools/Packet Sniffer' to prove that packets from 'yougetsignal.com' arrive on your WAN interface.

HTH,

ulysses · Mon Oct 05, 2015 11:00 am

Just in case - is your service on the local computer running when you are checking for open ports?

ulysses · Mon Oct 05, 2015 12:01 pm

FYI: the tool you are using is showing me that my open and working port forwarding is "closed". As well as the other one I checked, http://ping.eu/port-chk/. At the same time, I see correct network activity on the ports, see below.
Bottom line: to prove that your port forwarding is working, please use packet sniffer and a correct protocol checker, rather than some tools with unknown logic

since it won't work without an accepted forward
Unfortunately, you are wrong.
the packet gets new dest address and then is considered a forward packet during the route decision phase, and follows the forward path, including the forward filter chain
No, packet is directly send to host specified in DST-NAT 'to-addresses' parameter.
I have a plenty of routers in customers' offices and lot of DST-NAT rules.
They work properly without 'allow' rule in 'forward' chain.

HTH,

ditonet, you are wrong. Please check your working installations for an open forwarding ruleset, since there is something that accepts the DST-NATed packets. Also on vanilla linux iptables, DST-NATed packets follow forward chain, that's the beauty of the DST-NAT. It may be routed to any subnet since after the DST-NAT, which happens at the very start of packet flow, the packet is seen by the system as if it was sent from INTERNET_HOST -> INTERNAL_IP.

For the sake of this argument I have created a simple setup and here it is:

/ip firewall nat
chain=dstnat action=dst-nat to-addresses=192.168.174.73 protocol=tcp dst-address=<MY IP> dst-port=45678 log=no log-prefix="" 

/ip firewall filter
...
 4   chain=forward action=accept connection-state=established log=no log-prefix="" 
 5   chain=forward action=accept connection-state=related log=no log-prefix="" 
 6 X  ;;; for the sake of the argument
      chain=forward action=accept in-interface=ether1-gateway out-interface=bridge-local log=no log-prefix="" 
 7    chain=forward action=log protocol=tcp dst-port=45678 log=no log-prefix="f" 
 8    ;;; strict configuration
      chain=forward action=drop log=no log-prefix=""

with the setup above (rule #6 disabled), this is what packet sniffer sees:

ether1-gateway          645.178    313 <-                                             88.198.46.51:60098                  <MY IP>:45678                 ip:tcp       60   0
ether1-gateway          646.176    314 <-                                             88.198.46.51:60098                  <MY IP>:45678                 ip:tcp       60   0

and packet count

6 X  ;;; for the sake of the argument
      forward     accept                           12 875             218
7    forward     log                                 120               2
8    ;;; strict configuration
      forward     drop                              5 670             119

after I enable the rule 6 in filter:

sniffer:

ether1-gateway         1622.813    333 <-                                             88.198.46.51:33164                  <MY IP>:45678                 ip:tcp       60   0
bridge-local           1622.813    334 ->                                             88.198.46.51:33164                  192.168.174.73:45678                ip:tcp       60   0
wlan-nocast            1622.813    335 ->                                             88.198.46.51:33164                  192.168.174.73:45678                ip:tcp       60   0
wlan-nocast            1622.875    336 <-                                             192.168.174.73:45678                88.198.46.51:33164                  ip:tcp       64   0
bridge-local           1622.875    337 <-                                             192.168.174.73:45678                88.198.46.51:33164                  ip:tcp       64   0
ether1-gateway         1622.875    338 ->                                             <MY IP>:45678                 88.198.46.51:33164                  ip:tcp       64   0
...

packet count:

6    ;;; for the sake of the argument
      forward     accept                           14 371             245
7    forward     log                                 120               2
8    ;;; strict configuration
      forward     drop                              5 670             119

LearningCurve · Mon Oct 05, 2015 5:39 pm

@LearningCurve
Use 'Tools/Packet Sniffer' to prove that packets from 'yougetsignal.com' arrive on your WAN interface.

HTH,

OK. I tried various ports using a bunch of different online port-checking sites, and nothing from any of them is getting through on my wan interface (eth10). Though, I don't know if I'm using these tools right. It seems pretty straight forward, though, so I'm not sure what I could be messing up.

Tools>Packet Sniffer. On the Filter tab I set ether10-gateway as the interface, and direction "any". So I should be seeing all the traffic going in and out of my home network. I see my torrent program with all its connections, I see some miscellaneous HTTP, ICMP, POP3, etc., from everything else, and I see a bunch of probing on 21, 22, 443, and so on.

But what I don't see is anything[\i] showing up on 8096 - either with the "port checker" or when I try to connect using the Emby app on my mobile device.

Just in case - is your service on the local computer running when you are checking for open ports?

Yes, it is running. I can connect locally with the PC it's running on; I can connect with my mobile when wifi is on and I am connected to my LAN. What I can't do is connect remotely, from outside my network.

ulysses · Mon Oct 05, 2015 9:54 pm

first of all, with a sniffer you can also set filter-port to not miss the packets.

Secondly, are you sure your provider is assigning you a white ip address? I have seen providers performing NAT on their side as well, in which case you will not be able to use your WAN address from outside.

And again, if you don't sniff any packets at all, even on your WAN interface, then it's not your port forwarding rules, it is something on the provider side

Console · Mon Oct 05, 2015 10:11 pm

I've done port forwarding through the NAT rules not the firewall

add add action=dst-nat chain=dstnat disabled=no dst-port=65510 in-interface=wan \
    protocol=tcp to-addresses=192.168.88.40 to-ports=65510
add action=dst-nat chain=dstnat disabled=no dst-port=65510 in-interface=wan \
    protocol=udp to-addresses=192.168.88.40 to-ports=65510

192.168.88.40 is my PC local IP address, 65510 is the port and wan is the external interface from the mikrotik router (the one that's not on my same subnet)

Also better try portchecker.co or http://www.yougetsignal.com/tools/open-ports/ because canyouseeme.org sometimes use your local ip address instead of the global one and will always say it's not forwarded even if it is.

P.S. I'm no expert.

LearningCurve · Tue Oct 06, 2015 12:43 am

first of all, with a sniffer you can also set filter-port to not miss the packets.

OK, I'll remember that when I get back to it. Though, I think one time I did try it with 8096 set for the port, but the capture was empty.

assigning you a white ip address?

I don't even know what that is. I assume it's so, though, because I can use other services from outside.

Tue Oct 06, 2015 7:17 am

Remove the router and put the wire from isp into your computer directly. Test the things you expect that should work. If not the problem is elsewhere but not in router settings.

skuykend · Tue Oct 06, 2015 9:02 am

Add this before your global forward drop:
add chain=forward comment="Forward dstnats" connection-nat-state=dstnat

LearningCurve · Wed Oct 07, 2015 8:40 am

Add this before your global forward drop:
add chain=forward comment="Forward dstnats" connection-nat-state=dstnat

connection-nat-state throws an error. I don't think it's a thing.

skuykend · Wed Oct 07, 2015 9:25 am

Add this before your global forward drop:
add chain=forward comment="Forward dstnats" connection-nat-state=dstnat
connection-nat-state throws an error. I don't think it's a thing.

Hmmm, perhaps it is a newer thing. I'm on latest development 6.33rc16.

Weird thing is I didn't used to need it, then things stopped working. Not sure exactly what I changed when it stopped working (I thought when I switched to a default drop rule). I found (gui winbox) then added the above rule and my port forwards started working again.

LearningCurve · Wed Oct 07, 2015 5:10 pm

6.33rc16.

OK, I was a version behind. I was at 6.31 and just updated to 6.32.2. It's still not a command, though.

skuykend · Wed Oct 07, 2015 8:08 pm

6.33rc16.
OK, I was a version behind. I was at 6.31 and just updated to 6.32.2. It's still not a command, though.

From a search, looks like it's been there since 6.22. It needs to be in the /ip firewall filter not /ip firewall nat

LearningCurve · Wed Oct 07, 2015 8:13 pm

Quick update to add that I've done the following:

Set up a ddns.net account so I have a static address to use instead of a dynamic IP;
Changed ports for the service I'm trying to access from 8096 (http) and 8920 (https) to 22555 and 22535, respectively;

Again, if I access the service locally (http://localhost:22555) or if my mobile device is connected to my LAN, I have no problems.

If I try to access it remotely, even from the same computer it's running on, I get nothing. I can see in Packet Sniffer that the requests are being made, but they're not coming back to me.

I've attached my export. Hopefully someone can point out where I'm going wrong with this? Firewall is set to accept & forward connections on those ports. NAT is set to send those connections to my desktop. I'm not sure what the problem can be?

I should add that I can make all this work with my old WRT54 running tomato firmware.

# oct/07/2015 12:59:51 by RouterOS 6.32.2
# software id = 64RV-JMEM
#
/interface bridge
add admin-mac=00:0C:42:FD:2F:92 auto-mac=no name=bridge-local
/interface ethernet
set [ find default-name=ether1 ] name=eth1-master
set [ find default-name=ether2 ] master-port=eth1-master name=eth2-slave
set [ find default-name=ether3 ] master-port=eth1-master name=eth3-slave
set [ find default-name=ether4 ] master-port=eth1-master name=eth4-slave
set [ find default-name=ether5 ] master-port=eth1-master name=eth5-slave
set [ find default-name=ether6 ] name=eth6-master
set [ find default-name=ether7 ] master-port=eth6-master name=eth7-slave
set [ find default-name=ether8 ] master-port=eth6-master name=eth8-slave
set [ find default-name=ether9 ] master-port=eth6-master name=eth9-slave
set [ find default-name=ether10 ] name=ether10-gateway poe-out=off
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-onlyn channel-width=20/40mhz-Ce \
    country="united states" default-authentication=no disabled=no distance=\
    indoors frequency=auto mode=ap-bridge ssid=XXXYYYZZZ########## wireless-protocol=802.11
/ip neighbor discovery
set eth1-master discover=no
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa-psk,wpa2-psk mode=\
    dynamic-keys wpa-pre-shared-key=XXXYYYZZZ########## wpa2-pre-shared-key=\
    XXXYYYZZZ##########
/ip pool
add name=dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge-local name=default
/interface bridge port
add bridge=bridge-local interface=eth1-master
add bridge=bridge-local interface=eth6-master
add bridge=bridge-local interface=sfp1
add bridge=bridge-local interface=wlan1
/interface wireless access-list
add comment=laptop mac-address=XXXYYYZZZ########## vlan-mode=no-tag
add comment=mobile mac-address=XXXYYYZZZ########## vlan-mode=no-tag
add comment=laptop mac-address=XXXYYYZZZ########## vlan-mode=no-tag
add comment=mobile mac-address=XXXYYYZZZ########## vlan-mode=no-tag
/ip address
add address=192.168.88.1/24 comment="default configuration" interface=\
    bridge-local network=192.168.88.0
/ip arp
add address=192.168.88.252 comment=laptop interface=bridge-local \
    mac-address=XXXYYYZZZ##########
add address=192.168.88.253 comment=desktop interface=bridge-local \
    mac-address=XXXYYYZZZ##########
add address=192.168.88.254 comment=htpc interface=bridge-local mac-address=\
    XXXYYYZZZ##########
add
add address=192.168.88.250 comment=mobile interface=bridge-local mac-address=\
    XXXYYYZZZ##########
/ip dhcp-client
add comment="default configuration" dhcp-options=hostname,clientid disabled=\
    no interface=eth1-master
add dhcp-options=hostname,clientid disabled=no interface=ether10-gateway
/ip dhcp-server lease
add address=192.168.88.254 mac-address=XXXYYYZZZ########## server=default
add address=192.168.88.253 client-id=XXXYYYZZZ########## mac-address=\
    XXXYYYZZZ########## server=default
add address=192.168.88.252 client-id=XXXYYYZZZ########## mac-address=\
    XXXYYYZZZ########## server=default
add address=192.168.88.250 mac-address=XXXYYYZZZ########## server=default
/ip dhcp-server network
add address=192.168.88.0/24 comment="default configuration" gateway=\
    192.168.88.1 netmask=24
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 name=router
/ip firewall filter
add chain=forward dst-port=22535 protocol=tcp
add chain=forward dst-port=22555 protocol=tcp
add action=fasttrack-connection chain=input comment=\
    "FT established/related connections (input)" connection-state=\
    established,related
add action=fasttrack-connection chain=forward comment=\
    "FT established/related connections (forward)" connection-state=\
    established,related
add action=drop chain=input comment="Disallow weird packets" \
    connection-state=invalid
add chain=input comment="Allow LAN access to the router itself" \
    connection-state=new in-interface=bridge-local
add chain=input comment=" ^^ that originated from LAN" connection-state=\
    established
add chain=input comment=" ^^ that originated from LAN" connection-state=\
    related
add chain=input comment="Allow ping ICMP from anywhere" protocol=icmp
add action=drop chain=input comment="Disallow anything else"
add action=drop chain=forward comment="Disallow weird packets" \
    connection-state=invalid
add chain=forward comment="Allow LAN access to move through the router" \
    connection-state=new in-interface=bridge-local
add chain=forward comment=" ^^ that originated from LAN" connection-state=\
    established
add chain=forward comment=" ^^ that originated from LAN" connection-state=\
    related
add action=drop chain=forward comment="Disallow anything else"
/ip firewall nat
add action=masquerade chain=srcnat comment="default configuration" \
    out-interface=ether10-gateway
add action=dst-nat chain=dstnat dst-port=22555 protocol=tcp to-addresses=\
    192.168.88.253 to-ports=22555
add action=dst-nat chain=dstnat dst-port=22535 protocol=tcp to-addresses=\
    192.168.88.253 to-ports=22535
/ip service
set telnet disabled=yes
set ftp address=192.168.88.0/24
set ssh address=192.168.88.0/24
set api disabled=yes
set winbox address=192.168.88.0/24
set api-ssl disabled=yes
/lcd interface pages
set 0 interfaces="sfp1,eth1-master,eth2-slave,eth3-slave,eth4-slave,eth5-slave\
    ,eth6-master,eth7-slave,eth8-slave,eth9-slave,ether10-gateway"
/system clock
set time-zone-name=America/Detroit
/tool mac-server
set [ find default=yes ] disabled=yes
add interface=eth2-slave
add interface=eth3-slave
add interface=eth4-slave
add interface=eth5-slave
add interface=eth6-master
add interface=eth7-slave
add interface=eth8-slave
add interface=eth9-slave
add interface=ether10-gateway
add interface=sfp1
add interface=wlan1
add interface=bridge-local
/tool mac-server mac-winbox
set [ find default=yes ] disabled=yes
add interface=eth2-slave
add interface=eth3-slave
add interface=eth4-slave
add interface=eth5-slave
add interface=eth6-master
add interface=eth7-slave
add interface=eth8-slave
add interface=eth9-slave
add interface=ether10-gateway
add interface=sfp1
add interface=wlan1
add interface=bridge-local
/tool sniffer
set filter-interface=all filter-port=22535,22555 memory-limit=1000KiB

LearningCurve · Wed Oct 07, 2015 8:17 pm

6.33rc16.
OK, I was a version behind. I was at 6.31 and just updated to 6.32.2. It's still not a command, though.

You're right. I've got it now. I added that chain right at the very top (under the global dummy rule, anyway).

No change.

skuykend · Wed Oct 07, 2015 8:55 pm

You can't fasttrack the input chain. Seems like it just wouldn't work though, but maybe it's causing problems.

The top two forwards in your filter chain will be unnecessary if you have the forward of the connection-nat-state=dstnat

You have two DHCP client's setup, I'd disable the one on ether1-master, don't know if it's trying to serve itself and getting routes confused.

LearningCurve · Thu Oct 08, 2015 12:40 am

You can't fasttrack the input chain. Seems like it just wouldn't work though, but maybe it's causing problems.

I honestly don't even remember where those came from. They're racking up counts in the list, though. Hundreds of megabytes in just a few days. They've got to be doing something, no?

The top two forwards in your filter chain will be unnecessary if you have the forward of the connection-nat-state=dstnat

I did add that after I saw your last message. I'll ditch those two fast track rules, then, and eliminate that possibility.

You have two DHCP client's setup, I'd disable the one on ether1-master, don't know if it's trying to serve itself and getting routes confused.

I didn't catch that. Good call. That must be a remnant from when I was moving my WAN port from ETHER1 to ETHER10. (I needed all my Gigabit ports for my local use, and my internet isn't fast enough to justify using a gigabit port for it.)

I'll look at those two things and see what happens when I get home tonight. (Afternoon shift - Yay!)

Thu Oct 08, 2015 6:45 am

Maybe you can try to switch the fasttrack off.

LearningCurve · Thu Oct 08, 2015 7:09 am

Add this before your global forward drop:
add chain=forward comment="Forward dstnats" connection-nat-state=dstnat

Couldn't move Firewall Rule <> - cannot move builtin (6)

Is the error it gives when I try to drop that in at #0. I have it sitting at #1 instead.

skuykend · Thu Oct 08, 2015 7:49 am

Is the error it gives when I try to drop that in at #0. I have it sitting at #1 instead.

If fasttrack is still running it creates a dummy rule at 0 that can't be moved, so that's normal.

Like jarda mentioned, I'd disable all fasttrack rules until everything else is working. It's new and may have issues in some circumstances (Actually slows my CRS1009 down in some places).

Are you always testing this from outside your local network, or from inside just using the WAN ip address?

If you want to get this type of 'hairpin' NAT working as well then you can add something like this to the /ip firewall nat:

add action=masquerade chain=srcnat comment="Hairpin on bridge-local" dst-address=192.168.88.0/24 out-interface=bridge-local src-address=192.168.88.0/24

LearningCurve · Thu Oct 08, 2015 10:17 am

Is the error it gives when I try to drop that in at #0. I have it sitting at #1 instead.
If fasttrack is still running it creates a dummy rule at 0 that can't be moved, so that's normal.

Like jarda mentioned, I'd disable all fasttrack rules until everything else is working. It's new and may have issues in some circumstances (Actually slows my CRS1009 down in some places).

Are you always testing this from outside your local network, or from inside just using the WAN ip address?

If you want to get this type of 'hairpin' NAT working as well then you can add something like this to the /ip firewall nat:
Code: Select all
add action=masquerade chain=srcnat comment="Hairpin on bridge-local" dst-address=192.168.88.0/24 out-interface=bridge-local src-address=192.168.88.0/24

I got rid of the two fast-track rules, but the one dummy rule is still there and it won't let me delete it.

I've been trying both ways - by entering the remote address:port into Firefox on the machine with the media server, and using my phone with the official mobile app from ouutside.

That hairpin rule works fine, I guess, but that much of it was working before. I still can't access the service via my external IP or with my ddns.net address.

Fri Oct 09, 2015 6:51 am

You still need a proof that all packets are arriving to router from wan side. Otherwise your effort is useless.

Trying (and failing) at port forwarding.

Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re:

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Re: Trying (and failing) at port forwarding.

Who is online