This typically includes a supernet (summary address) and its individual subnets. For example, when advertising the networks of 192.168.10.0/24 and 192.168.20.0/24, the supernet would be 192.168.0.0/19. Once the VPN configuration has been completed on Microsoft Azure, check the address space(s) designated to traverse the VPN tunnel. One of the most common site-to-site VPN issues between a Cisco Meraki appliance and Microsoft Azure is caused by mismatched local/remote subnets, as described above. May 8 07:23:43 VPN msg: phase1 negotiation failed. May 8 07:23:53 VPN msg: no suitable proposal found. May 8 07:23:53 VPN msg: failed to get valid proposal. Here is an example log entry of a phase 1 failure: Review the event log for entries that indicate there has been a failure during phase 1 or 2 negotiation. The following log entries show a successful VPN connection between the MX (IP: 1.1.1.1) and a Non-Meraki VPN device (IP:2.2.2.2): A specific time range can also be defined to narrow the results if you need to know the specific time the issue occurred.
Select the All Non-Meraki / Client VPN event log type as the sole Event type include option and click on the search button. NOTE: The information from this point forward in this article only applies to Non-Meraki VPN Connections running firmware prior to MX15.12Įvent logs can be displayed from Network-wide > Monitor > Event log.
0 kommentar(er)
