Hello.
I have RB20011iL and I’ve configured the OpenVPN client connection on it. There is LAN behind each of connection side. I can ping LAN behind the server side from client ovpn interface, but cannot get access from LAN behind client neither to ovpn server network space nor to LAN behind the server. Route to the server LAN is exist, firewall filter rule allows traffic between client’s LAN and ovpn interfaces. What can be wrong else? Maybe, I need to put some more information here?
Follow my automatic signature for further steps to take. Is the ovpn server also a Mikrotik or something else?
Hello, Sindy, ovpn server is Linux Centos 6.5.
Have a look at this post, it seems to me it is relevant for your scenario.
Thank you for the link, I looked at it, I have already the route on the server to the network behind client. In my situation, the server doesn’t see even incoming packets sent from the client side.
But now, it has been decided to change VPN type from ovpn to ipsec. The connection is established, but traffic doesn’t passthrought over tunnel. Here’s my config.
ip address print (Network for vpn is 10.200.11.16/28 - ether3-Voice)
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 172.31.2.73/30 172.31.2.72 gre-tunnel_Master
1 172.31.3.73/30 172.31.3.72 gre-tunnel_Slave
2 192.168.1.4/24 192.168.1.0 ether2-LAN
3 1.1.1.163/28 1.1.1.160 ether1-gateway
4 192.168.5.1/24 192.168.5.0 ether10_Block
5 10.200.11.17/28 10.200.11.16 ether3-Voice
6 D 172.31.0.149/24 172.31.0.0 City
7 D 192.168.100.1/32 192.168.100.13 <ovpn-malychenkon>
ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 1.1.1.161 1
2 ADC 10.200.11.16/28 10.200.11.17 ether3-Voice 0
3 S 172.16.0.70/31 172.31.2.74 10
4 S 172.16.0.70/31 172.31.3.74 20
5 A S 172.16.0.70/31 172.31.0.129 30
6 ADC 172.31.0.0/24 172.31.0.149 City 0
7 S 172.31.0.0/26 172.31.2.74 10
8 S 172.31.0.0/26 172.31.3.74 20
9 A S 172.31.0.0/26 172.31.0.129 30
10 A S 172.31.0.53/32 City 1
11 A S 172.31.0.54/32 gre-tunnel_Slave 1
12 A S 172.31.0.55/32 gre-tunnel_Master 1
13 ADC 172.31.2.72/30 172.31.2.73 gre-tunnel_Master 0
14 ADC 172.31.3.72/30 172.31.3.73 gre-tunnel_Slave 0
15 A S 192.168.0.0/24 192.168.1.3 1
16 ADC 192.168.1.0/24 192.168.1.4 ether2-LAN 0
17 DS 192.168.1.0/24 <ovpn-malychenkon> 1
18 ADC 192.168.5.0/24 192.168.5.1 ether10_Block 0
19 ADC 192.168.100.13/32 192.168.100.1 <ovpn-malychenkon> 0
20 ADC 1.1.1.160/28 1.1.1.163 ether1-gateway 0
ip ipsec peer print (my peer is 3)
Flags: X - disabled, D - dynamic, R - responder
0 address=3.3.36.254/32 auth-method=rsa-key key=Local remote-key=Key_ASR generate-policy=no policy-template-group=default exchange-mode=main
send-initial-contact=yes nat-traversal=yes proposal-check=obey hash-algorithm=md5 enc-algorithm=aes-256 dh-group=modp1024 lifetime=1d dpd-interval=2m
dpd-maximum-failures=5
1 address=3.3.37.254/32 auth-method=rsa-key key=Local remote-key=City_Slave generate-policy=no policy-template-group=default exchange-mode=main
send-initial-contact=yes nat-traversal=yes proposal-check=obey hash-algorithm=md5 enc-algorithm=aes-256 dh-group=modp1024 lifetime=1d dpd-interval=2m
dpd-maximum-failures=5
2 X address=3.3.37.123/32 local-address=4.4.4.220 auth-method=pre-shared-key secret="(Rbtdcrjt@Jnltktybt#Htfkbpfwbb$Ytantghjlernjd)"
generate-policy=no policy-template-group=default exchange-mode=main send-initial-contact=yes nat-traversal=yes proposal-check=obey hash-algorithm=md5
enc-algorithm=aes-256 dh-group=modp1024 lifetime=1d dpd-interval=2m dpd-maximum-failures=5
3 ;;; Unsafe configuration, suggestion to use certificates
address=2.2.2.2/32 local-address=1.1.1.163 auth-method=pre-shared-key secret="XXX" generate-policy=no
policy-template-group=default exchange-mode=aggressive send-initial-contact=yes nat-traversal=no my-id=user-fqdn:KRMG-PBX proposal-check=obey
hash-algorithm=sha1 enc-algorithm=3des dh-group=modp1024 lifetime=1d dpd-interval=2m dpd-maximum-failures=5
ip ipsec policy> print(my policy is 4)
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes
1 src-address=1.1.1.163/32 src-port=any dst-address=3.3.36.254/32 dst-port=any protocol=gre action=encrypt level=require ipsec-protocols=esp
tunnel=no proposal=default ph2-count=0
2 src-address=1.1.1.163/32 src-port=any dst-address=3.3.37.254/32 dst-port=any protocol=gre action=encrypt level=require ipsec-protocols=esp
tunnel=no proposal=default ph2-count=0
3 XI src-address=172.31.4.28/32 src-port=any dst-address=172.31.0.0/26 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes
sa-src-address=4.4.4.220 sa-dst-address=3.3.37.123 proposal=ASA ph2-count=0
4 A src-address=10.200.11.16/28 src-port=any dst-address=10.200.0.0/22 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes
sa-src-address=1.1.1.163 sa-dst-address=2.2.2.2 proposal=main_office ph2-count=1
ip ipsec> proposal print
name="main_office" auth-algorithms=sha1 enc-algorithms=3des lifetime=30m pfs-group=none
ip firewall> nat print (my rules are 0 and 28)
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=accept src-address=10.200.11.16/28 dst-address=10.200.0.0/22 log=no log-prefix=""
1 X ;;; default configuration
chain=srcnat action=masquerade out-interface=ether1-gateway log=no log-prefix=""
2 ;;; City_Master Ipsec over GRE
chain=srcnat action=masquerade to-addresses=0.0.0.0 dst-address=172.31.0.0/26 out-interface=gre-tunnel_Master log=no log-prefix=""
3 ;;; City_Slave Ipsec over GRE
chain=srcnat action=masquerade to-addresses=0.0.0.0 dst-address=172.31.0.0/26 out-interface=gre-tunnel_Slave log=no log-prefix=""
4 ;;; City OpenVpn
chain=srcnat action=masquerade to-addresses=0.0.0.0 dst-address=172.31.0.0/26 out-interface=Kiev log=no log-prefix=""
5 X chain=srcnat action=src-nat to-addresses=172.31.4.28 dst-address=172.31.0.0/26 log=no log-prefix=""
chain=dstnat action=dst-nat to-addresses=192.168.1.7 to-ports=80 protocol=tcp dst-address=1.1.1.163 in-interface=ether1-gateway dst-port=80
log=no log-prefix=""
7 ;;; ND 13337
chain=dstnat action=dst-nat to-addresses=192.168.1.2 to-ports=13337 protocol=tcp dst-address=1.1.1.163 dst-port=13337 log=no log-prefix=""
8 ;;; ND 8050
chain=dstnat action=dst-nat to-addresses=192.168.1.2 to-ports=8050 protocol=tcp dst-address=1.1.1.163 dst-port=8050 log=no log-prefix=""
9 X ;;; RDP SQL
chain=dstnat action=dst-nat to-addresses=192.168.1.101 to-ports=3389 protocol=tcp dst-address=1.1.1.163 dst-port=8899 log=no log-prefix=""
10 X ;;; RDP Main
chain=dstnat action=dst-nat to-addresses=192.168.1.1 to-ports=3389 protocol=tcp dst-address=1.1.1.163 dst-port=2009 log=no log-prefix=""
11 X ;;; ND RDP
chain=dstnat action=dst-nat to-addresses=192.168.1.2 to-ports=3389 protocol=tcp dst-address=1.1.1.163 dst-port=1247 log=no log-prefix=""
12 ;;; 5060
chain=dstnat action=dst-nat to-addresses=10.200.11.18 to-ports=5060 protocol=udp src-address=5.5.5.54 dst-address=1.1.1.163 dst-port=5060
log=no log-prefix=""
13 ;;; 17000-20999
chain=dstnat action=dst-nat to-addresses=10.200.11.18 to-ports=17000-20999 protocol=udp src-address=5.5.5.54 dst-address=1.1.1.163 src-port=""
dst-port=17000-20999 log=no log-prefix=""
14 ;;; ND 443
chain=dstnat action=dst-nat to-addresses=192.168.1.2 to-ports=443 protocol=tcp dst-address=1.1.1.163 dst-port=443 log=no log-prefix=""
15 ;;; ND 8891
chain=dstnat action=dst-nat to-addresses=192.168.1.2 to-ports=8891 protocol=tcp dst-address=1.1.1.163 dst-port=8891 log=no log-prefix=""
16 ;;; ND 11965
chain=dstnat action=dst-nat to-addresses=192.168.1.2 to-ports=11965 protocol=tcp dst-address=1.1.1.163 dst-port=11965 log=no log-prefix=""
17 ;;; pochta_110
chain=dstnat action=dst-nat to-addresses=192.168.1.7 to-ports=110 protocol=tcp dst-address=1.1.1.163 dst-port=110 log=no log-prefix=""
18 ;;; pochta_25
chain=dstnat action=dst-nat to-addresses=192.168.1.7 to-ports=25 protocol=tcp dst-address=1.1.1.163 dst-port=25 log=no log-prefix=""
19 ;;; pochta_2525
chain=dstnat action=dst-nat to-addresses=192.168.1.7 to-ports=25 protocol=tcp dst-address=1.1.1.163 dst-port=2525 log=no log-prefix=""
20 ;;; pochta_2517
chain=dstnat action=dst-nat to-addresses=192.168.1.7 to-ports=25 protocol=tcp dst-address=1.1.1.163 dst-port=2517 log=no log-prefix=""
21 X ;;; 7777
chain=dstnat action=dst-nat to-addresses=192.168.1.7 to-ports=7777 protocol=tcp dst-address=1.1.1.163 dst-port=7777 log=no log-prefix=""
22 ;;; Kolya Oracl
chain=dstnat action=dst-nat to-addresses=192.168.1.20 to-ports=1521 protocol=tcp dst-address=1.1.1.163 dst-port=1219 log=no log-prefix=""
23 X ;;; MagTux
chain=dstnat action=dst-nat to-addresses=192.168.1.5 to-ports=55555 protocol=tcp dst-address=1.1.1.163 dst-port=55555 log=no log-prefix=""
24 ;;; CISCO ASA 5505
chain=dstnat action=dst-nat to-addresses=192.168.1.31 to-ports=22 protocol=tcp dst-address=1.1.1.163 dst-port=10022 log=no log-prefix=""
25 chain=dstnat action=dst-nat to-addresses=192.168.1.5 to-ports=8291 protocol=tcp dst-address=1.1.1.163 dst-port=11122 log=no log-prefix=""
26 chain=srcnat action=masquerade src-address=192.168.1.0/24 out-interface=ether1-gateway log=no log-prefix=""
27 chain=srcnat action=masquerade src-address=192.168.5.0/24 out-interface=ether1-gateway log=no log-prefix=""
28 chain=srcnat action=masquerade src-address=10.200.11.16/28 dst-address=!10.200.0.0/22 out-interface=ether1-gateway log=no log-prefix=""
29 ;;; Medok RDP
chain=dstnat action=dst-nat to-addresses=192.168.5.7 to-ports=3389 protocol=tcp dst-address=1.1.1.163 dst-port=2302 log=no log-prefix=""
30 ;;; Medok Local RDP
chain=dstnat action=dst-nat to-addresses=192.168.5.7 to-ports=3389 protocol=tcp src-address=192.168.1.0/24 dst-address=1.1.1.163 dst-port=2302
log=no log-prefix=""
31 ;;; Medok Local acsses RDP
chain=srcnat action=src-nat to-addresses=1.1.1.163 protocol=tcp src-address=192.168.1.0/24 dst-address=192.168.5.7 dst-port=2302 log=no
log-prefix=""
ip firewall> filter print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; RDP Local
chain=forward action=accept connection-state=established protocol=tcp dst-address-list=Local src-port=3389 log=yes log-prefix=""
1 ;;; Router 1_104
chain=forward action=drop src-address-list=block_list dst-address-list=Local log=no log-prefix=""
2 ;;; RDP
chain=forward action=accept protocol=tcp src-address-list=!Local dst-address-list=RDP dst-port=3389 log=no log-prefix=""
3 X ;;; Block Black List
chain=forward action=drop src-mac-address=8C:89:A5:7C:AA:F2 log=no log-prefix=""
4 X ;;; Block Youtube
chain=forward action=drop layer7-protocol=Block YouTube src-address-list=block_list log=no log-prefix=""
5 X ;;; Block Anonymizer
chain=forward action=reject reject-with=tcp-reset layer7-protocol=anonymizer protocol=tcp src-address-list=block_list log=no log-prefix=""
6 X ;;; Block Video
chain=forward action=reject reject-with=tcp-reset layer7-protocol=video protocol=tcp src-address-list=block_list log=no log-prefix=""
7 X ;;; Block Social
chain=forward action=reject reject-with=tcp-reset layer7-protocol=social protocol=tcp src-address-list=block_list log=no log-prefix=""
8 X chain=forward action=drop src-mac-address=64:89:9A:89:CA:4C log=no log-prefix=""
9 X chain=forward action=drop src-mac-address=A0:91:69:AB:4D:BE log=no log-prefix=""
10 X ;;; Kobka-PC
chain=forward action=accept src-address=0.0.0.0 dst-address=192.168.1.0/24 src-mac-address=10:BF:48:71:AC:B7 log=no log-prefix=""
11 X ;;; drop spammer
chain=forward action=drop protocol=tcp src-address-list=spammer dst-port=25 log=no log-prefix=""
12 X ;;; Find who is spammer
chain=forward action=add-src-to-address-list connection-limit=30,32 protocol=tcp src-address-list=spammer address-list=spammer address-list-timeout=1d
dst-port=25 limit=50,5 log=no log-prefix=""
13 chain=forward action=accept src-address=192.168.100.0/24 dst-address=192.168.1.0/24 dst-address-list=RDP log=no log-prefix=""
14 chain=forward action=accept src-address=192.168.1.0/24 dst-address=192.168.100.0/24 log=no log-prefix=""
15 X chain=forward action=accept src-address=185.35.145.228 dst-address=192.168.1.5 log=no log-prefix=""
16 chain=forward action=accept protocol=tcp dst-address=192.168.1.2 dst-port=13337,8050,443,8891,11965 log=no log-prefix=""
17 ;;; Kolya Oracl
chain=forward action=accept protocol=tcp dst-address=192.168.1.20 dst-port=1521 log=no log-prefix=""
18 X ;;; MagTux
chain=forward action=accept protocol=tcp dst-address=192.168.1.5 dst-port=55555 log=no log-prefix=""
19 chain=forward action=accept protocol=tcp dst-address=192.168.1.7 dst-port=25,80,110,2525,2517 log=no log-prefix=""
20 chain=forward action=accept src-address=192.168.1.0/24 dst-address=192.168.1.0/24 in-interface=ether2-LAN out-interface=ether2-LAN log=no log-prefix=""
21 ;;;
chain=forward action=accept in-interface-list=MY_NET log=no log-prefix=""
22 ;;;
chain=forward action=accept connection-state=established,related in-interface=ether1-gateway out-interface-list=MY_NET log=no log-prefix=""
23 chain=forward action=accept dst-address=172.31.0.0/26 log=no log-prefix=""
24 chain=forward action=accept connection-state=established src-address=172.31.0.0/26 log=no log-prefix=""
25 chain=forward action=accept protocol=tcp dst-address=192.168.1.31 src-address-list=Dnepr in-interface=ether1-gateway dst-port=22 log=no log-prefix=""
26 chain=forward action=accept protocol=tcp dst-address=192.168.1.5 dst-port=8291 log=no log-prefix=""
27 ;;; UkrTel Phones
chain=input action=accept protocol=udp src-address=5.5.5.54 dst-address=1.1.1.163 src-port="" dst-port=5060 log=no log-prefix=""
28 ;;; UkrTel Phones
chain=input action=accept protocol=udp src-address=5.5.5.54 dst-address=1.1.1.163 dst-port=17000-20999 log=no log-prefix=""
29 ;;; OUT 5060
chain=output action=accept protocol=udp dst-address=5.5.5.54 out-interface=ether1-gateway dst-port=5060 log=no log-prefix=""
30 ;;; OUT 17000-20999
chain=output action=accept protocol=udp dst-address=5.5.5.54 out-interface=ether1-gateway dst-port=17000-20999 log=no log-prefix=""
31 chain=forward action=drop log=no log-prefix=""
32 chain=input action=accept protocol=udp in-interface-list=MY_NET dst-port=53 log=no log-prefix=""
33 chain=input action=accept connection-state=established protocol=udp in-interface=ether1-gateway src-port=53 log=no log-prefix=""
34 chain=input action=accept protocol=udp src-address-list=Ukrnafta_Radius_NTP in-interface=!ether1-gateway src-port=123,1645,1646 log=no log-prefix=""
35 chain=input action=accept protocol=udp src-address-list=VPN_Peers in-interface=ether1-gateway dst-port=500,4500 log=no log-prefix=""
36 chain=input action=accept src-address=6.6.6.227 dst-address=1.1.1.163 log=no log-prefix=""
37 ;;; OpenVPN
chain=input action=accept protocol=tcp in-interface=ether1-gateway dst-port=1195 log=no log-prefix=""
38 chain=input action=accept protocol=icmp log=no log-prefix=""
39 chain=input action=accept protocol=gre src-address-list=VPN_Peers in-interface=ether1-gateway log=no log-prefix=""
40 chain=input action=accept protocol=ipencap src-address-list=VPN_Peers in-interface=ether1-gateway log=no log-prefix=""
41 chain=input action=accept protocol=ipsec-esp src-address-list=VPN_Peers in-interface=ether1-gateway log=no log-prefix=""
42 chain=input action=accept protocol=tcp src-address-list=Ukrnafta in-interface=!ether1-gateway dst-port=22,8291 log=no log-prefix=""
43 chain=input action=accept connection-state=established protocol=tcp src-address-list=VPN_Peers in-interface=ether1-gateway src-port=1194 log=no
log-prefix=""
44 chain=input action=accept protocol=tcp src-port=1198 log=no log-prefix=""
45 chain=input action=drop log=no log-prefix=""
ip ipsec> installed-sa print
Flags: H - hw-aead, A - AH, E - ESP
0 E spi=0x955899C src-address=2.2.2.2 dst-address=1.1.1.163 state=mature auth-algorithm=sha1 enc-algorithm=3des enc-key-size=192
auth-key="bf5d9ea5f101a40cb4827d15e85e0e975d9b1f0b" enc-key="801ddcbe357fea2b07a199fe3e54fb421884ca86a88523da" add-lifetime=24m/30m replay=128
1 E spi=0x702FB965 src-address=1.1.1.163 dst-address=2.2.2.2 state=mature auth-algorithm=sha1 enc-algorithm=3des enc-key-size=192
auth-key="5709225fa2431e12571f79bd933cbff8acd3de48" enc-key="0875a68387acea46290f87b41ed66b3ca9a4927164dd3b93" add-lifetime=24m/30m replay=128
ping interface=ether3-Voice 10.200.0.15
SEQ HOST SIZE TTL TIME STATUS
0 packet rejected
1 packet rejected
2 packet rejected
sent=3 received=0 packet-loss=100%
I’m away from the PC so cannot check the details till about this time of day tomorrow. What is the IPsec software on the other (Linux) side?
This time, I have Cisco ASA 5512 as other IPsec side instead of Linux software. It’s worth noting, I already had successfull connection between this ASA and another RB20011iL, but last one didn’t have any configuration except ipsec I need. No additional nat, firewall and other services. Current one has more complicated configuration, so I think the problem is the configs intersection. But where is exactly, I don’t see so far…
First of all, instead of ping interface=ether3-Voice 10.200.0.15, try ping 10.200.0.15 src-address=10.200.11.17.
If the ping continues to fail, regardless what error you get, have a look at /ip ipsec installed-sa print where dst-address=2.2.2.2 or src-address=2.2.2.2. If none of the two sas shows any packet and byte counts, the issue is on Mikrotik side; if the one from 1.1.1.163 to 2.2.2.2 counts and the other one doesn’t, the issue is at Cisco side.
Thanks a lot for your checking and tips. The one from 1.1.1.163 to 2.2.2.2 counts during the ping, but the the other one doesn’t. Thus the issue is on the ASA?! Though on the Cisco both counters are in zero, the direction where to go is clearlier.
There may be several issues:
I’d be really interested if you could use /tool sniffer at Mikrotik end and try pinging from Cisco side, to see whether the ESP packets are arriving and whether Mikrotik accepts or ignores them. Ideally do the same in the reverse direction if you have a chance to sniff packets on the ASA or right in front of it, the behaviour may be different in each direction.
For the last point in the list, there is a confirmed bug on Mikrotik side, but so far it seems to randomly affect a single reincarnation of an SA pair, so the next one is usually fine, and it seems to only exist when exchange-mode=ike2 is used. However, if you find out that the keys differ for every SA pair between Mikrotik and Cisco, it would be an important piece of information too.
BTW, what makes you use aggressive mode, given that there is no NAT between the devices?
I’ve set up Wireshark on the Windows host behind the ether2, filter “udp port 37008”. According these filters:
tool sniffer print
only-headers: no
memory-limit: 100KiB
memory-scroll: yes
file-name:
file-limit: 1000KiB
streaming-enabled: yes
streaming-server: 192.168.1.232
filter-stream: no
filter-interface: ether1-gateway
filter-mac-address:
filter-mac-protocol:
filter-ip-address: 2.2.2.2/32
filter-ipv6-address:
filter-ip-protocol:
filter-port:
filter-cpu:
filter-direction: any
filter-operator-between-entries: or
running: yes
I see ESP packets between Mikrotik and Cisco ASA even without pinging.
https://drive.google.com/open?id=1zY3WDmWkjpWGClYStzAzLN6Ud_hTMB34
May be I need to give more information about the packet sniffed?
To do the same on cisco side, I need a little more time.
I have many devices behind nat connected by the same way, and in this case, it’s just habit. But, I’m agree, it doesn’t need here, and I’ll change it.
well, to be 100% sure it would be good to see that the actual source and destination addresses (which the Wireshark doesn’t show in packet list pane due to the TZSP encapsulation) are correct, but I guess there is no other ESP running on that Mikrotik’s WAN.
But in this case, can you confirm that when you ping from Cisco side, the security association does count packets at Cisco side but doesn’t on Mikrotik side? Because if the sending side counts and the receiving doesn’t while you can see in Wireshark that the ESP packets do arrive, it means that the SA negotiation has failed or that Mikrotik has some other problem with processing of incoming ESP; if both the sending and receiving sides count packets in this direction, there is a chance that it is a firewall issue or that the ESP packets get lost on their way from Mikrotik to Cisco.
When the IPsec connection is up, what does /ip firewall connection print detail where protocol~“ipsec-esp” show?
I’m sorry, but I’ve found out recently that there is the another ipsec connection to this ASA-server from ASA-client behind ether2 of Mikrotik. So, the sniffed ESP packets, I showed before, belonged to that connection, which, by the way. works well. I’ve came down VPN of ASA-client for a while, and then I had another picture without ESP at all, only ISAKMP, when I pinged it from server side. The sas of both directions are same.
Here’s the output from ASA console:
ping
ping inside 10.200.11.17
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.200.11.17, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)
Route
sh route | in 10.200.11.16
V 10.200.11.16 255.255.255.240 connected by VPN (advertised), outside
VPN-Session
Session Type: LAN-to-LAN
Connection : KRMG-PBX
Index : 25835 IP Addr : 1.1.1.163
Protocol : IKEv1 IPsec
Encryption : IKEv1: (1)3DES IPsec: (1)3DES
Hashing : IKEv1: (1)SHA1 IPsec: (1)SHA1
Bytes Tx : 0 Bytes Rx : 0
Login Time : 22:13:38 EET Thu Sep 6 2018
Duration : 0h:07m:33s
ASA doesn’t count on its side.
OK, so the positive aspect of this is that it clearly tells us that nothing on the path between the 'Tik and the ASA drops ESP packets in either direction.
Which says nothing about what happens when you ping from client (Mikrotik) side, you have to try that too while the ASA-client is disabled.
If no sent packets are counted if you ping from ASA side, it means that routing or traffic selection doesn’t make the packets be sent via the SA at all, so most likely two independent issues exist.
I don’t know ASA’s way of specifying the traffic to be sent via the IPsec connection, but on Mikrotik and linux, routes and ipsec policies are in a way two distinct worlds.
So are you 100% sure that in ASA the configuration interface is a common one for both and the route above actually describes a traffic selector for the SA? I’m afraid the ASA might be encapsulating a GRE tunnel into the SA. This would not explain why the SA dump doesn’t shown any sent packets but might constitute a trouble later on.
And now a million-hryvna-question - does the Mikrotik do NAT on the interface looking towards the ASA-server?
I’ve done. Nothing to change on ASA-Server side.
Yes. All connections “from world” come in to only one (outside) interface of ASA. The same about the route, at least, all routes to our ipsec peers are marked so.
We don’t have GRE on our ASA, and as far as I know, ASA doesn’t support GRE:
GRE tunnels are not configurable on the ASA in any version.
Yes, of cource. There are “src nat” and “masq” on the ether-1 of Mikrotik, I published nat rules above. Even more, all directions from ether3-Voice, except 10.200.0.0/22, need to be nated and it works fine. To bypass nat for ipsec traffic, there are two rules:
chain=srcnat action=accept src-address=10.200.11.16/28 dst-address=10.200.0.0/22 log=no log-prefix=""
And I noticed, only first packet counted by this rule when ping is performed from Mikrotik to ASA.
The second one is:
chain=srcnat action=masquerade src-address=10.200.11.16/28 dst-address=!10.200.0.0/22 out-interface=ether1-gateway log=no log-prefix=""
You are careful unlike me 
))
The NAT is the issue which needs to be resolved first.
Only one ESP “session” from each remote address can traverse a NATing interface; ESP has no ports so it is not possible to map incoming packets to internal IP addresses by port number, and as the SPI values used in the two directions of the same ESP “session” are totally unrelated and as their negotiation is encrypted, the NATing device is also unable to route ESP packets coming from the public side based on their SPI field. As one of the ESP “sessions” is terminated locally in your case, it could be distinguished from a transiting one if the firewall module would talk to the IPsec module which has the knowledge of locally used SPIs, but unfortunately it is not the case. And it would only be useful for three people in the world having exactly the same scenario (one local peer and one NATed one talking to the same remote peer) that no one will invest the necessary development effort into that.
So one possibility is to use NAT-T which encapsulates ESP into UDP, so the price to pay is a reduction of usable packet space, another possibility is to reorganize your network so that you wouldn’t need to route ESP flows of two different devices via a NATing interface. So e.g. you would might cut the tunnel between the ASA-server and the ASA-client to halves and terminate both halves on the Mikrotik. Or you might use two different addresses at the ASA-server so the Mikrotik’s NAT could tell the flows from each other by the remote peer address.
I had something else in mind here, whether the Mikrotik actually sends the ESP packets when you ping from its end or it doesn’t, not whether they reach the ASA and how they are handled there. But it is not important until you resolve the NAT issue somehow.
Another misunderstanding, as I don’t know the ASA and given that it doesn’t count sent packets when you ping from its side, my concern was whether the route/traffic selector configuration is correct. By “configuration interface” I had in mind the CLI or GUI - whether an object called “route” can represent only an actual route or also an IPsec traffic selector.
This is normal because the nat table always handles only the initial packet of each connection (connection-state=new)
Everything is working now!
According your advice
I had something else in mind here, whether the Mikrotik actually sends the ESP packets when you ping from its end or it doesn’t,
, I looked at it and there was no ESP during the ping from Mikrotik to ASA-server.
Then, playing with config, I erased all Miktotik’s settings related to my ipsec connection: policy, peer etc, nat/filter rules, and created them again. And tunnel came up and traffic passed through over it. But ASA-client stopped working 
). His VPN was came up, but traffic doesn’t pass. Situation looked like as:
Mikrotik’s ipsec was working, but disabled at that moment.
ASA-server and ASA-client counted them outgoing traffic, but didn’t count incoming.
There was ESP on ether1 of Mikrotik side only from ASA-server.
I looked inside esp packet came in from ASA-server and noticed that it’s not NATed (without 4500 udp encapsulation). There was no nat-traversal on ASA-client. When I enabled it, everything worked.
Mikrotik’s ipsec peer was enabled again.
Now, I have two ipsec connections: first one is local and has “clean” ESP. Second one is transit over nat-traversal.
Thank you very much for your help! It’s solved!