Hi all,
so I have a setup that worked without problems for a few years. About 2 or 3 weeks ago I got a performance problem in one direction over EOIP tunnel.
The setup:
Router A is connected to Router B (I am on this end) via IPSEC tunnel und there is EOIP over IPSEC tunnel.
for performance reasons, I set enc-algorithms to null on IPSEC and it worked for a few years. Now with the same setup I get about
A to B 0.1Mbit
B to A around 4Mbit
when I turn encryption (for example enc-algorithms des or twofish)
I get
A to B around 1Mbit
I tested IPSEC tunnel (enc-algorithms des) with
/tool bandwidth-test <IPofIPSECtunnel> duration=10s protocol=tcp
and I get
A to B around 4Mbit
B to A around 6.5Mbit
I saw recommendation of setting MTU of EOIP to 1500, but it did not help.
On routers A and B with mtu=auto the actual-mtu is different...
Router A:
/interface eoip print
Flags: X - disabled, R - running
0 R name="eoip-tunnel1" mtu=auto actual-mtu=1280 l2mtu=65535 mac-address=xx:xx:xx:xx:xx:xx arp=enabled arp-timeout=auto
loop-protect=default loop-protect-status=off loop-protect-send-interval=5s loop-protect-disable-time=5m
local-address=192.168.99.2 remote-address=192.168.99.1 tunnel-id=10 dscp=inherit clamp-tcp-mss=yes dont-fragment=no
allow-fast-path=yes


Router B:
/interface eoip print
Flags: X - disabled, R - running
0 R name="eoip-tunnel1" mtu=auto actual-mtu=1396 l2mtu=65535 mac-address=bb:bb:bb:bb:bb:bb arp=enabled arp-timeout=auto loop-protect=default
loop-protect-status=off loop-protect-send-interval=5s loop-protect-disable-time=5m local-address=192.168.99.1 remote-address=192.168.99.2
tunnel-id=10 dscp=inherit clamp-tcp-mss=yes dont-fragment=no allow-fast-path=yes

similar Problem was posted in 2012:
viewtopic.php?t=59667
but without replies...
Firmare is 6.48.4 (stable) on both routers at the moment (updated the firware after the problem appeared, but it did not help)

I did a tcpdump on the computer connected to router B transfering something over the tunnel and got the following statistics: Router A:
https://pastebin.com/2jQx5BiQ
Router B:
https://pastebin.com/T6C6HsjP

What could I do to improve performance, why it worked for a few years and now does not work?
Thanks a lot

As you mention you use null encryption for performance reasons, what particular models are the two routers in question?

The thing is that so far all mysteries like this I've come across tracked down to packet loss, in some cases only the small second fragments of the transport packets were dropped. So sniffing at both WANs while testing should show that at once, but if the devices are weak, sniffing may affect results, and if they have small RAM, you may need to sniff externally.

thank you for the reply sindy!
both routers are RouterBOARD 941-2nD (hAP lite)
packet loss - I don't know, because
IPSEC tunnel seems to have the performance I need in both directions. (or the test with "/tool bandwidth-test <IPofIPSECtunnel> duration=10s protocol=tcp" does not prove it ?)
(A to B around 4Mbit,B to A around 6.5Mbit) (I need around 2-3 Mbit)
But EOIP tunnel on top of the IPSEC tunnel does not have the performance - but only in one direction...
And it is strange with the encryption as well. this is all happens in Europe (Germany) and not in China, so I don't think the internet provider is doing some DPI and messing with packets..

IPSEC tunnel seems to have the performance I need in both directions. (or the test with "/tool bandwidth-test <IPofIPSECtunnel> duration=10s protocol=tcp" does not prove it ?)

if the <IPofIPSECtunnel> is the private one inside the tunnel, then yes, it does prove it. However, there's a difference - with an L3 tunnel (bare IPsec), PMTUD usually works, so the TCP adjusts the MSS so that the transport packets could fit into the MTU; with an L2 tunnel, there is no way how to implement PMTUD, so fragmentation must take place if the MTU of the EoIP interface is 1500 - there's the EoIP overhead, and there is the IPsec overhead, so the transport packet carrying a payload one of 1500 bytes cannot fit into the 1500 byte MTU of the WAN (or even a smaller one if you use PPPoE as WAN).

