This bit may be very important - IPsec matches packets to traffic selectors of the individual policies until the first match, so if the traffic selector of your tunnel gets shadowed by a traffic selector of some other tunnel, the traffic the client sends to you may end up at another peer.they say that all other existing tunnels works fine for them only with mine are problems
It's not the kind of error I was expecting to see, but the non-0 values do indicate something is wrong. When it is broken, what does /ip ipsec installed-sa print show? If you want to obfuscate, it is only necessary to obfuscate the IP addresses, all the keys are ephemeral so the eventual attacker would have to use them while they are still valid. But their actual values would only be interesting if you had data from both devices from the same time (to compare them to see whether the rekeying result was the same at both peers, there used to be a bug in this a few years ago) anyway.On my sideCode: Select all/ip ipsec statistics print in-errors: 0 in-buffer-errors: 0 in-header-errors: 0 in-no-states: 233 in-state-protocol-errors: 0 in-state-mode-errors: 0 in-state-sequence-errors: 0 in-state-expired: 0 in-state-mismatches: 0 in-state-invalid: 0 in-template-mismatches: 0 in-no-policies: 0 in-policy-blocked: 0 in-policy-errors: 0 out-errors: 0 out-bundle-errors: 0 out-bundle-check-errors: 0 out-no-states: 3012 out-state-protocol-errors: 8 out-state-mode-errors: 0 out-state-sequence-errors: 0 out-state-expired: 8 out-policy-blocked: 0 out-policy-dead: 0 out-policy-errors: 0
/ip firewall raw print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; iii
chain=prerouting action=notrack log=no log-prefix="" src-address=10.254.0.0/24_MYLAN dst-address=172.16.3.0/30_CLIENT_LAN
chain=prerouting action=notrack log=no log-prefix="" src-address=10.251.0.0/24_MYLAN dst-address=10.14.0.0/16_CLIENT_LAN
chain=prerouting action=notrack log=no log-prefix="" src-address=172.16.3.0/30 dst-address=10.254.0.0/24
chain=prerouting action=notrack log=no log-prefix="" src-address=10.14.0.0/16 dst-address=10.251.0.0/24
/ip ipsec installed-sa print
Flags: H - hw-aead, A - AH, E - ESP
0 HE spi=0xF0D0A4F src-address=CLIENT_IP dst-address=MY_WANstate=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=256 auth-key="1de0"
enc-key="e7e23da6a4b2bcb94f17922d3970e1915d5ba3cf49c6f34" add-lifetime=48m/1h
replay=128
1 HE spi=0x9884EAF6 src-address=MY_WANdst-address=CLIENT_IP state=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=256 auth-key="26a66ed094f8ee0ef5cb"
enc-key="5eb3259s8f487c3b1661d1c67e9fb46" add-lifetime=48m/1h
replay=128
2 HE spi=0x637A3BB src-address=CLIENT_IP2 dst-address=MY_WANstate=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=128 auth-key="7b89486ad9c61183d0992b54cc8"
enc-key="5d0765sc5c3385ee481" add-lifetime=24m/30m replay=128
3 HE spi=0x85F90A9 src-address=MY_WANdst-address=CLIENT_IP2 state=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=128 auth-key="573608f9ss59b5cddcaee01c13e"
enc-key="00bbads27cb33a26" addtime=aug/12/2022 10:25:43 expires-in=16m15s
add-lifetime=24m/30m current-bytes=2048 current-packets=40 replay=128
NAT may be necessary so that IPsec could work or it may prevent it from working, it depends on the use case. But it would require something more to make inappropriate NAT rules cause this random behaviour - for example, routes in the regular routing would have to change because some interface would go down (or up), causing the same traffic to use a different route than usually, and consequently to hit another NAT rule.From that behave and all forums i have read about king of this isues maybe NAT rules affecting the traffic (just presuming).
That's an important observation, it may indicate that the problem is not with IPsec and that the traffic that should be sent through the tunnel actually doesn't reach your Mikrotik at all. But this is only the case if all of your traffic is a response one (i.e. your side doesn't actively send anything to the remote one).counters of these rules never grow when no traffic go in/out. Tunnel allways eshablished.
Actually, there was a small bit of traffic from you to them:At the moment no traffic to/from both tunnels.
3 HE spi=0x85F90A9 src-address=MY_WANdst-address=CLIENT_IP2 state=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=128 auth-key="573608f9ss59b5cddcaee01c13e"
enc-key="00bbads27cb33a26" addtime=aug/12/2022 10:25:43 expires-in=16m15s
add-lifetime=24m/30m current-bytes=2048 current-packets=40 replay=128
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec profile
add dh-group=modp1024 enc-algorithm=3des name=profile_1
add dh-group=modp1024 enc-algorithm=3des name=profile_2
add dh-group=modp1024 enc-algorithm=aes-128 name=CLIENT1 nat-traversal=no
add dh-group=modp1536 enc-algorithm=aes-256 lifetime=2h10m name=CLIENT2 \
nat-traversal=no
/ip ipsec peer
add address=3.3.3.3/32 local-address=2.2.2.2 name=CLIENT1 profile=CLIENT1 \
send-initial-contact=no
add address=1.1.1.1/32 local-address=2.2.2.2 name=CLEINT2 profile=CLIENT2 \
send-initial-contact=no
add disabled=yes name=peer2 passive=yes profile=profile_2
add disabled=yes name=peer1 passive=yes profile=profile_1
/ip ipsec proposal
set [ find default=yes ] disabled=yes enc-algorithms=3des pfs-group=none
add enc-algorithms=aes-128-cbc name=CLIENT1
add enc-algorithms=aes-256-cbc lifetime=1h name=CLEINT2 pfs-group=modp1536
/ip dhcp-client
add disabled=no interface=ether1
/ip firewall filter
add action=accept chain=input comment="ALLOW IPSEC" protocol=ipsec-esp
add action=accept chain=input comment="ALLOW IPSEC" protocol=ipsec-ah
add action=accept chain=input comment="ALLOW IPSEC" dst-port=500 log=yes \
protocol=udp
add action=accept chain=input comment="ALLOW IPSEC" dst-port=4500 protocol=\
udp
add action=accept chain=input dst-port=1701 protocol=udp
add action=accept chain=input comment="ALLOW IPSEC L2TP" dst-port=1723 \
protocol=tcp
add action=accept chain=input comment="ALLOW GRE" protocol=gre
add action=accept chain=input comment="ALLOW PING" protocol=icmp
add action=accept chain=input comment="ALLOW CLIENT1" dst-address=\
10.254.0.0/24 src-address=172.16.3.0/30
add action=accept chain=forward dst-address=172.16.3.0/30 src-address=\
10.254.0.0/24
add action=accept chain=forward dst-address=10.254.0.0/24 src-address=\
172.16.3.0/30
add action=accept chain=input comment="ALLOW CLIENT2" dst-address=\
10.251.0.0/24 src-address=10.14.0.0/16
add action=accept chain=forward dst-address=10.251.0.0/24 src-address=\
10.14.0.0/16
add action=accept chain=input comment="ALLOW SSTP" dst-port=443 protocol=tcp
add action=accept chain=input comment="ALLOW trafic from E1 (established)" \
connection-state=established in-interface=ether1
add action=drop chain=input comment="DROP trafic from E1 (all)" in-interface=\
ether1
add action=drop chain=input comment="DROP trafic from PPP (all)" \
in-interface=all-ppp
/ip firewall nat
add action=accept chain=srcnat comment="CLIENT1 " dst-address=172.16.3.0/30 \
src-address=10.254.0.0/24
add action=accept chain=srcnat comment="CLIENT1 " dst-address=10.254.0.0/24 \
src-address=172.16.3.0/30
add action=accept chain=srcnat comment=CLIENT2 dst-address=10.251.0.0/24 \
src-address=10.14.0.0/16
add action=accept chain=srcnat comment=CLIENT2 dst-address=10.14.0.0/16 \
src-address=10.251.0.0/24
add action=src-nat chain=srcnat comment=COMMENTS out-interface=ether1 \
src-address=192.168.111.0/24 to-addresses=2.2.2.2
add action=masquerade chain=srcnat comment=GW out-interface=ether1 \
src-address=!10.240.240.250
add action=masquerade chain=srcnat comment=COMMENTS dst-address=10.240.0.0/20
add action=masquerade chain=srcnat comment=COMMENTS dst-address=\
10.240.18.0/23
add action=masquerade chain=srcnat comment=COMMENTS dst-address=\
10.240.16.0/24 src-address=192.168.5.0/24
add action=masquerade chain=srcnat comment=COMMENTS dst-address=\
10.240.16.0/24 src-address=192.168.99.0/24
add action=masquerade chain=srcnat comment=COMMENTS dst-address=\
10.240.16.0/24 src-address=10.10.10.0/24
add action=masquerade chain=srcnat comment=COMMENTS dst-address=\
172.16.55.0/24 src-address=10.10.10.0/24
add action=masquerade chain=srcnat comment=COMMENTS dst-address=\
172.16.66.0/24
add action=masquerade chain=srcnat comment=COMMENTS dst-address=10.254.0.0/16 \
src-address=10.10.10.14
/ip firewall raw
add action=notrack chain=prerouting comment=CLIENT1 dst-address=172.16.3.0/30 \
src-address=10.254.0.0/24
add action=notrack chain=prerouting dst-address=10.254.0.0/24 src-address=\
172.16.3.0/30
add action=notrack chain=prerouting comment=CLIENT2 dst-address=10.14.0.0/16 \
src-address=10.251.0.0/24
add action=notrack chain=prerouting dst-address=10.251.0.0/24 src-address=\
10.14.0.0/16
/ip ipsec identity
# Suggestion to use stronger pre-shared key or different authentication method
add peer=CLEINT2 secret=secret
# Suggestion to use stronger pre-shared key or different authentication method
add peer=CLIENT1 secret=secret
add generate-policy=port-override peer=peer2 remote-id=ignore secret=\
verysecret
# Suggestion to use stronger pre-shared key or different authentication method
add generate-policy=port-override peer=peer1 remote-id=ignore secret=test
/ip ipsec policy
set 0 disabled=yes
add dst-address=172.16.3.0/30 level=unique peer=CLIENT1 proposal=CLIENT1 \
src-address=10.254.0.0/24 tunnel=yes
add dst-address=10.14.0.0/16 level=unique peer=CLEINT2 proposal=CLEINT2 \
src-address=10.251.0.0/24 tunnel=yes
/ip route
add comment="comment" distance=15 gateway=99.99.99.99 \
pref-src=99.99.99.91 routing-mark=DSL1
add comment="comment" distance=16 gateway=88.88.88.88 \
pref-src=88.88.88.81 routing-mark=DSL3
/ip route rule
add action=lookup-only-in-table dst-address=0.0.0.0/0 src-address=\
192.168.99.252/32 table=DSL1
add action=lookup-only-in-table dst-address=0.0.0.0/0 src-address=\
192.168.77.23/32 table=DSL
add action=lookup-only-in-table dst-address=0.0.0.0/0 src-address=\
10.240.14.24/32 table=DSL
add action=lookup-only-in-table dst-address=0.0.0.0/0 src-address=\
10.240.14.21/32 table=DSL
add action=lookup-only-in-table dst-address=0.0.0.0/0 src-address=\
10.240.14.202/32 table=DSL
If the the corresponding installed-sa (from your public address to client's one) also counts as you ping, the IPsec policy matching also does its job.Ping echo packets are send from my Router, but never gets back. Just to clear.
But there is one more possibility, I can see you have a multi-WAN arrangement. What can happen, and I admit it requires multiple factors to coincide:When pingins SA counters bytes are incresing only from my side too
How to check this one ???
IPSEC P2P OUTSIDE:1.1.1.3/30
Main route 0.0.0.0 1.1.1.1 / distance 1/ pref source 1.1.1.3
What was the exact command line you used for sniffing (substitute just the public IP addresses if you use them on that command line)?I have tried to capture, but none packets captured even from IP romete or local IP, or fithout filter What this could be. Tried to to flush, to disable and enable IPSEC peers but no packets were captured. Connections still showing establised. ????
What was the exact command line you used for sniffing (substitute just the public IP addresses if you use them on that command line)?I have tried to capture, but none packets captured even from IP romete or local IP, or fithout filter What this could be. Tried to to flush, to disable and enable IPSEC peers but no packets were captured. Connections still showing establised. ????
/tool sniffer
set filter-ip-protocol=ipsec-eso
set filter-ip-address=.163 or .177
What are option to check this ? As for were too strange as i am pinging but no traffic then send out ? Maybe firewall rules stops ?I am confused. The packet dissection (bottommost picture) shows a packet from the client to your Mikrotik (src-mac-address Cisco, dst-mac-address Mikrotik). That would mean that the ESP traffic is only coming from the client to your Mikrotik as no ESP sent from your address. In such case, it would mean that the ESP traffic from them is not induced by your pinging, and that your Mikrotik ignores it.
This /ip firewall connection print ... shows that the IPsec stack has bound the connection properly to .163 but the firewall has src-nated it to .162.
So do prevent the masquerade rule from acting on ESP by adding a protocol=!ipsec-esp match condition to it as I've suggested in my previous post (it is not a 100% clean solution but good enough for this particular case and I don't want to overload you with details at this stage).
Where exactly to add this as i am bit now confused. If one of the IPSEC tunnel works, and other dont - how this will affect working one?
Since rules in the nat table only act on the first packet of each connection, you have to remove the existing src-nated ESP connection from the conntrack data after the modification:
/ip firewall connection remove [find where srcnat and protocol=ipsec-esp]
Tried to /ip firewall connection find [where srcnat and protocol=ipsec-esp] and no connections appeared in the search.
The next packet will re-create the tracked connection, but without the src-nat.
At worst it would cause a loss of several packets of the working one, until the Mikrotik would send a packet towards the client.Where exactly to add this as i am bit now confused. If one of the IPSEC tunnel works, and other dont - how this will affect working one?
Tried to /ip firewall connection find [where srcnat and protocol=ipsec-esp] and no connections appeared in the search.
At worst it would cause a loss of several packets of the working one, until the Mikrotik would send a packet towards the client.Where exactly to add this as i am bit now confused. If one of the IPSEC tunnel works, and other dont - how this will affect working one?
Thats not problem
Tried to /ip firewall connection find [where srcnat and protocol=ipsec-esp] and no connections appeared in the search.
There are syntactic errors in this command, so if you've entered it exactly this way, no wonder it has shown nothing.
Tried to adapt to see what i will be removing with this command line:
/ip firewall connection remove [find where srcnat and protocol=ipsec-esp]
So use /ip firewall connection print detail where srcnat and protocol=ipsec-esp .Tried to adapt to see what i will be removing with this command line:
Sindy could you explain again for me simply stupid what did fixed this my issue:So use /ip firewall connection print detail where srcnat and protocol=ipsec-esp .Tried to adapt to see what i will be removing with this command line:
But as it is working now, chances are high that this command will also show nothing because the NATed connection has expired in the meantime due to lack of any traffic updating it.
Yes correct i do not see anything.
To double check, use /ip firewall connection print detail where !srcnat and protocol=ipsec-esp , you should see the working connections.
Yes now i see traffic when pinging other side. Complete esp packets
The modification of the masquerade rule was necessary to prevent newly created ESP connections from getting src-nated.what did fixed this my issue:
That i removed all srn-nated connections ? Or that i have added this rule to my GW ?