Local Port definition and Port Forwarding

beic · Sun May 31, 2020 5:24 pm

Hi there,

I recently purchased RB2011UiAS-2HnD-IN, updated to current firmware release v6.46.6, added all fixed leases, configured ports, but how I see, it's not working near like my old Cisco LinkSys with DD-WRT on it.

With MikroTik I have slower RDP connections like (3-5s) more until connection is established.
Can't use local ports transparently, etc...

If I put back the Cisco LinkSys router it's all flaying again without any latency or port related issues.
(Note: Used the same settings scheme from my old Linksys to config MikroTik)

I admit that it's my first time in MikroTik world, but boy, really so hard to setup it?!

Any suggestions would be highly appreciated,

Kind regards,
Viktor

CZFan · Tue Jun 02, 2020 1:58 am

Post output of "/export hide-sensitive" between code brackets, I.e.

anav · Tue Jun 02, 2020 2:21 pm

Post output of "/export hide-sensitive" between code brackets, I.e.
Code: Select all

/export hide-sensitive file=anynameyouwish

beic · Thu Jun 04, 2020 10:30 pm

Sorry for post delay, I forgot to subscribe to my own post and I didn't got notified.

And thank you for your support!

# jun/04/2020 21:17:38 by RouterOS 6.46.6
# software id = JE5F-K09Z
#
# model = 2011UiAS-2HnD
# serial number = B9070A937FC8
/interface bridge
add admin-mac=74:4D:28:86:91:2B auto-mac=no comment=defconf name=bridge
/interface ethernet
set [ find default-name=ether3 ] disabled=yes
set [ find default-name=ether4 ] disabled=yes
set [ find default-name=ether5 ] disabled=yes
set [ find default-name=ether6 ] disabled=yes
set [ find default-name=ether7 ] disabled=yes
set [ find default-name=ether8 ] disabled=yes
set [ find default-name=ether9 ] disabled=yes
set [ find default-name=ether10 ] disabled=yes
set [ find default-name=sfp1 ] disabled=yes
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=0 band=2ghz-b/g/n channel-width=\
    20/40mhz-XX country=no_country_set disabled=no distance=indoors \
    frequency=auto frequency-mode=manual-txpower mode=ap-bridge ssid=Cassini \
    wireless-protocol=802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk mode=dynamic-keys \
    supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.0.1-192.168.0.250
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=defconf
/user group
set full policy="local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,pas\
    sword,web,sniff,sensitive,api,romon,dude,tikapp"
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether9
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=sfp1
add bridge=bridge comment=defconf interface=wlan1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.0.251/24 comment=defconf interface=ether2 network=\
    192.168.0.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1
/ip dhcp-server lease
add address=192.168.0.7 address-lists="" comment="BEIC-LP LAN" lease-time=10m \
    mac-address=1C:83:41:09:F3:11 server=defconf
add address=192.168.0.2 client-id=1:90:2b:34:3f:6f:76 comment=AGI-PC \
    mac-address=90:2B:34:3F:6F:76 server=defconf
add address=192.168.0.3 comment=ALEX-PC mac-address=90:2B:34:A2:07:8A server=\
    defconf
add address=192.168.0.1 comment=BEIC-PC mac-address=90:2B:34:74:FE:CE server=\
    defconf
add address=192.168.0.5 comment="BEIC-LP WAN" mac-address=18:3D:A2:2A:86:18 \
    server=defconf
add address=192.168.0.6 comment=PETRA-PC mac-address=90:2B:34:B6:14:01 \
    server=defconf
add address=192.168.0.120 comment=ORANGE-PI-ONE mac-address=5E:21:83:A6:95:7A \
    server=defconf
add address=192.168.0.132 comment=BEIC-SERVER mac-address=B4:2E:99:28:D9:71 \
    server=defconf
add address=192.168.0.112 comment=IOT-EXAMPLER mac-address=A0:20:A6:04:09:10 \
    server=defconf
add address=192.168.0.177 comment=INT-DPC-001 mac-address=DE:AD:BE:EF:FE:ED \
    server=defconf
add address=192.168.0.178 comment=ARDUINO-31 mac-address=74:69:69:2D:30:31 \
    server=defconf
add address=192.168.0.179 comment=ARDUINO-32 mac-address=74:69:69:2D:30:32 \
    server=defconf
add address=192.168.0.243 comment=WD-TV-LIVE mac-address=00:90:A9:93:4B:B0 \
    server=defconf
add address=192.168.0.244 comment=WD-TV-LIVE-2 mac-address=00:90:A9:92:8F:68 \
    server=defconf
add address=192.168.0.150 comment=beicNET-Systems-D01 mac-address=\
    5C:CF:7F:AC:FB:8B server=defconf
add address=192.168.0.242 comment=AnyCast-773BCA mac-address=\
    00:F0:00:40:00:04 server=defconf
add address=192.168.0.245 comment=HPLJ1320NW mac-address=00:11:85:D2:2C:93 \
    server=defconf
