My current project contains multiple heterogeneous TCP servers, but our IT guys have clearly declared that they will give me only one 443 port, which is fair enough.

Two options are on the table now. One is VPN. We can set up a VPN server inside our cooperation and implement the access control. The other one is to implement some kind of software switch, which peeks the recognizable features of any [S] packet and then route the connection to responsible service. Our IT guys are neutral to both approaches for now before any evidence shows that one is superior than the other.

The pros of VPN are that it is a well-established technology and widely used in practice. In our scenario, it ensures sensitive information to be encrypted. The cons are the effort we will need to implement access control policies and mechanisms. The number of services will possibly grow, and the service will go multi-tenant, so it will become more complex.

The pros of the software switch are that it is simple to implement because the features/protocols of the sub-services are well known to us. The cons are that no such practices are heard before (I might be ignorant here), and we are not so confident if exposing such an in-house solution to the Internet is a good idea.

If you were me, what approach do you prefer? Why? Details can be clarified if needed and allowed.

I really appreciate any comments and answers.

  • Are the applications coded and used on the same HTTP server (Tomcat vs IIS, etc?) Are they any reason they would need to be separated? Are both of these applications safe to be exposed to the Internet? What does implementing a software switch look like -- can the software switch really provide enough security restrictions compared to a VPN?
    – Saustin
    Sep 22, 2020 at 0:10
  • @Saustin No, Yes, and it depends for the final question. They are not necessary HTTP/HTTPS. Some of them are quite different protocols. The only common point I can say is that they are all TCP. Some of the protocols are by default plaintext but can be configured with TLS. Sep 22, 2020 at 0:15
  • Not sure if it will work for you, but I've used sslh in the past to multiples an ssh connection on port 443, while also allowing normal HTTPS service. It can support other protocols also, if I recall. Worth a look, I think.
    – user88917
    Sep 25, 2020 at 6:46

3 Answers 3


I would caution coding your own version of a switch; is the development time really worth it compared to using a VPN solution? Can you securely code it and ensure no internal data is inadvertently accessed?

Should you decide to proceed with a modified TCP proxy, you can implement some architectural changes to increase security:

  • Ensure the TCP proxy server is in a segmented DMZ, and will only have access to those two applications. Should the TCP proxy server be compromised, only those two applications may be impacted.
  • Only allow communication to encrypted ports. Do not allow plaintext transmissions.
  • Log IPs in traffic -- remember, your applications may not see the true client IP anymore.
  • For any applications using HTTP(S), implement a WAF.
  • If the applications have a High Availability requirement, possibly consider implementing a load balancer as well as some mirrored servers.
  • It would not hurt to run a monthly or quarterly vulnerability scan with a tool such as Nessus, OpenVAS, or even nmap's Vulners plugin to get a picture of how exposed your application is to known vulnerabilities.

I would additionally recommend looking at the Application Security Verification Standard and reviewing what security controls you may be missing, and whether or not you can accept that risk from a business standpoint.

However for the sake of the argument, I would lean towards a VPN (or SSH proxy) anyway. From a security standpoint, here are some benefits:

  • All traffic is encrypted
  • You can implement some form of access control based on user ID
  • You can rest assured that VPN software is security tested very well, as it is the front door to most organizations.

For security purposes, make sure that your VPN server is in a segmented DMZ from the rest of your network. Ensure that this DMZ can communicate externally, as well with the two applications you need to be accessed externally. Therefore, if the VPN server or user credentials were ever compromised, the attackers would only be limited to attacking those two internal applications.

  • I am pro VPN too in this case, but the switch does show its simplicity. The guy who implements this forks a golang-based TCP proxy project: github.com/jpillora/go-tcp-proxy/blob/…, and what he does was just add a switch case body there to parse the first few bytes in every first connection. Based on that, the switch can handle 3+ protocols in no more than 50 lines. Sep 22, 2020 at 0:27
  • It will definitely be more simple. But with security, comes complexity. I guess it ultimately depends on how serious your organization takes security, and whether or not the timeliness of this is more important. Also keep in mind your company will now become reliant on this code, which may be difficult to merge later on.
    – Saustin
    Sep 22, 2020 at 0:31
  • Thanks for your answers and suggestions in general. But what if the software switch approach finally wins, what can we do to make sure the "tcp-proxy + patched" stuff is secure enough? Any suggestions? Sep 22, 2020 at 0:35
  • @user3427483 I have updated my answer, please let me know if you want more guidance. I think ASVS would help a lot.
    – Saustin
    Sep 22, 2020 at 0:44

The answer depends on how you authenticate your users right now, and how you identify the target destination services. it is good practice to expose only one open port on the internet, to route traffic internally you will usually deploy a load balancer/proxy/firewall. encrypting the traffic in VPN or SSH will add another layer of security.


In some contexts this is actually quite common, and since you are talking about port 443, those contexts are probably applicable to you. It depends though:

Most importantly, are these services built on the same protocol? If your services are raw TCP servers running separate, custom protocols, then you are going to have to figure out the details yourself and you may have trouble. If, however, your services are both running HTTP, then this is quite common. There are two main times where this happens:

  1. Shared hosting (multiple websites hosted from one server/IP, separated by the Host HTTP header)
  2. Modern load balancers use path-based routing (aka /service1 goes to one service and /service2 goes to another)

Neither option is crazy, and assuming that you are using a protocol (like HTTP) that lets you easily separate out sub-resources, having more than one service on the same port is actually pretty common.

In general though, for normal separation-of-concerns reasons, as well as for management, it would be easier to have these on not separate ports but actually separate servers/VMs. Having two separate services on the same server but different ports still brings additional risks (aka compromising one may compromise the other), and so, IMO, is not much more "secure" than having them both in the same port. For that reason I don't think that using one port is any worse of an idea than having them on the same server in the first place.

Of course only you know what these applications do, and whether or not the additional "risk" of using a shared server is reasonable, but I figured I'd give an example of a case where you don't want to do it. Imagine if one service handles much more sensitive data than the other, and have different levels of "exposure". AKA one service handles credit card data and the other one hosts data for public consumption. Having them on the same server limits your ability to restrict access to authorized users, and so attackers who otherwise would only be able to "attack" the public service may find a way into your credit card processing system. In a case like this I would definitely recommend separate servers.

  • Thanks for your hint. I now understand the scenario you mention is common in practice. However, just like I stated in other comments, the services are actually quite heterogeneous. Thanks anyway. Sep 22, 2020 at 22:47

You must log in to answer this question.

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