this is all happens in Europe (Germany) and not in China, so I don't think the internet provider is doing some DPI and messing with packets..

My mom always says "don't look for evil intention where mere stupidity is a sufficient explanation". I've seen a case where the small second fragments were dropped between two data centers in Germany - as soon as the MTU has been reduced at the tunnel interface so that the transport packets wouldn't get fragmented, everything went fine.

I'd say set the MTU of the EoIP interfaces manually to 1280 at both devices, and try the bandwidth test again. Based on the result, we can move forward, but I'm afraid sniffing will be necessary in any case.

yes. <IPofIPSECtunnel> is the private one inside the tunnel on the other side.
I tried it with udp and get higher throughput, but lost packets (guess this is OK ?):
/tool bandwidth-test 192.168.99.1 duration=10s protocol=udp
status: done testing
duration: 11s
rx-current: 11.4Mbps
rx-10-second-average: 11.1Mbps
rx-total-average: 11.1Mbps
lost-packets: 448
random-data: no
direction: receive
rx-size: 1222
connection-count: 20
local-cpu-load: 49%
remote-cpu-load: 67%

with tcp:
/tool bandwidth-test 192.168.99.1 duration=10s protocol=tcp
status: done testing
duration: 10s
rx-current: 10.7Mbps
rx-10-second-average: 7.5Mbps
rx-total-average: 7.5Mbps
random-data: no
direction: receive
connection-count: 20
local-cpu-load: 80%

I set MTU of the EoIP interfaces manually to 1280 at both devices, but it did not help.

The way to measure with UDP and with TCP differs, with UDP it is best to limit the sending rate to the expected throughput, and you should see no lost packets if everything is OK. If you let the transmitting end to send with unlimited speed, you get some lost packets even if the network path is fine because the packets are dropped due to traffic shaping (bandwidth contract enforcement).

Since mere IPsec shows a decent throughput whereas EoIP, even with MTU limited to 1280 bytes, does not, I cannot see any other way than sniffing at both ends simultaneously to find out what really happens there. So check the amount of free space on the devices, and set an appropriate file limit for the sniffer:
/tool sniffer set file-name=routerX.pcap file-limit=1000 (the maximum file size value is in kilobytes)
then, start the TCP test, and while it is running, run
/tool sniffer quick ip-address=ip.of.the.remote.hAP ip-protocol=udp
at both devices.

Then download the files from both devices and compare, using Wireshark, what has been sent and what has been received. If no packets are missing at the receiving side, there's an issue with EoIP handling at the sending or the receiving Mikrotik. If some packets sent by the sending side did not make it to the receiving side, the ISP must have dropped them, and the question is why it doesn't like IPsec transport packets carrying EoIP and doesn't mind IPsec transport packets carrying other payload.

@sindy

i wish if i can get all your suggestion regarding troubleshoot for the tunnels & VPNs into website.
So i can easily read through

@sindy
thank you for the instructions, I did the sniffing, but it is difficult to make sense - too much packets.
I noticed, that like 50% (1467 out of 2946) from the packets have and the sequence seems always to be 1 off: and so on...

I also realized that I did not mention, that both mikrotiks are behind another router (each behind NAT from Fritzbox router)
And this could be important too. Found this:
https://avm.de/service/wissensdatenbank ... einsetzen/
"Der IPSec-Betriebsmodus "Authentication Header" (AH) kann nicht genutzt werden." - Fritzbox does not support AH mode (I understand that this is the mode without encryption? Then it is strange that it worked and does not work now. Firmware/Settings on the Fritzboxes was not changed)

/ip ipsec installed-sa print
Flags: H - hw-aead, A - AH, E - ESP
0 E spi=0x8AD5033 src-address=xx.xx.254.2:20224
dst-address=192.168.178.23:4500 state=mature auth-algorithm=md5
enc-algorithm=des enc-key-size=64
auth-key="87335axxxxxxxxca" enc-key="db2f6xxxxxxxxxxxx"
addtime=sep/21/2021 05:00:31 expires-in=16h56m2s
add-lifetime=19h12m18s/1d23s current-bytes=41263927
current-packets=40315 replay=128