add address=192.168.0.131 comment=BEIC-NAS mac-address=00:11:32:9D:64:51 \
    server=defconf
add address=192.168.0.247 comment=VivaxTV mac-address=7C:82:74:37:16:34 \
    server=defconf
add address=192.168.0.81 comment=BEIC-NAS-2 mac-address=30:46:9A:B2:B8:6A \
    server=defconf
add address=192.168.0.246 comment=LGwebOSTV mac-address=14:C9:13:3F:CB:D6 \
    server=defconf
add address=192.168.0.4 client-id=1:ac:d5:64:10:46:eb comment=AGI-LP \
    mac-address=AC:D5:64:10:46:EB server=defconf
/ip dhcp-server network
add address=192.168.0.0/24 comment=defconf dns-server=8.8.8.8,8.8.4.4 \
    gateway=192.168.0.251 netmask=24
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.0.251 name=router.lan
/ip firewall address-list
add address=XXXXXX comment="DDNS Resolver" list="WAN IP"
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
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=accept chain=input comment="Accept DNS - TCP" in-interface-list=\
    LAN port=53 protocol=tcp
add action=accept chain=input comment="Accept DNS - UDP" in-interface-list=\
    LAN port=53 protocol=udp
add action=fasttrack-connection chain=forward comment="DNS Fasttrack - TCP" \
    dst-port=53 protocol=tcp
add action=fasttrack-connection chain=forward comment="DNS Fasttrack - UDP" \
    dst-port=53 protocol=udp
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
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=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
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=masquerade chain=srcnat comment="HAIRPIN NAT" dst-address=\
    192.168.0.0/24 out-interface-list=LAN src-address=192.168.0.0/24
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-address-list=\
    "WAN IP" dst-port=3260 protocol=tcp to-addresses=192.168.0.81 to-ports=\
    3260
add action=dst-nat chain=dstnat comment="Synology GUI" dst-address-list=\
    "WAN IP" dst-port=4001 protocol=tcp to-addresses=192.168.0.131 to-ports=\
    4001
add action=dst-nat chain=dstnat comment="Synology WebDAV" dst-address-list=\
    "WAN IP" dst-port=4006 protocol=tcp to-addresses=192.168.0.131 to-ports=\
    4006
add action=dst-nat chain=dstnat comment="HTTP Server" dst-address-list=\
    "WAN IP" dst-port=8008 protocol=tcp to-addresses=192.168.0.132 to-ports=\
    8008
add action=dst-nat chain=dstnat comment="FTP Server" dst-address-list=\
    "WAN IP" dst-port=21 protocol=tcp to-addresses=192.168.0.132 to-ports=21
add action=dst-nat chain=dstnat comment="MariaDB Server" dst-address-list=\
    "WAN IP" dst-port=3307 protocol=tcp to-addresses=192.168.0.132 to-ports=\
    3307
add action=dst-nat chain=dstnat comment="RDP Server" dst-address-list=\
    "WAN IP" dst-port=5555 protocol=tcp to-addresses=192.168.0.132 to-ports=\
    5555
add action=dst-nat chain=dstnat comment="Beicnet Systems D1" \
    dst-address-list="WAN IP" dst-port=21000 protocol=tcp to-addresses=\
    192.168.0.150 to-ports=21000
add action=dst-nat chain=dstnat dst-address-list="WAN IP" dst-port=80 \
    protocol=tcp to-addresses=192.168.0.150
/ip service
set telnet disabled=yes
set ftp disabled=yes
set ssh disabled=yes port=222
set api disabled=yes
set api-ssl disabled=yes
/ip smb
set allow-guests=no domain=BEAG enabled=yes
/ip smb shares
add comment="USB Drive External" directory=/disk1 max-sessions=25 name=\
    external
/ip smb users
add name=service read-only=no
/ip ssh
set allow-none-crypto=yes forwarding-enabled=remote
/lcd interface
set sfp1 disabled=yes
set ether3 disabled=yes
set ether4 disabled=yes
set ether5 disabled=yes
set ether6 disabled=yes
set ether7 disabled=yes
set ether8 disabled=yes
set ether9 disabled=yes
set ether10 disabled=yes
/system clock
set time-zone-name=Europe/Belgrade
/system identity
set name=Prometheus
/system scheduler
add interval=10m name="Refresh DDNS" on-event="Dynamic DNS" policy=\
    read,write,test start-time=startup
