All user can VPN into this environment but I have 2 users in India that can't

I have a 2004 ISA box configured to allow VPN access from External to the Internal corporate network and I also believe that staff members can VPN into here when they're abroad so long as they have access to a wen connection.

I have setup 2 AD Accs for users in India, locked down with GPOs, and who will connect onto the network via a Terminal Server. I have tested the accounts and have added them to our VPN AD Group allowing them VPN access. I have tested the VPN access using our ADSL line and connected successfully.

However, I have asked the user in India to test this access and they're receiving the 'ERROR 721'. The user has run a tracert from source to destination (India-to-UK) which bombs out at the last successful hop before reaching this location.

Am I right in saying that providing my VPN staff can connect into the company from here in the UK and Internationally then the issue lies with the environment in India?

I didn't know if there should be some kind of additional ISA rule to allow this access.
CTCRMInfrastructure EngineerAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Does your VPN sit on verifying username and password and then time out with error 721?  I had a similar issue and
In order to get a successfull pptp tunel, you HAVE to allow GRE packets OUT to the internet from the ISA server with an equivalent rule on the cisco PIX (or whatever router you may have), because ISA server needs a return path for all that encrypted traffic.
Can you check the logs,

1) Are they prompted for username/password. If so is there username being authenticated against AD

2) If not prompted, then they are unable to hit the gateway, if so some proxy might be stopping them.
CTCRMInfrastructure EngineerAuthor Commented:
For all other VPN users (300 Users) they create the VPN client on their home PC/laptop whether they are located here in the UK or out in Europe, double click and are then prompted to enter there AD username and password. Those credentials are authenticated against AD and the VPN connection is then established.

What they then do is run the MSTSC command from there PC and enter the target PC name (hostname) (desktop PC on there desk at work), and are able to login to their desktop PC and off they go.

For the 2 users in India, they have created the VPN client as per the companies instructions and then when they double click it the 'Connecting to "companyname"' dialog appears (verifying username and password) and shortly after that the following dialog box appears:
Error Connecting to "company name"

Error 721: The remote computer did not respond. For further assistance, click..........
They're then given the option to redial or cancel.

I would have thought that GRE packets are allowed to allow all other user VPN access from other external locations, but not sure.
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

Keith AlabasterEnterprise ArchitectCommented:
Are these users on stadalone computers oor on a network? Do your subnets conflict/overlap with theirs?
CTCRMInfrastructure EngineerAuthor Commented:
I believe the 2 users in India are on standalone PCs and are not devices provided by or part of the company.

The policy her for VPN users is that so long as there devices (PC/Laptop) at home or wherever is protected by AV then they're granted access.

Let me give you the overall picture summerised if I may.
The company is one single building with 300 members of staff located here (Midlands, UK).
Most of these 300 users can be granted VPN access onto there own desktop PC here in the building providing they're in the VPN AD Group.
All users in this building can connect into the building via VPN and authenticate the credentials against AD, then they can successfully run MSTSC from there home PC and gain access to their works desktop PC (providing it is switched on).

We also have members of staff (remote users) who live in different countries and are travelling around the world gaining VPN access into this building successfully but if there are ever any issues it is normally down to the network provider (ISP) in a different country and their network related issues but this is a very rare call to deal with.

We have now employed a company in India who have allocated 2 members of staff to carryout some work on behalf of this company and I was tasked to setup these accounts and a secure VPN connection into the building for them. The accounts have been setup, have been placed into theVPN AD Group, and the accounts have been locked down with GPOs.

I have a dedicated ADSL line here in the office which is an external line and I have successfully logged onto this machine, established a VPN connections, authenticate the user accounts and MSTSC'd onto my PC successfully so my test shows that the accounts access is working.

We have many VPN users gaining access to this environment with no issues both here in the UK and abroad so my diagnosis points to an issue over in India as I don't have any control over the links between the UK and India, nor do I have control over another companies infrastructure certainly when it is in another country.

Is there any reason that I have missed here configuration wise to allow these 2 users VP access?

Other tests:
The guys in India have provided me with a copy of a tracert they have run to here (I can provide a copy if neened) and from this I have run a tracert to the last/first public IP address on there result to test our traffic which was successful and this was done on the dedicated ADSL here.

The guys in India run there tracert to our public gateway IP address and the trace gets as far as a public backbone IP address located in Manchester and then it times out. If I run a trace from here to that Manchester IP address I can do so successfully so it just seems that it is going to be an external problem but I need to clarify this before making this suggestion.
CTCRMInfrastructure EngineerAuthor Commented:
One thing I did forget to mention Keith.

I have set these user accounts (India) to connect to one of the company's Terminal Servers instead of directly onto a desktop PC/laptop. The reason I did this is because we have around 100 Thin Client users here in the building that connect to the network via Terminal Server. This allowed my to lock the external accounts down with GPO a little easier.

With the above in mind I can still successfully VPN into this environment and so can any of the Thin Client users remoting in from home.
Keith AlabasterEnterprise ArchitectCommented:
The approach is sound - and is a common one. In fact, it is fairly similar in one aspect in that we used to do the same for our SAP support that was provided from India, although we used the SAP router service rather than terminal service.

If you run the log monitor in ISA (I am assumning you ARE on ISA 2004 SP3) from monitoring - logging - start query, do you see the VPN attempts from India? What is allowed, what is denied?

Do the same for your external attempt (which works) to the terminal services box, what is allowed, what is denied.... what is different, if anything, between the India and your terminal server access attempts in respect to what the logging shows/reports?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
CTCRMInfrastructure EngineerAuthor Commented:
Thanks Guys

All comments and advice were helpful but it seems that the issue was with the recipient end after all (Firewall)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Forefront ISA Server

From novice to tech pro — start learning today.