<div dir="ltr">You may well be onto something - I believe this was a Win7 machine. I'll try to confirm tomorrow.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 20, 2015 at 6:28 AM, Marc Luethi <span dir="ltr"><<a href="mailto:netztier.ch@gmail.com" target="_blank">netztier.ch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all<br><br>I suggest to investigate source address selection on the client side, while closely following name resolution (assuming this is similar to Windows 2012R2's DA implementation, DNS64 is supposed to be at work, here) and keeping an eye on the IPv6 routing table.<div><br><div>In your situation, I would presume that the end system ends up with an RFC 4193 address (from the /48 that was initially chosen when DA was set up) on its <i>IP-over-HTTPS</i> tunneling interface (courtesy of the DA implementation) and a global unicast address the (W)LAN interface, based on the CPE's RAs.</div><div><br></div><div>While things <i>should</i> be neat, my experience with Windows 7's way of picking source addresses was so bad ("longest match" seemed entirely unheard-of), I eventually gave up using RFC 4193 addresses for my internal network altogether. </div><div><br></div><div>I repeateadely observed Win7 using its global unicast address(es) to access internal ressources, while stubbornly sticking to te RFC4193 source address when attempting to talk to addresses on the global IPv6 internet. </div><div><br></div><div>cheers</div><div>Marc</div><div><br></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 19 December 2015 at 22:37, Kurt Buff <span dir="ltr"><<a href="mailto:kurt.buff@gmail.com" target="_blank">kurt.buff@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
I ran into an interesting situation some months ago which still<br>
baffles me, and though I was able to work around it, I expect it will<br>
happen again.<br>
<br>
We implemented MSFT DirectAcess at our company quite some time ago<br>
(using 2008R2 and Forefront 2010), and it works extremely well.<br>
<br>
At least it worked well for everyone until one of the employees got<br>
his Comcast connection upgraded, and then DirectAccess didn't work for<br>
that employee any more.<br>
<br>
We proved that if he tethered to his cell phone, that would work, and<br>
if he used an SSL VPN client while on his Comcast connect that would<br>
work, but DirectAccess would not work at home.<br>
<br>
Finally, I discovered that his Comcast-installed router was handing<br>
our IPv6 addresses on his home LAN. Turning that off enabled<br>
DirectAccess to work again.<br>
<br>
We do not have an assigned IPv6 block from our ISP, though of course<br>
MSFT OSes use it, and auto-assign themselves addresses, but for now<br>
we're ignoring it.<br>
<br>
Has anyone run into this problem and solved it - not by turning off<br>
iIPv6 address assignment for the home LAN, but really solved it? If<br>
so, how did you do that?<br>
<br>
Would getting and implementing an IPv6 assignment from our ISP cure<br>
the problem, or make it worse?<br>
<br>
I've found little guidance from MSFT about DirectAccess in an IPv6<br>
environment, though I admit I haven't been terribly diligent in my<br>
searches.<br>
<span><font color="#888888"><br>
Kurt<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><div><div>'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.' </div><div>(Terry Pratchett, in 'Eric').</div><div><br></div><div><a href="mailto:netztier.ch@gmail.com" target="_blank">netztier.ch@gmail.com</a></div></div></div></div>
</font></span></div>
</blockquote></div><br></div>