/system script
add dont-require-permissions=no name="Dynamic DNS" owner=admin policy=\
    read,write,test source="# No-IP automatic Dynamic DNS update\r\
    \n\r\
    \n#--------------- Change Values in this section to match your setup -----\
    -------------\r\
    \n\r\
    \n# No-IP User account info\r\
    \n:local noipuser \"XXXXXX\"\r\
    \n:local noippass \"XXXXXX\"\r\
    \n\r\
    \n# Set the hostname or label of network to be updated.\r\
    \n# Hostnames with spaces are unsupported. Replace the value in the quotat\
    ions below with your host names.\r\
    \n# To specify multiple hosts, separate them with commas.\r\
    \n:local noiphost \"XXXXXX\"\r\
    \n\r\
    \n# Change to the name of interface that gets the dynamic IP address\r\
    \n:local inetinterface \"ether1\"\r\
    \n\r\
    \n#-----------------------------------------------------------------------\
    -------------\r\
    \n# No more changes need\r\
    \n\r\
    \n#:global previousIP;\r\
    \n\r\
    \n:if ([/interface get \$inetinterface value-name=running]) do={\r\
    \n# Get the current IP on the interface\r\
    \n   :local currentIP [/ip address get [find interface=\"\$inetinterface\"\
    \_disabled=no] address];\r\
    \n\r\
    \n# Strip the net mask off the IP address\r\
    \n   :for i from=( [:len \$currentIP] - 1) to=0 do={\r\
    \n       :if ( [:pick \$currentIP \$i] = \"/\") do={\r\
    \n           :set currentIP [:pick \$currentIP 0 \$i];\r\
    \n       }\r\
    \n   }\r\
    \n\r\
    \n   :local previousIP [:resolve \"\$noiphost\"];\r\
    \n\r\
    \n   :log info \"DNS IP: \$previousIP, interface IP: \$currentIP\";\r\
    \n\r\
    \n   :if (\$currentIP != \$previousIP) do={\r\
    \n      :log info \"No-IP: Current IP \$currentIP is not equal to previous\
    \_IP \$previousIP, update needed\";\r\
    \n     # :set previousIP \$currentIP;\r\
    \n      :local url \"http://dynupdate.no-ip.com/nic/update\\3Fmyip=\$curre\
    ntIP\";\r\
    \n      :log info \"No-IP: Sending update for \$noiphost\";\r\
    \n      /tool fetch url=(\$url . \"&hostname=\$noiphost\") user=\$noipuser\
    \_password=\$noippass mode=http dst-path=(\"no-ip_ddns_update-\" . \$host \
    . \".txt\")\r\
    \n      :log info \"No-IP: Host \$noiphost updated on No-IP with IP \$curr\
    entIP\";\r\
    \n      \r\
    \n   } else={\r\
    \n   :log info \"No-IP: Previous IP \$previousIP is equal to current IP, n\
    o update needed\";\r\
    \n   }\r\
    \n} else={\r\
    \n   :log info \"No-IP: \$inetinterface is not currently running, so there\
    fore will not update.\";\r\
    \n}"
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

anav · Thu Jun 04, 2020 11:51 pm

/ip address
add address=192.168.0.251/24 comment=defconf interface=ether2 network=\
192.168.0.0

should be
/ip address
add address=192.168.0.251/24 comment=defconf interface=bridge network=\
192.168.0.0

Dont think you need these at all (remove)
add action=fasttrack-connection chain=forward comment="DNS Fasttrack - TCP" \
dst-port=53 protocol=tcp
add action=fasttrack-connection chain=forward comment="DNS Fasttrack - UDP" \
dst-port=53 protocol=udp

A bit of extra stuff in your hairpin nat rule...... to remove
/ip firewall nat
add action=masquerade chain=srcnat comment="HAIRPIN NAT" dst-address=\
192.168.0.0/24 out-interface-list=LAN src-address=192.168.0.0/24

Fix above, and answer questions below...........

Now for hairpin nat to work,
one needs to know if your WAN IP is static or dynamic?:?
also one needs to know which SERVER(s) are you specifically looking to be able to use this functionality??

This will determine the structure of your rules.
If you have a clould ddns place from MT, also could be helpful or if you have one from a different provider AND you can set a C name to point the MT cloud ddns.

beic · Fri Jun 05, 2020 1:14 am

/ip address
add address=192.168.0.251/24 comment=defconf interface=ether2 network=\
192.168.0.0

should be
/ip address
add address=192.168.0.251/24 comment=defconf interface=bridge network=\
192.168.0.0

Fixed - Merged

Dont think you need these at all (remove)
add action=fasttrack-connection chain=forward comment="DNS Fasttrack - TCP" \
dst-port=53 protocol=tcp
add action=fasttrack-connection chain=forward comment="DNS Fasttrack - UDP" \
dst-port=53 protocol=udp

Removed - (on some YouTube tutorial it stated that the connections would be highly faster)

A bit of extra stuff in your hairpin nat rule...... to remove
/ip firewall nat
add action=masquerade chain=srcnat comment="HAIRPIN NAT" dst-address=\
192.168.0.0/24 out-interface-list=LAN src-address=192.168.0.0/24

Removed LAN - out iterface

Now for hairpin nat to work,
one needs to know if your WAN IP is static or dynamic?:?
also one needs to know which SERVER(s) are you specifically looking to be able to use this functionality??

This will determine the structure of your rules.
If you have a clould ddns place from MT, also could be helpful or if you have one from a different provider AND you can set a C name to point the MT cloud ddns.

