Curious situation - not urgent, but I'd like to know more

[Kurt Buff]

You may well be onto something - I believe this was a Win7 machine. I'll
try to confirm tomorrow.

On Sun, Dec 20, 2015 at 6:28 AM, Marc Luethi <netztier.ch at gmail.com> wrote:

> Hi all
>
> 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.
>
> 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 *IP-over-HTTPS* tunneling interface (courtesy of the DA
> implementation) and a global unicast address  the (W)LAN interface, based
> on the CPE's RAs.
>
> While things *should* 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.
>
> 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.
>
> cheers
> Marc
>
>
>
>
> On 19 December 2015 at 22:37, Kurt Buff <kurt.buff at gmail.com> wrote:
>
>> All,
>>
>> I ran into an interesting situation some months ago which still
>> baffles me, and though I was able to work around it, I expect it will
>> happen again.
>>
>> We implemented MSFT DirectAcess at our company quite some time ago
>> (using 2008R2 and Forefront 2010), and it works extremely well.
>>
>> At least it worked well for everyone until one of the employees got
>> his Comcast connection upgraded, and then DirectAccess didn't work for
>> that employee any more.
>>
>> We proved that if he tethered to his cell phone, that would work, and
>> if he used an SSL VPN client while on his Comcast connect that would
>> work, but DirectAccess would not work at home.
>>
>> Finally, I discovered that his Comcast-installed router was handing
>> our IPv6 addresses on his home LAN. Turning that off enabled
>> DirectAccess to work again.
>>
>> We do not have an assigned IPv6 block from our ISP, though of course
>> MSFT OSes use it, and auto-assign themselves addresses, but for now
>> we're ignoring it.
>>
>> Has anyone run into this problem and solved it - not by turning off
>> iIPv6 address assignment for the home LAN, but really solved it? If
>> so, how did you do that?
>>
>> Would getting and implementing an IPv6 assignment from our ISP cure
>> the problem, or make it worse?
>>
>> I've found little guidance from MSFT about DirectAccess in an IPv6
>> environment, though I admit I haven't been terribly diligent in my
>> searches.
>>
>> Kurt
>>
>
>
>
> --
> 'Multiple exclamation marks,' he went on, shaking his head, 'are a sure
> sign of a diseased mind.'
> (Terry Pratchett, in 'Eric').
>
> netztier.ch at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20151220/b43005ac/attachment.html