Community discussions

MikroTik App
 
Lister169126
just joined
Topic Author
Posts: 5
Joined: Thu Jan 12, 2017 8:46 pm

Slow opening connection behind nat

Thu Jan 12, 2017 9:06 pm

Hello,
i have problem with my mikrotik. I have 2 bridges. One with public ips and one with private network. From private bridge i have nat to public bridge. When i try ping on any server on public, its very fast. When i try ping on private network, it takes a long time to open but speed is ok.

public bridge:
root@ts:/home/lister# time ping google.com -c1
PING google.com (172.217.23.206) 56(84) bytes of data.
64 bytes from prg03s05-in-f14.1e100.net (172.217.23.206): icmp_seq=1 ttl=57 time=3.77 ms

real    0m0,008s
user    0m0,000s
sys     0m0,000s
private bridge:
root@robot:/home/lister# time ping google.com -c1
PING google.com (172.217.23.206) 56(84) bytes of data.
64 bytes from prg03s05-in-f14.1e100.net (172.217.23.206): icmp_seq=1 ttl=56 time=3.76 ms

real    0m5.014s
user    0m0.000s
sys     0m0.004s
I don't have special firewall, only basic (defconf) with few aditional rules and forwards:
/ip firewall address-list
add address=x.x.x.x list=allow
/ip firewall filter
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="Allowed connection" dst-port=8291 protocol=tcp src-address-list=allow
add action=accept chain=input dst-port=8081 protocol=tcp src-address-list=allow
add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=bridge1-public
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept 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=bridge1-public
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=bridge1-public
add action=dst-nat chain=dstnat comment="SSH robot" dst-port=22024 in-interface=bridge1-public protocol=tcp src-address-list=allow to-addresses=192.168.4.11 to-ports=22022
add action=dst-nat chain=dstnat comment=bmc dst-port=8088 in-interface=bridge1-public protocol=tcp src-address-list=allow to-addresses=192.168.4.2 to-ports=80
add action=dst-nat chain=dstnat comment=vsphere dst-port=8080 in-interface=bridge1-public protocol=tcp src-address-list=allow to-addresses=192.168.4.3 to-ports=443
add action=dst-nat chain=dstnat dst-port=902 in-interface=bridge1-public protocol=tcp src-address-list=allow to-addresses=192.168.4.3 to-ports=902
add action=dst-nat chain=dstnat comment=ts dst-port=9987 in-interface=bridge1-public protocol=udp to-addresses=192.168.4.10 to-ports=9987
add action=dst-nat chain=dstnat dst-port=9988 in-interface=bridge1-public protocol=udp to-addresses=192.168.4.10 to-ports=9988
add action=dst-nat chain=dstnat comment="ts file transfer" dst-port=30033 in-interface=bridge1-public protocol=tcp to-addresses=192.168.4.10 to-ports=30033
add action=dst-nat chain=dstnat comment="ts server query" dst-port=10011 in-interface=bridge1-public protocol=tcp src-address-list=allow to-addresses=192.168.4.10 to-ports=10011
add action=dst-nat chain=dstnat comment=auta dst-port=80 in-interface=bridge1-public protocol=tcp to-addresses=192.168.4.11 to-ports=80
add action=dst-nat chain=dstnat comment=https dst-port=443 in-interface=bridge1-public protocol=tcp to-addresses=192.168.4.11 to-ports=443
add action=dst-nat chain=dstnat comment=FTP dst-port=21 in-interface=bridge1-public protocol=tcp to-addresses=192.168.4.11 to-ports=21
add action=dst-nat chain=dstnat comment="SSH vSphere" dst-port=22023 in-interface=bridge1-public protocol=tcp to-addresses=192.168.4.3 to-ports=22
Router model is 850Gx2 but it has higher temperature: 52C. May it be a problem? Do you need dump anything more?

Thanks for reply and help.
 
paranoidsat
just joined
Posts: 4
Joined: Wed Sep 26, 2018 12:51 pm

Re: Slow opening connection behind nat

Wed Sep 26, 2018 1:05 pm

Hello

I see the same problem on two brand new 850Gx2.
All clients behind NAT have slow DNS-Resolution. But you have to use an external nameserver like 8.8.8.8 on you clients. Also you have to disable your local DNS-Cache on your Client.
Otherwise you won't run into that Bug.
The best way to show the problem is to setup an ubuntu machine. Check your /etc/resolv.conf you are not using systemd-resolved! (127.0.0.53)
apt update
apt update ist waiting about 2-3 seconds for dns resolution
with any other routerboard no problem at all. Clients weren't changed.
Only powerusers/admin's would see the problem. Any User with local dns-cache won't be as much affected.

With same configuration and any other routerboard i don't see this problem.

Seems only DNS is affected.

