Mailing List Archive

I run the IPv6 program for Comcast. Let me know how I can help.

Adding my work email so I don't miss these emails.

John

On Saturday, December 19, 2015, Kurt Buff <kurt.buff@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
>

Have you tried running a Wireshark capture on that employee's computer to confirm if it's trying use DirectAccess over IPv6?

Frank

-----Original Message-----
From: ipv6-ops-bounces+frnkblk=iname.com@lists.cluenet.de [mailto:ipv6-ops-bounces+frnkblk=iname.com@lists.cluenet.de] On Behalf Of Kurt Buff
Sent: Saturday, December 19, 2015 3:38 PM
To: ipv6-ops@lists.cluenet.de
Subject: Curious situation - not urgent, but I'd like to know more

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

Interesting situation indeed :-)

As we all known, Microsoft DirectAccess uses IPsec over IPv6 (and
potentially over Teredo or SSL-VPN if the host does not have native IPv6).
So, if your DirectAccess head-end is dual-stack, it now receives Ipsec
packets over IPv6 rather than HTTLS or Teredo over IPv4, so, firewall
settings must be tuned for that.

Now, I am really puzzled by your sentence "his Comcast-installed router
was handing our IPv6 addresses on his home LAN", is it a typo in 'our'
rather than 'out' ? It would be interesting to see the
addresses/prefixes/routes of the failing DirectAccess client as well as
which IPv6 address.prefix is used by DirectAccess for the
normally-functionning clients.

-éric


On 19/12/15 22:37, "ipv6-ops-bounces+evyncke=cisco.com@lists.cluenet.de on
behalf of Kurt Buff" <ipv6-ops-bounces+evyncke=cisco.com@lists.cluenet.de
on behalf of kurt.buff@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

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@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@gmail.com

Thanks!


I'll go back to my notes tomorrow in the ticketing system, and see if I can
give more detail.

Failing that, I'm going to see if I can recruit someone to help recreate
the problem - I don't have Comcast myself.

Kurt

On Sat, Dec 19, 2015 at 6:49 PM, Brzozowski, John Jason <jjmb@jjmb.com>
wrote:

> I run the IPv6 program for Comcast. Let me know how I can help.
>
> Adding my work email so I don't miss these emails.
>
> John
>
> On Saturday, December 19, 2015, Kurt Buff <kurt.buff@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
>>
>

I can help. Can you send details how to setup the scenario please? Not only do I have access, I also have a long list of co-workers that are are capable and willing.

John
+1-484-962-0060

On Dec 20, 2015, at 13:43, Kurt Buff <kurt.buff@gmail.com<mailto:kurt.buff@gmail.com>> wrote:

Thanks!


I'll go back to my notes tomorrow in the ticketing system, and see if I can give more detail.

Failing that, I'm going to see if I can recruit someone to help recreate the problem - I don't have Comcast myself.

Kurt

On Sat, Dec 19, 2015 at 6:49 PM, Brzozowski, John Jason <jjmb@jjmb.com<mailto:jjmb@jjmb.com>> wrote:
I run the IPv6 program for Comcast. Let me know how I can help.

Adding my work email so I don't miss these emails.

John

On Saturday, December 19, 2015, Kurt Buff <kurt.buff@gmail.com<mailto:kurt.buff@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

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.

Per my earlier statement, I'll either retrieve those settings from the
ticket, or try to recreate.

Kurt

On Sun, Dec 20, 2015 at 1:10 AM, Eric Vyncke (evyncke) <evyncke@cisco.com>
wrote:

