Azure network design considerations

Azure networking looks simple at first glance. You create a virtual network in the Azure portal. In the next part, you define a subnet with an IP range. With only a few mouse clicks, there is a network in which you can place resources.  At a certain point in time, organizations are going to install “something” in Azure. In most cases, this involves a test environment for one thing or another. The IT organization arranges access to the Azure Portal so the Azure team can start building.

Virtueel netwerk aanmaken

There is nothing more permanent than a temporary solution. This rule seems to be especially valid for “test” environments in the cloud.

In most cases, the Azure environment needs a connection to the existing infrastructure after some time. This connection is relatively easy to build with the Azure VPN Gateway. You have to make sure you’ve thought it through from the beginning, or else you will run into difficulties. To protect you from difficult situations, here is a list of considerations when designing an Azure network:  

  • Have I thought of an IP Plan?
    • Subnets per resource group
  • Which locations should I connect to Azure?
    • Data Centers
    • Offices
    • 3rd party
  • What technology do I use to connect the sites to Azure?
    • IPSEC site-to-site
    • Express route
    • IPSEC to NVA
    • Cato Networks
  • How do I apply network security within my Azure network?
    • Network security groups
    • Application security groups
    • Network virtual appliances (NVA)
  • What Azure network topology am I going to use?
    • Hub and spoke
    • Vnet peering
  • Is routing needed?
    • User-defined-routes

These topics will help you start designing your Azure network. There is plenty of information on each subject on the Internet. If you get lost in the sea of information, don’t hesitate to contact me. You can always reach me at The “keep it simple stupid” philosophy works very well for Azure network design. Nowadays, we should also apply the idea of “safe” to this philosophy.

Hub and spoke ontwerp

In my next blog, I’ll share details of our connection from the on-premises datacenters to Azure. These datacenters connections are not via a Microsoft ExpressRoute. If you suspect we are using IPSEC tunnels, you will be in for a surprise next time. We use one of the most fascinating and secure connections to Azure from our different datacenters.

Follow on instagram for your daily dose of IT humor.

The ultimate list of Microsoft Security portals.

In addition to being a software vendor, Microsoft is the unknown leader in cybersecurity. The M365 bundles from Microsoft include a complete package of tooling to safeguard “Identities” and “Computers”.

Many traditional security products are not required anymore.
The M365 bundles have the modern version of the security product integrated within. Organizations can achieve significant savings by taking advantage of the functionality within their M365 licenses. 

overview M365 security

Setting up and using Azure Sentinel requires some training. The other products are relatively straightforward. The collaboration among Microsoft security products is outstanding.

The different portals:

Microsoft Defender (for end Endpoint)Security center
Microsoft Defender for office365
Microsoft 365 admin center
Microsoft 365 admin center
Microsoft 365 compliance center
Office365 Security & comopliance center
Cloud App Discovery
Cloud App Security
Azur Sentinel
Azure Security Center
Azure Active Directory
Azure Active Directory
Microsoft Defender for Identity
Azure AD Identity Protection
Azure  AD Identity Protection (Free version)
Azure information protection (unified labeling)

Follow on instagram for your daily dose of IT humor.

Time to use some buzz words

In this article, I am going to explain five buzz words commonly used. Some terms have been in use for quite some time. So it’s more a fresh up of the meanings. Most vendors give their own meaning to the terms. Just like the marketing departments of the various vendors, I give my own interpretation of the terms. It may well be that you have a different view on this. If this is the case I would like to hear about it @


When I think of the edge I think of all the data that is created outside the “cloud”. In the edge, data is created that goes to the cloud to be stored or processed. Think of someone taking a picture and posting it on social media. IoT is also a great example of edge computing. These collect data and send it to the data center/cloud. So there is a big shift happening. Traditionally, data is created within a datacenter. At the edge, more and more data is being created and requested. With the emergence of the 5G network, software or apps will need to be closer to the end-user. This means that mini data centers will be placed near 5g masts to get the content as close as possible. For video streams, for example..

Most companies also have an edge. Whether they realize it or not. In one of my following blogs, I will talk about securing the “Edge”.