Here my config:
[admin@MikroTik] > export compact
# jan/02/1970 00:03:41 by RouterOS 6.43.2
# software id = 0ZJB-YVJ6
#
# model = 850Gx2
# serial number = 71DC04D5BEC5
/ip address
add address=192.168.65.1/24 interface=ether2 network=192.168.65.0
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1 src-address=192.168.65.0/24
/system routerboard settings
set silent-boot=no
[admin@MikroTik] >
Kind regards,
 
Lister169126
just joined
Topic Author
Posts: 5
Joined: Thu Jan 12, 2017 8:46 pm

Re: Slow opening connection behind nat

Thu Sep 27, 2018 10:33 am

I'll confirm it.

I configured another Mikrotik CRS109 with the same settings and works fine. With 850Gx2 I found 2 solutions on Debian (this issue is only in 850Gx2 and it's affected only Linux system).
The issue is described here and here (look at DNS NSS improvement).

  • Simple solution is adding directive "options timeout:1" into resolve.conf. It causes the system will not wait to ipv6 resolve (because the issue is in timeout) - only 1 second to timeout.
  • Alternatively, you can set directive "options single-request" into resolv.conf, it causes the system will not try ipv6 resolve because the request is resolved in the first (ipv6) request. (not recommended)
  • A better solution is to install system own DNS resolver or another separate DNS resolver in the network (except Mikrotik). You can use bind, dnsmasq and small and best, that I found is nscd. After install set this one ip into resolv.conf. It causes the active response for ipv6 resolve request. You local DNS resolver will now cache all request and will not wait for timeout in Mikrotik (only first request is affected).
 
paranoidsat
just joined
Posts: 4
Joined: Wed Sep 26, 2018 12:51 pm

Re: Slow opening connection behind nat

Fri Sep 28, 2018 6:49 am

Hello

Thank you very much for your reply.
The workaround isn't any option for my use-cases.

We could use the 850gx2 as gigabit switch (In bridge only setup no problem at all). :-)

Have you already talked to support@mikrotik.com?
Otherwise I would send them supout.rif with link to this thread.

Kind regards,
 
Lister169126
just joined
Topic Author
Posts: 5
Joined: Thu Jan 12, 2017 8:46 pm

Re: Slow opening connection behind nat

Fri Sep 28, 2018 1:19 pm

Yes in bridge works fine :D.

No, I did not write to support. I think they read this forum and will try to help me. After a few days, I found this workaround and forget to it. If you can please send them mail.

Kind regards
 
paranoidsat
just joined
Posts: 4
Joined: Wed Sep 26, 2018 12:51 pm

Re: Slow opening connection behind nat

Mon Oct 01, 2018 9:34 am

Okay

I've sent mail to support@mikrotik.com with supout.rif

Kind regards,
 
paranoidsat
just joined
Posts: 4
Joined: Wed Sep 26, 2018 12:51 pm

Re: Slow opening connection behind nat

Wed Oct 03, 2018 5:31 pm

For Documentation rb850gx2 adds 5sec delay on dns queries

