I have a IPSEC connection from On-PREM to Azure via VPN gateway. I want to monitor all traffic, aka src/dest, ports, and data that ever enters or leaves that VPN gateway. How would I accomplish this under Azure?
You could check out Azure Network Watcher. It will log the flows from your networks. It won't provide exact transfer amounts of traffic, but it will show traffic distribution and patterns.
Included in the Azure Network Watcher is also packet capture and if I remember right it also will show what ports the traffic is going over as well as source and destination IPs.
There are also some easily found Power-Bi templates that will read the logs and let you do some interactive digging.
https://learn.microsoft.com/en-us/azure/network-watcher/
Not at the moment - your only options are
To log traffic via NSGs for resources attached to VNETs
deploy a 3rd party VPN gateway with associated Route tables.
Logging is the biggest restraint I've run into with the native VPN GATEWAY.
Hopefully this will improve with time.
Related
I'm trying to setup a VPN connection from a VLAN in Azure to on-premise. We have two different ISP's on-premise and I want to setup Azure with a VPN connecting to both so that if the primary ISP is down Azure will try to connect using the secondary.
The problem is that I can't add two gateways to a single VLAN, and the one gateway will not let me add two VPN connection with the same IP address range. I can understand that if I wanted both to be active, but I want one to be standby and only used if the first disconnects.
Is this even possible? Any pointers would be great?
I have been looking at https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-highlyavailable#a-name--activeactiveonpremamultiple-on-premises-vpn-devices but that only covers active-active setup which is not what I want.
I want both VNET resouces and on-premise resources to reach each other via the same IP addresses no matter if it's the primary or secondary VPN that's connected.
I know that Azure has fail over on it's side via a standby gateway, but I want fail over when on-premise is down, not Azure.
Update
I know that Azure has fail over on it's side via a standby gateway,
but I want fail over when on-premise is down, not Azure.
Unfortunately, there is not an auto solution for on-premise failover, you could manually perform, which is the same as If the on-premises gateway IP change need to update the same entry. You need to update the local network gateway (Including the On-premises gateway IP and private range ) on the Azure side and the ISP settings where VPN is connected on the on-premise side. Please expect some downtime, because IPSEC session of ISAKMP, PH1 and PH2 Will again take place.
Besides, If you have more than one ISP and need a redundant connection to the Azure. Azure now supports redundant Site to Site VPNs.
Support multiple tunnels between a VNet and an on-premises site with automatic failover based on BGP
You can establish multiple connections between your Azure VNet and
your on-premises VPN devices in the same location. This capability
provides multiple tunnels (paths) between the two networks in an
active-active configuration. If one of the tunnels is disconnected,
the corresponding routes will be withdrawn via BGP and the traffic
automatically shifts to the remaining tunnels.
The following diagram shows a simple example of this highly available setup:
NOTE
BGP is supported on Azure VpnGw1, VpnGw2, VpnGw3, Standard and HighPerformance VPN gateways. Basic SKU is NOT supported.
BGP is supported on Route-Based VPN gateways only.
We have a cisco load balancer on-premise which routes traffic to our DMZ Servers on-premise
We want to use Azure Load Balancer or Azure Solutions (AG) which can balance traffic to our DMZ Servers on-premise, basically replace the CISCO with Azure
Is it possible? we have SFT/HTTPS sites currently hosted on our DMZ Environment.
TIA
What you're proposing isn't the use-case for Application Gateways. Application Gateways are Layer 7 load balancers / reverse proxies. What you want to do is almost treat them as a one-site forward proxy. It's not a good architecture and even if it were possible would ultimately be more costly in the long-run since you would pay for data egress as your App Gateway accepts requests and then forwards on to your web servers via an outbound connection over the Internet. They then receive the response headers/body from your web servers and again send that result on to the original caller.
In that scenario, you are forced to have to use end-to-end SSL for your applications, removing any possibility of using the App Gateway for SSL offload in the future. If your traffic isn't encrypted or doesn't need to be, the predictability of the source and destination of your traffic increases the security risk to your website's users and your company.
You also have the possible security implications of this type of architecture. Your web servers still need to be accessible at the very least by your Application Gateway, which means they are either freely available on the Internet anyway (in which case why bother with an App Gateways at all) or they're firewalled at a single layer and permit only traffic from the source IP address of your Application Gateway.
The bad news with the firewall approach is that you cannot assign a static public IP address to an Application Gateway, it is forced as Dynamic. Realistically the public IP won't change until the App Gateways are rebooted but you should know that when, not if, they do, your firewall rules will be wrong and your App Gateways won't be able to get to your DMZ servers any more, which means an outage. The only true solution for that is a firewall that can do URI based firewall rules...the impact there is cost (time and CPU) to perform a DNS lookup, see if the traffic is from the App Gateway by its DNS address - something like bd8f86bb-5d5a-4498-bc0c-e1a48b3873bf.cloudapp.net and then either permit or deny the request.
As discussed above, a further security consideration is that your traffic will be fairly consistently originating from one location (the App Gateways) and arriving at your DMZ. If there's a well defined source of traffic, that fact could be used in an attack against your servers/DMZ. While I'm sure attacking this is non-trivial, you damage your security posture by making source and destination traffic predictable across the Internet.
I've configured a good number of Application Gateways now for Enterprise applications and out of morbid curiosity I had a go at configuring a very basic one using HTTP to do what you're attempting - fortunately (yes, fortunately) I received an HTTP 502 so I'm going say that this isn't possible. I'll add that I'm glad it isn't possible because it's a Bad Idea (TM).
My suggestion is that you either migrate your DMZ servers to Azure (for the best performance/network latency) or implement a VPN or (preferably) ExpressRoute. You'll then be able to deploy an Application Gateway using the correct architecture where you terminate your users' connections at the App Gateway and that re-transmits the request within your RFC1918 network to your DMZ servers which respond within the network back to the App Gateway and ultimately back to the requestor.
Sorry it's not what you wanted to hear. If you're determined to do this, perhaps nginx could be made to?
We have a client who wants to connect their premises to Azure. Their main hindrance at this point is determining the best way to connect to Azure given their current connectivity configuration. They have two redundant ISP connections going to the head office for internet access. They want to be able to configure a VPN connection to Azure that would operate in a similar way i.e. if ISP A went down it would seamlessly use ISP B and vice versa. The normal multi-site VPN configuration does not fit this since there is one local network behind which means the network behind separate VPNs over each ISP would have overlapping IP address ranges which is not supported. Is such a configuration possible? (See diagram below)
Either that or is there a way to abstract the two ISP connections onto one VPN connection to Azure.
They’re currently considering using a Cisco ASA device to help with this. I’m not familiar with the features of this device so I cannot verify if it will solve their issue. I know there is also a Cisco ASAv appliance in the Azure marketplace don't know if that could also be a part of a possible solution if they went with such a device.
required vpn configuration
The Site-to-Site VPN capability in Azure does not allow for automatic failover between ISPs.
What you could do are the following
- Have automation task created that would re-create the local network and gateway connection upon failover. Manual and would take some RTO to get it up and running
- Use the Cisco CSRs to create a DMVPN mesh. You should be able to achieve the configuration you want using that option. You would use UDRs in Azure to ensure proper routing
I havent done it in Azure, but here is what you do in AWS (And I am sure there would be parallel in Azure)
Configure a "detached VGW" (virtual Private gateway) in aws. Use DMVPN cloud to connect CSRs to multi-site on-prem.
Also, for failover between ISPs you could have a look at DNS load balancing via a parallel to AWS's Route 53 in Azure.
Reference thread :
https://serverfault.com/questions/872700/vpc-transit-difference-between-detached-vgw-and-direct-ipsec-connection-csr100
I am running a few machines and we services in Windows azure that I would like to lock off to the rest of the world because of the confidential data that is on there. I have a few small things that make it harder to get at, but I would like to setup a VPN to lock it down. If I set up a VPN service on one of the VM's would I then be able to latch onto the virtual network I have setup there? What is the process in setting this up?
If your cloud service is in a VNET you can create a VPN gateway and connect to it using either a Site-to-Site VPN or a Point-to-Site VPN. The former is IT focused, requiring VPN router configuration - the latter is developer focused, and requires minimal configuration. When using either form of VPN it is possible to take your cloud service completely off the internet for inbound traffic - outbound traffic can go out regardless of what endpoints you define for your VM.
My Azure web role can, using remote desktop, connect with a browser (IE) to google.com and to a DMZ server on our corporate network.
My web role cannot connect via HTTP GET (IE) to a non-DMZ box behind the firewall. My web role cannot ping this box either. My service is hosted in north/central, allegedly all published IP ranges of north/central have been granted access to the target IP by our CorpIT people. They claim they are seeing no traffic via their sniffer from my compute instance IP when I attempt to ping or HTTP GET against the target local IP.
CorpIT wants help from the Microsoft side but we have no Microsoft relationship. I'm convinced this is the outcome of months of slapdash thirdhand firewall rules applied to the target environment in question. What can I do to further elucidate this for CorpIT?
thx in advance!
You can try to run a trace route or get a network trace from the Azure instance and see what you get back from where. You could also create a support case with microsoft:
https://support.microsoft.com/oas/default.aspx?&c1=501&gprid=14928&&st=1&wfxredirect=1&sd=gn
I wouldn't bet on using the IP ranges to make your applications work correctly. Windows Azure already provides you with some services that allow you to solve these types of issues:
Windows Azure Connect: Allows you to create an IPSec secured connection between your servers and your hosted services. This means you won't need to add rules to the firewall for incoming traffic.
Windows Azure Service Bus Relay: Allows you to expose WCF services to the cloud without having to add rules to the firewall for incoming traffic. Choosing this option might add some extra work for you to do, you might need to create a WCF service if you don't already have one and change the code in your Web Role to connect to this WCF Service.