Tunnel its up.  I didnt need to add remote peer ID.  Settings i posted all worked.   Thank you all for your replies. ... View more

Thank you, we are going to try it again next Wednesday as it is a live system. We currently have a tunnel but use IKEv1 and it is a ASA. Fingers crossed. ... View more

So would that be the public or private ip of the firepower? ... View more

Yes, the key was correct. I am going to try again to see if there is anything is missed. ... View more

Yes, maximum   I removed the traffic shape rule, but still low speed test.   The server is wired into the MX. ... View more

with Amp off throughput is the same. I have run the speed test from the wired.meraki and it is 200Mbps Internet 1 link negotiation is set at Auto ... View more

Throughput = 254.8Mbps   yes ... View more

Locally. No proxy ... View more

MX speed test  Pinged google.com - 22ms The server i speed test is white listed. ... View more

I have traffic shaping rule for onedrive - ignore network per client.   uplink is maximum.   Tunnel is hub to my other 2 sites which both have MX firewalls. (1 is mx64w and the other is MX84).   Speed test, i use my ISP web gui.  ... View more

I ran the ping test today which was successful both ways. Meraki Support ran the tests and took a packet capture both Lan and Wan which showed the ping response. This proves the meraki is passing traffic down the .115 and with the SIP Inspection test last week, now all points to the pbx. Not sure what the voip supplier will come back with but ill have to wait on them for some form of solution. ... View more

Hi Adam,   I have just got my ISP to turn SIP Inspection off on the cisco ASA so I could test the phones. As soon as it was disabled the same symptoms happened, one way audio and not outgoing calls. I then got it switched back on and phones started working correctly. This must mean the issue is with SIP ALG on the PBX.       ... View more

Thanks Adam,   I will be testing this Sunday as the office will be empty.   ... View more

Meraki is on .114 Voip is on .115   PBX is on 216 DSP is on 217   Open ports 5060 UDP to internal ip of PBX 16000-16200 UDP to Internal ip of DSP   SIP 11.222.33.0 /24 to internal address of PBX   so I have created a 1:Many NAT Public address: 22.300.256.115 Description     Protocol     Pub port              Lan IP            Local Port                Allowed Remote IPS. SIP                    UDP          5060            192.168.2.216       5060                 11.222.33.0 /24, 11.222.34.0 /24 VOIP                 UDP    16000-16200     192.168.2.217    16000-16200       11.222.33.0 /24, 11.222.34.0 /24   Hope this makes sense.   ... View more

Still not luck. I have had to connect the old asa firewall back in as phones have been down for a full working day. As soon as the ASA connected and the arp cleared the phones started working. Sip inspection is on with the asa but I don't think that really matters as the meraki is replacing this fw.   so I have provided the information (changed addresses) which have been given.   11.222.33.0 /24 SIP Main to internal IP address of pbx and pbx dsp 11.222.34.0 /24 SIP Failover to internal IP address of pbx and pbx dsp Open Ports 5060 UDP to internal IP of PBX 16000 – 16200 to internal IP of DSP   Port re-direct from 8888 to internal port 443 pointed at IP of pbx   Also need   444.55.66.88 allowed to internal IP of PBX   IP’s   192.168.2.216 is the internal Address of the PBX 192.168.2.217 is the internal address of the DSP       UDP 16000>16171  to 192.168.2.217 UDP 5060 (SIP) to 192.168.2.216 TCP 8888 to 192.168.2.216.   Return traffic from .216 & .217 will originate from 22.300.256.115. All other traffic will originate from 22.300.256.114.   All outbound traffic is allowed.   If you are having issues with your SIP based phone system, you will need to look at how the Meraki handles SIP traffic. ... View more

Haha yes just a typo, random addresses. 🙂 Hopefully the voip engineer will come back with some fix tomorrow morning.   T ... View more