I have Dynamic WAN IP address, it's getting resolved fine using script, and Address Lists (I'm using NO-IP service) rather than using MT's (if it's not an issue).

p.s. After changes made and reboot, all issues stayed the same...

anav · Fri Jun 05, 2020 2:26 am

Hi Beic, nice work!
You have two options for DYNAMIC WANIP and dstnat rules when working with hairpin nat otherwise the following rule would be used.
{no hairpin nat - standard dstnat rule for dynamic wanip}
add chain=dstnat action=dst-nat in-interface-list=WAN
protocol=tcp dst-port=9000 to-address=192.168.88.50

With hairpin nat one has to add the sourcenat rule for both dynamic and static wanips (already done) and special dstnat rules for dynamic wanips.
1. Use the cloud DDNS service and have more regular looking dstnat rules
2. Use modified dstnat rules.

To compare here is the format for a fixed WANIP which requires no special changes (they work with or without hairpin nat just fine).
add chain=dstnat action=dst-nat dst-address=FIXED WANIP
protocol=tcp dst-port=9000 to-address=192.168.88.50

However we have to deal with dynamic WANIP.

Method 1:
Use the MT cloud service*** and very slightly alter dstnat rules (works for internal and external users as well).
add action=dst-nat chain=dstnat dst-address-list=cloudDNS
protocol=tcp dst-port=9000 to-addresses=192.168.88.50

Note: To use method 1 -
a. Turn on mikrotik cloud service
b.Go to IP-> Firewall-> Address lists, create an entry with whatever name you wish e.g "cloudDDNS" and at the address type the cloud DDNS name of your Mikrotik...
This will automatically resolve the name to your Public IP address....

Method 2:
Modify Existing DST nat rules for a dynamic WANIP.
add chain=dstnat action=dst-nat dst-address=!192.168.88.1 \
dst-address-type=local protocol=tcp dst-port=9000 to-address=192.168.88.50

Note: where 192.168.88.1 is the lanip of the subnet, your server AND users are located on..

beic · Fri Jun 05, 2020 11:40 am

Hi Beic, nice work!
You have two options for DYNAMIC WANIP and dstnat rules when working with hairpin nat otherwise the following rule would be used.
{no hairpin nat - standard dstnat rule for dynamic wanip}
add chain=dstnat action=dst-nat in-interface-list=WAN
protocol=tcp dst-port=9000 to-address=192.168.88.50

With hairpin nat one has to add the sourcenat rule for both dynamic and static wanips (already done) and special dstnat rules for dynamic wanips.
1. Use the cloud DDNS service and have more regular looking dstnat rules
2. Use modified dstnat rules.

To compare here is the format for a fixed WANIP which requires no special changes (they work with or without hairpin nat just fine).
add chain=dstnat action=dst-nat dst-address=FIXED WANIP
protocol=tcp dst-port=9000 to-address=192.168.88.50

However we have to deal with dynamic WANIP.

Method 1:
Use the MT cloud service*** and very slightly alter dstnat rules (works for internal and external users as well).
add action=dst-nat chain=dstnat dst-address-list=cloudDNS
protocol=tcp dst-port=9000 to-addresses=192.168.88.50

Note: To use method 1 -
a. Turn on mikrotik cloud service
b.Go to IP-> Firewall-> Address lists, create an entry with whatever name you wish e.g "cloudDDNS" and at the address type the cloud DDNS name of your Mikrotik...
This will automatically resolve the name to your Public IP address....

Method 2:
Modify Existing DST nat rules for a dynamic WANIP.
add chain=dstnat action=dst-nat dst-address=!192.168.88.1 \
dst-address-type=local protocol=tcp dst-port=9000 to-address=192.168.88.50

Note: where 192.168.88.1 is the lanip of the subnet, your server AND users are located on..

So, in my case would be?:

192.168.88.1 = 192.168.0.251
192.168.88.50 = External/Public IP Address (WAN IP - Resolved by DDNS?)
also what is represent the 9000 port?

Thank you for your support!

anav · Fri Jun 05, 2020 2:32 pm

No, LOL, those were just examples, the numbers not to be taken literally.
192.168.88.50 is the IP address of the server on the LAN in the example (not a legitimate public IP number anyway)
The 9000 port is the port that your server provides to access the server..........

Take one of your rules. Its wrong for any setup regardless with dst-address list (or at least never seen it setup like that).
add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-address-list=\
"WAN IP" dst-port=3260 protocol=tcp to-addresses=192.168.0.81 to-ports=\
3260

In any case the PORT 9000 is equivalent to your port 3260, note that the to port is NOT required if same as dst-port!
Also the ..88.50 is equivalent to your server IP 192.168.0.81

beic · Fri Jun 05, 2020 3:17 pm

No, LOL, those were just examples, the numbers not to be taken literally.
192.168.88.50 is the IP address of the server on the LAN in the example (not a legitimate public IP number anyway)
The 9000 port is the port that your server provides to access the server..........

