NAP – How to connect workstations using Network Access Protection to a RADIUS server

Posted by on 31 May, 2015 in Cisco Meraki, Microsoft, Windows Server | 0 comments


Radius Server – Windows server 2012 R2 Standard with NAP installed and configured

Wireless – Cisco Meraki M32 Wireless Access Points connected to a MX firewall.




When Clients are connecting to a Wireless network using 802.11 or WPA2 Enterprise they are showing in the event viewer on the radius server  as Non-NAP Capable and quarantined.


Event ID: 6276

Authentication Details:

Connection Request Policy Name:   NAP 802.1X (Wireless)

Network Policy Name:  NAP 802.1X (Wireless) Non NAP-Capable

Authentication Provider:  Windows

Authentication Type:  PEAP

EAP Type:  Microsoft: Secured password (EAP-MSCHAP v2)

Quarantine Information:

Result:  Quarantined




This occurs if the client is not setup correctly causing them to show as Non-NAP Capable.




There are a few Settings that need to be enabled on the client and most/all of the settings below can be pushed out by a group policy.


1) Make Sure the Network Access Protection Service is running



2) As there is a delay when the wireless network connects you need to start the NAP service after the wireless.


This can be done by going to the following entry in the registry and making the change below:


Update the DependOnService entry and add napagent.


The entry should look similar to the below.  You will need to reboot the client for the registry change to take effect.

NOTE: The service WCMSVC below is only required for Windows 8 workstations. 



3) Enable the Following Setting in:

GPO Manager > Computer Configuration > Policies > Windows Settings > Security Settings > Network Access Protection > NAP Client Configuration > Enforcement Clients




4) On the Client Machine go to Network and Sharing

Select adaptor settings > Right click the Wireless connection once connected to the wireless connection > Select Status > Wireless Properties > Security Tab > Settings > Select Enforce Network Access Protection > Select OK on all open windows.



Read More

Websense Cloud Security – Users stopped appearing in reports

Posted by on 24 Feb, 2015 in Security, Websense | 1 comment


  • Websense Cloud Security Installed and Configured
  • Websense endpoint installed on users machines.
  • Users and groups synced up from Active Directory using DirSyncClient (DSC)



Users stopped appearing in the Websense reports catalogue and if you run any reports from the reports builder they do not appear in the results



Log into the Triton portal. Select Account > End Users > Search for all users ending with nosuchdomain.autoregistration.proxy. Delete all users ending with nosuchdomain and run another DSC to make sure there are no more nosuchdomain users appearing.  Wait about 10-15 minutes and the users should start appearing in the reports.

Read More

Juniper Netscreen – Route traffic through another firewall

Posted by on 18 Feb, 2015 in Firewalls, Juniper, Security | 1 comment


Office A – Juniper Netscreen SSG5 (Static IP)

Office B – Juniper Netscreen SSG5 (Dynamic IP)

Both offices are connected to one another via a VPN tunnel using the SSG5


I came across an issue recently where we had remote hosted servers locked down to a certain IP address (Office A) and we needed office B to access those servers from there office using the Dynamic IP. The way I found around this was to redirect certain traffic over the VPN from office B to Office A, then display the IP as the Static IP from office A to access the servers.


I won’t go through setting up the VPN between the offices as I am assuming this is already done with the following settings.

  • The VPNs are setup using tunnels
  • The VPNs are working in both directions
  • The Policies used are set to allow ANY service through for this test setup.


Office A


  • Login into the Juniper and select Policy > Policies.
  • In the from dropdown select untrust. From the To dropdown select untrust and then click New.
    • Source Address: Select the as the office B LAN.
    • Destination LAN: Select Any (or to make it more secure create an Address List for the hosted servers and select them).
    • Service: Select the required service (i.e. RDP) or select ANY to allow everthing through.
    • Logging: enable this setting
    • Click Advanced
      • Source Translation: Tick this option
      • (DIP on): Select None (Use Egress Interface IP)
      • Enable any other relevant settings you require.
      • Click OK
      • Click OK


  • Office B


  • Select Network > Routing > Destination
  • Click New (Top Right Corner)
    • IP Address/Netmask: Enter the external server IP and mask. If it is a single IP use the mask as 32
    • Gateway: Enable this option
    • Interface: Select the interface as the tunnel interface for the VPN to Office A.
    • Gateway IP Address: Enter the internal IP of the Juniper Netscreen for Office A
    • Permanent: Enable this option
    • Description: I would enter a description here such as the hosted server name
    • Click OK


You should have access to the hosted server now. You could if you wanted direct all traffic over the VPN by adding the IP Address/Netmask as

Read More

Juniper Netscreen – DNS entries changing on reboot (fixed)

Posted by on 18 Feb, 2015 in Firewalls, Juniper, Security | 0 comments

If you are using a Juniper Netscreen as a DHCP server you may find that when rebooting the device the DNS server entries for the DHCP change to the entries of the untrust port. This is down to the default DNS override settings and they can be changed either by using the GUI or Shell commands. I will show both ways below:



  • Log into the juniper and select Network > Interfaces > untrust port > Edit
  • Deselect the setting Automatic Update DHCP Server Parameters




Login to the shell (i.e. using Putty) then type the following command to disable the setting on the untrust port:

unset interface untrust dhcp client settings update-dhcpserver 



Read More

Cisco Meraki – allowing client VPN access to other (VPN) sites

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


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

The above two sites are connected to one another using the guide in my other post which can be found here


If you use the Cisco Meraki MX Firewall to connect to third party firewalls such as Juniper Netscreen’s you will notice that clients who are connected to the Meraki VPN client won’t have access to VPN sites even if you allow them access on the Meraki’s Site-to-Site VPN page. This is because to need to add the Client IP ranges to the third party firewalls.


If you are using a Juniper SSG5 or similar you need to add the Meraki Client’s internal IP ranges to the following places in the Juniper Firewall:

  • On the Proxy ID for the VPN (VPNs > Autokey IKE > Proxy ID) you need to add the internal IP ranges of the Meraki Client
  • You need to create a untrust address for the Client VPN IP ranges in Policy > Policy Elements > Address > Lists.
  • Once the addresses above have been created you need to add the addresses to the existing policies for the juniper to the Meraki and vice versa.
  • Finally you need to create a route to the destination using the same tunnel interface as the existing VPN in Network > Routing > Destination.

This will allow the users on the client VPN to access the site connected with a VPN between the Meraki and Juniper Netscreen.

Read More

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