Thanks Guys,   I cannot use 1:1 Nat as the pbx has two ip addresses which 1:1 wont let me use the public address twice, this is why I had to try with 1:many. Currently with using the interface address I am using port forwarding.   example: SIP - 123.34.231.232 UDP 5060 192.168.1.1 5060 allowed addresses.                 VOIP - 123.34.231.232 UDP 19000-19400 182.168.1.2 19000-19400 allowed addresses.   That is I I need but not working. The company who hosts our VOIP are the ones who are trying to get there system working.   As you can imagine the bosses are not happy as phones are down and my window of opportunity is nearly closed. I have passed the information on to the voip support. Extra long sigh ... View more

It comes in through the internet. I have a pool of public addresses which I assigned one to the voip. 1:many nats are configured for the sip port and voip range both udp. We have a pbx on site which the voip support guys are looking into it but they don't seem to be progressing and have even which to the firewall interface address to see if that works but still one way voice and no outgoing calls. ... View more

Hi Guys,   Update.   I have create a new tunnel on the checkpoint firewall and the tunnel is now up and traffic is going before ways.   Only issue I have now is the voip isn't working correctly.   Incoming calls are received but the users cannot hear the person making the call and also they cannot make outgoing calls. I have 1:many NATs for the ports. which is correct. ... View more

I think the issue maybe the tunnel setup as another Site also uses this. Site A - Checkpoint   Site B - Meraki (ASA 5510 Previous)   Site C - ASA 5510   So on the checkpoint the tunnel which has been created by the previous IT has both sites using the tunnel.   The error I see on the checkpoint tracker is Scenario 3 Title: Site-to-site VPN tunnel fails with various error messages Product: Security Gateway Version: NGX R65, R70, R71, R75 OS: SecurePlatform, Windows Symptoms: Site-to-site VPN tunnel with 3rd party vendor fails with one or more errors in SmartView Tracker: Error: "Encryption failure: packet is dropped as there is no valid SA" Error: "No valid SA" Error: "Encryption failure: No response from peer" Error: "No proposal chosen" "Invalid ID information" error in SmartView Tracker when the Security Gateway initiates a Quick Mode. VPN tunnel can be initiated from one side to the other but no return traffic is seen. TCPdump on the external interface shows that UDP traffic on port 500 enters the Security Gateway, but is not routed past the Security Gateway. VPN tunnel becomes unstable after an 'IKE: Send Delete' packet was sent. Summary: Phase-two Quick Mode failure occurs due to configuration/misconfiguration of VPN/encryption domain for firewalls involved in Site-to-Site VPN tunnels. Typically, this occurs when VPN domain group contains either numerous networks, or numerous hosts from different consecutive networks along with network objects. This article discusses troubleshooting the supernetting issue.   With two different sites uses the same tunnel with two subnets and two shared keys I think this maybe the issue as there maybe something in the config. I removed Site C and created a new tunnel but it was a simple tunnel which users where unable to speak to Site A. I think this tunnel was setup to work with the two ASAs at site B and C and the meraki does not like something in it. My next step is to create a tunnel just for site B and see what happens. What encryption does meraki like the best on phase 1 and phase 2?       ... View more

