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 :
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
Les derniers articles par Benoit (tout voir)
- Forecast de consommation Azure - 30 août 2019
- Gestion de la sauvegarde de vos VM Azure avec des tags. - 18 juillet 2019
- Azure BluePrint Import/Export - 18 juin 2019