Many companies struggle with concepts of “cloud networks” and how it relates to their on-premises networks. How do you deploy a firewall in there, with multiple subnets? Do we need multiple VNET’s and what about those subnets? Well, this post is about what you actually need to understand prior to deploying 3rd party firewalls (and/or VNets) and how routing works inside a VNET, and finally the common mistake of comparing an Azure VNET to a Hyper-V/VMWare VNET.
Hosting applications in Azure usually requires some form of connection to the on-premises networks. You could use Point-to-Site dialup or ExpressRoute, but Site-2-Site VPN’s seems the most use technology, and certainly is cheaper than ExpressRoute connection.
But what if you want to use multiple links for failover? What if your local firewall fails or the internet connection itself? Well, that’s why Azure supports MultiSite VPN’s. While it is capable of having two tunnels from on-premises to Azure with preferences, there is no automatic failover support. That means that if tunnel 1 goes down, tunnel 2 is NOT automatically activated. You need to disable tunnel 1 in Azure itself and only THEN tunnel 2 comes up. Which is annoying, but there is another way to fully automate this.. BGP, Border Gateway Protocol.
A lot of customers on Azure want to use the 3rd party firewalls that are available in the Azure Marketplace. But when it comes to Site2Site VPN connections, sometimes it doesn’t work as expected. Especially when using different vendors on-premises.. Why? let’s find out…
Azure Active Directory and thus any relying party on that service (such as Office 365) has two different modes for (your) custom domains that are added to it. Managed and Federated. Managed means that the authentication happens against the Azure Active Directory. The password (-hashes) of the user accounts are in Azure AD and no connection to any (on-premises) Active Directory Domain is made.
Managed domains have the advantage that you don’t require any additional infrastructure, and setting up the identities for logging on to Office 365 for example, is fairly easy. However, it does not support any Single-Sign-On which most companies do want. That is why AAD also supports Federated domains, in this case the authentication for a user happens against the corporate (on-premises) Active Directory through a service called ADFS (Active Directory Federation Services). More information on federated versus managed can be found on the Kloud blog (https://blog.kloud.com.au/2013/06/05/office-365-to-federate-or-not-to-federate-that-is-the-question/)
In this article we are going to take a look at how the federation service can be hosted in Azure (and possibly also on-premises) and what the architectures might look like.
These are my notes on the newer Checkpoint VPN stuff.. but still working on actually testing them.. – I put a 2016 date on it to remove it from the main page.. Seems the MSS clamping on Azure VPN’s needs to be 1350, my PPPOE adapter needed to be 1492 for du Connections. Note: MTU […]
In a previous post we looked at the ability of creating a Site-2-Site connection from Checkpoint to Azure using a Dynamic Gateway. In this post, we look at client-dialup (VPN) into the Azure network and establish routing between all the sites involved.
In this post, how to configure a Site2Site VPN connecting using a Checkpoint firewall.
[EDIT: The instructions below are for R77, which is a really old version. I’m currently writing the instructions for the R80.20 version, but it seems it’s a bit harder to get the S2S tunnel up and stable.. certainly on my PPPOE internet connection… more updates soon!
But in case you still want to make this work, please check this hidden article with my notes.. that have not been validated yet! [/EDIT]
While http://msdn.microsoft.com/en-us/library/azure/dn133795.aspx tells you how to create the Site2Site VPN, the firewall part only covers Juniper or Cisco appliances. As I do not own such a device, I got to work on the Checkpoint together with Syed Pasha.
Below the network overview…
When you have servers in the DMZ that are members of your internal AD (not best practice ok.. ) .. you find yourself shooting holes in the firewall to allow RPC, SMB and other protocols. In that case perhaps an IPSEC tunnel can help you out.. when you use a tunnel between your internal and DMZ hosts, the firewall only has to allow UDP 500 and ESP protocol (protocol 50). No high ports required. To set it up use the following guide.