1 E spi=0xC7E756 src-address=192.168.178.23:4500
dst-address=xx.xx.254.2:20224 state=mature auth-algorithm=md5
enc-algorithm=des enc-key-size=64
auth-key="0xxxxxxxxxxxxxxxxxx1f1" enc-key="5xxxxxx82xxxxxxxx5c"
addtime=sep/21/2021 05:00:31 expires-in=16h56m2s
add-lifetime=19h12m18s/1d23s current-bytes=5011718
current-packets=41066 replay=128

So, E means that this is ESP and not AH, so this is should be fine for Fritzbox, I guess ?
What are the alternatives that should also work, I can also do EOIP over pptp or sstp ?
(assuming that the provider or Fritzbox are messing with ESP)

If 1/2 of all ESP packets are marked duplicated, it's 99.9 % a measurement method error - I assume your WAN interface is a bridge, and the sniffer captures the same packet twice, once as it enters the bridge on the "bridge" interface between the router software and the bridge software, and another time as it leaves the bridge to the cable on the physical Ethernet interface. So you have to add interface=etherX, where etherX is the physical WAN interface connecting the Mikrotik to the Fritzbox, to sniffer's match conditions. The file format of the sniffer is still .pcap, not .pcapng, so you cannot filter the packets by interface name. You could use editcap but I think capturing once more with the additional filter will be simpler.

AH and ESP mainly differ in what part of the payload packet is protected by authenticity check, so AH cannot pass through NAT no matter what actual device implements the NAT. And yes, the E flag means ESP, so no need to worry about AH. In fact, to use AH, you'd have to explicitly ask for it when creating the policy. More than that, as soon as at least one of the peers is behind a NAT, the ESP gets encapsulated into UDP (I let you google up why is that), so you don't even need to worry about how Fritzbox deals with bare ESP.

So sniff once again as suggested above, and then watch for missing ESP sequence numbers again. If you find some, check whether they are only or the receiving side, which means a packet loss on the path between the devices, or whether they are also at the sending side, which means some minor bug (I've seen that on a CCR recently).

yes, the are bridges...
so I ran the sniffing with MTU 1290 und 1000 und get quite a lot Fragments, e.g. with MTU 1280: Length of 1290 is OK, I guess ? (for MTU 1000 it was 1010)
Do I need to set MTU 1280 on the bridges as well and maybe somewhere else too?
Stats show wrong seq. numbers of SPI for 99 packets out of 1149 looks like this: does it mean, that 13 packets were lost ?
will try to take a closer look at the dumps tonight...
Sindy, in case you have time/desire to take a look:
http://45.62.251.244:8000/routerB_1280.pcap
http://45.62.251.244:8000/routerA_1280.pcap

As you wrote that it worked before, I didn't study deep the configurations (or maybe I've missed them, or maybe you have added them to the OP later). It is better to attach configuration exports directly here, either as file attachments (which may require some karma) or into the body of the post, between [code] and [/code] tags - this works even for newbies. Whatever way is better than posting them on 3rd party sites that install their own cookies to give you even more advertisements.

After reading the configs, at least the mystery of the shrinking MTU is clear - the EoIP interface at one of the routers is a member port of the bridge (bridge1) through which the transport packets are sent, and the thing is that if the mtu of a bridge is set to auto, it accommodates to the smallest one of the MTUs of all member ports of that bridge, whereas if the mtu of an EoIP interface is set to auto, it adjusts its MTU to the MTU of the gateway interface of the route to remote-address, reducing it by 42 bytes if there is no active IPsec policy; if an IPsec with an established security association exists, it is reduced even more, taking into account the overhead of the SA and the MTU of the interface through which the transport packers of the SA are sent. So these two mtu=auto form up a self-locking loop, which only doesn't get down to 0 bytes of MTU because 1280 is some magic number in the code and after reaching it, the EoIP's MTU stops shrinking further.

So this explains why, although the actual MTU of the Ethernet interface facing to the Fritzbox is 1500, the 1280-byte TCP packets encapsulated into GRE, ESP, UDP, and IP are sent as two frames, 1290 and 150 bytes.

L2 tunneling is almost always a bad idea. L2 tunneling via the same L2 segment you are tunneling is an even worse idea, for the reason above.