Take one of your rules. Its wrong for any setup regardless with dst-address list (or at least never seen it setup like that).
add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-address-list=\
"WAN IP" dst-port=3260 protocol=tcp to-addresses=192.168.0.81 to-ports=\
3260

In any case the PORT 9000 is equivalent to your port 3260, note that the to port is NOT required if same as dst-port!
Also the ..88.50 is equivalent to your server IP 192.168.0.81

You meant to be like this?!

add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-port=3260 \
    protocol=tcp to-addresses=192.168.0.81 to-ports=3260

This can be reachable from the outside too? (that would be my main goal).

vasilaos · Fri Jun 05, 2020 3:23 pm

yes since you don't specify an in-interface or dst-address or some other specifier it should kick from outside networks also

beic · Fri Jun 05, 2020 3:43 pm

yes since you don't specify an in-interface or dst-address or some other specifier it should kick from outside networks also

Thanks, but it still does not solved my big connection latency issue.
e.g. waiting on local network to connect over RDP for like 3-5sec, also can't use OTA programming for IoT devices anymore, etc...

vasilaos · Fri Jun 05, 2020 4:04 pm

If you rdp with the local address rather than the domain name do you experience latency?

beic · Fri Jun 05, 2020 4:16 pm

If you rdp with the local address rather than the domain name do you experience latency?

Yes, I'm talking about local address direct connection (between two computers on a same network range).

jvanhambelgium · Fri Jun 05, 2020 4:38 pm

If you rdp with the local address rather than the domain name do you experience latency?
Yes, I'm talking about local address direct connection (between two computers on a same network range).

So latency in the INITIAL RDP setup right ? Not a CONTINUOUS SLOW/DELAYED operation during a session ?
Smells like something with nameresolving causing some initial delay ? Would be interesting to look at a packet-capture to see the interaction between RDP-client <> RDP-server

anav · Fri Jun 05, 2020 4:48 pm

Disagree with my esteemed colleague........
The below is not correct.

add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-port=3260 \
protocol=tcp to-addresses=192.168.0.81 to-ports=3260

ASSUMING NO HAIRPIN NAT - (hairpin nat only required if you have users on the same lan as the server that need access the server and you want them to use the WANIP address of the router to get them there instead of the direct LANIP)

Correct NORMAL dstnat rules.....

DYNAMIC WANIP
add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" in-interface-list=WAN dst-port=3260 \
protocol=tcp to-addresses=192.168.0.81

FIXED WANIP (static)
add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-address=fixedwanip dst-port=3260 \
protocol=tcp to-addresses=192.168.0.81

vasilaos · Fri Jun 05, 2020 6:08 pm

If you try to reach the rdp server by local ip and still experience latency it is not something related to the above configuration. Since the client and server pc are on the same broadcast domain /24 their ip are directly connected and the router is not involved in the communication. I notice that you have disabled all ethernet interfaces except ethernet 2 for LAN. Are computers connected to another switch behind ethernet 2? Are you trying to access from wireless interface?

beic · Fri Jun 05, 2020 6:27 pm

If you try to reach the rdp server by local ip and still experience latency it is not something related to the above configuration. Since the client and server pc are on the same broadcast domain /24 their ip are directly connected and the router is not involved in the communication. I notice that you have disabled all ethernet interfaces except ethernet 2 for LAN. Are computers connected to another switch behind ethernet 2? Are you trying to access from wireless interface?

Yes, there are like 4-5 Gigabit Unmanaged Switches, I'm using wired connection.

vasilaos · Fri Jun 05, 2020 7:03 pm

Apart from the initial dhcp negotiation the router will not involve in the internal communication of the hosts that are directly connected with each other if you use local ip address. If you use domain name that is translated to some ip address public or local then there may be something related to the name resolving delay or to nat if resolving to the public ip rather than the local ip

beic · Fri Jun 05, 2020 7:13 pm

Apart from the initial dhcp negotiation the router will not involve in the internal communication of the hosts that are directly connected with each other if you use local ip address. If you use domain name that is translated to some ip address public or local then there may be something related to the name resolving delay or to nat if resolving to the public ip rather than the local ip

Ok, then explain this, if I put back the old Linksys WRT54GL router everything is flying like a rocket (used same settings to configure this MikroTik device).

beic · Fri Jun 05, 2020 7:22 pm

Disagree with my esteemed colleague........
The below is not correct.

add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-port=3260 \
protocol=tcp to-addresses=192.168.0.81 to-ports=3260

ASSUMING NO HAIRPIN NAT - (hairpin nat only required if you have users on the same lan as the server that need access the server and you want them to use the WANIP address of the router to get them there instead of the direct LANIP)

Correct NORMAL dstnat rules.....

DYNAMIC WANIP
add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" in-interface-list=WAN dst-port=3260 \
protocol=tcp to-addresses=192.168.0.81

FIXED WANIP (static)
add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-address=fixedwanip dst-port=3260 \
protocol=tcp to-addresses=192.168.0.81

So, basically my initial config was good for Dynamic IP, right?

