1

Scenario:

  1. VNET address range is 10.2.0.0/23 with Default subnet of 10.2.0.0/27
  2. Brand new ASE instance, configured to use the VNET from step 1 and on that same Default subnet
  3. MySQL VM joined to VNET from step one at 10.2.0.8, good to go!
  4. Add new Azure Web App to Service Plan of the ASE from step 2
  5. Deploy web site code to Azure Web App that's configured to point to 10.2.0.8 for MySQL VM
  6. Hit web site from step 5 and, when attempting to talk to MySQL VM, it gets denied on network access trying to connect to 10.2.0.8

Now, if I set up a point-to-site and explicitly connect the web app to that point-to-site I can get through, but obviously now all my traffic is going through a gateway and this is not the desired set up. Also, if I use the .cloudapp.net public address (and expose the MySQL port public) I can get through, but obviously that's even worse because I'm going out to the internet. Obviously the whole point of putting the VM and the ASE on the same VNet/subnet is so that they can talk directly to one another.

So, what am I missing? Am I completely off base in my understanding that putting an ASE on a VNet should cause its related apps to run in that same VNet automatically?

  • Did you check NACL and/or NSG on the VM itself and ensure the port level stuff is open? – Taylor Oct 23 '15 at 16:46
  • @Taylor so we're not doing any NSG configuration right now because our understanding was (perhaps incorrect) if everything ended up on the same subnet, which is what our intent was here, we shouldn't need to punch a hole through with an NSG entry. What would be awesome is if I could find the private IP of the web app running in the ASE (whatever the worker pool servers are), but it does not show you that in the portal anywhere. – Drew Marsh Oct 23 '15 at 17:22
  • see my answer but I think you should try having compute and ASE in separate Subnets in the same VNET and see if that works. I dont think you can get a private IP b/c if it works like other "connected" public resources (like API Gateway) the fabric will at times "dance" the services around to account for infrastructure concerns/etc ... so the IP could change .. which is another reason why just saying a separate subnet is "the ase" may work better – Taylor Oct 23 '15 at 17:25
  • Well, I'll give it a shot as I'm dead ended on everything else right now. I did start down this road yesterday by creating a second subnet, but then realized I'd have to get into NSG configuration and haven't done that yet so it'd be a further learning curve. Guess it's worth a try... – Drew Marsh Oct 23 '15 at 17:29
  • When you create an ASE i know the subnet has to be empty, and API Gateway works in a "i need my own space" paradigm ... so def give that a shot – Taylor Oct 23 '15 at 17:38
1

I'm not able to confirm this right now, but I thought the intent was for ASE to be placed in a separate subnet in the VNET from the VM/Compute resources ... vs co-existing with compute. Have you tried placing the ASE and the VMs in separate subnet and seeing if the default or UDR routes for "local" traffic allow the communication to occur if the ASE is allowed to "own" a specific subnet for its work?

  • We haven't tried putting it in a separate subnet yet because then, as you commented above, we'd have to get into punching holes with NSG and we didn't really want to have to do that. As mentioned above, it would be nice if I could tell what the actual private IP of the worker roles in the ASE are so that I could understand if they're actually ending up on the same subnet or not. I would hope they are because all the data from resource manager (and portal) says the ASE is configured to run on same VNet/Subnet, but... clearly there's something amiss here. – Drew Marsh Oct 23 '15 at 17:25
  • Tried this. Threw the MySQL VM onto a 10.2.2.0/27 subnet, separate from the 10.2.0.0/27 subnet the ASE was on, and still no joy. As of now I am blowing away the whole ASE and recreating it because this should "just work" according to everything I've read. – Drew Marsh Oct 25 '15 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.