SD-wan also comes up a lot. SD-WAN stands for software-defined wide area network. Where a “Traditional” WAN is often built from MPLS connections or EVPNs, with SD-wan these are not necessary. Other forms of leased lines are also not needed. The Internet has improved significantly in recent years. As a result, expensive managed Internet connections are unnecessary. Connecting multiple internet connections to an SD-wan device can provide a great alternative to an mpls connection. If you have multiple inexpensive internet connections, cost savings can be made quickly. Even on current contracts. A core feature of SD-wan is that network traffic can be routed better. A good example of this is that a customer has significantly reduced the bandwidth of its mpls connections. Now only the traffic for the data center passes through the mpls networks. The SD-wan device sends all internet traffic over its cheap internet line. By cleverly deploying sd-wan, significant cost reduction can be achieved quickly.


Besides SD-WAN, Edge computing, ZTNA, Firewalls, cloud brokers, there are numerous abbreviations bundled into one type of solution. In today’s age where everything is different, SASE offers a perfect solution. SASE stands for Secure Access Service Edge. A true SASE solution offers all modern network and security capabilities from a single platform. Of course every vendor will now tell you that they have had a SASE solution for years. This often turns out to consist of several products from their portfolio that poorly work together.

Cato network is one of the few players that meet Gartner’s criteria. By making smart use of this SASE product, complex network environments can be brought back to being simple. Linking locations is simple. Security policies for communication can be set with a few mouse clicks. Adding a network segment has no consequences and gives no extra work. Also, with a SASE solution numerous legacy (security) network devices can be phased out. This means fewer appliances are needed, less hardware, less management. More time for fun things.

Many network administrators are quite skeptical when I tell them about this. After all, it sounds too good to be true. Reach out to me and I ‘l make your life a lot easier.

Distributed Cloud

Once upon a time, there was a public cloud. Soon a private cloud emerged. A hybrid cloud also proved to be very useful. The near future is going to be very foggy. For example, numerous new clouds are emerging. The “5G mobile cloud edge” and “Metro-area community cloud” are two examples. The idea behind this is to bring software/apps closer to the end-users. The content will be distributed across multiple and different types of clouds. It should not matter which type of cloud it is in. As long as the end-user can consume a lot of data without latency. I don’t want to say that the cloud is someone else’s computer but still.

IoB – Internet of Behavior

In the digital world, we are already leaving our footprints behind quite a bit. The traces we leave behind are called dust. This process has been going on for some time. Websites are trying to collect more and more data about you. IoT devices are used more and more. There are numerous wearable s that people wear. These devices also collect more and more data. Right now, in many cases, the collected data is still used on its own. The websites analyze it for their purposes. IoT analyses its data to improve itself. The telemetry of your phone is used by the supplier to improve it. Personalized offers already appear at most webshops.

Within the Internet of Behaviour, all these different substances (dust) will be combined This way a detailed picture of the consumer will be created. All to induce the consumer to make a purchase.

Many ethical questions still need to be addressed in this area.

Fortigate policies based on Azure Dynamic Groups

Almost every organization uses groups to assign permissions to employees. For example, these groups grant read or write admissions to a folder. The simple structure of groups keeps it clear for administrators whether they assign permissions to folders or printers or any other resource type.

Within the cloud era, groups are still relevant to assign permissions or resources. However, this requires a different approach.

The administration around group memberships still leaves much to be desired. Employees with many working years often collected a large backpack of group memberships. The dynamics of working have also changed over the years. The workspace tends to be more flexible and more project/team-oriented. To place these requirements in existing group structures is very difficult. In many organizations, there has been a sprawl of groups within their Active Directory.

As a result, many Active Directory contain a jungle of groups. I don’t need to explain why this is bad for IT security.

Azure AD Dynamic Groups

Within Azure AD, you can create groups that are populated based on a user account’s properties. These groups are called Dynamic Groups. For example, a group can be made based on the job title. It is, therefore, relatively easy to create a group with all managers of an organization. This group is also automatically updated. When a member no longer meets the requirements, Azure AD will remove the member.

Azure AD can use almost all user account properties to create membership rules.

The beauty of these Azure AD Dynamic Groups is that Fortigates can use them. (Read here how to set up your Fortigate SAML authentication with Azure AD) Access to resources is granted based on these dynamic groups. The employee can only access resources via the SSL-VPN if their account meets the Dynamic Group’s requirements.

In the examples below, I created two different groups. One is for the security team. The other is for the CSN Microsoft licensing specialists.

Describe the purpose of the dynamic group as concretely as possible and add it to the description

In the examples below, I created two different groups. One is for the security team. The other is for the CSN Microsoft licensing specialists.

