Recently I came across a scenario where we had a PPTP Site-to-Site VPN between two TMG servers. We were able to access the shares of one TMG server from the other but we were unable to access the shares in the opposite direction as shown in the figure below:
Live logging was enabled on TMG from Site B and there the following error was appearing:
The IP address 10.10.11.1 showing above in the above Log as the ‘Source’ is the IP address of Internal Network Card of the TMG server. We checked the Live Logging on the Remote TMG server from where we could access the shares on this Local TMG server and we noticed that in the ‘Source’ it was showing the IP address of the RAS interface of the server.
During the investigation process to understand why TMG (site B) was showing us the Internal IP of the TMG server in the ‘Source’ instead of the RAS interface IP we checked the Binding Order of the Network Cards and we came to know that the Network Card which was on the top of the list was a third Network Card installed on the server (as shown in the image below) where Local Area Connection 5 is the third Network Card:
We moved the Internal NIC (Local Area Connection 3) to the top of the Binding Order. After making this change, when we tried to access the shares on the remote site it worked just fine. At this time the logging was showing the successful access:
The take away from this post is: remember to always use the internal NIC on the top. Here are some other cases where bind order was the culprit:
Unable to install Forefront TMG 2010 – Error 0x80074e46 Another performance caveat when troubleshooting TMG or ISA slow browsing behavior Troubleshooting Tips for VPN Client Access on ISA Server 2006
Author Nitin Singh Support Engineer Microsoft CSS Forefront (ISA/TMG) Team
Technical Reviewer Yuri Diogenes Sr Support Escalation Engineer Microsoft Forefront (ISA/TMG) Team
Nice work nitin..i guess thats why we always suggest correcting the binding order as in one of my blog posts blogs.technet.com/.../09.aspx.