TechOnTip Weblog

Run book for Technocrats

Archive for December, 2012

Microsoft Direct Access – Basic Architecture Options

Posted by Brajesh Panda on December 29, 2012

Click here for other Direct Access related articles.

Microsoft  Direct Access 2012’s basic architecture options. Will add load balancer in next version. Let me know if I got something wrong or any other good suggestions.

Posted in Direct Access, IPv6 | Tagged: , , , , | 4 Comments »

Microsoft Direct Access – When what type of IPv6 Transition Technology used by Direct Access Client?

Posted by Brajesh Panda on December 23, 2012

Click here for other Direct Access related articles.

Direct Access server can be configured for all three internet IPv6 Transition Technologies i.e. Teredo, 6to4 & IP-HTTPS. As per server config group policy get applied on clients. So if server is configured for all 3 transition technologies & GPO is applied accordingly, when what type of IPv6 transition technologies is used by direct access clients???

This post describes the same. These are my screenshot notes from TechNet Article.



Posted in Direct Access | Tagged: , , | 6 Comments »

Microsoft Direct Access – How DNS64 & NAT64 works?

Posted by Brajesh Panda on December 23, 2012

Click here for other Direct Access related articles.

As I said in my previous article Direct Access is an IPv6 only technology; Direct Access clients talk to Direct Access Server using IPv6 technologies. (Don’t forget this communication happens using IPv6 transition technologies i.e. IPV6 encapsulation in IPv4 packets.). As client to server communication happens using IPv6, Name lookup also happens using IPv6 & AAAA query. So if a internal server has IPv6 address it is easy for the client to start communication. But if internal server is only IPv4 configured, how it will communicate. This is where DNS64 and NAT64 come into the picture.  So NAT64/DNS64 are needed when you want to have IPv6 communication over IPv4 network. For other way round look forward to next article.

  • So IPv6 enabled DA Clients send an IPv6 host resolution query (AAAA Query- Quad A query) to Direct Access Server.
  • In Direct Access Server DNS64 (DNS 6 to 4 Proxy) accepts this query & contact internal corporate DNS server as per Direct Access Servers own internal DNS IP Address config.
  • Internal corporate DNS server hands over either IPv6 or IPv4 or both addresses for the internal destination application server to DNS64. This depends on what kind of address internal app server is registered with internal dns server.
  • If DNS64 receives both IPv6 & IPv4 address it hands over the IPv6 address to DA Client. DA Client starts communication to that IPv6 address of destine application server.
  • If DNS64 receives only IPv6 address from the internal Corporate Server, it hands over that IPv6 IP to the Direct Access Client. DA Client starts communication to that IPv6 address of destine application server.
  • If DNS64 receives only IPv4 address from the internal corporate server, it cannot hand over that to Direct Access client; because DA client is not aware of IPv4 address. So it handover that address to NAT64 service in the same server.
  • NAT64 service converts that IPv4 address to IPv6 by using it’s configured IPv6 Prefix
  • Then DNS64 hand over the translated IPv6 address to the DA Client
  • Then DA Client sends it’s communication to above IPv6 address thru Direct Access Server
  • In Direct Address server NAT64 captures the IPv6 communication packets as it is carrying it’s NAT64 prefix.
  • Then NAT64 removes its proxy and creates an IPv4 payload of same data and forwards to the destination application server.
  • When NAT64 receive a reply for that packet, again it creates IPv6 address using prefix & forward to Direct Access client & continues.
  • Just to remember; When Direct Access Server is load balanced, these translation packets carry same nodes address so reply come to the same node, which did the translation.
  • Here is a nice article about this functionality with some good picture; http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
  • In Windows 2008 R2 version Direct Access, DNS64 & NAT64 were not inbuilt so had to use UAG or any other 3rd party product and in UAG we have to configure NAT64 prefix.
  • But in Windows 2012 NAT64 &DNS64 are integrated, so we don’t need UAG, Also we don’t need to configure any separate prefix per say.