add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-address-list=\
"WAN IP" dst-port=3260 protocol=tcp to-addresses=192.168.0.81 to-ports=\
3260

anav · Sat Jun 06, 2020 12:43 am

Nope,
Use in-interface-list=WAN, not dst-address="an address list"

FM
add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-address-list=\
"WAN IP" dst-port=3260 protocol=tcp to-addresses=192.168.0.81 to-ports=\
3260

TO
add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" in-interface-list=WAN \
dst-port=3260 protocol=tcp to-addresses=192.168.0.81

beic · Sat Jun 06, 2020 3:11 pm

Nope,
Use in-interface-list=WAN, not dst-address="an address list"

FM
add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-address-list=\
"WAN IP" dst-port=3260 protocol=tcp to-addresses=192.168.0.81 to-ports=\
3260

TO
add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" in-interface-list=WAN \
dst-port=3260 protocol=tcp to-addresses=192.168.0.81

Ok, but that setting will know my Dynamic DNS path ?!

in-interface-list=WAN

The problem is, like that, it will not work from Public IP....

anav · Sat Jun 06, 2020 4:00 pm

Interesting, it works fine from my public IP.
I suggest we look at what you have included in your interface list membership then,.

This is standard
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN

THis is where the problem may lie
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN

No that looks pretty good to, assuming you dont have a pppoe type connection
where one has to add the pppoe connection to the list.....
add interface=ppp0e-connection list=WAN

Since you don't have that, not sure what the issue is ???
Out of curiosity, how do you determine the contents of the firewall address list called "WAN IP" ??

beic · Sat Jun 06, 2020 4:45 pm

Since you don't have that, not sure what the issue is ???
Out of curiosity, how do you determine the contents of the firewall address list called "WAN IP" ??

I have posted a screenshot about how I'm getting the "WAN IP", but I will post it again.

anav · Sat Jun 06, 2020 5:08 pm

I see you are getting the IP address from you dyndns site
The dyndns site gets your IP due to the script.
Pretty cool!

DOH, I get it , you are using the same method above (method 1) except with the dnydns provider name vice the MT cloud name.

Well I guess in this case your dst-address will always be accurate and thus a nice work around.

(althought it still doesnt explain why the usual method doesnt work... the mysteries of MT or my lack of knowledge take your pick LOL).

Just for giggles did you also try..... in-interface=eth1 (vice list)?

How are you testing access from external users?

beic · Sat Jun 06, 2020 6:14 pm

I see you are getting the IP address from you dyndns site
The dyndns site gets your IP due to the script.
Pretty cool!

DOH, I get it , you are using the same method above (method 1) except with the dnydns provider name vice the MT cloud name.

Well I guess in this case your dst-address will always be accurate and thus a nice work around.

(althought it still doesnt explain why the usual method doesnt work... the mysteries of MT or my lack of knowledge take your pick LOL).

That's why I'm here in the first place, because I'm new to the MikroTik devices!

(I have/had used many types of UTMs and other Router platforms for decades without any issues with 10 time more configuration, like IPCop, IPFire, Smoothwall, Endian, Cisco, DD-WRT, etc..., but, ohh boy, this MikroTik is starting to piss me up!!!)

Just for giggles did you also try..... in-interface=eth1 (vice list)?

Tried as we speak, but not working.

How are you testing access from external users?

Over mobile phone and mobile network (other ISP)

anav · Sat Jun 06, 2020 6:58 pm

Yes my bad, I have limited experience but have used many zyxel products and a couple of cisco products besides the usual commercial crap.
There usually is a reason for something not working but in this case I cannot explain why the in-interface-list rule does not work for external users???

In any case, sorry I havent been able to address why that particular setup seems to be an issue but it sounds as you have a viable working config!!

I might be tempted to shorten up your dst nat rules like so................ (and change comments appropriately)

add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-address-list=\
"WAN IP" dst-port=3260 protocol=tcp to-addresses=192.168.0.81

add action=dst-nat chain=dstnat comment="Synology GUI" dst-address-list=\
"WAN IP" dst-port=4001,4006 protocol=tcp to-addresses=192.168.0.131

add action=dst-nat chain=dstnat comment="FTP Server" dst-address-list=\
"WAN IP" dst-port=21,3307,5555,8088 protocol=tcp to-addresses=192.168.0.132

add action=dst-nat chain=dstnat comment="Beicnet Systems D1" dst-address-list=\
"WAN IP" dst-port=21000,80 protocol=tcp to-addresses=192.168.0.150

Sob · Sat Jun 06, 2020 8:39 pm

Don't confuse the poor guy, @anav.

Yes, dstnat rules have dst-address-list="WAN IP", which would be wrong if "WAN IP" meant numeric IP address, but it's actually the name of address list (where XXXXXX is DDNS hostname):

/ip firewall address-list
add address=XXXXXX comment="DDNS Resolver" list="WAN IP"

Ok, then explain this, if I put back the old Linksys WRT54GL router everything is flying like a rocket (used same settings to configure this MikroTik device).

