none
Can I use a forefront TMG to act as a virtualization gateway ?

    Question

  • Most customer deployments require communication from the network virtualized environment to the non-network virtualized environment. Therefore Hyper-V Network Virtualization gateways are required to bridge the two environments. The gateway is designed for when the VMs within the virtualized network need to communicate with physical devices outside the Virtualized Network. (source Technet)

    Question 1 : Can I use a forefront TMG to act as a virtualization gateway ?

    Example :   INTERNET (briged to physical network card)  <<====>> FOREFRONT TMG VM <<====>>  LAN (Virtualised Network) <<==>> client VM in Virtualised Network

    I have already tried to give internet access to a VM machine in a virtualized network throught Forefront TMG but i was no able to do it.The machine was able to communicate with TMG but not with internet. (It was working with a non virtualised netwwork.)

    My configuration example : (Source : Keithmayer blog on Technet)

    My Forefront TMG IP adress is 10.1.1.11 and my client machine is 10.1.1.12

    1. Enable the Windows Network Virtualization binding on the physical NIC of each Hyper-V Host ( Host 1 and Host 2 )

    Enable-NetAdapterBinding Ethernet -ComponentID ms_netwnv


    2. Configure Blue Subnet Locator and Route records on each Hyper-V Host ( Host 1 and Host 2 )

    New-NetVirtualizationLookupRecord -CustomerAddress "10.1.1.11" -ProviderAddress "192.168.1.10" -VirtualSubnetID "6001" -MACAddress "101010101105" -Rule "TranslationMethodEncap"

    New-NetVirtualizationLookupRecord -CustomerAddress "10.1.1.12" -ProviderAddress "192.168.1.20" -VirtualSubnetID "6001" -MACAddress "101010101107" -Rule "TranslationMethodEncap"

    New-NetVirtualizationCustomerRoute -RoutingDomainID "{11111111-2222-3333-4444-000000000000}" -VirtualSubnetID "6001" -DestinationPrefix "10.1.1.0/24" -NextHop "0.0.0.0" -Metric 255

    3. Configure the Provider Address and Route records on Hyper-V Host 1 ( Host 1 Only )

    $NIC = Get-NetAdapter Ethernet

    New-NetVirtualizationProviderAddress -InterfaceIndex $NIC.InterfaceIndex -ProviderAddress "192.168.1.10" -PrefixLength 24

    New-NetVirtualizationProviderRoute -InterfaceIndex $NIC.InterfaceIndex -DestinationPrefix "0.0.0.0/0" -NextHop "192.168.1.1"


    4. Configure the Provider Address and Route records on Hyper-V Host 2 ( Host 2 Only )

    $NIC = Get-NetAdapter Ethernet

    New-NetVirtualizationProviderAddress -InterfaceIndex $NIC.InterfaceIndex -ProviderAddress "192.168.1.20" -PrefixLength 24

    New-NetVirtualizationProviderRoute -InterfaceIndex $NIC.InterfaceIndex -DestinationPrefix "0.0.0.0/0" -NextHop "192.168.1.1"


    5. Configure the Virtual Subnet ID on the Hyper-V Network Switch Ports for each "Blue" Virtual Machine on each Hyper-V Host ( Host 1 and Host 2 )

    Get-VMNetworkAdapter -VMName Forefront | where {$_.MacAddress -eq "101010101107"} | Set-VMNetworkAdapter -VirtualSubnetID 6001Get-VMNetworkAdapter -VMName Client | where {$_.MacAddress -eq "101010101105"} | Set-VMNetworkAdapter -VirtualSubnetID 6001 

    Question 2 : Why myy packets are not routed Thourought forefront TMG ?

    I hope you can give me some help.
    Aurel



    • Modifié Aurel2013 lundi 18 février 2013 16:58
    lundi 18 février 2013 16:55

