<div dir="ltr"><div><div><div>Yes - "our" should read "out" - they were not anything we would hand out, and ISTR that they were listed on the NIC entries, separately from the DirectAccess addresses listed in the other ipconfig entries.<br><br></div><div>Per my earlier statement, I'll either retrieve those settings from the ticket, or try to recreate.<br></div><div><br></div><div>Kurt<br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 20, 2015 at 1:10 AM, Eric Vyncke (evyncke) <span dir="ltr"><<a href="mailto:evyncke@cisco.com" target="_blank">evyncke@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Interesting situation indeed :-)<br>
<br>
As we all known, Microsoft DirectAccess uses IPsec over IPv6 (and<br>
potentially over Teredo or SSL-VPN if the host does not have native IPv6).<br>
So, if your DirectAccess head-end is dual-stack, it now receives Ipsec<br>
packets over IPv6 rather than HTTLS or Teredo over IPv4, so, firewall<br>
settings must be tuned for that.<br>
<br>
Now, I am really puzzled by your sentence "his Comcast-installed router<br>
was handing our IPv6 addresses on his home LAN", is it a typo in 'our'<br>
rather than 'out' ? It would be interesting to see the<br>
addresses/prefixes/routes of the failing DirectAccess client as well as<br>
which IPv6 address.prefix is used by DirectAccess for the<br>
normally-functionning clients.<br>
<br>
-éric<br>
<br>
<br>
On 19/12/15 22:37, "ipv6-ops-bounces+evyncke=<a href="mailto:cisco.com@lists.cluenet.de">cisco.com@lists.cluenet.de</a> on<br>
behalf of Kurt Buff" <ipv6-ops-bounces+evyncke=<a href="mailto:cisco.com@lists.cluenet.de">cisco.com@lists.cluenet.de</a><br>
<div class="HOEnZb"><div class="h5">on behalf of <a href="mailto:kurt.buff@gmail.com">kurt.buff@gmail.com</a>> wrote:<br>
<br>
>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>
><br>
>Kurt<br>
<br>
</div></div></blockquote></div><br></div>