The Missing ISATAP prefix case

During a recent DirectAccess deployment I had to troubleshoot an interesting issue. Internal computers that were supposed to have an ISATAP interface were not able to get the ISATAP prefix from my UAG box. According to my configuration, systems should be able to retrieve this information because they were able to reach my UAG box and were configured as ISATAP clients. There were ISATP interfaces but using FE80 prefix only. After doing some research, I finally decided to go deep dive with some network traces. I What I discovered was interesting. According to network traces, ISATAP client computer try to contact my UAG box and send a Router Solicitation message. But no answer? If we refer to a normal ISATAP behavior, we would have expected a results as illustrated bellow :

SOLLICITATIONOKSRV

 

My UAG box is responding with a Router Advertisement message. That provides the ISATAP prefix. But why does it works on my lab and not in production environment? Because my UAG box is also it’s own ISATAP client and successfully generate it’s own ISATAP address, I knew that it was a backend firewall issue. After performing some check with the network team we discovered that there were no firewall rule for the IP41 protocol that ISATAP use to carry IPv6 payload.

 

Conclusion : Having  complete checklist of all points to validate before going in production is a good practice. Even if this information was available in my network matrix flows, too many information can lead to that kind of misconfiguration.

 

BenoîtS – Simple and Secure by design but Business compliant

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.