[SOLVED] Hosting services behind VPN

[Earthenware]

I have an unusual requirement which I think I can solve using a VPN, but I'd like to confirm first whether it would work.

My setup is...

• Public-facing web server running HTTPS (already in place).
• Public-facing web server generates custom-format requests to back-end server (in my home).
• Public-facing web server requires a static IP to which to forward said requests, but home server is behind CGNAT (unavoidable).

I'm aware that some VPN providers offer dedicated IPs, but I assume that these are intended for client, not server, use.
The difference, of course, is that a client generates outgoing traffic, whereas a home server will be servicing incoming traffic (albeit from only one address).

If I buy a VPN service with a dedicated IP, am I going to run into problems with incoming traffic or would the VPN provider just say "it's a dedicated IP and I don't care where traffic is being initiated from" or such?

Does anyone have relevant experience?

 

[bill001g]

Pretty much the only reason you would even pay for a dedicated IP of any kind is when you wanted to run a server. There is little actual need for a dedicated IP on the client end.

I guess it depends on how fancy the server is you currently have. You should be able to run a second process that uses the same IP used for the web server as a VPN end point. The machine in your house would connect to the web server IP but instead of using the web function it would open a vpn tunnel. You could then pass traffic between the web server function and the machine in your house using private IP over the VPN.

This is kinda the same as when you pay for vpn service with a second public IP it is just running in a different machine rather than both being on the same server.

This complexity is partially why most companies completely outsource their functions to the cloud rather than trying to keep some in house.

 

[Earthenware]

Thanks, but I think I may not have made myself clear.

Under normal VPN usage, a client (i.e. desktop PC) would initiate an outgoing connection to the internet which would pass through the VPN provider's server(s). The VPN provider could detect this as having been initiated from the client and hence it would constitute 'outgoing' traffic.

If the conversation were to be initiated from the public-facing server, the VPN provider could detect that the traffic was initiated from the internet.

At the risk of over-complicating, think 'INPUT' and 'OUTPUT' in IPTABLES. And yes, I'm aware that all conversations are two-way.

My question is whether the VPN provider would block conversations initiated from the internet, on the basis that it was expecting 'outgoing' conversations only?

 

[bill001g]

You miss the extra thing you are paying extra for is a dedicated IP addresses.

In the more normal VPN the traffic only goes from the client pc to things on the internet. You use a IP shared with others in most cases. The sharing of IP is what makes it attractive to most people using a VPN.

When you pay for your own IP address why would the VPN company care if you got incoming sessions. In many cases the is the whole reason you buy the dedicated IP in the first place. It is not a cheap option to add most times costing as much as or more than the base VPN service.

I can't really see of a reason someone would pay extra for a fixed IP addresses that does not allow incoming sessions. This is not a common offering by vpn service but the last one I saw actually talked about using it to host servers.

I don't know if it is still true but a few years back there were articles saying it was cheaper most time to use one of the hosting sites that preload small vpn servers on one of their virtual machines. I know the main difference can depend on how much traffic since not all are unlimited.

In any case it is going to be a matter of reading the fine print to see that they don't disallow it. From what I have seen all the vpn providers that offer dedicated public IP kinda expect you to use it for incoming sessions.

 

[Earthenware]

Ok, thanks.