Within Azure AD, create a new group. Specify that the membership type is: "Dynamic User". Next, add a "Dynamic query".
In the "Rule builder" you can specify what properties are needed to meet the  group requirrements. In the example below, his job title should have something to do with "security".
Use the "validation rules" to check if the desired members meet the criteria By choosing a number of test persons you can quickly see if the rule works.
This group was created for the Microsoft licensing specialists of CSN Group.

When creating a Dynamic Group a welcome mail is sent to the members. You can disable this behavior in exchange online:

Set-UnifiedGroup -Identity "" UnifiedGroupWelcomeMessageEnable:$false
The groups have been created. The object ID of the group is needed in the Fortigate configuration later on.

The object id of the group is used in the Fortigate configuration

By opening the group you can check if the desired members are present.
We also use the Dynamic Groups to assign the enterprise app "Fortigate SSL-VPN"
Gives a clear name to the attribute here. This will be needed later in the Fortigate configuration.
In the SAML user configuration of the Fortigate, place the name of the group attribute you just created.
In the group configuration of the Fortigate you create the new groups. In these groups, you specify the condition they must meet. In this case, the "group-name" must match the "Object-id" of the group in Azure AD.
The newly created groups can now be used to allocate resources. In other words. They can be used in the Fortigate security policies.

Fortigate and Azure AD: Safe remote access

Within CSN Group, like the rest of the world, we work mostly from home this year. Our employees, therefore, need access to the resources within our data center from home. And that in a way that does not compromise data security. Consequently, we combine two of the best security products available: Fortigate firewalls and Azure Active Directory (Azure AD). Are you wondering how these products work together? I will explain it below.

Possibly it is redundant, but the security products separately do the following:

A Fortigate is a so-called next-gen firewall. This firewall offers broad protection against countless cyber threats. If properly configured, this firewall will fend off attacks such as ransomware. Also, it provides solutions for connectivity issues. For example, we connect sites to data centers based on SD-WAN technologies. The Fortigates offer the ability to give home workers secure access to network resources. It is a versatile device that will speak to the imagination of most people.

Azure Active Directory (Azure AD)
Azure AD is Microsoft’s Identity Manager. It is sometimes confused with the traditional Windows Active Directory. However, these are independent products. The products do have some similarities. For example, both can distribute authorizations and handle authentication requests. Azure AD also provides a central location for account administration and can address cloud applications’ above issues. For example, log in to Office 365 is handled by Azure AD, and the accounts within Azure AD can be linked to all SaaS applications so that you have one account that you can log in to anywhere. It eliminates the numerous separate accounts you have to remember for each online service.

How does CSN deploy these tools for secure home working?
Our employees who work from home through corona can securely access the necessary resources within the data center through the Fortigate SSL-VPN client. It creates a secure tunnel through the Internet from the endpoint to the Fortigate firewall. To keep things simple for employees, they use the same account as Office365. It includes using the same Multi-Factor Authentication (MFA). In our case, this is a push message that authorizes the login attempt with the push of a button. The diagram below shows the connection and authentication schematically:

What do our employees need to do to set up the connection? Watch it in the video below?

Technical interpretation
Now that we have covered the purpose, we can look at the technical interpretation. SAML handles the authentication. We are dealing with three stakeholders in this configuration:

  1. User: the employee who works from home and wants access to the content.
  2. Identity Provider: the party that contains the identities of the employees, or Azure AD.
  3. Service Provider: the party that provides access to the content, or Fortigate firewall.

Want to read more about the configuration? You’ll find all the details in this guide.

The configuration starts with creating an enterprise application within Azure AD. Enter the Fully Qualified Domain Name (FQDN) or the IP address of the Fortinet.

After the enterprise application is configured you can assign it to users. This authorizes employees to use the application. This can also be done on the basis of groups.

The employee can then easily find the connection by logging into Office365. Here you can find the shortcut.

If you followed the Fortigate-ssl-vpn-tutorial guide, the User and Identity Provider is now configured. Now only the Service Provider remains to be done. In this case, that is the Fortigate firewall. After the certificate is imported into the Fortigate, the SAML configuration can start.

Don’t forget to assign the SSL-VPN portal. SAML authentication is possible for web-access and tunnel-access.

As a final step, we need to provide the firewall with a security policy. In our case, we want to give the SSL-VPN users access to a specific application server with a fileshare and a database.

See the video below for the end user experience to setup an ssl-vpn connection

Read more about the specific security tools here: