The Challenge: You are providing cloud services for a tenant using vCloud Director (obviously!) and want to provide a dedicated [routed] subnet and firewall services that are managed by the tenant admins.  Apps deployed in this cloud will be utilizing shared infrastructure services – LDAP, patching, scanning, etc – outside the cloud, so you’re trying to avoid NAT due to possible complications introduced by masking/translating source IPs.  Sound familiar?  Read on…
The release of vCloud Director (vCD) v1.5 along with vShield Edge (VSE) v5.0 provided a significant number of in-cloud networking enhancements that put a smirk on the faces of socially awkward cloud geeks everywhere.  Okay, I’ll admit it – the networking capabilities VMware has baked into vCloud Director have been one of the most intriguing components of the solution.  The combination of vCD 1.5 and VSE 5.0, riding on top of vSphere’s native networking capabilities, provide the framework for enhanced (and industry-leading) networking options for your cloud.  Check out the vCD 1.5 Technical Whitepaper for more info on these and other enhancements.
Here are the cliff notes for those who don’t care to read the marketing stuff:
  • improved network isolation at several levels within the cloud,
  • enhanced firewall capabilities,
  • baked-in VPN tunnels and the ability to securely stretch tenant networks across clouds,
  • enhanced NAT’ing flexibility,
  • the addition of static routes and layer-3 routing
Speaking of static routes and layer-3 routing (yep, that’s the best transition I can come up with), I have found many of my customers questioning what is actually possible with the use of these features.  My favorite argument of all is, “NAT does not equal routing!”.  This misconception is probably due to the confusing label of “NAT-Routed” when referring to an external org network behind an auto-provisioned VSE appliance.  That may have been the case with previous versions, but not so today.  In fact, a VSE appliance can perform basic L3 routing functions independent of NAT’ing.  I prefer to avoid NAT’ing (when it’s an option) — and some enterprises have banned it all together across internal networks — so this capability often comes in handy.
It seems that using VSE as a router and/or firewall in vCloud independent of NAT is poorly documented (so I’ve heard).  The following guide walks you through the use case and setting it up in your cloud…
A snapshot of my lab network:

Config Summary:

Physical (Core) Router: 192.168.1.1
vSphere Network:
  • dvSwitch – dvSwitch-Core
  • dvPortGroup – dvPG-Prod
Provider Network:
  • External (Provider) Network: “EZLAB Prod (EXT)”, 192.168.1.0/24
  • Gateway: 192.168.1.1
  • Static IP Pool: 192.168.1.200 – 192.168.1.249

Tenant (Org) Network:

  • Network Pool Type: vCD-NI (VLAN 102)
  • 1 x External Org Network, Direct-Connect
  • 1 x External Org Network, Routed – 10.10.2.0/24
  • vShield Edge Ext IP: 192.168.1.200
  • vShield Edge Int IP: 10.10.2.1
  • 1 x Internal Org Network – 10.10.1.0/24

So, our objective is to provide control over firewall policy, no NAT, and external routing at the org level.  To do this, we need to:

  • Enable Firewall Rules (optional)
  • Disable NAT IP Masquerading in the “NAT Mapping” tab
  • Add Static Routes (only if needed…more on that later)
Right-click on the External Routed Org network (“Eng-EXT-10.10.2.0/24” in my case) and select “Configure Services”.
Firewall: Use the Firewall tab to configure any firewall policies you desire.  This can be done at any time.  I let all the traffic flow in my lab by setting the Default Action to “Allow”: 

 













Disable NAT / IP Masquerade: Go to the NAT Mapping Tab and unselect “Enable IP Masquerade”.  If checked, all outgoing IP traffic will be NAT’d using the VSE’s external IP (192.168.1.200 in this example)…we don’t want that: 

 














Static Routes on VSE: You actually don’t have to create any static routes unless you want to point to a network that the upstream router (the core) is not aware of.  The VSE’s external interface is assigned a next-hop address of my network’s physical gateway.  As long as that router knows how to get other networks, I don’t have to define those routes at the VSE level:

 

 

 

 

 

 

 

 

Static Routes on Physical: Since the External Org network doesn’t exist anywhere on the physical side, you will need to create a static route to it (likely at the L3 core) to advertise the route to other networks (cloud or otherwise).  In EZLAB, the physical router is configured with a static route for each External-Routed Org network.  To do this, I added a route to the 10.10.2.0/24 network using the VSE’s external IP – 192.168.1.200 in this case.  Remember when a VSE device is deployed for a External Routed Org network, the external interface gets an IP from the Provider network’s IP Pool…that’s the IP you want to use for creating the ‘inbound’ static route.

All vApps/VMs deployed in this org and directly connected to this network are assigned a 10.10.2.x address and 10.10.2.1 gateway IP via the VSE’s built-in DHCP server: 

 

 

 

 

 

 

 

 

At this point you will have configured a External Routed Organizational Network that is protected by a Firewall policy, is accessible from external entitites, and contains no NAT.  Give it a shot, share your experiences…

+++++
virtualjad
Categories: Cloud, NSX, VMware