Hi there, thanks for your insights.
Yes on the Azure side all routes (both instances) seem to be there (checking on NIC of the VM used for ping test). On the WatchGuard0 side we have indeed to active tunnels but if we enable both virtual interfaces only one gets the routes and one remains empty. That's when a ping from Azure fails to on-premises.
I added two images to show you this condition on the WatchGuard side fo things:
The BGP on WathGuard0 looks like below but indeed without a BGP router ID (interface) like the CISCO example has. WatchGuard mentions this for clustered setups but we have a single box in the lab. https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/dynamicrouting/bgp_configure_c.html I did try below with a router ID - Public IP address of the WatchGuard (PPOE). bgp router-id PUBLIC IP WatchGuard0 but no joy.
!
! The local BGP ASN is 10001
!
router bgp 10001
!
! to Azure VPC
!
! The Azure (remote) BGP ASN is 65515 and the VIF IPs (bgpPeeringAddresses) are !10.250.250.12 and 10.250.250.13
! These are the two parameters you must get from the Azure side.
!
neighbor 10.250.250.12 remote-as 65515
neighbor 10.250.250.12 ebgp-multihop
neighbor 10.250.250.12 activate
!
neighbor 10.250.250.13 remote-as 65515
neighbor 10.250.250.13 ebgp-multihop
neighbor 10.250.250.13 activate
!
! To advertise the local networks
!
network 192.168.2.0/24
network 172.16.100.0/24