Other Direct Access Articles

Microsoft Direct Access & IPv6 Transition Technologies

Posted in Direct Access, IPv6 | Tagged: , , | 13 Comments »

Microsoft Direct Access & IPv6 Transition Technologies

Posted by Brajesh Panda on December 23, 2012

Click here for other Direct Access related articles.

  • Direct Access is a completely IPv6 Technology
  • DirectAccess uses IPv6 with IPsec to create a secure connection between DirectAccess client computers and the internal corporate network.
  • However, DirectAccess does not necessarily require connectivity to the IPv6 Internet or native IPv6 support on internal networks.
  • Instead, it automatically configures and uses IPv6 transition technologies to tunnel IPv6 traffic across the IPv4 Network
    • Over IPv4 INTERNET (Extranet) it can use 6to4, Teredo and IP-HTTPS
    • Over IPv4 INTRANET it use any one between ISATAP, NAT64 and DNS64
  • These IPv6 transitioning technologies provide automatic tunneling between two Dual-Stack devices; here tunnel doesn’t mean a typical vpn like tunnel. Tunnel refers to encapsulation and they also auto assign IPv6 address to the participating hosts.
    • So IPv6 transitioning technologies encapsulate IPv6 packet with an IPv4 Packet Header

    • As per Dual Stack is concern, it refers to how IPv6 Stack is implemented in that device
      • Dual IP Layer – Common Transport Stack

      • Dual Stack Layer – Different Transport Stack

  • Extranet (Internet) IPv6 Transitioning Technologies
    • 6To4
      • It is an address assignment and dual stack IPv6 tunneling technology
      • Used to provide Unicast IPv6 connectivity between IPv6 sites & hosts across IPv4 Internet
    • Teredo
      • It provides address assignment and automatic tunneling for unicast IPv6 connectivity across the IPv4 Internet, even when IPv6/IPv4 hosts are located behind one or multiple IPv4 NATs.
      • Known as IPv4 NAT Traversal (NAT-T) for IPv6. To traverse IPv4 NATs, IPv6 packets are sent as IPv4 UDP messages.
      • Due to nature of UDP Teredo provides more performance than other transition technologies.
      • It is designed as last resort transition technology for IPV6. It only used where native IPv6, ISATAP or 6To4 connectivity is not possible.
    • IP-HTTPS
      • Like other extranet IPv6 transition technologies, IP-HTTPS auto assigns globally routable IPv6 address to IPv4 enabled hosts.
      • IP-HTTPS establish connectivity by tunneling IPv6 packets inside an IPv4-based HTTPS session.
      • IP-HTTPS is used instead of HTTP so that Web proxy servers will not attempt to examine the data stream and terminate the connection.
      • On certain networks, Internet firewall settings may prevent successful client connections using the 6to4 or Teredo IPv6 transition technologies; but IP-HTTPS bring more flexibility due to HTTPS
      • IP-HTTPS implementation in Windows 2012 Direct Access is different from Windows 2008 R2 Implementation.
      • In Windows 2008 R2 Direct Access with Windows 7 clients also use IPSec encryption for data transfer. Resulting IPSec Encryption inside SSL Encryption tunnel. This brought more overhead & performance issues.
      • Windows 2012 implementation brings more enhancement & performance to the protocol by implementing SSL with NULL encryption. Null encryption allows for authentication to take place during the SSL handshake. Once the SSL handshake has completed all messages flow without being encrypted over that socket.
      • Windows 7 Direct Access deployment needs Computer Certificate for each IP-HTTPS client. But Windows 8 Direct Access deployment don’t need a Computer Certificate for IP-HTTPS client
      • In Windows Server 2012, a new feature solves issues while Direct Access client is behind a proxy server. Specifically, the user can configure IP-HTTPS to work when behind a proxy that is not configured using WPAD (Proxy Discovery) and IP-HTTPS will request and provide the proxy credentials needed to IP-HTTPS request authenticated, and relay it to the DirectAccess server.
      • IP-HTTPS can use a valid Public/Private SSL cert generated from CA or Self Signed Certificate.
  • Intranet IPv6 Transitioning Technologies
    • ISATAP
      • Stands for Intra-site Automatic tunnel Addressing Protocol
      • It is an address assignment and dual stack IPv6 transitioning/tunneling/encapsulating technology
      • It doesn’t need any manual configuration. It can automatically assign IPv6 address using auto configuration mechanism & tunneling
      • Used to provide Unicast IPv6 Connectivity between IPv6/IPv4 hosts across an IPv4 intranet
      • ISATAP mostly used to provide auto IPv6 Address to intranet servers
      • If we are using ISATAP and want to establish connectivity to another IPv6 subnet we need ISATAP Router
    • NAT64 & DNS64
      • Unlike other intranet & extranet IPv6 transition technologies; NAT64 & DNS64 don’t provide encapsulation or tunneling of IPv6 packets over IPv4 packets
      • Windows 2008 R2 Direct Access deployment doesn’t provide these two options out of box. And Direct Access needs these two features to work. Microsoft UAG (Unified Access Gateway) provides these two options & you have to configure little bit. If you don’t have UAG; you need a 3rd party component to deploy them.
      • Windows 2012 Direct Access provides these two features out of box & you don’t need to configure anything.
      • NAT64 & DNS64 work hand in hand
      • NAT64 is a network translation service, which provides IPv6 to IPv4 Address Translation i.e. it translate Direct Access Clients IPv6 traffic to IPv4 to reach internal servers; not other way round i.e. it is Unidirectional. So any intranet server needing access to Direct Access Clients needs to have their own IPv6 Address using static assignment or ISATAP technology.
      • DNS64 is a DNS Proxy service provides DNS service for Direct Access Clients.
      • DNS64 takes DNS resolution request from IPv6 client and query to corporate dns server & return the address. In case query resulted a IPv4 address, it take help from NAT64 to generate a corresponding IPV6 address and handover to direct access client. See other article to understand how NAT64 & DNS64work hand in hand.

