Hello,

I have two Mikrotik routers, each one has its own Local bridges, i.e.:

Router 1: bridge A, bridge B
Router 2: bridge C, bridge D

I have an EoIP tunnel between both routers that allows me to have some 'bridge A' ports on Router 2.
Now I'd like to have also some 'bridge B' ports on Router2 too.

Which is the proper way to do so?

Setting up another EoIP tunnel?
Maybe another tunnel inside the EoIP tunnel (I'm afraid of MTU)?

Thanks,

Another EoIP tunnel with the same endpoint IP addresses and different tunnel-id value is the right solution. If you have configured ipsec-secret for the first tunnel, you don't need to configure it for the second one if you keep same IP addresses at both ends, but for the sake of security, make sure that the GRE packets carrying EoIP will not be sent via the default gateway so that they don't leak in plaintext if the IPsec tunnel is not up.

Hi sindy,

Thank you very much for the input.
I'll try it tomorrow and let you know if it works.

Many thanks!

Two things I don't understand.

a. why not EOIP over wireguard
b. why not forget eoip+ipsec or eoip+wireguard and simply use zerotier??

Two things I don't understand.

a. why not EOIP over wireguard
b. why not forget eoip+ipsec or eoip+wireguard and simply use zerotier??

For example, I do not want to be dependent on another - a third side in communications !

Two things I don't understand.

a. why not EOIP over wireguard
b. why not forget eoip+ipsec or eoip+wireguard and simply use zerotier??

For example, I do not want to be dependent on another - a third side in communications !

EOIP over wireguard is not using a third party !!

For example, I do not want to be dependent on another - a third side in communications !

EOIP over wireguard is not using a third party !!

I'm talking about a zerotier that you offer us all the time .

EOIP over wireguard is not using a third party !!

I'm talking about a zerotier that you offer us all the time .

IM not offering up zerotier its just if more people try it maybe then can tell me how to config the EFFING thing.
By the way in case mozerd comes by, I think we should all use tailscale!!

Another EoIP tunnel with the same endpoint IP addresses and different tunnel-id value is the right solution. If you have configured ipsec-secret for the first tunnel, you don't need to configure it for the second one if you keep same IP addresses at both ends, but for the sake of security, make sure that the GRE packets carrying EoIP will not be sent via the default gateway so that they don't leak in plaintext if the IPsec tunnel is not up.

Hello everyone,

I've set up a second EoIP tunnel between both routers as sindy suggested; it works flawlessly !

However I still have a couple of questions:

-Why is it not needed to activate IPsec on this second tunnel? (remote IP adresses on the tunnels are public IP adresses)

-I've currently set up an IPsec secret for this second EoIP tunnel (a different IPsecret from the first tunnel), because I'm worried about sending data in plain text. However, in Winbox when I look at IP>IPSec, I only see one policy, one identity, one peer... -the ones that were created when I build the first tunnel-. Is this normal?

-Why should I run this tunnel over Wireguard ?

Thanks!

Well, for most new folks wireguard is much easier to setup.
However you seem to have no issues with IPSec and thus no reason for you to change.

-Why is it not needed to activate IPsec on this second tunnel? (remote IP adresses on the tunnels are public IP adresses)
...
- in Winbox when I look at IP>IPSec, I only see one policy, one identity, one peer... -the ones that were created when I build the first tunnel-. Is this normal?

Your second question is the answer to the first one. For most use cases, it is enough to have a single "control" IPsec session between two devices, hence a single active peer. And the EoIP tunnels use GRE as transport protocol, so the source and destination addresses as well as IP protocol are the same for transport packets of both tunnels; the tunnel-id that differentiates the two tunnels from one another is transported in the GRE headers. So as far as the traffic selector of the IPsec policy can say, there is no difference between the transport packets of the two tunnels, because it is unable to look into the GRE headers.

-Why should I run this tunnel over Wireguard ?

I'll disagree a bit with @anav here - the complexity of IPsec settings is not the reason here.

No complexity whatsoever is associated with using IPsec to encrypt EoIP as long as you are happy with the automatically generated settings, which use IKE(v1), pre-shared key authentication, and default encryption and message authenticity algorithms - it is enough to fill in a single field with a decently random secret. However, things turn more complex as soon as you want more.

First, probably the most interesting one for most Mikrotik users, Wireguard uses a cipher that is very efficient CPU-wise, so even on weak devices with no hardware encryption engines, you can get decent speeds of the tunnel while there's still CPU power left for the other tasks. For some reason, this encryption algorithm is not available for IPsec, at least in RouterOS 6.x.

Second, a pre-shared key has an intrinsic vulnerability - you have to set it up using an already encrypted channel, otherwise someone may intercept it. So nothing wrong about it if you configure both devices on your table before sending them to the actual place of deployment, but if you configure the devices remotely, there is a theoretical chance someone might decipher the configuration session and extract the key from it. You can use non-symmetric cryptography for IPsec authentication, but it requires use of certificates for IKEv2; for the original IKE (v1), the private/public key pair can be used directly too but this way is not widely supported. In Wireguard, a direct private/public key pair is the default authentication method.

Third, Wireguard can deal with change of the transport IP address at one peer without any renegotiation, which is computationally complex for a good reason. So if one of your devices is on a dynamic address, you have shorter dropouts with Wireguard. IPsec can do this too but unless something has changed recently, not on Mikrotik.

Last, configuration of Wireguard indeed requires less knowledge because almost nothing is variable. So the less options available, the less configuration needed. Of course, this lack of options can be considered both an advantage (simpler configuration) and a drawback (game over as soon as someone breaks the only ciphering algorithm available).

Thanks for the clarification Sindy, and the confirmation that WG is the way to go.