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 <[email protected]> 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 <[email protected]> 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'). > > [email protected] >