Réponses

  • Okay I think I understand. You confused me with "network virtualization gateways" as they do not apply here. Per your diagram and your description, I think you are having trouble access the internet from VM02 through TMG on VM01? Is that correct?
    mardi 19 février 2013 16:45
  • The assumption with Network Virtualization is that the .1 is your gateway.  You need to align with that assumption.

    So, whatever you are using as the Gateway (router of some style in a VM) it needs that IP for one of its interfaces.  Everything beyond that is about routing rules within that gateway.  So it knows to properly forward.

    If inside your TMG VM you can 'see' the traffic from the other VM then you have the virtual network working properly and it is up to TMG to forward form the virtual network NIC to the second vNIC which would have a vSubnet ID of 0 and no routing rules.

    And yes, without a gateway the members of a Virtual Network can only talk to each other.  The Gateway is required for the network traffic to exit the virtual network to the physical fabric.

    My question is if you attempting to use a virtualized network in a place that is better suited for an Internal or Private switch.  Or you are using the virtual network instead of a private switch (so the VMs can be on any host).

    Beyond that, I can give all kinds of warnings about managing this over time.  So if this is a demo, fine, if this is production, you need a management layer to mange the routing rules.


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    jeudi 21 février 2013 19:15

Toutes les réponses

  • Most customer deployments require communication from the network virtualized environment to the non-network virtualized environment. Therefore Hyper-V Network Virtualization gateways are required to bridge the two environments. The gateway is designed for when the VMs within the virtualized network need to communicate with physical devices outside the Virtualized Network. (source Technet)

    Can you define more about what you mean by the above statement? I disagree that most deployments require the use of network virtualization gateways. In fact, I think it is the opposite. Are you maybe confused with the virtual switching concepts (external, internal, private) and the network virtualization concepts? I think the solution you need is to use an external virtual switch?
    lundi 18 février 2013 17:37
  • Hello,

    Thank you for your asnwer .

    I have made a schema to explain what I want to do :

    I don't want to use a dedicated network card for communication between VM01 and VM02 because SRV01 and SRV02 have only 2 network card and host lot's of VM . That is the reason why the best is to use network virtualization.



    mardi 19 février 2013 13:04
  • Okay I think I understand. You confused me with "network virtualization gateways" as they do not apply here. Per your diagram and your description, I think you are having trouble access the internet from VM02 through TMG on VM01? Is that correct?
    mardi 19 février 2013 16:45
  • Hello Ted,

    Yes correct.

    VM02 is able to PING VM01 (TMG) and VM01 (TMG) is able to ping VM02. But VM02 is unable to acess to Internet.

    On SRV02 with a protocol analyser I can see the  packet from VM02 to VM01. but I am not able to see any packets to Internet.

    mercredi 20 février 2013 09:29
  • Maybe I'm misreading the drawing, but shouldn't your gateway for VM02 be 10.1.1.11 (VM01 - TMG)?
    mercredi 20 février 2013 16:55
  • Hello,

    Correct there is an error in the drawing. The correct gateway is 10.1.1.11 (VM01 - TMG). The drawing have been updated.

    jeudi 21 février 2013 16:44
  • The assumption with Network Virtualization is that the .1 is your gateway.  You need to align with that assumption.

    So, whatever you are using as the Gateway (router of some style in a VM) it needs that IP for one of its interfaces.  Everything beyond that is about routing rules within that gateway.  So it knows to properly forward.

    If inside your TMG VM you can 'see' the traffic from the other VM then you have the virtual network working properly and it is up to TMG to forward form the virtual network NIC to the second vNIC which would have a vSubnet ID of 0 and no routing rules.

    And yes, without a gateway the members of a Virtual Network can only talk to each other.  The Gateway is required for the network traffic to exit the virtual network to the physical fabric.

    My question is if you attempting to use a virtualized network in a place that is better suited for an Internal or Private switch.  Or you are using the virtual network instead of a private switch (so the VMs can be on any host).

    Beyond that, I can give all kinds of warnings about managing this over time.  So if this is a demo, fine, if this is production, you need a management layer to mange the routing rules.


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    jeudi 21 février 2013 19:15
  • Oh, and this:

    http://itproctology.blogspot.com/search?q=WNV


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    jeudi 21 février 2013 19:17