connecting to secure database on private network from website host

Question

Hello all,

I've got a requirement to both read and write data via a .net webservice to a sqlserver database that's on a private network. this database is currently accessed via a vpn connection by remote client software (on standard desktop machines) to get latest product prices and to upload product stock sales. I've been tasked with finding a way to centralise this access from a webservice that the clients then access, rather than them using the vpn route to connect directly to the database.

My question is related to my .net service's relationship to the sqlserver database. What are the options for connecting to a private network vpn from a domain host in order to achive the functionality of allowing the webservice to both read and write data to the database. For now, I'm not too concerned about the client connectivity and security (tho i appreciate that this will have to be worked out too), I'm really just interested in discovering the options available in order to allow my .net webservice to connect to the private network in as painless and transparent a way as posible.

[edit] the webservice will also be available to the retail website in order for it to lookup product info as well as allocate stock transfers to the same sqlserver db. it will therefore be located on the same domain as the retail site

The option of switching the database onto public hosting is not feasible, so I have to work with the scenario as described above for now, unless there's a compelling rationale presented to do otherwise.

thanks all...

jim

Answer 1

Can you put the service close to the database - i.e. rather than hosting that service externally, host it internally on the same network as the database. It could then talk privately with the database on the network rather than across the internet and you could point all of the clients at it across the VPN.

Answer 2

We have a similar issue, we use secure SQL connections on a none standard SQL Server port to allow customers access the database. The server is in the DMZ of our businesses web presence and hidden from the internet using a firewall where we only allow certain IP addresses to access the database.

We had the same problem of hosting externally, our customers did not want their details in the hands of a 3rd party.

By putting two network cards in the server we can service both the internal and external requirement for access to the database (internal use use 1433).

This solution has been working without issue for 7 years now and at the time it was the favoured solution that we came up with.

It's a halfway house.