You can break the loop by setting the mtu of both bridge1 and eoip-tunnel1 to 1500 manually, knowing that the IPsec-encapsulated EoIP transport packets will get fragmented. You can not set a smaller MTU on the EoIP while it is a member of the bridge, as it would mean that packets that fit to the bridge wouldn't fit into the EoIP and would bet dropped.

So I'd try the above (manual setting of MTU to 1500 at both bridge1 and eoip-tunnel1) as the second step; in the first step, I'd reconsider whether it wouldn't be possible to separate the L2 segment that needs to be tunneled from the LAN of the Fritzbox.

The RB941s seem to have tough time, as there are fragments missing in the pcap from the sending side but present in the pcap from the receiving side, which means that the capturing was the problem, not the actual sending of these fragments. So we cannot take the captures seriously enough to make some deep conclusions.

so, I tried with MTU 1500 everywhere, on Router A on Router B: speed did not really improved.
dumps:
http://45.62.251.244:8000/routerB_1500.pcap
http://45.62.251.244:8000/routerA_1500.pcap
what is interesting, is that the packet size is now different - on Router B the largest packet is 770, on Router A - 1514
so, somewhere MTU is different ?

I also tried removing eoip-tunnel1 from bridge1,. assigned an IP to eoip-tunnel1 and did src NAT - speed was the same.
you mention, that L2 tunnelling is a bad idea. For my purposes L3 or maybe even L4 will also work.
here is the setup I have:
MikrotikA < WiFi > FritzboxA <-> Internet <-> FritzboxB <-LAN Cable-> MikrotikB <-LAN Cable ether4-> Device B
so, I would like that the Device B gets DHCP and goes to internet with public IP of FritzboxA and can access devices on the A side.
Is it possible to do L3 tunnel ? How ? (or what would be a solution?)
Is it possible to run dhcp server on ether4, then src-nat to 192.168.99.1 (IPSEC RouterA), firewall rule (?) to forward traffic to 192.168.99.2 (IPSEC RouterB) und src-nat to IP of RouterB ?

I guess I could also connect MikrotikB to FritzboxA directly over "IPSec Xauth PSK", but I have not found a good howto for this...
(viewtopic.php?t=121258 not really helpful)

What I still don't understand, why performance over IPSEC is OK, but not over EOIP...

what is interesting, is that the packet size is now different - on Router B the largest packet is 770, on Router A - 1514
so, somewhere MTU is different ?

I have no clue whether this happens due to different MTU as such, but something on the path between the routers indeed does fragment the packets in another way. An ESP packet with SPI 0x0c6f3159 and sequence number 97155 is sent as a 1514-byte frame carrying the first fragment and a 150-byte fragment carrying the second and last one from router A, and it arrives to Router B as three frames - a 770-byte one, a 778-byte one, and a 126-byte one. So something between Router A and Router B reassembles the original packet and fragments it in this weird way. Especially the fact that the first two fragments have a different size puzzles me.

I also tried removing eoip-tunnel1 from bridge1,. assigned an IP to eoip-tunnel1 and did src NAT - speed was the same.

As said - since the routers have problems with sniffing, I'm afraid the CPU load during the test is too high, so anything can happen. The manual explicitly prohibits using bandwidth-test on the router whose throughput capability you test, so using an external device (another router or a Linux/Windows machine with iperf) at both ends would remove this doubt.

you mention, that L2 tunnelling is a bad idea. For my purposes L3 or maybe even L4 will also work.

here is the setup I have:
MikrotikA < WiFi > FritzboxA <-> Internet <-> FritzboxB <-LAN Cable-> MikrotikB <-LAN Cable ether4-> Device B
so, I would like that the Device B gets DHCP and goes to internet with public IP of FritzboxA and can access devices on the A side.
Is it possible to do L3 tunnel ? How ? (or what would be a solution?)

Routing the traffic from device B to internet via Router A using an L3 tunnel is simple. Getting access to devices at A side via an L3 tunnel is simple too if it doesn't matter that Device B's address is not from the LAN subnet used at A side (no idea what kind of traffic you plan to tunnel, some niche protocols need L2 transparency as they are not intended to be used outside LAN segments). But a DHCP server at A side assigning address(es) to client(s) at B side makes little sense without an L2 tunnel. Plus I'm not sure how DHCP relay works on Mikrotik via a routed tunnel.

