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.

This is the configuration at the Mikrotik


/interface ethernet
set [ find default-name=ether2 ] disable-running-check=no name=lan1
set [ find default-name=ether1 ] disable-running-check=no name=wan
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256,3des hash-algorithm=sha256 name=site2site
/ip ipsec peer
add address=90.90.90.90/32 exchange-mode=ike2 local-address=90.90.90.85 name=mad.DOMAIN.com profile=site2site
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=8h name=site2site pfs-group=modp2048
/ip address
add address=194.194.194.194/18 interface=wan network=194.194.194.0
add address=192.168.30.1/24 interface=lan1 network=192.168.30.0
/ip dns
set servers=8.8.8.8,1.1.1.1
/ip firewall address-list
add address=XXXXXXXXXXX comment="Fixed IPs from FQDN" list=admin-access
add address=192.168.0.0/16 list=admin-access
add address=172.26.0.0/16 list=admin-access
add address=XXXXXXXXXXX comment="Fixed IP" list=admin-access
/ip firewall filter
add action=accept chain=forward comment="Aceptar tr\E1fico Established & Related" connection-state=established,related
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="Rechazar tr\E1fico Invalid" connection-state=invalid
add action=accept chain=input comment="Aceptar Ping Red Interna y Autorizadas" in-interface=wan protocol=icmp src-address-list=admin-access
add action=drop chain=input comment="Bloquear Ping Externo" in-interface=wan protocol=icmp
add action=accept chain=input comment="Aceptar Acceso Winbox IPs Autorizadas" dst-port=8291 protocol=tcp src-address-list=admin-access
add action=accept chain=input connection-state=new in-interface=wan protocol=ipsec-ah
add action=drop chain=input comment="Bloqueo Puertos Externo" connection-mark=!ipsec dst-port=21,22,23,80,443,8291,8728,8729 in-interface=wan protocol=tcp
/ip firewall mangle
add action=mark-connection chain=forward comment="Mark IPsec" disabled=yes ipsec-policy=out,ipsec new-connection-mark=ipsec passthrough=yes
add action=mark-connection chain=forward comment="Mark IPsec" disabled=yes ipsec-policy=in,ipsec new-connection-mark=ipsec passthrough=yes
add action=set-priority chain=postrouting new-priority=1 out-interface=wan passthrough=yes
/ip firewall nat
add action=accept chain=srcnat comment="MAD -> CLOUD" dst-address=192.168.40.0/24 src-address=192.168.30.0/24
add action=accept chain=srcnat comment="MAD -> CLOUD" dst-address=192.168.114.0/24 src-address=192.168.30.0/24
add action=accept chain=srcnat comment="CLOUD -> MAD" dst-address=192.168.30.0/24 src-address=192.168.40.0/24
add action=accept chain=srcnat comment="CLOUD -> MAD" dst-address=192.168.30.0/24 src-address=192.168.114.0/24
add action=masquerade chain=srcnat out-interface=wan
/ip ipsec identity
add peer=mad.DOMAIN.com
/ip ipsec policy
add comment="Subnet 192.168.40.0" dst-address=192.168.40.0/24 peer=mad.DOMAIN.com proposal=site2site src-address=192.168.30.0/24 tunnel=yes
add comment="Subnet 192.168.114.0" dst-address=192.168.114.0/24 peer=mad.DOMAIN.com proposal=site2site src-address=192.168.30.0/24 tunnel=yes
/ip route
add distance=1 gateway=194.194.194.1
/system clock
set time-zone-name=Europe/Madrid
/system identity
set name=Cloud-ROUTER
/system ntp client
set enabled=yes primary-ntp=162.159.200.123 secondary-ntp=95.216.78.223
/system package update
set channel=upgrade


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=*****

if yes, how to include the tunnel in the route?

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.

BOVPN is used by Watchguard firewalls for Branch Office VPN. The same as site to site VPN.

I've just added the line: /ip ipsec policy set [find peer=mad.DOMAIN.com] level=unique
and now everything is working.

I've to investigate the meaning of this line.

You saved me. GREAT THANKS SINDY !!!!

Found this info here -> https://wiki.mikrotik.com/wiki/Manual:IP/IPsec

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).

Thanks again Sindy

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.