Azure Connect is a service found on the older Azure.com portal and allows connectivity between on-premise and cloud servers/roles/resources. It creates a virtual IP (overlay) network - pretty much a VPN.
Azure Virtual Network (found on the new Azure portal) is ALSO touted as a VPN solution for also the same purpose however the configuration seems a lot twisted (although with a pretty UI).
I'm confused how these two product stack up against each other. Googling and searching MSDN didn't reveal much information either.
What are the differences between them and the target use-cases? Are they expected to be merged into one product down the road?
The use case for us is a WebRole that's running as a cloud service, whose REST/Web API services are consumed by machines on a private network. Azure Connect or Azure Virtual Network would (should?) provide the underlying connectivity between them.
Azure Connect allows users to connect Azure applications with on-premise servers in a super simple and quick way. It does not require VPN devices, it does not require user to have network knowledge, it does not require/assume user have access to network infrastructure (e.g. ability to configure the firewall at company's edge firewall). You express your connectivity intent (e.g. Azure service x should connect to a set of machines (machine group) y on-premise) in the management portal, Azure Connect does the rest for you. It is also very flexible in that you can change the network and connectivity policy at any time via the portal, without requiring redeployment of your app or any change on-premise. e.g. you can make Azure service x to connect to machine group z on-premise instead of y, once you make that change in portal, the rest happens automatically, machines in y are not long accessible to/from Azure. Azure Connect uses endpoint software to manage all the network connectivity for users, so you do have to install endpoint software. But it supports many different automatic deployment options including using Microsoft Update.
Azure Virtual Network allows user to extend part of their on-premise infrastructure to your Azure virtual network via standard site-to-site IPSEC connection. You must have an internet facing VPN device at on-premise side. The solution also assumes you have network knowledge - you will be asked to specify the network address range you will be using at both Azure and on-premise sides, you will must launch a VPN gateway at Azure side and manage the IPSEC connection. It does not require install endpoint software on servers, you are responsible for setting up routes to route the traffic from VPN device to servers and vice versa.
The two technologies complement each other, they are suitable for different scenarios.
Related
This is Yaseen Zafar. DevOps Engineer from Integrated Dealer Systems. We have multiple customers whose servers are hosted on multiple locations from Canada to America. They are hosted on premises (i.e. they are not currently on Azure). Though we are currently using Microsoft Azure Log Analytics to get some insights of the Windows and Linux Servers. So far it has been a very good experience.
Actually I wanted to know if there is any solution available on Azure that can show me firewall related logs, rules, IP and port details ingested from the Windows and Linux Servers that are hosted on premise location.
Best Regards.
Yaseen Zafar
• Yes, there is a way through which you can forward your on-premises firewall logs to Azure log analytics workspace since almost every firewall device has syslog functionality in built in it to forward logs to a log management server on a specific port. Thus, similarly, on-premises firewall logs that include all data collected related to the traffic passed inbound and outbound to the environment can be forwarded to a Linux virtual machine which then can be forwarded to the Azure Log Analytics.
• Syslog is the cross-platform equivalent of Windows Event log which can be leveraged by forwarding these syslog messages to Azure Log Analytics through Linux machines. This linux system should be deployed as a virtual appliance (VM) in on-premises or in Azure cloud such that the syslog-generating firewalls can communicate directly with them. The Linux forwarder can be on-premises physically near the firewall, or it can be in Azure or another cloud, connected to your firewall by an IPSEC tunnel. The Linux computer has a Log Analytics agent configured to communicate with your Log Analytics workspace.
• Once your firewall is connected to Azure Log Analytics you should create a custom dashboard solution that suits your needs. You will have excellent visibility and gain a lot of insight into your firewall operation by studying the collected and indexed syslog data in the Log search feature of the Azure portal. You will notice which types of data your firewall is delivering and learn what to monitor to meet your business and security needs.
Please find the below links for more information on how to configure the Linux virtual machine as a syslog forwarder and how to implement the above stated solution as a whole: -
https://blog.johnjoyner.net/connect-your-firewall-to-azure-log-analytics-for-security-insights/
https://accountabilit.com/azure-log-analytics-best-syslog-destination/
I am working with Windows IoT core on a Gateway to Run some Edge services, all the ways to connect to the IoT core device is locally, so basically you have to be on the same network, Any possible way to access the device via the internet?
It is a generic network question. There are a two options, depending if this is for private or commercial grade use.
Configure 'port forwarding' on your router.
Using cloud service which have a published IP address. Your device 'publish' on a known location and your clients access a known place. For example, you can use Microsoft Azure IoT Hub. The purpose of remote connection is nothing more than managing the device. You can use Azure IoT Device Management.
I have a scenario where I have a Windows VM in windows Azure that needs to connect to an external customer network (and connect to a database that is not in Azure).
This traffic is uni-directional in that it is only my VM that needs to connect to the customer's databases and not the other way around. Site to site is managed on Azure, which I cannot really test locally.
Conceptually, connecting to the customer's network via a point-to-site VPN seems more suitable (by creating the VPN connection in Windows itself via the network config).
The customer prefers site-to-site even though they don't need to connect to my VM. Am I missing something?
In point-to-site, you have to connect to the network you want to access manually. Usually, if you log-off or restart the workstation it loses connection, and you have to reconnect every time. It's common to use this type of VPN when we are working remotely, and we need to access our company assets. The channel is bi-directional, but it's 1-to-many.
Site-to-site is used when you want to connect two networks and keep the communication up all the time. It's also bi-directional, but it's many-to-many and stays up no matter if your server/workstation is running or not because the connection is established through a network gateway and not from the computer operating system.
In Azure, the Virtual Network Gateway is the platform providing both functionalities. You can configure site-to-site to connect to your customer network. If this network is not running in Azure, they usually have an appliance to establish dedicated tunnels. As long as it supports IPsec IKE, you are good to go.
If you are using the VM in Azure as a workstation, then point-to-site may be enough, but if your application needs to get data from the customer database automatically with or without someone logged in the VM, then site-to-site is a better approach.
A better explanation can be found here
Does anyone know how to use Openswan to create an IPSec tunnel to a Cisco router on EC2?
I keep reading that people can or they cannot set up the IPSec tunnels on Amazon's cloud. Is it possible or not?
If so, can someone point me to a tutorial where it was successful?
Update
AWS has just dropped the requirement to establish Border Gateway Protocol (BGP) peerings in order to use the built in VPN connectivity to an Amazon Virtual Private Cloud (VPC), see Amazon VPC - Additional VPN Features:
You can now create Hardware VPN connections to your VPC using static
routing. This means that you can establish connectivity using VPN
devices that do not support BGP such as Cisco ASA and Microsoft
Windows Server 2008 R2. You can also use Linux to establish a
Hardware VPN connection to your VPC. In fact, any IPSec VPN
implementation should work. [emphasis mine]
The outlined reason for this change specifically highlights BGP as a previous barrier to adoption of this otherwise very appealing VPN connectivity to a VPC:
First, BGP can be difficult to set up and to manage, [...]. Second, some firewalls and entry-level
routers support IPSec but not BGP. These devices are very popular in
corporate branch offices. As I mentioned above, this change
dramatically increases the number of VPN devices that can be used to
connect to a VPC. [...]
I couldn't agree more - accordingly you should now be able to facilitate Openswan (or the built in Linux IPSec stack) to connect to the respective built in VPC IPSec functionality.
Initial Answer
A related tutorial based on Racoon is available at Amazon VPC with Linux. However, before you dive into that, I highly recommend to read the referring article Connecting to Amazon VPC first, at least section Using Linux as VPN Server:
Let us say you have decided to use some linux for your VPN server. For
an IPSec newbie there is no obvious reason that this is a bad idea.
And because one soon finds a tutorial like
http://openfoo.org/blog/amazon_vpc_with_linux.html it seems possible
to perform that task. Following this tutorial you should be able to
ping the two BGP servers from your VPN server. [...] But after that point you will
start to get in trouble. Maybe you are able to connect to a server in
your VPC. But there is one thing you won’t get working stable:
Connecting from the VPC to some server in your home net
192.168.1.1/24. That is because linux has a policy-based IPSec implementation. [...]
Consequently the author concludes:
And the last and most important reason is that Openswan is not
intended to be used that way. Abusing software in a security relevant
place doesn’t seem to be a good idea. [emphasis mine]
YMMV as usual, but you have been warned ;)
I sell a product that runs on Amazon EC2. A company now wants to purchase and install it within their perimeter... This also implies the use of a VPN connection to the EC2 datacenter.
I want to test my product using Amazon VPN (VPC) before handing over the code. Must I change my code to make it work across VPC? If I run on Windows, then wants the quickest and easiest desktop VPN client avaialable that will allow me to connect across VPN to the Amazon datacenter?
Make sure you setup NAT servers and set your routes in the AWS console. Your client can have some security infrastructure for extending their data center to the cloud - firewall rules at the VPC level etc. Disable firewall rules on the server you deploy to since your VPC already takes care of this. As root execute the following command. service iptables stop (you probably already know this I am guessing)
Is it important for your app to run across VPCs?
Depending on how large the company you are selling to is, their security team may give them the run around to have VPC to VPC communication. Is it important for your software to span across VPCs?