Hi Marek Community. I have today set up four Non-Meraki Peer Site to Site VPNs into AWS. All four VPNs are showing status green and are conveying constant pings requests from our main site into instances within each of the four VPNs. The problem is that the Event Log is constantly reporting negotiation errors, despite the fact that the VPN paths are successfuly carrying ping traffic. I have attached a screen shot of the event log for reference. It appears to be an issue within the phase 1 negotiation but I am assuming the key life periods etc are all aligned since the configuration is set by the AWS template. Any support would be gratefully received. ... View more

Hi all in Meraki Community. I am running a site to site VPN with a non Meraki device at the distant end. The device in question is a virtual VPN server on AWS running on StrongSwan software. The VPN is working fine although I often get the following message appearing in the logs    Non-Meraki / Client VPN negotiation msg: pfkey DELETE failed: No such process   Can anyone interpret this message ?   With Thanks.   Mel ... View more

Hi Community I hope someone can help.   I have a non meraki peer site to site VPN into AWS. The AWS end is not a standard customer gateway so the AWS template was not applicable.   The VPN is up and running with no issues when accessed from within the main subnet 192.168.100.0/24 The distant end subnet is 172.16.0.0/12   However if I try to access the resources at 172.16.0.0/12 from my home via the Client VPN (Windows 10 inherent Client VPN) I cannot see any of them. The client VPN subnet is 192.168.101.0/24   Initially I could not see anything in the main subnet either except singularly the meraki firewall on 192.168.100.1. The help documentation states that all of the main subnet should be accessible from the client vpn subnet. The only way I gained access to the whole main subnet via the client vpn was by adding an outgoing firewall rule enabling source 192.168.101.0/24 to destination 192.168.100.0/24. I suspect this is masking an incorrect setting but would welcome suggestions.   I read previous community dialogue that revolved around checking that the client VPN subnet and main subnet were both enabled for VPN. They always have been in my case so that is not the issue.   Packet Captures have helped a bit but also are misleading. For example if I am in the office running constant ping 192.168.100.200 to 172.16.13.221 they receive successful echo returns. When I tracert this path from 192.168.100.200  it shows >>>192.168.100.1 >>>>172.16.1.16>>>172.16.13.221 When I run packet captures I see the ICMP traffic in both directions at LAN but nothing on site to site VPN. I know it must be passing through the VPN however as the pings are successful. (I have raised that question on a separate article)   If I run contant ping from home via the client VPN I see echo requests at Client VPN originating from 192.168.101.32 (my allocated IP address on the client vpn subnet, but no corresponding echo returns which is not surprising as the pings are failing. When I look for packet captures on the site to site vpn no traffic is visible. Here is a strange thing, the meraki support engineer tells me that when he accessed the network over a client VPN that I set up for him, he could see the ping requests from 192.168.101.151 on the site to site vpn but no echo returns. His conclusion is that something is amiss at the distant end and I don't doubt this. However I cannot understand how I never see packet captures on site to site VPN interface either when pings are originating from the main subnet or client VPN subnet  Incidentally I have not generated any additional VLANs   Still waiting on further messages from Meraki Support but any advice would be greatly appreciated. I am still suspecting that a fundamental setting is wrong, based on having to set a firewall rule to allow the client VPN subnet access to the main subnet.  ... View more

I have a non-meraki peer site to site set up consisting of a MX64 at our office and a AWS instance containing StrongSwan software. The site to site works perfectly but people connecting into the office via client VPN cannot see resources on the distant end of the site to site VPN.   I have been using packet captures to diagnose the  and came across a strange situation. When I run constant ICMP Ping from within the office to a device at the distant end of the S2S VPN I see packet captures on the LAN but nothing when monitoring on site to site VPN. I know the pings are passing through because echo returns are being relayed back.   Why am I not seeing the packets when they must be there as the pings are 100% successful and the only path open is the site to site VPN. ... View more

. I get very little info from the VPN monitor facility, only a green dot depicting a healthy VPN. There are no stats Throughput and Latency or other info. Does that info only come with Meraki Auto VPNs ie a Meraki device at both ends. I have glanced at some literature that refers to VPN registers but again I think this involves Meraki - Meraki VPNs.   2. Having set up a client VPN link for working from home I am trying to get access to the site to site VPN. I initially set up a firewall rule to allow the VPN subnet access to the main subnet. That allowed my PC at home access to every resource within our main office. When I tried adding the subnet at the distant end of the site to site VPN I fail to get access to the resources at the VPN distant end   First setting VPN subnet 192.168.101.0/24 ------------- Main Subnet 192.168.100.0/24  OK : can see all local resources   Second Setting 192.168.101.0/24 ------------ 192.168.100.0/24, 172.16.0.0/12 (added distant subnet) : Can still see main subnet but no access to distant subnet.   Both Main and VPN Subnet are enabled.   A tracert does not get past the MX 64 which suggests it is a firewall rule issue. You can see from the settings above that I tried to inclide the VPN subnet in the forwarding rules but to no avail   Any advice would be great ... View more

Hi. I am new to the Meraki Community having just installed a Meraki MX64 Security Device. I am experiencing problems with the single site to site VPN that I set up involving a non-meraki device at the other end. I am getting continuous reports in the Events Log suggesting that the ipsec process is failing at phase 1 (see below screen shot)   Oct 3 18:23:02   Non-Meraki / Client VPN negotiation msg: phase1 negotiation failed. Oct 3 18:23:02   Non-Meraki / Client VPN negotiation msg: failed to pre-process ph1 packet (side: 1, status 1). Oct 3 18:23:02   Non-Meraki / Client VPN negotiation msg: failed to get valid proposal. Oct 3 18:23:02   Non-Meraki / Client VPN negotiation msg: no suitable proposal found. Oct 3 18:22:20   Non-Meraki / Client VPN negotiation msg: phase1 negotiation failed. Oct 3 18:22:20   Non-Meraki / Client VPN negotiation msg: failed to pre-process ph1 packet (side: 1, status 1). Oct 3 18:22:20   Non-Meraki / Client VPN negotiation msg: failed to get valid proposal. Oct 3 18:22:20   Non-Meraki / Client VPN negotiation msg: no suitable proposal found. Oct 3 18:21:57   Non-Meraki / Client VPN negotiation msg: phase1 negotiation failed. Oct 3 18:21:57   Non-Meraki / Client VPN negotiation msg: failed to pre-process ph1 packet (side: 1, status 1). Oct 3 18:21:57   Non-Meraki / Client VPN negotiation msg: failed to get valid proposal. Oct 3 18:21:57   Non-Meraki / Client VPN negotiation msg: no suitable proposal found. Oct 3 18:21:44   Non-Meraki / Client VPN negotiation msg: phase1 negotiation failed. Oct 3 18:21:44   Non-Meraki / Client VPN negotiation msg: failed to pre-process ph1 packet (side: 1, status 1). Oct 3 18:21:44   Non-Meraki / Client VPN negotiation   Despite these logs the VPN is successfully passing traffic in both directions.   Another issue is the VPN status does not display any data such as throughput or connectivity. I read an article that described available stats but I could not ascertain if they are only available with auto VPN ie Meraki to Meraki links.   Any help or advice would be greatly appreciated.                             ... View more