> Interesting situation indeed :-)
>
> As we all known, Microsoft DirectAccess uses IPsec over IPv6 (and
> potentially over Teredo or SSL-VPN if the host does not have native IPv6).
> So, if your DirectAccess head-end is dual-stack, it now receives Ipsec
> packets over IPv6 rather than HTTLS or Teredo over IPv4, so, firewall
> settings must be tuned for that.
>
> Now, I am really puzzled by your sentence "his Comcast-installed router
> was handing our IPv6 addresses on his home LAN", is it a typo in 'our'
> rather than 'out' ? It would be interesting to see the
> addresses/prefixes/routes of the failing DirectAccess client as well as
> which IPv6 address.prefix is used by DirectAccess for the
> normally-functionning clients.
>
> -éric
>
>
> On 19/12/15 22:37, "ipv6-ops-bounces+evyncke=cisco.com@lists.cluenet.de on
> behalf of Kurt Buff" <ipv6-ops-bounces+evyncke=cisco.com@lists.cluenet.de
> on behalf of kurt.buff@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
>
>

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@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@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@gmail.com
>

On 21/12/2015 03:28, Marc Luethi 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.

Yes. Apparently Win8 is up to date in that respect (i.e. follows RFC6724 not
RFC3484). It would be possible to make Win8 misbehave by changing the default
preferences (https://tools.ietf.org/html/rfc6724#section-10.6).

Conversely, it's possible to make Win7 behave correctly by changing its default
policies to conform to RFC6724. I just found the following site that offers a
script (YMMV, I haven't checked it):
https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies

But if that is the cause of the original issue, maybe switching off the
ULA prefix would be easier, and nicer than switching off IPv6.

Brian Carpenter


>
> cheers
> Marc
>
>
>
>
> On 19 December 2015 at 22:37, Kurt Buff <kurt.buff@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
>>
>
>
>

Just an update: I eyeballed the "PrefixPolicies-Vista78.cmd" script from
https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies, concluded
that it was safe, and ran it. It apparently works, but I don't have a
ULA setup to test it with.

jrey42 deserves kudos.

Regards
Brian

On 21/12/2015 07:57, Brian E Carpenter wrote:
> On 21/12/2015 03:28, Marc Luethi 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.
>
> Yes. Apparently Win8 is up to date in that respect (i.e. follows RFC6724 not
> RFC3484). It would be possible to make Win8 misbehave by changing the default
> preferences (https://tools.ietf.org/html/rfc6724#section-10.6).
>
> Conversely, it's possible to make Win7 behave correctly by changing its default
> policies to conform to RFC6724. I just found the following site that offers a
> script (YMMV, I haven't checked it):
> https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies
>
> But if that is the cause of the original issue, maybe switching off the
> ULA prefix would be easier, and nicer than switching off IPv6.
>
> Brian Carpenter
>
>
>>
>> cheers
>> Marc
>>
>>
>>
>>
>> On 19 December 2015 at 22:37, Kurt Buff <kurt.buff@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
>>>
>>
>>
>>

Sounds good. I'll see what I can dig up tomorrow.

Kurt

On Sun, Dec 20, 2015 at 10:47 AM, Brzozowski, John <
John_Brzozowski@cable.comcast.com> wrote:

> I can help. Can you send details how to setup the scenario please? Not
> only do I have access, I also have a long list of co-workers that are are
> capable and willing.
>
> John
> +1-484-962-0060
>
> On Dec 20, 2015, at 13:43, Kurt Buff <kurt.buff@gmail.com> wrote:
>
> Thanks!
>
>
> I'll go back to my notes tomorrow in the ticketing system, and see if I
> can give more detail.
>
> Failing that, I'm going to see if I can recruit someone to help recreate
> the problem - I don't have Comcast myself.
>
> Kurt
>
> On Sat, Dec 19, 2015 at 6:49 PM, Brzozowski, John Jason <jjmb@jjmb.com>
> wrote:
>
>> I run the IPv6 program for Comcast. Let me know how I can help.
>>
>> Adding my work email so I don't miss these emails.
>>
>> John
>>
>> On Saturday, December 19, 2015, Kurt Buff <kurt.buff@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
>>>
>>
>

On Mon, 21 Dec 2015, Brian E Carpenter wrote:

> Yes. Apparently Win8 is up to date in that respect (i.e. follows RFC6724 not
> RFC3484). It would be possible to make Win8 misbehave by changing the default
> preferences (https://tools.ietf.org/html/rfc6724#section-10.6).
>
> Conversely, it's possible to make Win7 behave correctly by changing its default
> policies to conform to RFC6724. I just found the following site that offers a
> script (YMMV, I haven't checked it):
> https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies
>
> But if that is the cause of the original issue, maybe switching off the
> ULA prefix would be easier, and nicer than switching off IPv6.

Anybody from MS know whether there's a planned official patch for Win7?
Turning on IPv6 on a network with many Win7 systems might result in IPv6
being turned off with extreme prejudice :)

Antonio Querubin
e-mail: tony@lavanauts.org
xmpp: antonioquerubin@gmail.com

On 19 Dec 2015, at 22:37, Kurt Buff wrote:
> 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?

Hi,

Disclaimer; my knowledge of DA's inner workings is almost non-existent.

I had this issue as a user some years back at the company I work for. I
had "native" (tunneled) IPv6 at home, and DA would not work. If I
disabled IPv6 (either on my machine, or on my router), DA started
working immediately.

It turned out that the FQDN used as the DA-endpoint (the destination
where the client tries to establish the tunnel) had ULA as it's
AAAA-record. When I confronted our DA-guy with this, he told me that it
used to be in the official documentation from Microsoft to use ULA. I
never actually cared enough to try looking it up (so I cannot say if it
was real or not, or if it was misconfiguration regarding split-DNS), but
in any case removing the AAAA-record (from the external DNS) solved the
issue.

You can find the FQDN by issuing "netsh int teredo show state" or "netsh
int httpstunnel show interfaces" in cmd. Do a lookup on it, and if there
is no AAAA-record, the prefix policies that's been discussed might be
the issue.

--
Joachim

All,

Just a quick update - I sent some details of the client config to John
Brzozowski offlist just now.

Brian's info sounds reasonable, and I'm willing to bet that's what is the
root cause, but I'm going to wait for John to have his say, and we'll see
what comes of that.

Thanks for the feedback everyone, and I'll keep the list posted with any
results.

Kurt



On Sat, Dec 19, 2015 at 1:37 PM, Kurt Buff <kurt.buff@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
>

Op 19-12-2015 om 22:37 schreef Kurt Buff:
> 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.
>

> 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?

We use OpenVPN on pfSense with Viscosity on the clients, or the Android
OpenVPN app. It is a complete Dual-Stack solution for both the servers
and the clients, and because we push more specific IPv6 routes it takes
precedence of the default route as intended. We've been using this for
almost 2 years now on a variation of Windows and MacOS as well as some
phones. It works well.

We use mostly UDP on 1194, unless it's a really crappy hotel wifi and
they use the TCP 443 to get around silly firewalls.

Kind regards,

Seth

On 23/12/15 10:54, Seth Mos wrote:

> We use OpenVPN on pfSense with Viscosity on the clients, or the Android
> OpenVPN app. It is a complete Dual-Stack solution for both the servers
> and the clients, and because we push more specific IPv6 routes it takes

What happens if the client has no local, non-VPN IPv6 traffic? Doesn't
it break things, because even though you're pushing more-specifics, the
device now thinks it has a global IPv6 address and breaks address selection?

Op 23-12-2015 om 12:13 schreef Phil Mayers:
> On 23/12/15 10:54, Seth Mos wrote:
>
>> We use OpenVPN on pfSense with Viscosity on the clients, or the Android
>> OpenVPN app. It is a complete Dual-Stack solution for both the servers
>> and the clients, and because we push more specific IPv6 routes it takes
>
> What happens if the client has no local, non-VPN IPv6 traffic? Doesn't
> it break things, because even though you're pushing more-specifics, the
> device now thinks it has a global IPv6 address and breaks address
> selection?
>

It doesn't have a IPv6 default route,because a no route to host is
immediate you are unlikely to see slow downs.

This is by no means a scientific method, but I've had no complaints either.

Regards,

Seth

Reviving an old thread, with a new twist.

I've currently got a similar problem with another user, but with two
differences:
- The connection in this case is ATT, not Comcast
- The machine this time is running Win8.1 and not Win7

What I've zeroed in on is two stanzas from ipconfig /all:

On my test machine (Also Win8.1), sitting outside of my corporate
firewall on a public IP address, I see the following:

Tunnel adapter 6TO4 Adapter:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft 6to4 Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2002:4332:7632::4332:7632(Preferred)
Default Gateway . . . . . . . . . : 2002:4332:7626::4332:7626
DHCPv6 IAID . . . . . . . . . . . : 268435456
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1E-45-38-94-00-26-2D-FA-9F-EF
DNS Servers . . . . . . . . . . . : 8.8.8.8
NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . :
2001:0:4332:7626:2803:8c2:bccd:89cd(Preferred)
Link-local IPv6 Address . . . . . : fe80::2803:8c2:bccd:89cd%9(Preferred)
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 285212672
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1E-45-38-94-00-26-2D-FA-9F-EF
NetBIOS over Tcpip. . . . . . . . : Disabled

On her machine, which is on a wireless connection at her home on ATT,
I see this:

Tunnel adapter 6TO4 Adapter:

Connection-specific DNS Suffix . : attlocal.net
Description . . . . . . . . . . . : Microsoft 6to4 Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2002:100:69::100:69(Preferred)
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 553648128
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-CC-30-DE-34-E6-D7-13-7E-02
DNS Servers . . . . . . . . . . . : 1.0.0.1
NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes



She's able to get an IPv4 connection at her location using our SSL
VPN, and she states that when at her local coffee shop her
DirectAccess connection works, though I haven't been able to confirm
that yet.

I'm going to see next week if I can take a peek at her router/firewall
configuration and glean any clues from it, and also see if she's
willing to make a trip to the coffee shop to do some work with me from
there.

I'm not certain if prefix policies have anything to do with this
problem, as I'm not seeing the relevant IPv6 addresses for
DirectAccess anywhere in her ipoconfig output.

Any thoughts or comments would be appreciated.

Kurt

On Sat, Dec 19, 2015 at 1:37 PM, Kurt Buff <kurt.buff@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

I would suggest:

netsh interface ipv6 6to4 set state state=disabled

You don't want to go near 6to4 these days (http://tools.ietf.org/html/rfc7526).
Use real IPv6 or no IPv6.

Regards
Brian (co-author of 6to4, but that was 15 years ago)

On 05/03/2016 13:06, Kurt Buff wrote:
> Reviving an old thread, with a new twist.
>
> I've currently got a similar problem with another user, but with two
> differences:
> - The connection in this case is ATT, not Comcast
> - The machine this time is running Win8.1 and not Win7
>
> What I've zeroed in on is two stanzas from ipconfig /all:
>
> On my test machine (Also Win8.1), sitting outside of my corporate
> firewall on a public IP address, I see the following:
>
> Tunnel adapter 6TO4 Adapter:
>
> Connection-specific DNS Suffix . :
> Description . . . . . . . . . . . : Microsoft 6to4 Adapter
> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
> DHCP Enabled. . . . . . . . . . . : No
> Autoconfiguration Enabled . . . . : Yes
> IPv6 Address. . . . . . . . . . . : 2002:4332:7632::4332:7632(Preferred)
> Default Gateway . . . . . . . . . : 2002:4332:7626::4332:7626
> DHCPv6 IAID . . . . . . . . . . . : 268435456
> DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1E-45-38-94-00-26-2D-FA-9F-EF
> DNS Servers . . . . . . . . . . . : 8.8.8.8
> NetBIOS over Tcpip. . . . . . . . : Disabled
>
> Tunnel adapter Teredo Tunneling Pseudo-Interface:
>
> Connection-specific DNS Suffix . :
> Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
> DHCP Enabled. . . . . . . . . . . : No
> Autoconfiguration Enabled . . . . : Yes
> IPv6 Address. . . . . . . . . . . :
> 2001:0:4332:7626:2803:8c2:bccd:89cd(Preferred)
> Link-local IPv6 Address . . . . . : fe80::2803:8c2:bccd:89cd%9(Preferred)
> Default Gateway . . . . . . . . . :
> DHCPv6 IAID . . . . . . . . . . . : 285212672
> DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1E-45-38-94-00-26-2D-FA-9F-EF
> NetBIOS over Tcpip. . . . . . . . : Disabled
>
> On her machine, which is on a wireless connection at her home on ATT,
> I see this:
>
> Tunnel adapter 6TO4 Adapter:
>
> Connection-specific DNS Suffix . : attlocal.net
> Description . . . . . . . . . . . : Microsoft 6to4 Adapter
> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
> DHCP Enabled. . . . . . . . . . . : No
> Autoconfiguration Enabled . . . . : Yes
> IPv6 Address. . . . . . . . . . . : 2002:100:69::100:69(Preferred)
> Default Gateway . . . . . . . . . :
> DHCPv6 IAID . . . . . . . . . . . : 553648128
> DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-CC-30-DE-34-E6-D7-13-7E-02
> DNS Servers . . . . . . . . . . . : 1.0.0.1
> NetBIOS over Tcpip. . . . . . . . : Disabled
>
> Tunnel adapter Teredo Tunneling Pseudo-Interface:
>
> Media State . . . . . . . . . . . : Media disconnected
> Connection-specific DNS Suffix . :
> Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
> DHCP Enabled. . . . . . . . . . . : No
> Autoconfiguration Enabled . . . . : Yes
>
>
>
> She's able to get an IPv4 connection at her location using our SSL
> VPN, and she states that when at her local coffee shop her
> DirectAccess connection works, though I haven't been able to confirm
> that yet.
>
> I'm going to see next week if I can take a peek at her router/firewall
> configuration and glean any clues from it, and also see if she's
> willing to make a trip to the coffee shop to do some work with me from
> there.
>
> I'm not certain if prefix policies have anything to do with this
> problem, as I'm not seeing the relevant IPv6 addresses for
> DirectAccess anywhere in her ipoconfig output.
>
> Any thoughts or comments would be appreciated.
>
> Kurt
>
> On Sat, Dec 19, 2015 at 1:37 PM, Kurt Buff <kurt.buff@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
>

I may have implemented DA for the company, but that doesn't mean I'm
an expert at it.

But, I will try this on my test laptop, and if that seems to work,
I'll try it on the user's laptop.

If that fixes her problem,then I'll likely roll out a GPO to all of
the DA client machines.

I'll post back to the list with what I find. I'm looking at several
entries from Richard Hick's blog on the subject now.

With any luck, this will become moot in a month or so, as we'll be
migrating to the 2012R2 version of DA.

Kurt

On Fri, Mar 4, 2016 at 4:35 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> I would suggest:
>
> netsh interface ipv6 6to4 set state state=disabled
>
> You don't want to go near 6to4 these days (http://tools.ietf.org/html/rfc7526).
> Use real IPv6 or no IPv6.
>
> Regards
> Brian (co-author of 6to4, but that was 15 years ago)
>
> On 05/03/2016 13:06, Kurt Buff wrote:
>> Reviving an old thread, with a new twist.
>>
>> I've currently got a similar problem with another user, but with two
>> differences:
>> - The connection in this case is ATT, not Comcast
>> - The machine this time is running Win8.1 and not Win7
>>
>> What I've zeroed in on is two stanzas from ipconfig /all:
>>
>> On my test machine (Also Win8.1), sitting outside of my corporate
>> firewall on a public IP address, I see the following:
>>
>> Tunnel adapter 6TO4 Adapter:
>>
>> Connection-specific DNS Suffix . :
>> Description . . . . . . . . . . . : Microsoft 6to4 Adapter
>> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>> DHCP Enabled. . . . . . . . . . . : No
>> Autoconfiguration Enabled . . . . : Yes
>> IPv6 Address. . . . . . . . . . . : 2002:4332:7632::4332:7632(Preferred)
>> Default Gateway . . . . . . . . . : 2002:4332:7626::4332:7626
>> DHCPv6 IAID . . . . . . . . . . . : 268435456
>> DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1E-45-38-94-00-26-2D-FA-9F-EF
>> DNS Servers . . . . . . . . . . . : 8.8.8.8
>> NetBIOS over Tcpip. . . . . . . . : Disabled
>>
>> Tunnel adapter Teredo Tunneling Pseudo-Interface:
>>
>> Connection-specific DNS Suffix . :
>> Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
>> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>> DHCP Enabled. . . . . . . . . . . : No
>> Autoconfiguration Enabled . . . . : Yes
>> IPv6 Address. . . . . . . . . . . :
>> 2001:0:4332:7626:2803:8c2:bccd:89cd(Preferred)
>> Link-local IPv6 Address . . . . . : fe80::2803:8c2:bccd:89cd%9(Preferred)
>> Default Gateway . . . . . . . . . :
>> DHCPv6 IAID . . . . . . . . . . . : 285212672
>> DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1E-45-38-94-00-26-2D-FA-9F-EF
>> NetBIOS over Tcpip. . . . . . . . : Disabled
>>
>> On her machine, which is on a wireless connection at her home on ATT,
>> I see this:
>>
>> Tunnel adapter 6TO4 Adapter:
>>
>> Connection-specific DNS Suffix . : attlocal.net
>> Description . . . . . . . . . . . : Microsoft 6to4 Adapter
>> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>> DHCP Enabled. . . . . . . . . . . : No
>> Autoconfiguration Enabled . . . . : Yes
>> IPv6 Address. . . . . . . . . . . : 2002:100:69::100:69(Preferred)
>> Default Gateway . . . . . . . . . :
>> DHCPv6 IAID . . . . . . . . . . . : 553648128
>> DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-CC-30-DE-34-E6-D7-13-7E-02
>> DNS Servers . . . . . . . . . . . : 1.0.0.1
>> NetBIOS over Tcpip. . . . . . . . : Disabled
>>
>> Tunnel adapter Teredo Tunneling Pseudo-Interface:
>>
>> Media State . . . . . . . . . . . : Media disconnected
>> Connection-specific DNS Suffix . :
>> Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
>> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>> DHCP Enabled. . . . . . . . . . . : No
>> Autoconfiguration Enabled . . . . : Yes
>>
>>
>>
>> She's able to get an IPv4 connection at her location using our SSL
>> VPN, and she states that when at her local coffee shop her
>> DirectAccess connection works, though I haven't been able to confirm
>> that yet.
>>
>> I'm going to see next week if I can take a peek at her router/firewall
>> configuration and glean any clues from it, and also see if she's
>> willing to make a trip to the coffee shop to do some work with me from
>> there.
>>
>> I'm not certain if prefix policies have anything to do with this
>> problem, as I'm not seeing the relevant IPv6 addresses for
>> DirectAccess anywhere in her ipoconfig output.
>>
>> Any thoughts or comments would be appreciated.
>>
>> Kurt
>>
>> On Sat, Dec 19, 2015 at 1:37 PM, Kurt Buff <kurt.buff@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
>>

Hi Kurt,

First of all, +1 to Brian's suggestion to disable 6to4. I'd also disable
Teredo.

> On my test machine (Also Win8.1), sitting outside of my corporate
> firewall on a public IP address, I see the following:
>
> Tunnel adapter 6TO4 Adapter:
>
> Connection-specific DNS Suffix . :
> Description . . . . . . . . . . . : Microsoft 6to4 Adapter
> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
> DHCP Enabled. . . . . . . . . . . : No
> Autoconfiguration Enabled . . . . : Yes
> IPv6 Address. . . . . . . . . . . : 2002:4332:7632::4332:7632(Preferred)

Ok, so this tells us that this machine has the public IPv4 address
67.50.118.50 (0x43.0x32.0x76.0x32). 6ot4 requires public IPv4 addresses
to work, so on this machine it has at least a *chance* of working.

Note that Windows won't activate 6to4 if the local address is a
special-use one, such as RFC1918 ones typically seen behind NAT.

> On her machine, which is on a wireless connection at her home on ATT,
> I see this:
>
> Tunnel adapter 6TO4 Adapter:
>
> Connection-specific DNS Suffix . : attlocal.net
> Description . . . . . . . . . . . : Microsoft 6to4 Adapter
> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
> DHCP Enabled. . . . . . . . . . . : No
> Autoconfiguration Enabled . . . . : Yes
> IPv6 Address. . . . . . . . . . . : 2002:100:69::100:69(Preferred)

This tells us that her IPv4 address is 1.0.0.105. That's a completely
normal and public IPv4 address, so Windows proceeds to activate 6to4.
But I am going to assume that your user does not live in an APNIC lab,
which is where this prefix is currently being used...

If ATT will allow her 6to4 packets through to the Internet in the first
place (they shouldn't), any server replies will not come back to her
but instead head straight to Geoff or George's tcpdump session. (With
some luck they'll be the topic of an amusing blog post.)

The exact same breakage is bound to happen with CGN deployments using
100.64.0.0/10, by the way.

Tore

* Kurt Buff

> Can you expand a bit on the above? I'm quite ignorant of what you're
> speaking, and would love to know more.
>
> Why shouldn't ATT allow her 6to4 packet back, and what is the tcpdump
> session to which you refer? And, I've only recently become aware that
> CGN has its own address range, but don't understand why breakage would
> occur for 6to4.

Ok, so her home router improperly uses the public IPv4 range 1.0.0.0/24
on her LAN (instead of a private IPv4 range such as 10.0.0.0/24). This
tricks Windows to starting 6to4 in a situation where it really should
not (it should only do so if it has a public IPv4 address). That's what
causing the problems in the first place.

It would be interesting to know what kind of home gateway she has,
where she got it from, and if it came with this broken config out of
the box.

Another thing, ATT supports IPv6 via 6RD (AFAIK), so I'd look into why
this doesn't work and try to get that fixed. ATT's own 6RD IPv6
connectivity is going to be better than 6to4 in every way possible.

Anyway, the reason why return traffic won't work is simply the way 6to4
works. The public IPv4 address of the host is embedded in bits 17-48 of
the IPv6 address, and this is where the return traffic gets sent.

That is, if she wants to talk to ipv6.example.org, her initial outbound
6to4 packet will look like this:

| IPv4 outer header: src=1.0.0.105 dst=192.88.99.1
| IPv6 inner header: src=2002:100:69::100:69 dst=ipv6.example.org
| TCP SYN

The packet leaves her LAN (possibly after having the 10.0.0.105 address
be rewritten to her real public address by her home gateway, but this
does not really help), and gets routed to the nearest 6to4 relay
(192.88.99.1). It strips off the IPv4 outer header and injects the
resulting packets into the IPv6 network:

| IPv6 header: src=2002:100:69::100:69 dst=ipv6.example.org
| TCP SYN

This reaches ipv6.example.org which responds normally:

| IPv6 header: src=ipv6.example.org dst=2002:100:69::100:69
| TCP SYN+ACK

This packet gets routed to the nearest 6to4 relay (since it it's
addressed to an address inside 2002::/16), which encapsulates in IPv4.
As mentioned before IPv4 destination address is found in bits 17-48 of
the IPv6 destination address, thus:

| IPv4 outer header: src=192.88.99.1 dst=1.0.0.105
| IPv6 inner header: src=ipv6.example.org dst=2002:100:69::100:69
| TCP SYN+ACK

This packet then gets injected into the IPv4 network and routed to
1.0.0.105. But, from the Internet's point of view, that address points
to APNIC - not your colleague. Thus it won't ever reach your colleague.

The tcpdump session I (jokingly) referred to belongs to Geoff Huston and
George Michaelson, APNIC's fine scientists who are listening in on all
traffic sent to 1.0.0.0/24 and use the data to give us amusing
presentations at the various networking conferences. Mayhaps your
colleague will be honoured with a slide next time.

The situation is pretty much the same for 100.64.0.0/10, i.e., it is an
IPv4 range that is being used behind NAT but that most 6to4
implementations won't recognise as private. There's no route to
100.64.0.0/10 on the public IPv4 Internet, thus return 6to4 traffic
cannot reach the original sender.

Tore

Thanks for this reply.

Am just getting back into things after a bout with a vicious bug that
downed my entire family for well over a week - I'm still coughing, in
spite of taking meds that are supposed to quell it.

After I catch up, I'll keep working on this.

Kurt

On Sat, Mar 5, 2016 at 10:40 PM, Tore Anderson <tore@fud.no> wrote:
> * Kurt Buff
>
>> Can you expand a bit on the above? I'm quite ignorant of what you're
>> speaking, and would love to know more.
>>
>> Why shouldn't ATT allow her 6to4 packet back, and what is the tcpdump
>> session to which you refer? And, I've only recently become aware that
>> CGN has its own address range, but don't understand why breakage would
>> occur for 6to4.
>
> Ok, so her home router improperly uses the public IPv4 range 1.0.0.0/24
> on her LAN (instead of a private IPv4 range such as 10.0.0.0/24). This
> tricks Windows to starting 6to4 in a situation where it really should
> not (it should only do so if it has a public IPv4 address). That's what
> causing the problems in the first place.
>
> It would be interesting to know what kind of home gateway she has,
> where she got it from, and if it came with this broken config out of
> the box.
>
> Another thing, ATT supports IPv6 via 6RD (AFAIK), so I'd look into why
> this doesn't work and try to get that fixed. ATT's own 6RD IPv6
> connectivity is going to be better than 6to4 in every way possible.
>
> Anyway, the reason why return traffic won't work is simply the way 6to4
> works. The public IPv4 address of the host is embedded in bits 17-48 of
> the IPv6 address, and this is where the return traffic gets sent.
>
> That is, if she wants to talk to ipv6.example.org, her initial outbound
> 6to4 packet will look like this:
>
> | IPv4 outer header: src=1.0.0.105 dst=192.88.99.1
> | IPv6 inner header: src=2002:100:69::100:69 dst=ipv6.example.org
> | TCP SYN
>
> The packet leaves her LAN (possibly after having the 10.0.0.105 address
> be rewritten to her real public address by her home gateway, but this
> does not really help), and gets routed to the nearest 6to4 relay
> (192.88.99.1). It strips off the IPv4 outer header and injects the
> resulting packets into the IPv6 network:
>
> | IPv6 header: src=2002:100:69::100:69 dst=ipv6.example.org
> | TCP SYN
>
> This reaches ipv6.example.org which responds normally:
>
> | IPv6 header: src=ipv6.example.org dst=2002:100:69::100:69
> | TCP SYN+ACK
>
> This packet gets routed to the nearest 6to4 relay (since it it's
> addressed to an address inside 2002::/16), which encapsulates in IPv4.
> As mentioned before IPv4 destination address is found in bits 17-48 of
> the IPv6 destination address, thus:
>
> | IPv4 outer header: src=192.88.99.1 dst=1.0.0.105
> | IPv6 inner header: src=ipv6.example.org dst=2002:100:69::100:69
> | TCP SYN+ACK
>
> This packet then gets injected into the IPv4 network and routed to
> 1.0.0.105. But, from the Internet's point of view, that address points
> to APNIC - not your colleague. Thus it won't ever reach your colleague.
>
> The tcpdump session I (jokingly) referred to belongs to Geoff Huston and
> George Michaelson, APNIC's fine scientists who are listening in on all
> traffic sent to 1.0.0.0/24 and use the data to give us amusing
> presentations at the various networking conferences. Mayhaps your
> colleague will be honoured with a slide next time.
>
> The situation is pretty much the same for 100.64.0.0/10, i.e., it is an
> IPv4 range that is being used behind NAT but that most 6to4
> implementations won't recognise as private. There's no route to
> 100.64.0.0/10 on the public IPv4 Internet, thus return 6to4 traffic
> cannot reach the original sender.
>
> Tore