Even with same config, some things may be different. If it would be related to DNS, which probably shouldn't affect all services, but it's not completely impossible, then perhaps Linksys could be automatically adding local DNS entries for DHCP leases, but RouterOS doesn't do that (it needs to be scripted). Just an example. I'd play with packet sniffer, it often shows useful info.

One tip about DDNS, instead of running script periodically, it's better to use lease script:

https://wiki.mikrotik.com/wiki/Manual:I ... pt_example

It avoids unnecessary checking for changed address, and there's no delay when it does change. Address list can be also updated directly by lease script, instead of resolving hostname, where's another delay because of TTL.

anav · Sat Jun 06, 2020 9:17 pm

Hi Sob,
I think the chap has a better handle on it than I do LOL.
The question we both (I think) have is why does "in-interface-wan" NOT work in his dstnat rules (no hairpin nat involved).
He is in a way forced to use the dyndns route.

beic · Sat Jun 06, 2020 9:19 pm

Yes my bad, I have limited experience but have used many zyxel products and a couple of cisco products besides the usual commercial crap.
There usually is a reason for something not working but in this case I cannot explain why the in-interface-list rule does not work for external users???

In any case, sorry I havent been able to address why that particular setup seems to be an issue but it sounds as you have a viable working config!!

I might be tempted to shorten up your dst nat rules like so................ (and change comments appropriately)

add action=dst-nat chain=dstnat comment="BEIC-NAS2 - iSCSI" dst-address-list=\
"WAN IP" dst-port=3260 protocol=tcp to-addresses=192.168.0.81

add action=dst-nat chain=dstnat comment="Synology GUI" dst-address-list=\
"WAN IP" dst-port=4001,4006 protocol=tcp to-addresses=192.168.0.131

add action=dst-nat chain=dstnat comment="FTP Server" dst-address-list=\
"WAN IP" dst-port=21,3307,5555,8088 protocol=tcp to-addresses=192.168.0.132

add action=dst-nat chain=dstnat comment="Beicnet Systems D1" dst-address-list=\
"WAN IP" dst-port=21000,80 protocol=tcp to-addresses=192.168.0.150

No problem at all, now I learned that I also can "combine" multiple ports into one rule, nice one, thank you for that!

The only downside of this that I can't disable certain ports fast, rather than edit/delete it/them.

anav · Sat Jun 06, 2020 9:24 pm

Yes beic, its a good shortcut if not monkeying in the rules too much.
YOu may want to use scheduling for rules if the rules change at select times.
You may also use FW address lists to limit access to external users as well (means they have static addresses or perhaps they have dyndns URLS that the firewall address list can resolve).

As for in-interface-list our good buddy Sob stated:

"If you need port forwarding only from outside, then using in-interface or in-interface-list is the simplest solution, because it will take everything, no matter what the destination address is. Even if some hacker in ISP's network would be sending packets with random destination addresses to your router, this rule would still match and would forward them to target device. The only way how it can not work is when you use wrong interface. For example, if you'd have PPPoE, but instead of using that, you'd use parent ethernet interface.

The reasons against in-interface(-list) and for dst-address(-list) are:

- need for hairpin NAT
- when you have more than one public address and want different config for them
- when you just can't overcome the feeling that it's wrong to match all addresses when you really want only one"

Which is why I asked about pppoe, but you are already pointed I think its straight eth1 standard type cable wan input.
So in conclusion we still dont know why the general rule didnt work, which will bother me to my grave LOL, and that for better definition and security your method is superior.

beic · Sat Jun 06, 2020 9:38 pm

Don't confuse the poor guy

Who de fak says that I'm poor?!

beic · Sat Jun 06, 2020 9:44 pm

Yes beic, its a good shortcut if not monkeying in the rules too much.
YOu may want to use scheduling for rules if the rules change at select times.
You may also use FW address lists to limit access to external users as well (means they have static addresses or perhaps they have dyndns URLS that the firewall address list can resolve).

As for in-interface-list our good buddy Sob stated:

"If you need port forwarding only from outside, then using in-interface or in-interface-list is the simplest solution, because it will take everything, no matter what the destination address is. Even if some hacker in ISP's network would be sending packets with random destination addresses to your router, this rule would still match and would forward them to target device. The only way how it can not work is when you use wrong interface. For example, if you'd have PPPoE, but instead of using that, you'd use parent ethernet interface.

The reasons against in-interface(-list) and for dst-address(-list) are:

- need for hairpin NAT
- when you have more than one public address and want different config for them
- when you just can't overcome the feeling that it's wrong to match all addresses when you really want only one"

Which is why I asked about pppoe, but you are already pointed I think its straight eth1 standard type cable wan input.
So in conclusion we still dont know why the general rule didnt work, which will bother me to my grave LOL, and that for better definition and security your method is superior.

Yes, there are only eth1 and eth2 used (eth1 = WAN, eth2 = LAN).
Also if you as a long time MT user don't know, imagine me inside MT world in the first time!