Posted in Direct Access | Tagged: , | 4 Comments »

EMC VNX: Volume is unreachable by server_2, Message ID: 13690601492

Posted by Brajesh Panda on December 6, 2012

I was running out of space in NFS stores, which are assigned to VMware farm. I created two LUNs added to ~filestorage Storage Group.

To get them detected by the NAS Pool quickly I ran Storage Scan from Unisphere; ended up with below error;

Discovering storage on corp-cstst-01 (may take several minutes)
d7 d10 d8 d9 d11 d12 d13 d15 d14: volume is unreachable by server_2.ch

Message ID: 13690601492

Also tried to scan from “nasadmin” shell using “server_devconfig server_2 -c -s -a” but ended up nearly same kind of error. Which I forget to noted down. 😉

Later on while troubleshooting found all disks (LUNs) assigned to ~filestorage Storage Group are only attached to one data mover server i.e. Server_2. As my two new luns are not showing I removed them & did couple of scanning but no luck.

After working with EMC Engineering Support found this is a bug in my existing NAS code; which has been fixed in 7.0.54.x higher. EMC engineer referred to EMC Primus article emc295151 but never gave me a copy though and told me to stay away from that debug page ;-(

Well he logged me into VNX Debug URL (https://StorageProcessorIP/debug) & then we ran “Force full poll” in both storage processor and after completion storage processor scan in nasadmin shell. It helped to rebind those LUNs to both data mover servers.

Ten added my two new luns & checked status with “nas_disk -l“, they are still unassigned to server_3.
After running a storage scan they automatically assigned to server_3. And I am able to create new NFS stores.

Posted in EMC Storage | 2 Comments »

 
%d bloggers like this: