Yes - we call that "Force Tunneling" in DirectAccess (DA) lingo. Force Tunneling allows you to force all traffic through the DA connection. Some admins consider Force Tunneling to be the last link in the chain of true DirectAccess client security and what truely separate the threat model of a traditional "bolted-in" corpnet clent from a roaming client. When you Force Tunnel your DA clients, all traffic always goes through the DA tunnels. That means you can enforce your Internet connection policies on DA clients like you do on clients that are connected directly to the corpnet. The locks down the threat posed by downloading malware (which is the most often source of zero-day threats) from the Internet.
Force tunneling requires that you always use IP-HTTPS, so there might be a performance hit. Also, you will need to use a Web proxy device that understands IPv6, or use the UAG NAT64/DNS64 to insure seamless Internet connectivity. Finally, you need to consider the perfomance requirements on your corporate Internet link, since all your coprnet and DA clients are going to have to use it. HTH, Tom
Posts: 111
Joined: 23.May2001
From: Skutskär, Sweden
Status: offline
Hi,
I have some questions on this setup. (Force tunneling)
Is it possible to route traffic through the tunnel originating from IPv4-addresses? ,if you have an application accessing IP-address instead of FQDNs.
Is it possible to make all DNS lookups go throuh DNS64? (maybe except da.xdom.real & crl.xdom.real??) ..like add something of a wildcard to make all DNS-querys end up at UAG (DNS64)??. Name Suffix *.* [DNS64]
All domains that you list on the NRPT (except for the exemptions) go through DNS64. And DNS64 always returns an IPv6 address to the DirectAccess client, because the DirectAccess client only understands IPv6 when connecting to the intranet. If you try to use IPv4 addresses, the connection will fail. If all DNS queries go to DNS64, then all the connection requests will go through the DirectAccess server - which means you either need to bounce the connections off the UAG DirectAccess server or configure the DirectAccess clients to use a proxy through your intranet. HTH, Tom
Posts: 111
Joined: 23.May2001
From: Skutskär, Sweden
Status: offline
Tom, thanks for explaining..
I tried som stuff in the NRPT registry values: Test 1: *.net (resolve the root-domain .net) HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig Key: "UAGDA Rule 1" "Name" .net
In both cases ping resolvs throu DNS64 on UAG (passing it on to internal DNS servers) and everything resolves OK. (*.net in test 1. & all DNS querys in test2)
But surfing through ie (proxy enabled) fails as explained: In test 1 DA client can access all webpages exept pages ending with .net (ex. java.net fails) looking at ipconfig /displaydns you can see that java.net is present with a IPv6 address, but ex. hp.com is not present in DNS cache which works just fine in ie. (hp.com is not resolvet at client) Looking at UAG (DA) java.net is denied with its IPv6
In test 2 DA client cannot access any webpages at all. And it looks lite nothing is sent to proxy, UAG denys it all with IPv6-addresses ipconfig /displaydns you can see all lookups to the faild webpages, and there is nothing sent to proxy.
This odd because the DNS64 service in a web proxy scenario isn't doing any name resolution - the web proxy typically does name resolution on behalf of the client.
The NAT64 component will enable you to connect to an IPv4 web proxy server, such as the TMG firewall, since it will translate the IPv4 address of the web proxy listener. But name resolution takes place in the client/server web proxy "tunnel".
Posts: 111
Joined: 23.May2001
From: Skutskär, Sweden
Status: offline
quote:
ORIGINAL: tshinder This odd because the DNS64 service in a web proxy scenario isn't doing any name resolution - the web proxy typically does name resolution on behalf of the client.
I totaly agree! And nameresolution of sites visited should not typically get DNScached at DA client at all (ipconfig /displaydns)
quote:
ORIGINAL: tshinder The NAT64 component will enable you to connect to an IPv4 web proxy server, such as the TMG firewall, since it will translate the IPv4 address of the web proxy listener. But name resolution takes place in the client/server web proxy "tunnel".
Yes, as in this case an internal ISA proxy (on same DMZ as the UAG-DA server) And when in this case, NRTP table contains <"Name" *.net> the ISA proxy does not receve any "proxy traffic" regarding *.net-websites from DA client at all. Seems like DA client tryes to "surf" outside "proxy tunnel" and therefore doing the nameresolution itself. Traffic to *.com sites is confirmed as going through "proxy tunnel" I have now confirmed FW/Proxy-Logs on ISA, TMG(DA) and Netmon traces that this behavour is occuring.
Either; 1. this is an effect of something beeing micongured or. 2. Or NRTP config with DNS64 lookup take presence over proxy in ie.
Anyone else seen this behavour? .......... EDIT: figured that maybe "Bypass proxyserver for local addresses" might be involved in this, and somehow IE would consider all websites in *.net "zone" as internal, Tried to uncheck, but no success still. .......... Cheers =)
< Message edited by PatrickM -- 2.Feb.2011 7:42:53 AM >
When you configured the UAG SP1 DirectAccess server, did you configure force tunneling to use a web proxy, or did you configure it to "bounce" the connection off the DirectAccess server?
The NAT64 component will enable you to connect to an IPv4 web proxy server, such as the TMG firewall, since it will translate the IPv4 address of the web proxy listener.
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [Forefront Unified Access Gateway 2010] >> DirectAccess >> Can I send all traffic through the DirectAccess Connection? 
Can I send all traffic through the DirectAccess Connect... - 
"Name" .net 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread