It's very difficult to compare those two without knowing what the application will be doing. If the application is very processor intensive (i.e. processing data) versus data intensive (retrieving data) then it would make sense to build something for the client environment to offload work from the server. This of course implies that you either know the target client or you'll have to write versions to support multiple client platforms.
On the flip side, if you build the application to run as a web application, you will easily expand your accessibility to the application by not having to deal with cross platform compatibility.
It sounds from your description that you know what your target audience will be given that a client application will have to access data over a VPN. This being so, you will most likely have more control over what you need to support. Your organization probably standardizes on one OS platform.
From a perspective of usability, a client application is most certainly better. Making round trips to a web server can become time consuming. Particularly if your application needs to do a lot of little things instead of large things. Why redraw a whole HTML page just to update one bit of information.
I find it interesting that you posted this message in the web services forum but made no mention of them in your question. I really like the idea of using web services for remote data. Perhaps the optimal solution for you is to build a client application that uses web services to access the data. Not only would this eliminate the need to expose the database server to your whole VPN, but it would provide access to only the data your application needs. When you are working in a pure .net environment, using web services is very easy. From the programmatic side you never even see the HTTP/XML interaction of the web service objects.
Another nice aspect of using web services is that you can secure them without the need for a VPN. By providing restricted access to the web service you can control WHO sees the service. This can be achieved with simple protocol management like IP filtering or by building the service methods to require some kind of authentication. In addition, you can use web services over HTTPS so you can secure against network sniffing. All of this without the need to VPN. Depending on your situation this could be a very attractive benefit.
In the end, you'll need to evaluate several things:
- What is the application doing? (Processor or data intensive?)
- How do you want users to access it? (Will they always be or need to be on VPN?)
- UI consideration. (Fancy or quick).
- Upgrade considerations. (Much easier with a web app. But you could make the application check for updates automatically.)
Work smarter, not harder.