We are attempting to move our domain controller to the cloud to facilitate a distributed network. The crux of the problem we're having is that I am unable to send network traffic through the VPN to the VNet and VM domain controller I've created there.
The setup is as follows: (Main Office) SonicWALL NSA 220. (Branch Office 1) SonicWALL TZ105. (Branch Office 2) SonicWALL TZ105. (Azure) VNet with Site-to-Site networking enabled, VM residing within a subnet within the VNet. I've manually configured the VNet gateway to create the VPN connections to all three locations and have confirmed that the VPNs are live and operational and appear to be functioning correctly.
The VNet was created with a "dynamic" routing gateway, per SonicWALL documentation. The SonicWALLs are configured with "tunneled" VPNs and static routes created from each office to the VM subnet. I have not created any outgoing NAT translation rules because I am operating under the assumption that the VNet gateway performs that function. I've enabled incoming translation rules.
I've created the Windows 2012 R2 virtual machine and configured it as a domain controller. Disabled Windows Firewall (by turning it off in the control panel) and intend to install McAfee SaaS (but will not do so until I have everything working as intended). As of right now, the virtual machine can ping hosts on all three office networks (main office, branch office 1, and branch office 2) however the VM cannot be pinged from outside the subnet in Azure.
The Azure configuration looks like this:
Address Space: 192.168.0.0/21
Subnet 1: 192.168.1.0/16
Gateway: 192.168.0.0/29
Local Network 1: 192.168.10.0/16
Local Network 2: 192.168.11.0/16
Local Network 3: 192.168.12.0/16
Routing configuration is as follows:
Source: [Local Subnet]
Destination: [Azure Subnet 1]
Type: All
Interface: VPN Tunnel
The Virtual Machine resides on Subnet 1 with a static IP address (e.g., 192.168.1.4) configured through Windows Azure Powershell.
Ping from the VM to our local networks works fine. Ping from our local networks to the VNet/VM does not work.
I have a feeling that the problem lies in NAT translation. I looked but was completely unable to find any documentation, discussion, information, or resources addressing how the Azure VNet gateway translates incoming and outgoing traffic. I've tried adding translation rules for incoming traffic from Azure to our local network to no avail.
Any ideas? I am not very familiar with network troubleshooting tools so if a response asks for creation of a log or use of any such tools please provide some detail as to how to do it.
Thanks,
Adam
With further troubleshooting I was able to solve the issue and I can now ping all systems from Azure to Local Network and from Local Network to Azure. The problem was with a default NAT rule on the SonicWALL which provided for use of our public IP address for all traffic originating inside our corporate network unless a more specific rule otherwise applies.
To solve the problem I added the following NAT rule:
Source:
Original-Local Subnet
Translated-Original
Destination:
Original-Azure Subnet
Translated-Original
Service:
Original-Any
Translated-Original
Interface:
Inbound-Any
Outbound-Any
This rule corrected the scenario we were experiencing where our firewall was translating all traffic being sent to Azure as our public IP address which, obviously, would create a problem.
Related
I am setting up an Azure VPN Gateway in order for my Azure VM to connect to a remote RTSP feed, following this documentation: https://learn.microsoft.com/fr-fr/azure/vpn-gateway/tutorial-site-to-site-portal.
What I have done:
Create a virtual network + a subnet and a Virtual Machine
Create the VPN Gateway in the same virtual network
Create a local network gateway with the Public IP and IPs range of the remote network that contains the RTSP feeds
Create the site to site VPN connection with needed shared access key.
The status of the VPN connection is "connected", as you can see in below picture:
Moreover, the subnet on which my azure virtual machine is, is in the same virtual network as the subnet of the VPN Gateway:
From what I understand, as long as the VM is in the virtual network of the Gateway, I should be able to reach the remote network...
Expected behaviour: I should be able to reach the following IP addresses: 192.168.250.30/32 that are on the remote network, from my azure virtual machine.
Actual behavior: From my azure virtual machine, I'm still unable to reach the remote network.
Any ideas where the problem can come from?
If the issue is that the Azure VM's are not getting gateway routes, then a gateway reset should be tried first and the gateway reset needs to be done twice.
Reference :
VPN gateway Reset
References for S2S VPN issues troubleshooting:
S2S VPN cannot connect and stops working
S2S VPN disconnects intermittently
Note : If this doesn’t solve your issue then please reach out to Azure support for more troubleshooting as it may need assisted support by clicking (Support+Help) and creating a technical support request. Please validate your Onprem VPN device as well.
And as Andriy Bilous has mentioned in comments section:
You should see default gateway on your VM routing table. Default Gateway is responsible for routing traffic further. Can you see that
tunnel is UP on your VPN onpremise device.
If no VPN Gateway subnet (10.0.0.0/28) in your VM route table - You may add route to VM using route command. Example: route ADD 10.0.0.0
MASK 255.255.255.240 [Your Gateway IP address]
Here a Data engineer who needs your help to setup a connection to an on-premise environment :)!
I have created a virtual network (10.0.0.0/16) with a default subnet (10.0.0.0/24).
Then I created a (Windows) virtual machine which is connected to the vnet/subnet and has allowed ICMP inbound and outbound rules for the ping test. Ping google.com is no problem.
The next step was to create a Virtual network gateway & Local network gateway to connect to an on-premise environment.
The Local network gateway has an Site-to-site (IPsec) connection to a VPN device from a third party (over which I have no control). Status in the Azure portal = 'Connected'.
The third party is able to ping the Virtual Machine in Azure, the 'data in' property on the VPN connection shows that 2 kb (ping) has been received. So that works!
When i try to send a ping command to the ip-address (within the 'address space' specified from the Local network gateway) the ping command fails (Request timed out.).
After a lot of searching on google/stackoverflow I found out that I need to configure a Route Table in Azure because of the BGP = disabled setting. So hopefully I did a good job configure the Routing Table Routes but still I can't perform a successful ping :(!
Do you guys/girls know which step/configuration I have forgotten or where I made a mistake?
I would like to understand why I cannot perform a successful ping to the on-premise environment. If you need more information, please let me know
Site-to-site (IPsec) connection screenshot/config
Routing Table setup screenshot/config
Routing Table Routes in more detail
If you are NOT using BGP between the Azure VPN gateway and this particular network, you must provide a list of valid address prefixes for the Address space in your local network gateway. The address prefixes you specify are the prefixes located on your on-premises network.
In this case, it looks like you have added the address prefixes. Make sure that the ranges you specify here do not overlap with ranges of other networks that you want to connect to. Azure will route the address range that you specify to the on-premises VPN device IP address. There are no other operations that we can do. We don't need to set UDR, especially we don't associate a route table to the Gateway Subnet. Also, avoid associating a network security group (NSG) to the Gateway Subnet. You can check the route table by selecting Effective routes for a network interface in Azure VM. Read more details here.
If you would like to verify the connection from Azure VNet to an on-premise network, ensure that you PING a real private IP address from your on-premise network(I mean the IP address is assigned to an on-premise machine), you can check the IP address with ipconfig/all in local CMD. Moreover, you could Enable ICMP through the Windows firewall inside the Azure VM with the PowerShell command New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4. Or, instead of using PING, you can use the PowerShell command Test-NetConnection to test a connection to a remote host.
If the problem persists, you could try to reset the Azure VPN gateway and reset the tunnel from the on-premises VPN device. To go further, you could follow these steps to identify the cause of the problem.
Again, I tried to create a VNet-to-VNet connection.
Briefly, I created
Gateway Subnet at East US Region
Gateway Subnet at West US Region
Virtual Network Gateway for East US Region and
Virtual Network Gateway for West US Region
Using Connection type VNet-to-VNet, I connected both Virtual Network Gateway from both sides.
I created connection between both Virtual Network Gateway.
The status of both connections says, Connected.
Windows Server Domain Controller is set up at East US and Windows 10 is installed at West US.
Windows 10 is unable to ping and join the Windows Server Domain Controller.
While joining the Domain Controller, the error message is
The issue is
I am able to connect both VMs which is at two different VNets using RDP with Public IP.
Both VMs’ virtual network gateways are also connected to each other through Connections.
I am able to connect one VM from another using RDP with Private IP.
But I am not able to join Windows 10 VM to Windows Server 2016 Domain Controller.
I request please go through the link https://1drv.ms/u/s!Ail_S1qZOKPmlgBU5fLviInoisrx?e=ImrqpL and help me to fix the issue related to VNet-to-Vnet Connection so that Windows 10 VM from one VNet can join the Windows Server 2016 Domain Controller VM which is at another VNet.
I hope you'll consider it positively.
Regards
TekQ
You might have to create routes, you are not using recommended private address space so routes are not created for you.
Azure automatically creates default routes
for the following address prefixes: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16: Reserved for private use in RFC 1918.
100.64.0.0/10: Reserved in RFC 6598.
Check the effective routes to seen next hop for traffic in the peering address space.
https://learn.microsoft.com/en-us/azure/virtual-network/diagnose-network-routing-problem
Additional Information on VNet Routing
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview
Instead of rely on Vnet Gateway and VPN S2S, you could as well using Vnet Peering between region.
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview
I agree with the other answers. Global VNet Peering would remove the necessity of using a VPN GW, which greatly simplifies the environment and removes the monthly cost of hosting a pair of GWs. Assuming you need those GWs for other connections to VPN devices on-premises, then you can still use this design.
As Hannel pointed out, you're using public ranges for your private networks. That is also okay, but routing would be affected for VMs in those subnets if they attempted to go to actual public IPs in those ranges. Note that Hewlett Packard owns large parts of those ranges, so if your VM needed to get info from an HP website, you would have to create manual UDRs to route that traffic to Next Hop Internet.
So, please do check your Effective Routes on your NICs. You can check this from the NIC and also from Network Watcher. This should help you identify if another route is taking precedence or even if you have a route sending traffic to a virtual appliance.
Do make sure that you chose VNet-to-VNet when you set up your connection. If you chose IPSec, then you would need to have correctly configured your local network gateways.
I'm new to Azure (strike 1) and totally suck at networking (strike 2).
Nevertheless, I've got two VMs up and running in the same virtual network; one will act as a web server and the other will act as a SQL database server.
While I can see that their internal IP addresses are both in the same network I'm unable to verify that the machines can communicate with each other and am sort of confused regarding the appropriate place to address this.
Microsoft's own documentation says
All virtual machines that you create in Windows Azure can
automatically communicate using a private network channel with other
virtual machines in the same cloud service or virtual network.
However, you need to add an endpoint to a machine for other resources
on the Internet or other virtual networks to communicate with it. You
can associate specific ports and a protocol to endpoints. Resources
can connect to an endpoint by using a protocol of TCP or UDP. The TCP
protocol includes HTTP and HTTPS communication.
So why can't the machines at least ping each other via internal IPs? Is it Windows Firewall getting in the way? I'm starting to wonder if I've chose the wrong approach for a simple web server/database server setup. Please forgive my ignorance. Any help would be greatly appreciated.
If both the machines are in the same Virtual Network, then just turn off Windows Firewall and they will be able to ping each other. Other way is to just allow all incoming ICMP traffic in Windows Firewall with Advanced Settings.
However there is a trick. Both the machines will see each other by IP Addresses, but there will be no name resolution in so defined Virtual Network. Meaning that you won't be able to ping by name, but only by direct IP address. So, if want your Website (on VM1) to connect to SQL Server (on VM2), you have to address it by full IP Address, not machine name.
The only way to make name resolution within a Virtual Network is to use a dedicated DNS server, which you maintain and configure on-premises.
This article describes in details name resolution scenarios in Windows Azure. Your particular case is this:
Name resolution between virtual machines and role instances located in
the same virtual network, but different cloud services
You could potentially achieve name resolution, if you put your VMs is same cloud service. Thus you will not even require dedicated virtual network.
If your VMs are inside a Virtual Network in Azure, then you have to make sure two things.
Required Port is enabled.
Firewall is disabled on the server.
I was trying to connect to one VM where SQL Server DB was installed, from another VM. I Had to enable 1433 port in the VM where SQL was installed. For this you need to add an MSSQL endpoint to the VM on the azure management portal. After that i disabled windows firewall. Then i was able to connect to the VM from another.
I am trying to connect my Windows Azure Virtual machines to my On Premise network. I have established a site to site VPN tunnel, and have created the appropriate subnets and placed a virtual machine in one of the subnets that isn't the gateway subnet.
My on premise test network is 192.168.9.x/24 my Azure Network is 10.4.x.x/16 with a subnet for DMZ - 10.4.2.x/24 and ServerNetwork at 10.4.3.x/24.
I have confirmed that the tunnel is up and running both on the Windows Azure side, as well as on my Cisco ASA 5505.
I want my servers to be able to communicate across the tunnel, however currently they cannot see each other. I am missing something, I tried static routes between the two servers, and have not had any success. Has anyone gotten this to work? If so what did you do on the networking side of the config to make it work?
Thanks,
Steve
Windows Azure Virtual Network enables you to create secure site-to-site connectivity, as well as protected private virtual networks in the cloud.
You can specify the address space that will be used for both your virtual network and the virtual network gateway.
Additionally, new name resolution features allow you to connect directly to role instances and virtual machines by hostname.
These features allow you to use Windows Azure as you would a branch office, or as a protected private virtual network in the cloud.
You can read more about it here:
http://msdn.microsoft.com/en-us/library/windowsazure/jj156007.aspx
Here is a lab exercise to walk you through the process:
http://www.windowsazure.com/en-us/manage/services/networking/create-a-virtual-network/