here is a ping request from the Checkpoint site to the meraki site. 6689 11.415022 192.9.200.66 192.168.2.50 ICMP 78 Echo (ping) reply    id=0x0001, seq=17545/35140, ttl=126 (request in 6681) Internet Protocol Version 4, Src: 192.9.200.66, Dst: 192.168.2.50     0100 .... = Version: 4     .... 0101 = Header Length: 20 bytes (5)     Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)     Total Length: 60     Identification: 0x177d (6013)     Flags: 0x00     Fragment offset: 0     Time to live: 126     Protocol: ICMP (1)     Header checksum: 0xda1d [validation disabled]     [Header checksum status: Unverified]     Source: 192.9.200.66     Destination: 192.168.2.50     [Source GeoIP: Unknown]     [Destination GeoIP: Unknown] Frame 6689: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)     Encapsulation type: Ethernet (1)     Arrival Time: Feb 28, 2018 13:33:34.526000000 GMT Standard Time     [Time shift for this packet: 0.000000000 seconds]     Epoch Time: 1519824814.526000000 seconds     [Time delta from previous captured frame: 0.000702000 seconds]     [Time delta from previous displayed frame: 0.000702000 seconds]     [Time since reference or first frame: 11.415022000 seconds]     Frame Number: 6689     Frame Length: 78 bytes (624 bits)     Capture Length: 78 bytes (624 bits)     [Frame is marked: False]     [Frame is ignored: False]     [Protocols in frame: eth:ethertype:vlan:ethertype:ip:icmp:data]     [Coloring Rule Name: ICMP]     [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: CiscoMer_05:a9:dd (e0:cb:bc:05:a9:dd), Dst: Dell_51:c0:31 (90:b1:1c:51:c0:31)     Destination: Dell_51:c0:31 (90:b1:1c:51:c0:31)         Address: Dell_51:c0:31 (90:b1:1c:51:c0:31)         .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)         .... ...0 .... .... .... .... = IG bit: Individual address (unicast)     Source: CiscoMer_05:a9:dd (e0:cb:bc:05:a9:dd)         Address: CiscoMer_05:a9:dd (e0:cb:bc:05:a9:dd)         .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)         .... ...0 .... .... .... .... = IG bit: Individual address (unicast)     Type: 802.1Q Virtual LAN (0x8100) 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1     000. .... .... .... = Priority: Best Effort (default) (0)     ...0 .... .... .... = DEI: Ineligible     .... 0000 0000 0001 = ID: 1     Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.9.200.66, Dst: 192.168.2.50     0100 .... = Version: 4     .... 0101 = Header Length: 20 bytes (5)     Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)     Total Length: 60     Identification: 0x177d (6013)     Flags: 0x00     Fragment offset: 0     Time to live: 126     Protocol: ICMP (1)     Header checksum: 0xda1d [validation disabled]     [Header checksum status: Unverified]     Source: 192.9.200.66     Destination: 192.168.2.50     [Source GeoIP: Unknown]     [Destination GeoIP: Unknown] Internet Control Message Protocol     Type: 0 (Echo (ping) reply)     Code: 0     Checksum: 0x10d2 [correct]     [Checksum Status: Good]     Identifier (BE): 1 (0x0001)     Identifier (LE): 256 (0x0100)     Sequence number (BE): 17545 (0x4489)     Sequence number (LE): 35140 (0x8944)     [Request frame: 6681]     [Response time: 2.117 ms]     Data (32 bytes)         Data: 6162636465666768696a6b6c6d6e6f707172737475767761...         [Length: 32]   ... View more

Everything is the same. I went on Site A and ran tests again, which I was able to connect to Site B with RDP but when I tried to ping back from Site B to Site A nothing happened. I did a packet capture on the Meraki which showed plenty of traffic to and from Site A to Site B. I could browse the shares which are on Site B. As soon as I switched back to the ASA everything was working again. Its very odd as the tunnel is up but for some reason Site B is not talking to Site A.   4253 4.914302 192.9.200.66 192.168.2.59 TCP 1518 443 → 55382 [ACK] Seq=6512 Ack=2605 Win=64240 Len=1460 [TCP segment of a reassembled PDU] 4254 4.914644 192.9.200.66 192.168.2.59 TCP 1518 443 → 55382 [ACK] Seq=7972 Ack=2605 Win=64240 Len=1460 [TCP segment of a reassembled PDU] 4255 4.914651 192.9.200.66 192.168.2.59 TLSv1 328 Application Data 4256 4.916186 192.168.2.59 192.9.200.66 TCP 64 55382 → 443 [ACK] Seq=2605 Ack=7972 Win=17520 Len=0 4257 4.917057 192.168.2.59 192.9.200.66 TCP 64 55382 → 443 [ACK] Seq=2605 Ack=9702 Win=17520 Len=0 4258 4.918156 192.168.2.59 192.9.200.66 TCP 64 55382 → 443 [RST, ACK] Seq=2605 Ack=9702 Win=0 Len=0   As you can see in the packet traffic is happening and the black Bold is at the checkpoint site and the red is the meraki site. Lots of the traffic showing. ... View more