RB850Gx2 bad
16:21:49 markus@i5:~$ cat /etc/resolv.conf
nameserver 8.8.8.8
16:21:51 markus@i5:~$ ip addr sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether d4:5d:df:10:00:81 brd ff:ff:ff:ff:ff:ff
inet 192.168.65.2/24 brd 192.168.65.255 scope global enp0s31f6
valid_lft forever preferred_lft forever
3: wlp1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 8e:0a:34:7b:9e:df brd ff:ff:ff:ff:ff:ff
16:21:53 markus@i5:~$ ip r sh
default via 192.168.65.1 dev enp0s31f6
192.168.65.0/24 dev enp0s31f6 proto kernel scope link src 192.168.65.2
16:21:57 markus@i5:~$ time ping www.google.at -c 1
PING www.google.at (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=54 time=26.5 ms

--- www.google.at ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 26.455/26.455/26.455/0.000 ms

real 0m5.140s
user 0m0.005s
sys 0m0.004s
16:22:08 markus@i5:~$ time ping www.google.at -c 1
PING www.google.at (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=54 time=24.1 ms

--- www.google.at ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.121/24.121/24.121/0.000 ms

real 0m5.132s
user 0m0.005s
sys 0m0.004s
16:22:18 markus@i5:~$ time ping www.google.at -c 1
PING www.google.at (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=54 time=25.5 ms

--- www.google.at ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 25.531/25.531/25.531/0.000 ms

real 0m5.134s
user 0m0.007s
sys 0m0.002s
16:22:25 markus@i5:~$
RB600A Good
16:22:25 markus@i5:~$ cat /etc/resolv.conf
nameserver 8.8.8.8
16:23:51 markus@i5:~$ ip addr sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether d4:5d:df:10:00:81 brd ff:ff:ff:ff:ff:ff
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 74:e5:f9:8d:49:8d brd ff:ff:ff:ff:ff:ff
inet 192.168.154.76/23 brd 192.168.155.255 scope global dynamic noprefixroute wlp1s0
valid_lft 7162sec preferred_lft 7162sec
inet6 fe80::49e6:e29d:52cd:e0ef/64 scope link noprefixroute
valid_lft forever preferred_lft forever
16:23:53 markus@i5:~$ ip r sh
default via 192.168.155.5 dev wlp1s0 proto dhcp metric 600
192.168.154.0/23 dev wlp1s0 proto kernel scope link src 192.168.154.76 metric 600
16:24:02 markus@i5:~$ time ping www.google.at -c 1
PING www.google.at (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=55 time=27.8 ms

--- www.google.at ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.843/27.843/27.843/0.000 ms

real 0m0.172s
user 0m0.006s
sys 0m0.003s
16:24:06 markus@i5:~$ time ping www.google.at -c 1
PING www.google.at (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=55 time=33.7 ms

--- www.google.at ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.678/33.678/33.678/0.000 ms

real 0m0.127s
user 0m0.005s
sys 0m0.004s
16:24:08 markus@i5:~$ time ping www.google.at -c 1
PING www.google.at (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=55 time=25.8 ms

--- www.google.at ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 25.794/25.794/25.794/0.000 ms

real 0m0.109s
user 0m0.009s
sys 0m0.001s
16:24:11 markus@i5:~$
 
dksoft
Member Candidate
Member Candidate
Posts: 148
Joined: Thu Dec 06, 2012 8:56 am
Location: Germany

Re: Slow opening connection behind nat

Mon May 17, 2021 5:06 pm

I'll confirm it.
...
  • Alternatively, you can set directive "options single-request" into resolv.conf, it causes the system will not try ipv6 resolve because the request is resolved in the first (ipv6) request. (not recommended)
Is there any update to this problem?
I can only use the Mikrotik DNS server on my IPv4/IPv6 enabled Linux clients when "options single-request" or "options single-request-reopen" is set in /etc/resolv.conf.
 
Lister169126
just joined
Topic Author
Posts: 5
Joined: Thu Jan 12, 2017 8:46 pm

Re: Slow opening connection behind nat

Mon May 17, 2021 8:23 pm

I'll confirm it.
...
  • Alternatively, you can set directive "options single-request" into resolv.conf, it causes the system will not try ipv6 resolve because the request is resolved in the first (ipv6) request. (not recommended)
Is there any update to this problem?
I can only use the Mikrotik DNS server on my IPv4/IPv6 enabled Linux clients when "options single-request" or "options single-request-reopen" is set in /etc/resolv.conf.
Hi, I installed plain linux on my nb few weeks ago. I thing it's solved in new version of mikrotik. I didn't notice any issue. U have this issue still? I can start it and test.

I found this issue described somewhere where author described linux kernel and he wrote some about fix in new kernel version. So maybe it solved in new linux kernel.
 
dksoft
Member Candidate
Member Candidate
Posts: 148
Joined: Thu Dec 06, 2012 8:56 am
Location: Germany

Re: Slow opening connection behind nat

Tue May 18, 2021 11:24 am

I didn't notice any issue. U have this issue still? I can start it and test.
Yes, I still have the problem on all of my Linux installations. Kernel is 5.4.106. It only appears on installations with IPv4 and IPv6, which is causing the problem.
 
Lister169126
just joined
Topic Author
Posts: 5
Joined: Thu Jan 12, 2017 8:46 pm

Re: Slow opening connection behind nat

Tue May 18, 2021 12:41 pm

I didn't notice any issue. U have this issue still? I can start it and test.
Yes, I still have the problem on all of my Linux installations. Kernel is 5.4.106. It only appears on installations with IPv4 and IPv6, which is causing the problem.
Ok. So, u can disable ipv6, it solves most outgoing connection, especially in application.

/etc/sysctl.d/disableipv6.conf:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
`reboot` or `sysctl -p`

But now it do the same in linux based application like ping, traceroute, curl, wget bcs using glibc (mentioned before).
Very fast solution is put `options timeout:1` into `resolv.conf`. It's much better than five seconds :-). U can install nscd, it's dns cache and from this moment take long only first request. There is no need to change anything else.

Or u can still use mentioned `options single-request` but it's true workaround, it can cause to slower other connection in some situations.

Good solution is separately (from mikrotik) installed dns server like bind or dnsmasq.

Best solution is spam mikrotik to do fix... But you see... Many years later is still valid.

Who is online

Users browsing this forum: atejani, HokieCat, SpOuK3, TeWe and 124 guests