Posts made in February, 2015

Cisco Meraki – Creating a VPN between a Cisco Meraki and Juniper Netscreen

Posted by on 18 Feb, 2015 in Cisco Meraki, Firewalls, Juniper, Security | 10 comments


  • Cisco Meraki MX100 (connected with a static external IP)
  • Juniper Netscreen SSG5/NS5GT (connected with a static external IP)


I am in the process of replacing our Juniper kit with the Cisco Meraki MX100’s. As there are various sites that need replacing, as I replace one sites Juniper firewall with the Meraki, the MX100 needs to connect with our other sites Juniper kit until they are replaced.

The requirements for the Cisco Meraki to connect to a third party VPN Firewall are below and are taken from the Cisco Meraki Docs website (

MX series support for third-party VPN interoperability requires the following:

    • Preshared keys (no certificates)
    • LAN static routes (no routing protocol for the VPN interface)
    • Phase 1 (IKE Policy): 3DES, SHA1, DH group 2, lifetime 8 hours
    • Phase 2 (IPsec Rule): Any of 3DES, DES, or AES; either MD5 or SHA1; PFS disabled; lifetime 8 hours


Cisco Meraki MX100 Setup

  • Log in to the Meraki dashboard and select the network you have created for the MX100 from the drop down at the top of the webpage.
  • Select Configure > site-to-site VPN.
  • Select the following options
    • Mode: Change to split tunnel or Full depending on your requirements.
    • Topology: Select connect directly to all VPN Peers.
    • NAT Traversal: I left this as automatic but you can change to your requirements.
    • Local Networks: Select the networks you want to have access to the VPN.
    • Organisation-Wide Settings: Select add a peer.
      • Name: A friendly name for the connection to the Juniper
      • Public IP: External IP for the Juniper Firewall.
      • Private Subnets: Enter the internal subnet for the juniper in the format
      • IPsec Policies: Select the policies required for the Juniper. I left the default but there are pre-set settings for connecting to Microsoft Azure and Amazon’s AWS as well.
      • Preshared secret: Create a secret for connecting to the Juniper.
      • Availability: Select the networks to have access to the VPN’s
      • Site-to-Site Firewall: You can create firewall rules here to only allow certain traffic through.



Juniper SSG5 Setup:


  • Create a Tunnel


  • Select Network > Interfaces > List
  • Select Tunnel IF from the top right hand corner drop down
  • Select New (top right corner)
    • Zone (VR): Select Untrust (trust-vr)
    • Unnumbered: Select interface as Untrust (trust-vr)


  • Create a Gateway


  • Select VPNs > AutoKey Advanced > Gateway
  • Select New (top right corner)
    • Gateway Name: Give the Gateway a friendly name
    • Version: Cisco Meraki only supports IKEv1
    • Remote Gateway: Select Static IP Address and enter the External IP address of the Meraki Firewall
    • Click Advanced
      • Preshared Key: Enter the preshared key you entered in the Meraki above.
      • Security Level: Select Custom and from the first drop down for Phase 1 Proposal select pre-g2-3des-sha. You can select additional selections as long as they meet the requirements for Meraki at the top of the page (Phase 1 (IKE Policy): 3DES, SHA1, DH group 2, lifetime 8 hours)
      • Mode (Initiator): Only Main (ID Protection) will work with Meraki
      • I left the rest as the default
    • Click Return
    • Click OK


  • Create a AutoKey IKE


  • Select VPNs > AutoKey IKE
  • Select New (top right corner)
    • VPN Name: Enter a name for the VPN
    • Remote Gateway: Select Predefined and select the Gateway created above.
    • Click Advanced
      • Security Level: Select Custom and select nopfs-esp-des-sha. You can select alternative options here but the must meet the Meraki criteria above (Phase 2 (IPsec Rule): Any of 3DES, DES, or AES; either MD5 or SHA1; PFS disabled; lifetime 8 hours)
      • Bind to: Select Tunnel Interface and select the Tunnel created in Step 1 above.
      • Proxy-ID Check: Tick this box
      • VPN Monitor: Tick this box
      • Optimized: Tick this box
      • Rekey: Tick this box
      • Leave the rest as default.
      • Click Return
      • Click OK
    • Select Proxy ID. Enter the Local and remote internal IPs (in the format XXX.XXX.XXX.XXX/24) and select the service you wish to allow (select ANY to allow everything) and click New.


  • Create a Route


  • From the left Menu Select Network > Routing > Destination
  • Select trust-vr from the top right hand corner then click New
    • IP Address / Netmask: Enter the Network and Subnet for the internal network for the Meraki
    • Gateway: Select the interface as the tunnel number you created in Step 1 and select Permanent
    • Click OK


  • Create Policies


  • From the Left menu select Policy > Policy Elements > Addresses > Lists
  • Select Trust from the top left hand menu.
  • You should already have entries here if the firewall is in use. If this is a new firewall setup select New from the top right hand corner.
    • Address Name: Give a name for the trusted policy
    • IP: Enter the local network and subnet for the trusted network which is the network behind the Juniper.
    • Zone: Make sure trust is selected
    • Click OK
  • Select Untrust from the top left hand menu. Click New
    • Address Name: Give a name for the untrusted policy
    • IP: Enter the Meraki local network and subnet for the trusted network which is the network behind the Meraki.
    • Zone: Make sure untrust is selected
    • Click OK
  • From the Left menu select Policy > Policies
    • From the Top in the from drop down select Trust and in the To drop down select Untrust
    • Click New
      • Name (Optional): You can enter a name here or leave it blank
      • Source Address: In the Address Book Entry select the local address created above
      • Destination Address: In the Address Book Entry select the local Meraki address created above
      • Service: select the service you wish to allow or select ANY to allow it all through
      • You can select any additional options as well here. I normally enable logging as well.
      • Click OK
      • Click OK


You should be able to ping both ways and access both networks from either side. As you can see setting up a Meraki is a lot easier than setting up a Juniper!

The way Cisco Meraki’s work is that you need to purchase the hardware appliance then pay for a licence to use the firewall. The Licences normally come in 1, 2, 3, 5, 10 year licences. There are two types of Licence that are available (below) and they include 24X7 telephone support with the hardware having a lifetime warranty.


Enterprise Licence Features:


  • Stateful firewall
  • Site to site VPN
  • Client VPN
  • Branch routing
  • Link bonding and failover
  • Application control
  • Web caching
  • WAN optimization



Advanced Security Licence (includes all the Enterprise Licence Features above)


  • Content filtering
  • Google SafeSearch
  • YouTube for Schools
  • Intrusion prevention (IPS)
  • Anti-Virus and Anti-Phishing
  • Geo-based IP rules


The advanced licence includes web filtering so the cost is about twice as much as the enterprise licence. If you have multiple sites and want to use the web filtering feature then you need to by a licence for each sites firewall unless you want to redirect the internet traffic of over the VPN to a central site which has a fast internet connection then you can get away with a single advanced licence. If you have teleworker sites using devices such as the Meraki Z1 and want to filter the web traffic then you will have to redirect the internet traffic over the VPN as there is only a single licence type available for the teleworker devices and they do not include web filtering.


I have added a couple of links that may be useful in setting up the Meraki.


Meraki’s Documents website which I found to be very helpful:

Meraki sizing guide so you can see the differences in the types of Firewall’s:



Read More

Office 365 – Fast Track Network Analysis (EMEA) Connectivity/Bandwidth tester

Posted by on 10 Feb, 2015 in Office 365, Office 365, Tools/Utilities | 1 comment

If you are having issues with connecting to office 365 services in your office I recommend running the following tool to test your connectivity.  Its quite a thourgh test




  • The first check is a port test to see if the ports are open.


  1. SMTP – (TCP-25)
  2. HTTP – (TCP-80)
  3. https – (TCP-443)
  4. imap – (TCP-993)
  5. pop – (TCP-995)
  6. stun – (UDP-3478)
  7. lyncpush – (TCP-5223)
  8. rtp-audio – (UDP-50000-50019)
  9. rtp-video (UDP – 50020-50039)
  10. lyncft – (TCP – 50040-50059)


  • The second test is a route (hop) test
  • The third test is a speed test.


  • VoIP Test which is a jitter and packet loss test


  • Capacity test which shows the amount of packets the upload/download can handle without packet lost.



  • Round Trip time



  • Packet loss


  • The next three tabs show the data in graphical, summary and advanced forms. If you click on the summary tab and select test audit report this will bring up a URL you can copy and use later to bring back the results of this report.


  • Having a high consistency of service is required to make sure you do not get outlook connection dropouts (80%+)



Read More

Office 365 – Azure Active Directory Sync Tool (password changes)

Posted by on 10 Feb, 2015 in Azure Active Directory Sync, Office 365, Tools/Utilities | 0 comments

If you are using office 365 you may be using the Azure Active Directory Sync Tool to sync up your active directory to office 365.

You are probably aware that by default DirSync runs by default every three hours. I have seen various websites showing how to change the default setting in the Config. file (Microsoft.Online.DirSync.Scheduler) to make the sync happen faster. The main reason is to sync up the changes faster. I have found that this is not necessary to sync password changes up faster as the DirSync tool will sync up the passwords within about 3 minutes in the background. It won’t sync the AD changes such as a change in name but will sync the password in the background.

The details of the sync can be found in the event viewing searching for event ID 656 which is the password sync request ID. You will see the time stamp a couple of minutes after the password is reset.





There are various IDs that you can search for regarding the sync. The list below is taken from the Microsoft site (



Read More

Office 365 – Azure Active Directory Sync Tool (Synchronisation Service Manager)

Posted by on 10 Feb, 2015 in Azure Active Directory Sync, Office 365, Tools/Utilities | 0 comments

You can monitor and see the status of previous syncs to see what information has been synced up by the Azure Active Directory Sync using the Synchronisation Service Manager. By default you can find this application in the following folder:


C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe


When running the application you will see the screen looking like this:



You can see the previous syncs and the details of what information has been synced by double clicking the relevant name and selecting the relevant export statistics in the bottom left hand corner.


Read More

Office 365 – Migrating Mailboxes from on premise to office 365

Posted by on 10 Feb, 2015 in Microsoft, Office 365 | 0 comments


Hybrid Setup Exchange 2010 and Office 365


When migrating mailboxes in batches to office 365 using the Office 365 admin portal I had a couple of mailboxes fail when the mailbox status was completing. After about 20 minutes with mailboxes being stuck on completing. The following error appeared in the logs:

Error: SyncTimeoutException: Email migration failed for this user because no email could be downloaded


To resolve the issue with the mailboxes I deleted them from the batch and created a separate batch with the failed mailbox(s) and ran the migration again. This resolved the issue. When migrating mailboxes I found that migration them in batched of about 20-25 worked fine. When I had larger numbers or total emails for the batch exceeding 400-450k it seemed to cause issues. It could have just been coincidence but the smaller batches worked fine.

Read More