Is it possible to run dhcp server on ether4, then src-nat to 192.168.99.1 (IPSEC RouterA), firewall rule (?) to forward traffic to 192.168.99.2 (IPSEC RouterB) und src-nat to IP of RouterB ?

I don't understand this idea at all. The DHCP client broadcasts the DHCPDISCOVER request, so it cannot be routed from B side to A side without the help of a DHCP relay, but even if it worked, the address assigned to the client cannot be from the same subnet like addresses assigned to clients at A side as otherwise an L2 tunnel would be necessary. Or, better to say, it could be done but it would involve so much static configuration that it would be much easier to assign the address to the client at B side also statically.

I guess I could also connect MikrotikB to FritzboxA directly over "IPSec Xauth PSK", but I have not found a good howto for this...
(viewtopic.php?t=121258 not really helpful)

That would be an L3 tunnel anyway, so it only makes sense if you use Mikrotik A solely to build the tunnel, as a "greener" solution.

What I still don't understand, why performance over IPSEC is OK, but not over EOIP...

Nor do I. Start from moving the test generator and responder out from the two 941s, which should allow us to sniff both the TCP payload and the ESP transport without missing packets in the sniff.

Routing the traffic from device B to internet via Router A using an L3 tunnel is simple.

could you please elaborate ? I think this is all I need.

I don't understand this idea at all. The DHCP client broadcasts the DHCPDISCOVER request...

Sorry I was not clear - the DHCP Server does not have to be on the A side, would be OK if it is on the B side, or actually I could even set the IP manually on the Device B.

Start from moving the test generator and responder out from the two 941s

I did not use test generator/responder, when doing "sniffs" - I just generated some traffic from Device B...
I could also probably try to sniff the traffic on the Fritzboxes - they provide such functionality, then it would be hopefully be clear who fragments the packets.
But before I do this, I would like to try the L3 Solution.... (please see above)

have you tried other tunnels?
if you really need to be bridged,then you can play with BCP,and compare the result

could you please elaborate ? I think this is all I need.

OK. Remove ether4 from the bridge at Router B, assign an address to it, like 192.168.77.1/24, and either assign 192.168.77.2/24 manually to Device B with 192.168.77.1 as a default gateway, or set up the complete /ip dhcp-server stuff at Router B (/ip pool, /ip dhcp-server network, /ip dhcp-server linked to ether4).

As Router B acts as a responder, at Router B:
/ip ipsec policy
add dst-address=192.168.77.0/24 src-address=192.168.77.0/24 action=none
add dst-address=0.0.0.0/0 group=ike2-gre proposal=ike2-gre src-address=192.168.77.0/24 template=yes

At Router A, add a mirror policy, but not as a template:
/ip ipsec policy
add dst-address=192.168.77.0/24 group=ike2-gre peer=xxx8 proposal=ike2-gre src-address=0.0.0.0/0 level=unique tunnel=yes

I remember there was some protection of the router acting as responder from losing connectivity if dst-address of a generated policy would be 0.0.0.0/0, but I hope it only kicks in if the src-address is 0.0.0.0/0 as well. If the policies don't come up, there is a solution to bypass that protection.

