- Router A (RB4011)
Router B (MikroTik CHR on VPS)
Router C (RB3011)
Some time ago, after adding a "clean" IPsec tunnel to Router A, some strange things started to happen on that Router with different IP-IP / IPsec tunnel between Router A and B. As it turns out, this is not the fault of the additional tunnel or ISP provider I suspected (I thought so)
Ping between them (172.16.16.4/30) stopped working.
Everything worked and suddenly stopped.Ping timeout
The first solution, as it turned out, mikrotik has the `Detect Internet` option and by default discovery went to the` ip-mt-up` interface, i.e. an IP interface with a tunnel and address 172.16.16.6. After modify the Interface List properly the tunnel started working ... but only 2 days.
Then again the problem.
Here the problem turned out to be more serious but for some reason (trial and error method) I moved the IP-IP / IPsec tunnel on Router A from the address that ends on x.179 => to x.180. Updating changes on Router B after that to the new IP of Router A. It started working. Ping passed, OSPF was back and running. Awesome. Another 2 days passed ..
... and again.. it collapsed.
Here I could not figure out what was going on.
Yesterday, however, I decided to move public Router A to the newly created interface bridge `bridge_net`, I added the ether1 interface to bridge_net. I switched SNAT on out-interface to bridge_net with an indication of the public address ending 178 (as it was) and still nothing, not working
At the same time, I did the same on Router C. Which is...
1. I added bridge_net and shifted the public IP with the 154 end to bridge_net and added ether1 to bridge_net. Changed SNAT of entry.
2. I added a second public IP with the 155 end and switched the configuration in IPIP/IPsec configuration to connect 155 end (instead of previous 154) to 73 (Router B Address End) and on Router B the same but in the opposite way. Changing the remote-address from 154 to 155. Of course, everything worked out well ... until... read below[/list]
I returned to Router A again and here I moved back again from 180 end => to 179 end and ... The tunnel works (sic!), Ping passes. Hip Hip Huray? Not necessarily. After this action, Pinging between Router B and C (172.16.16.0/30) stopped working suddenly (this is when I said `Read Below` ). So one worked, the other stopped.
I will add only that when I disable just IPsec on that tunnel ping starts working again. I attach IPsec back again & it stops. I had the same for Router A and B.
I have the impression that adding another public causes some random problem on one side when communicating with Router B. Any comments, suggestions are welcome. Maybe I skipped something, lack of information, so please help.
In case of config I can drop the config using gist.guthub but I haven't done it yet. I added a Graph.
I did not take anything into account, so I think that the more experienced company from me of this group is able to indicate the reason and what needs to be improved.
Router A (IP x.179) => Router B / Ping does not work
Router A (IP x.180) = => Router B / Ping works 2 days
Adding another public ping IP on Router C works
Router A (IP x.179) => Router B / Ping works again (as in point 1) but stops working on Router C
Maybe I shouldn't support so many tunnels on Router B which has Only ONE public IP address ? That Router operate with two, different, VPN (IPsec IKEv2) tunnels connected with Google Cloud Platform and that works also. So Basically he has 4 VPN. 2x IP/IPsec and 2x Clear IPsec.