0

I need to configure a Linux server (probably CentOS) to run a web application online.

Elements in the flow:

  • mywebapp, reachable at the url https://mywebapp.example.org
  • thirdpartwebserv, reachable at the url https://thirdpartwebserv.example.org and must be tunneled via VPN
  • user, the typical mywebapp user, he does not have the VPN on his computer but only access to his mywebapp account
  • operation A that queries thirdpartwebserv and requests VPN
  • operation B that does not require VPN and only uses mywebapp functions

Typical flow:

  1. user accesses https://mywebapp.example.org
  2. user carries out operation B
  3. mywebapp processes operation B
  4. the result of operation B is shown to the user.
  5. user performs another operation, this time an operation A
  6. mywebapp communicates with thirdpartwebserv through a VPN, processes operation A and returns a result
  7. the result of operation A is shown to the user.

What I'm interested in is letting anyone have an account on mywebapp while still guaranteeing tunneling towards communications with thirdpartwebserv.

Can I use OpenVPN on mywebapp server to communicate with the VPN protected thirdpartwebserv server and obtain a similar infrastructure?

The use of VPN is dictated by thirdpartwebserv.

Improve this question
2
  • Yes, you can do it. Don't see the reason of doing it, however, since HTTPS uses the same security machinery as OpenVPN, and therefore provides the same level of security (when used with client certificates). It doesn't need to be enveloped within VPN. Why are you going to complicate things that way? Also, Plesk is mentioned, does it play any role in this problem? From the problem description, I don't see how even knowing about it can influence the solution (else I'd be voting to close this as we don't want questions involving web control panels here).
    – Nikita Kipriyanov
    Commented Jun 20 at 12:57
  • Hello and thanks for the comment. The VPN is provided and requested by our client (who is also the owner of the thirdpartwebserv services in the example). It's definitely a complication. I mentioned Plesk because I thought it could be important in thinking about the possibility of creating this infrastructure. I can also remove it from the question if it's not relevant.
    – user31929
    Commented Jun 20 at 13:37

1 Answer 1

Reset to default
1

Yes, you can. This is basic VPN functionality, which OpenVPN, WireGuard, or I suspect any VPN out there implements.

Things to consider:

  1. In case of OpenVPN, it's desirable to use its tun mode, L3 tunnel, as it's more efficient (has less overhead)
  2. VPN will imply tunneled IP addresses, i.e. the ones assigned to the ends of the tunnel, to the tunX interfaces. Typically private RFC 1918 addresses are used for that. To guarantee that communication takes place through the VPN tunnel, your application mywebapp must use the tunneled IP address or the address routed via the tunnel. It may not be the same public address that you'll use to establish VPN.
  3. thirdpartwebserv is probably going to be a standard web server which would process Host headers, i.e. it may not respond properly if you use dotted-quad IP address to communicate with it. Given you know the name configured on the thirdpartwebserv's virtual host that runs the back-end service (e.g. thirdpartwebserv.example.org, as in the question), you may need to associate that name with the tunneled IP address using local hosts file. You can also publish this tunneled (private) IP address into the public DNS under that name (I know some people will disagree with me, but I don't see anything wrong with this).
  4. There may be a public DNS name thirdpartwebserv.example.org which you may want to use for VPN. In case the internal web server is going to use the same name for its virtual host, you may end up with clash, where the VPN client tries to reestablish the connection through the connection itself, which will make everything fail. To avoid such clashes of the name resolution, for VPN use literal public IP or a different hostname (like thirdpartvpn.example.org) that points to the public IP of the VPN peer. (If you published a private address, this would be out of question.)
Improve this answer
6
  • Well if the requirement is that the site is accessible litterally through the address thirdpartvpn.example.org over VPN then you need to supply a DNS server that is accessible through VPN and implement RPZ. That way you can replace the public ip address for the site with a local ip that is accessible through VPN. I use that exact trick with a Nginx proxy to cache files for my LAN. :-)
    – Lasse Michael Mølgaard
    Commented Jun 21 at 11:39
  • I knew someone will suggest this. No, I am certainly against any DNS over VPN. If VPN breaks (outage), DNS breaks too? I've seen that, want no more. If there was an interface in the OS to tell it which of the configured DNS resolvers to use for which domain, that might have been revived, but that also defeats the purpose of the resolver — to offload this role and configuration for each computer.
    – Nikita Kipriyanov
    Commented Jun 21 at 17:53
  • Why against DNS over VPN? How else would you resolve internal hosts on VPN? If VPN breaks then the client will fall back to the default DNS. Granted I use it mostly with split VPN, but I have had no issue with this solution with IPsec or Wireguard. The only thing is that if you supply DNS via VPN then you must also provide a caching resolver for the rest of the internet or else you will only have access to remote networks or internet, but not both!
    – Lasse Michael Mølgaard
    Commented Jun 21 at 20:22
  • How else would you resolve internal hosts on VPN? — by putting them into public DNS, as I suggest in the answer. If your security depends on private IPs or names being externally unknown, screw that security; else, until name in DNS is exposed somewhere, it is invisible — no enumeration, so it's functionally no different than having names in internal DNS. What's the problem? Less DNSes, less reliance on fallbacks (which don't always work, again, I've seen that), more robustness overall.
    – Nikita Kipriyanov
    Commented Jun 22 at 3:28
  • Well your solution has a particular flaw: It is not possible to serve any ressources with a FQDN ending on a non-official TLD, like .internal, .lan, .vpn etc. How would you serve those ressources to VPN clients if DNS over VPN is not allowed?
    – Lasse Michael Mølgaard
    Commented Jun 22 at 15:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .