I’ve one Mikrotik CHR and a Watchguard T55, both joined by a BOVPN that works perfectly. Devices on both networks can see each other.
On the Watchguard side I’ve also an IKEv2 VPN for remote users, these users can access the network on the Watchguard but when trying to ping, dns, … to the network on the Mikrotik side I don’t receive any answer.
Tunnels for both subnetworks are created on both sides, I can see the ping, dns, …. On the Mikrotik / Firewall / Connections so connections are clearly arriving to the Mikrotik. Also, I can see them passing through the Watchguard logs.
Anyone can help me? Need this traffic because the Active Directory is on the Mikrotik side.
Is there a route at the Mikrotik side via the Mikrotik-to-Watchguard tunnel towards the subnet/range from which the IKEv2 clients of the Watchguard get their addresses ? As you say you can see the incoming connections in /ip/firewall/connection/print output, firewall is not the issue.
The Mikrotik side has the subnet: 192.168.30.0/24
The Watchguard side has two subnets: 192.168.40.0/24 and 192.168.114.0/24. The 192.168.114.0/24 is for the IKEv2 VPN clients.
Between 192.168.30.0 and 192.168.40.0 devices at both sides can ping between them. With 192.168.114.0 no way.
sindy, should I add something like /ip route add dst-address=192.168.114.0/24 gateway=*****
As I’ve never heard the abbreviature BOVPN before (and still don’t understand what BO means there), it wasn’t clear to me at first place that the VPN tunnel between the Mikrotik and the Watchguard was an IKEv2 one as well, hence I’ve asked for the route.
But since the site-to-site VPN is actually a bare IPsec with policy matching, and since you say you can see connections from the remote users in Mikrotik firewall’s connection list, the only thing to come to my mind is that Watchguard doesn’t like shared security associations. If it is the case, /ip ipsec policy set [find peer=mad.DOMAIN.com] level=unique will make it work.
level (require | unique | use; Default: require) Specifies what to do if some of the SAs for this policy cannot be found: use - skip this transform, do not drop packet and do not acquire SA from IKE daemon; require - drop packet and acquire SA; unique - drop packet and acquire a unique SA that is only used with this particular policy. It is used in setups where multiple clients can sit behind one public IP address (clients behind NAT).
This desciption of the difference between require and unique only concentrates at the sending direction, so it doesn’t explicitly explain what is important for your case.
The thing is that the traffic selectors of IPsec policies are used not only by the sending peer to choose the packets to be sent via an SA, but also by the receiving peer to filter the received decrypted packets. And for some implementations/configurations (level=require) it is enough that the transport packet carrying the payload one being inspected came from the expected IP address via any SA, whereas for others (level=unique) it is necessary that the transport packet belonged to a particular SA. So when the policy level at Mikrotik side was set to require, Mikrotik was sending traffic matching to either policy via the same SA, whereas the Watchguard uses unique and drops packets that did not arrive via the particular SA.