Then, add a masquerade rule as the first (topmost) one:
chain=srcnat src-address=192.168.77.0/24 action=masquerade
(it could be done better, but it's a proof of concept with the minimum required changes, so first check whether it works like this, then clean up the configuration of Router A, and then eventually make the srcnat chain more elegant).

after

At Router A, add a mirror policy, but not as a template:
/ip ipsec policy
add dst-address=192.168.77.0/24 group=ike2-gre peer=xxx8 proposal=ike2-gre src-address=0.0.0.0/0 level=unique tunnel=yes

IPSEC tunnel is getting killed and the error message in log:
ipsec,error responder selectors does not match my policy

routing from router A with source traffic from 192.168.77.0/24 to router B does not need to be configured ? This will be done via ipsec policy ?

IPSEC tunnel is getting killed and the error message in log:
ipsec,error responder selectors does not match my policy

What does the log say at the same time on Router B? And show me the output of /ip ipsec policy export from RouterB. It can either be caused by a policy template misconfiguration at Router B or it's that "we know better than you what you actually want" protection I've mentioned before.

routing from router A with source traffic from 192.168.77.0/24 to router B does not need to be configured ? This will be done via ipsec policy ?

192.168.77.0/24 is supposed to be on Router B, so I suppose you had in mind "routing from router A towards 192.168.77.0/24 via the tunnel to router B".

The answer is "yes, but". The traffic selectors of IPsec policies indeed intercept matching packets and send them down the SA associated to the policy; however, the packets must first be routed "somewhere" in order that they could reach the TS matching stage, as TS matching is one of the last steps of packet processing, after "normal" routing and even NATing. But this pre-requisite is met here, as you have a default route on both routers and no type=blackhole routes, so every packet is always routed "somewhere".

What does the log say at the same time on Router B?

12:25:49 ipsec,info,account peer authorized: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:c0ed8b0caab3c720:3e5c98fcd461edb4
12:25:49 ipsec,info killing ike2 SA: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:c0ed8b0caab3c720:3e5c98fcd461edb4
12:25:50 ipsec,info new ike2 SA (R): 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:127336d174ad36cb:2ac5acb8b98e464f
12:25:50 ipsec,info,account peer authorized: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:127336d174ad36cb:2ac5acb8b98e464f
12:25:50 ipsec,info killing ike2 SA: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:127336d174ad36cb:2ac5acb8b98e464f
12:25:51 ipsec,info new ike2 SA (R): 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:3c39e561001bf5cf:07e7ff51b2b8e939
12:25:51 ipsec,info,account peer authorized: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:3c39e561001bf5cf:07e7ff51b2b8e939
12:25:51 ipsec,info killing ike2 SA: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:3c39e561001bf5cf:07e7ff51b2b8e939
12:25:52 ipsec,info new ike2 SA (R): 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:52ad431e1a14c780:3be9ea07384574f7
12:25:52 ipsec,info,account peer authorized: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:52ad431e1a14c780:3be9ea07384574f7
12:25:52 ipsec,info killing ike2 SA: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:52ad431e1a14c780:3be9ea07384574f7
12:25:54 ipsec,info new ike2 SA (R): 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:b542072372b2fbf8:5619bf6b3529f019
12:25:54 ipsec,info,account peer authorized: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:b542072372b2fbf8:5619bf6b3529f019
12:25:54 ipsec,info killing ike2 SA: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:b542072372b2fbf8:5619bf6b3529f019
12:25:56 ipsec,info new ike2 SA (R): 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:4ca1b336f122b61a:99723d5d5efcb6a5
12:25:56 ipsec,info,account peer authorized: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:4ca1b336f122b61a:99723d5d5efcb6a5
12:25:56 ipsec,info killing ike2 SA: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:4ca1b336f122b61a:99723d5d5efcb6a5
12:25:57 ipsec,info new ike2 SA (R): 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:0d718a0650da4bd2:c6d2f55e92f3452f
12:25:57 ipsec,info,account peer authorized: 192.168.178.23[4500]-92.117.xx.yyy[4500] spi:0d718a0650da4bd2:c6d2f55e92f3452f
and so on

Router A:
2:25:43 ipsec,info new ike2 SA (I): 192.168.188.86[4500]-77.12.xxx.zz[4500] spi:42d1763408753b60:1062abad9f7db527
12:25:43 ipsec,info,account peer authorized: 192.168.188.86[4500]-77.12.xxx.zz[4500] spi:42d1763408753b60:1062abad9f7db527
12:25:43 ipsec,error responder selectors does not match my policy
12:25:43 ipsec,info killing ike2 SA: 192.168.188.86[4500]-77.12.xxx.zz[4500] spi:42d1763408753b60:1062abad9f7db527
12:25:44 ipsec,info new ike2 SA (I): 192.168.188.86[4500]-77.12.xxx.zz[4500] spi:c60f033f68e89416:9f83173ccfe4f5a3
12:25:44 ipsec,info,account peer authorized: 192.168.188.86[4500]-77.12.xxx.zz[4500] spi:c60f033f68e89416:9f83173ccfe4f5a3
12:25:44 ipsec,error responder selectors does not match my policy
12:25:44 ipsec,info killing ike2 SA: 192.168.188.86[4500]-77.12.xxx.zz[4500] spi:c60f033f68e89416:9f83173ccfe4f5a3

/ip ipsec policy export from RouterB

/ip ipsec policy group
add name=ike2-gre
/ip ipsec policy
add dst-address=192.168.99.2/32 group=ike2-gre proposal=ike2-gre src-address=192.168.99.1/32 template=yes
add action=none dst-address=192.168.77.0/24 src-address=192.168.77.0/24
add dst-address=0.0.0.0/0 group=ike2-gre proposal=ike2-gre src-address=192.168.77.0/24 template=yes

/ip ipsec policy print
Flags: T - template, B - backup, X - disabled, D - dynamic, I - invalid, A - active, * - default
# PEER TUNNEL SRC-ADDRESS DST-ADDRESS PROTOCOL ACTION LEVEL PH2-COUNT
0 T * ::/0 ::/0 all
1 T 192.168.99.1/32 192.168.99.2/32 all
2 192.168.77.0/24 192.168.77.0/24 all none
3 T 192.168.77.0/24 0.0.0.0/0 all




Router A:

/ip ipsec policy group
add name=ike2-gre
/ip ipsec policy
add dst-address=192.168.99.1/32 group=ike2-gre proposal=ike2-gre src-address=192.168.99.2/32 template=yes
add dst-address=192.168.77.0/24 level=unique peer=xxx8 proposal=ike2-gre sa-dst-address=77.12.xxx.zz sa-src-address=0.0.0.0 src-address=0.0.0.0/0 tunnel=yes

/ip ipsec policy print
Flags: T - template, B - backup, X - disabled, D - dynamic, I - invalid, A - active, * - default
# PEER TUNNEL SRC-ADDRESS DST-ADDRESS PROTOCOL ACTION LEVEL PH2-COUNT
0 T * ::/0 ::/0 all
1 T 192.168.99.2/32 192.168.99.1/32 all
2 xxx8 yes 0.0.0.0/0 192.168.77.0/24 all encrypt unique 0

OK, so as the first step, replace 0.0.0.0/0 in the src-address of the policy on Router A by 0.0.0.0/1. If that helps, we may move further in that direction, otherwise disable that added policy at Router A, do /system logging add topics=ipsec,!packet at Router B, run log print follow-only file=ipsec-start where topics~"ipsec" there, enable the policy at Router A, wait for the error to appear twice at Router A, then stop (Ctrl-C) the /log print ... at Router B, download the file and see what it didn't like about the TS proposed by Router A.

replace 0.0.0.0/0 in the src-address of the policy on Router A by 0.0.0.0/1.

huhu!! it worked

Okay, so it means it was caused by the Dummkopf protection. Therefore,
/ip ipsec policy add copy-from=[find src-address=0.0.0.0/1] src-address=128.0.0.0/1
is the remaining step in that direction, to cover the other half of the internet.

so, it worked - but still slow
I tested from ping from routerA to public IP of routerB and it turns out there is about 20-25% packet loss over wifi
sent=20 received=15 packet-loss=25% min-rtt=17ms avg-rtt=201ms max-rtt=882ms
sent=26 received=20 packet-loss=23% min-rtt=17ms avg-rtt=216ms max-rtt=882ms

so this could be the reason for the slow connections...
I will go to the location A and will try to place the router to get a better reception. It is strange that it worked for a few years without any problems. Maybe some other router is interfering on the same channels now...

It is strange that it worked for a few years without any problems.

This is not as strange as the fact that it worked when you tested IPsec alone at the time when the EoIP already had problems.

Maybe some other router is interfering on the same channels now...

/interface wireless scan wlan1 background=yes will show that quickly. Just bear in mind that the 2.4 GHz channel numbering matches 5 MHz channels whilst 20 MHz channels are typically used, so if your channel is N, all channels from N-3 to N+3 cause interference; if the interfering channel is also N, the situation is not that bad because the networks can understand each other's control packets and coexist, whilst if the competing channel is different, it's pure noise so no way to coordinate the use of the channel.

so - I gave up and configured the connection between 2 Frtizboxes according to https://avm.de/service/vpn/praxis-tipps ... inrichten/
it has advantage, that the "weak" wifi-link is not being used.
Speed is now around 4Mbit - more than I need.
sindy, thank you very much for the support!!!
I think we could have found the issue, but it would take a lot of time and it is not clear if I would be able to fix it in case the issue is with the providers, it all worked before, so I think it could be that the issue is not on my side.