Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A business partner has asked to set up a site-to-site VPN just so that a few servers can communicate with each other over HTTPS. I'm convinced this isn't necessary, or even desirable. To be fair it must be part of a wider policy, potentially even a legal requirement. However I'd like to convince them to simply offer an IP to us (and us only) and a port of their choosing for HTTPS.

Has anyone had a similar experience, or had to come up with a cast-iron argument against a VPN?

Allow me to expand a little - we have a web service that initiates a connection to the partner's corresponding service using an encrypted HTTP connection. The connection uses a client certificate to authenticate. The connection is firewalled so only our IPs can contact the service. So why is a VPN necessary?

share|improve this question
Not sure I follow, VPN can use only HTTPS or any other protocol... what is the question? Do you by "HTTPS" mean they should publish a web site that only you can access over HTTPS? – Oskar Duveborn Aug 14 '09 at 14:02
What I mean is we are accessing a web service over HTTPS, but they want to use a site-to-site VPN rather than simply filtering connections by IP. Hope that's clear... – Cawflands Aug 14 '09 at 14:08
up vote 5 down vote accepted

I would say that the VPN can be considered defense in depth. Look at all the recent attacks against SSL and HTTPS, which render the communication breakable. If you have a VPN between the sites which is not SSL based, then you are just adding another layer of defense.

Also, if they want to extend past HTTPS in the future (and they most likely will, everyone does), then the VPN can accommodate that.

I would second Alnitak's suggestion to do mutual auth with SSL, so that will require certificates on both sides.

share|improve this answer
I can't see us using services other than HTTPS for this particular application. What about having to make sure subnets are available on both sides of the VPN? It's a coupling I don't want to worry about. – Cawflands Aug 14 '09 at 14:11
do you mean if you happen to be using the same (RFC1918) IP address ranges on both sites? That can be resolved by having the VPN be triggered based on the outside public address ranges and then NATing the traffic to the right internal addresses. – Alnitak Aug 14 '09 at 14:14
@Nasko, Is mutual-auth possible with HTTPS? – Pacerier May 21 '15 at 21:00

Well, layering HTTPS on top of a VPN does seem slightly excessive given that it's encrypting everything twice, but it's only slightly excessive.

Should you mutually agree to use HTTPS without the VPN, then do at least go for client-side certificates and not just passwords. This would be more secure than allowing just any machine from either site to connect, and would prevent someone who happens to figure out a password from accessing the system.

share|improve this answer
If you verify the ip of the connection along with the password, What would be the point of the cert? Does it add security? – Pacerier May 21 '15 at 21:02

IMO, a VPN is mandatory when you want to talk between two networks and HTTPS the 'optional one' (but might still be desirable, if only for 'defense in depth' argument).

Once you get the VPN running, it's easy to run whatever service you want on it, and all the security-related work is already done, including any NAT issue, and also hiding your ports from the outside.

Think about the future, what if you later want to add more services? would you piggyback on your HTTPS webservice? or use another port, and repeat all required safety validation? With a VPN in place, it's really simple to do.

share|improve this answer
The vpn solution just seems extremely heavyweight when we're just talking about a couple of boxes talking to each other. We simply do not anticipate needs to open more ports between us, and frankly I'd like to save cycles on my firewall. – Cawflands Aug 14 '09 at 15:27

The VPN should/can be much more secure than HTTPS but there really shouldn't be an issue using both together unless you're on a really slow link. I'd just accept the complexity knowing you'll be watertight.

share|improve this answer
neither VPN nor HTTPS add to the amount of transfered data. the only issue is a couple extra roundtrips at the beginning of the HTTP request. – Javier Aug 14 '09 at 15:52
I guess that depends on when the data is compressed. Is https/vpn data first compressed, then encrypted or the other way around? that could affect bandwidth usage. – Zig Mandel Oct 16 '14 at 23:36

IF it's an excuse to budget out a separate VPN device for this purpose, pick one and go with it (I like Juniper). New requiements aren't free. Don't forget to get a fault-tolerant pair.

I'd go with the VPN - just make sure the added capex/opex cost to the company because of the requieremnt doesn't get silently absorbed - make sure it's clear.

Most of the questions here you can't answer for yourself - technically HTTPS should be secure enough if they are doing it right, but there may be other things going on with regards to administration and who knows what that make VPN attractive. Maybe they just want to run in private IP space rather than public.

It very well could be regulatory, in which case they maybe required to do all kinds of things you don't anticipate.

share|improve this answer

Either use HTTP over TLS or HTTP over IPsec but not both at the same time as it is an overhead. Neither TLS nor IPsec pipe protects fully. IPsec pipe breaks at the edge routing firewall while TLS pipe breaks somewhere inside DMZ zone. To increase the security of the webs service call you would have to add payload (application) level encryption and authentication. The problem with HTTPS is that a user should trust an HTTPS connection to a website if and only if all of the following are true: The user trusts that the browser software correctly implements HTTPS with correctly pre-installed certificate authorities. The user trusts the certificate authority to vouch only for legitimate websites. The website provides a valid certificate, which means it was signed by a trusted authority. The certificate correctly identifies the website. Either the intervening hops on the Internet are trustworthy, or the user trusts that the protocol's encryption layer (TLS/SSL) is sufficiently secure against eavesdroppers.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.