Hi There!
Anyone knows if its possible to connect V1 (Classic) to V2 (ARM) VNETS while the both reside under different subscriptions?
i read the following article:
https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-vnet-vnet-rm-ps/
but the examples here show how to connect different (V1 and V2) VNETS but on the same subscription.
thanks.
I had been recently evaluating network capabilities of Microsoft Azure and found an undocumented reverse connection option that looked interesting to me.
It looks like there is a feature (or bug) in the configuration of "Point-to-Site" VPN client of Microsoft Azure. This feature allows me to connect back from any Windows Virtual Machine running in my Microsoft Azure subscription to local VPN clients
via RDP session.
I describe my findings below.
Short description
In usual conditions a "Point-to-Site" VPN connection drops in the case when you try to connect back to physical or virtual client machine that initiated this VPN connection, but as I found it survives if the initial VPN connection was done inside
the RDP session established to the physical or virtual machine.
Question
Can anyone explain technical reasons of the observed behavior: P2S VPN connection drops in the case when you try to connect back to a physical or virtual machine but survives in case of existing RDP from that machine?
The matter is I can see hidden security risks for my customers in case of misusing this backdoor by IT staff. So I want to understand the core reasons why it happens.
Initial conditions
Assume you have a Virtual Network ("VNET") in your Azure subscription with configured "Point-to-Site" VPN.
You have a Virtual Machine running Windows ("Azure VM"); it has Remote Desktop client ("RDP").
You also have a physical or virtual local machine with <g class="gr_ gr_126 gr-alert gr_gramm gr_disable_anim_appear Grammar multiReplace" data-gr-id="126" id="126">installed</g> "Point-to-Site" VPN client
for Microsoft Azure. Let's name it "Local PC #1".
You establish a Remote Desktop session from "Local PC #1" to "Azure VM"; let's name this connection "RDP Azure VM". You initiate and open a "Point-to-Site" VPN connection from "Local PC #1" to your "VNET"
as usually.
As a result, you can connect to your resources hosted in Azure subscription using private IP addresses of "VNET".
Attempt to connect back #1
If you try to connect back from "RDP Azure VM" to your "Local PC #1" using RDP client of "RDP Azure VM" and IP address issued to "Point-to-Site" VPN client of "Local PC #1" the connection fails *. It happens
because your "Point-to-Site" VPN session immediately disconnects as it should be (no shared connection allowed).
* You can easily find this IP address in a number of ways, for example:
- On the VPN client machine using "<g class="gr_ gr_162 gr-alert gr_spell gr_disable_anim_appear ContextualSpelling ins-del multiReplace" data-gr-id="162" id="162">ipconfig</g>" and exploring the section "PPP
adapter <name of your VNET>".
- On the portal.azure.com under All resources > (your VPN gateway) > Point-to-site configuration > Allocated IP addresses (for Resource model VNET).
- On the portal.azure.com under All resources > (your VNET) > VPN connections > (n) clients > IP addresses (for Classic model VNET).
- A simple Powershell script that just iterates a potential set of IP addresses of your VPN pool accessible from "Azure VM".
Special conditions
Assume you have a second local machine, let's name it "Local PC #2", and you establish a Remote Desktop session from "Local PC #2" to "Local PC #1"; let's name this connection "Local RDP PC #1".
After that, you install "Point-to-Site" VPN client for Microsoft Azure inside the RDP connection "Local RDP PC #1".
You initiate and open a "Point-to-Site" VPN connection from "Local RDP to PC #1" to your "VNET" as usually.
As a result, you can connect from "Local RDP PC #1" to your resources hosted in Azure subscription using private IP addresses of "VNET".
Now please find and remember the IP address issued to "Point-to-Site" VPN client of "Local RDP PC #1".
Let's name it "Local RDP IP of VPN Client".
- Refer to the previous chapter to find this IP address.
- Note this IP address issued to "Local RDP PC #1" is different from the one issued to "Local PC #1" because technically there are two different VPN clients who established connections.
Attempt to connect back #2
If you try to connect back from "RDP Azure VM" to your "Local RDP PC #1" using RDP client of "RDP Azure VM" and IP address issued to Point-to-Site VPN client of "Local RDP PC #1" ("Local RDP IP of VPN Client",
see above) the connection somehow succeeds while there is still no shared connection allowed. As a result, you can access any resources of "Local PC #1" and other machines of LAN from "RDP Azure VM" using RDP connection established to "Local
RDP PC #1".
As you can see there is an unexpected and undocumented difference in reverse connection behavior between "Attempt to connect back #1" and "Attempt to connect back #2".
Tested environments
Reverse connection has succeeded at least in the following client VPN environments of mine:
- Windows 7
- Windows Server 2008 R2, Standard Edition
- Windows 8.1
I am using a simple internal Active Directory Domain Services (AD DS) domain environment (with about 4 VM's total in it, 2 of them are domain controllers) that forward requests outside the domain to Google DNS servers (8.8.8.8 and 8.8.4.4). Sometimes my nslookup's on www.dropbox.com on my Azure VM's will not resolve (can't open the page, etc.). This problem is very random and can sometimes last for 30 minutes or so and then it magically is all working again out of nowhere. However, not on an Azure VM all is great and I am able to resolve www.dropbox.com. Is there something I am missing on an Azure VM that would need to be in place for reliable DNS lookups to the internet? I do know at one point there was an Azure DNS server that could be used but not sure if that is the case anymore or not. Thanks in advance!
Disclaimer: Networking is not my strong point so the below might just be complete gibberish :-)
My company has setup ExpressRoute to allow traffic from the company internal network to Office365 to travel across the ExpressRoute instead of the public internet.
We are now beginning to look at getting access to on-prem internal resources via ExpressRoute for applications we develop and run in Azure.
Our preference have been to run our apps as *.azurewebsites.net and my understanding is that only Public Peering is available for azurewebsites, which requires an expensive App Service Environment.
Is this something that may change and Private Peering would be possible for azurewebsites.net as well or are azurewebsites stuck with Public Peering due to some technical limitation?
What are our options to get on-prem connectivity via ExpressRoute if we don't want to use ASE? Move apps to run on VMs or Cloud Services (*.cloudapp.net), which do support Private Peering?
Would it be possible to go from an AzureWebsite to ExpressRoute via Private Peering by going via a Cloud Service that has 2 VNETS configured (one connected to express route and another that azurewebsites would connect to)?
Cheers
Martin
Hi,
I have set up Virtual Machine on Microsoft Azure. I would like to connect external business entity but it needs hardware VPN to be set up within Azure.
Can anyone please help on this?
Thanks in Advance.
Regards,
Delphian
Hi All,
I'm trying to make a Site-to-Site VPN connection between Cyberoam(CR100ia10.04.2 build 527) and Azure VNet by following the instructions from here http://kb.cyberoam.com/default.asp?id=2936&Lang=1.
I've used the exact settings/configurations used in the instructions and able to established a connection as the status of the Gateway of the VNet says it's connected.
I can also ping a local pc on VPN from Azure VM but the problem is that I cannot ping/rdp/access shared folder of the Azure VM from local pc.
I tried disabling firewall on both systems and still no luck.
I can ping VM's on the same VNet with no problem.
Cyberoam wasn't on the device list provided here https://msdn.microsoft.com/library/azure/jj156075.aspx so I have no scripts or templates.
Any help would be greatly appreciated.
Thanks!
This is for issues using the CLI commands to import a zones into DNS Zones (Preview). Basically after the import, the zone file is missing some of the records. Mostly got somewhat cryptic related warnings, in one case the CLI command did not produce a warning
The source of the zone file is 'Windows 2008 R2 Standard' . I have resolved the problems by manually creating the problem records. I hope this will be forwarded to the Dev team to resolve the problem or document work a around for the issues.
1) the most serious problem is that it did not import the SPF record and it did not show any warning to that fact.
2) The Windows 2008 R2 zone file has banks in the host field when there are more than one IP for the host (for round robin lookups). I fixed the zone file and re-imported to correct the problem. This would be helpful if it was fixed to handle that or provide that as a warning in the documentation.
3) It did not import the MX record for the zone. The warning is very cryptic:
\warn: g record set "@" of type "MX"
Hi everyone, I'm trying to setup a VPN S2S between two differents Azure VNET (under the same subscription).
Here the steps I've just done:
- create a Virtual Network in Europe
- add.space: 10.11.0.0/16
- sub: 10.11.0.0/24
- create a Virtual Network in US
- add.space: 10.12.0.0/16
- sub: 10.12.0.0/24
- create a GW subnet in Europe (CIDR 10.11.255.0/27)
- create a virtual network gateway (under the vnet in Europe) with pubblic ip 13.81.113.111
- create a GW subnet in US (CIDR 10.12.255.0/27)
- create a virtual network gateway (under the vnet in US) with pubblic ip 13.91.111.105
- create local network GW in Europe entering the US address space (10.12.0.0/16) and pubblic ip address 13.91.111.105
- create the VPN connection specifying the two Vnet GW and the shared key
- the connection status was "connected"
Now the test: I've deployed two vm under the two location. The Europe VM has the internal ip 10.11.0.4 and the US VM has 10.12.0.4.
What I want is to give the possibility to ping each other.....but the VM can't ping :(
Am I wrong/miss something?
Thank you very much
We have a Route-based VPN setup in Azure, connecting to a SonicWall NSA 3600.
We followed the SonicOS 6.2 – Microsoft Azure Configuration Guide when configuring the VPN. With the Tunnel Interface enabled, we were able to ping from Azure LAN to our local LAN, but could not ping the other way.
I double-checked the SonicWall static route we created for the Azure LAN, and tried removing it and re-adding it.
When I change the SonicWall VPN type to Site-to-Site, we can ping both ways?
SonicWall IKE settings are:
IKEv2 Mode
Group 2
AES-256
SHA1
28800
IPSEC:
ESP
AES-256
SHA1
PFS unchecked
3600
Keep Alive checked, everything else unchecked.
Hi,
I assigned a static internal IP address to a VM in Azure. Is the static internal IP address automatically released after the VM and its NIC deleted, or do I need to take any specific action to release that static IP for other VMs?
Thanks!
Julie
I have a VPN setup between local network and an Azure network. I am able to access resources on the Azure network when on the local network with no issues. I am also able to access local resources from the Azure network. I have a SSL VPN setup to the firewall of the local network. When connected to this SSL VPN I am able to access local network resources remotely. However I am unable to access resources in the Azure network when connected to the SSL VPN.
Current setup is Dell SonicWall firewall connecting local network to the Azure network via site to site VPN. SSL VPN is setup on the SonicWall firewall to remotely connect to the firewall, local and cloud resources remotely. There is no issue with the VPN connection. Firewall config has been verified with Dell. It has also been verified that packets are being forwarded from the firewall using the correct address space.
Has anyone else experienced this issue and if so how was it resolved?
Dears
I have a problem with azure
I have one VM (File server with DFS ) hosted in azure and Ihave one VM (FS with DFS ) internal in our network
The 2 VM It is connected through AZure Vpn Client Point to Site , I am needing to configure auto connect and disable idle time .
I would like to configure two external IPs.
But before add two local network 10.0.0.0 and 10.0.1.0 and link them with one Ethernet interface.
I have followed the steps in the following link to connect two Virtual Networks:
https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-vnet-vnet-rm-ps/
Each VNet contains two subnets: "Front", where a single VM is located, and "GatewaySubnet", where the Virtual Gateway is located.
The gateways were created correctly:
I have verified that the Gateway connection between Vnet 1 to Vnet 2, and vice versa, works:
However, I cannot ping the VM in Vnet 2 from the VM in Vnet 1, and vice versa:
I am using Azure Resource Manager. How can I route inter-VNet traffic correctly?
Following these instructions:
Attempting to run the following step:
'Get-AzureVM -ServiceName AzureDC1 -Name AzureDC1 | Set-AzureStaticVNetIP -IPAddress 10.0.0.4 | Update-AzureVM
PS C:\users\user\downloads> Get-AzureVM -ServiceName SERVICENAME -Name COMPUTER1 |Set-AzureStaticVNetIP -IPAddress x.x.x.x |Update-AzureVM
Getting the following error:
Update-AzureVM : BadRequest: The value for parameter 'SubnetNames' is null or empty.
OperationID : '994946d2851d0d2f8024d72243d56dab'
At line:1 char:99
+ ... s x.x.x.x |Update-AzureVM
+ ~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Update-AzureVM], ComputeCloudException
+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.IaaS.UpdateAzureVMCommand
Note: The machine is currently turned off.
My client is using Azure DNS nameservers for their DNS records/SOA. We noticed this morning that they were receiving no mail and their website returned a "server DNS address could not be found" error.
NSLOOKUP yields a "Non-existent" domain for any record lookup. The records themselves are still present in the portal.azure.com "DNS Zones" section.
Specifying Azure's nameservers resolves the records fine; literally every other nameserver yields the "non-existent" error.
What can this be?
Hi,
In the Classic Azure VM, I can add a new endpoint to map public port 443 to private port 3389 for RDP. How can I do that for the new Azure VMs? I looked into Network Security Group, but didn't find a way to do the same thing.
Thanks!
Julie
Hi, in our company we have a VM in a 3rd party could provider that we would like to be able to connect using Virtual Network with a new VM that we have now in Azure, is this possible?
I am asking because I have read articles that mention only Azure -> company network but I can't find Azure to another Could provider.
Is this possible?
JV
I'm trying to setup a haproxy + keepalived cluster - the problem i'm having is the virtual_ipaddress in the keepalive config, seems to be bonding to both hosts, so I dont think keepalived is working as it should !!!
master node ip details
[root@weeu-c-u-pxy01 conf.d]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0d:3a:25:dc:14 brd ff:ff:ff:ff:ff:ff
inet 10.20.1.39/27 brd 10.20.1.63 scope global eth0
valid_lft forever preferred_lft forever
inet 10.20.1.51/32 scope global eth0
slave node ip details
[root@weeu-c-u-pxy02 conf.d]# ip aMaster node
vrrp_instance VI_1 {
notify /usr/local/bin/keepalived-notify.sh
smtp_alert
virtual_router_id 51
state MASTER
interface eth0
priority 151
advert_int 1
virtual_ipaddress {
10.20.1.51
}
track_script {
haproxy
}
}
Slave node
vrrp_instance VI_1 {
notify /usr/local/bin/keepalived-notify.sh
smtp_alert
virtual_router_id 51
state MASTER
interface eth0
priority 91
advert_int 1
virtual_ipaddress {
10.20.1.51
}
track_script {
haproxy
}
}
Does this have something to do with multicast / unicast not being supported ???
regards
James