We will see if my method is superior or not after a few months of running and hack attempts "red lines in the log listing")!

What is eating me most, is a measured 10-12 second of RDP connection time, nothing else (almost same latency with UltraViewer and TeamViewer too).

anav · Sat Jun 06, 2020 9:51 pm

Concur, it would eat at me too. No reason for it.............

Sob · Sat Jun 06, 2020 10:01 pm

Who de fak says that I'm poor?!

You kind of are, in the "unfortunate" sense, because it doesn't work for you (not "stricken by poverty", I wouldn't know about that). But you're focusing on wrong details.

If the problem is reliably reproducible, it's next best thing after having no problem. As was suggested before, packet sniffer is your friend. Run e.g. Wireshark on target server, capture what happens when you try to connect, and hopefully you'll find something useful.

beic · Sat Jun 06, 2020 10:08 pm

Who de fak says that I'm poor?!
You kind of are, in the "unfortunate" sense, because it doesn't work for you (not "stricken by poverty", I wouldn't know about that). But you're focusing on wrong details.

If the problem is reliably reproducible, it's next best thing after having no problem. As was suggested before, packet sniffer is your friend. Run e.g. Wireshark on target server, capture what happens when you try to connect, and hopefully you'll find something useful.

Sorry for harsh words, but it was a funny state!

Thanks for the Wireshark proposition!

beic · Sat Jun 06, 2020 10:55 pm

After a little search over the forum and google, there are lot of complains about IPSec, MTU and RDP and all unsolved cases? Weird...

anav · Sun Jun 07, 2020 4:41 am

Statistically irrelevant, for example I use IKEv2 vpn at home and we also use RDP outbound and no issues at all.

beic · Mon Jun 08, 2020 12:09 pm

Statistically irrelevant, for example I use IKEv2 vpn at home and we also use RDP outbound and no issues at all.

True, because just noticed that every connection and protocol layer I have, has the same latency issues, WebDAV, iSCSI, etc... Weird

anav · Mon Jun 08, 2020 12:29 pm

Perhaps its the modem LOL, or some weird firewall on PCs......

beic · Mon Jun 08, 2020 1:07 pm

Perhaps its the modem LOL, or some weird firewall on PCs......

As I said before, if I put back the old router, everything is working perfectly!

anav · Mon Jun 08, 2020 1:34 pm

Sorry, yes you had noted that.......... Send a supout to MT, with some additional evidence and see what they say??

beic · Mon Jun 08, 2020 1:42 pm

Sorry, yes you had noted that.......... Send a supout to MT, with some additional evidence and see what they say??

First I will disable fasttrack for ipsec, and I think my NAT rules are not in correct order?

anav · Mon Jun 08, 2020 4:30 pm

Ur NAT rule order seemed fine to me.

beic · Mon Jun 08, 2020 4:36 pm

Ur NAT rule order seemed fine to me.

1. Rearranged everything, disabled fasttrack, still same.

2. Edited fasttrack to:

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

Nothing changed, still same!

Sob · Tue Jun 09, 2020 3:11 am

You have simple config with nothing special in it. And it's not like the firewall could even slow down packets in a way to give you delays like you see.

Did you check it it could be problem with DNS, as others already suggested? If target machine tries to find client's hostname from IP address and it can't, it takes a while before it gives up. Resulting delay could be exactly what you're describing. So if you have RPD server at 192.168.0.132:5555 and connecting to it is slow, what DNS servers 192.168.0.132 uses? Is it router or something else? If router, does it have functioning DNS? You have nothing in config, so it would come from DHCP client.

Of course this is just something that *could* be happening. Befriend a packet sniffer and you can see what *is* happening.

beic · Tue Jun 09, 2020 10:19 am

You have simple config with nothing special in it. And it's not like the firewall could even slow down packets in a way to give you delays like you see.

Did you check it it could be problem with DNS, as others already suggested? If target machine tries to find client's hostname from IP address and it can't, it takes a while before it gives up. Resulting delay could be exactly what you're describing. So if you have RPD server at 192.168.0.132:5555 and connecting to it is slow, what DNS servers 192.168.0.132 uses? Is it router or something else? If router, does it have functioning DNS? You have nothing in config, so it would come from DHCP client.

Of course this is just something that *could* be happening. Befriend a packet sniffer and you can see what *is* happening.

I have the same slow connection while I'm trying to connect to the company's server from my home, it's the same latency issue.

You meant configured routers DNS ? If yes, in my old Cisco LinkSys router I have one DNS address setted up, 192.168.251 (routers IP, Gateway, DNS 1).
On MikroTik I tried to do like DNS1: 192.168.253, DNS2: 192.168.254 (no changes) and also tried DNS1: 8.8.8.8, DNS2: 8.8.4.4 (also no changes).

Now I'm working over old Cisco LinkSys router again, and the connection time are less or equal to 1s (basically instant)...but not 10-12s as in the MikroTik.

Sad story!

Who is online