Question

Have anybody using port forwarding for database configuration? I have a lot of different environments and configuring them per java app is getting worse because we make mistakes. So I was thinking about using port forwarding in each box so my app is only configure to go to localhost:3306/3307… and it doesn’t need to change.

Any thought about doing that?

Answer 1

Using port-forwarding for database connections only makes sense in extreme circumstances. In general it is not a good idea because:

• modifying the OS firewall/packet forwarding settings typically requires system administrator privileges, which may not be available to the user/installer of the client application.

• setting up port-forwarding rules is system-specific, which is exactly what people try to avoid in the first place by writing their clients in e.g. Java.

• setting up port-forwarding rules correctly requires networking expertise, which goes way beyond what is usually required to point a client application to the right DB server. You should not depend on people having that kind of knowledge at hand.

• it adds a layer of indirection that is not immediately visible, unless someone has a look at the OS settings. The client logs and debugging information would all point to a database process that does not really exist, adding even more confusion to a potential future problem.

• it adds yet another point where something can break – what if an OS update changes the way port-forwarding rules are handled? What if a new firewall application decides to block forwarded packets, despite the existence of a forwarding rule at the OS level? Your client application would simply report being unable to connect to the DB server, and you would be scratching your head trying to find out what is wrong.

• it can potentially interfere with other applications, by invisibly redirecting their ports. Do you know the configured server ports on all your target systems? What if a local user also tries to use e.g. SSH-tunneling and their mail-client inadvertently tries to talk to your DB server?

• it does not scale well at all. What if you have multiple applications talking to multiple servers?

• I mentioned it before, but this one deserves a repeat: Do you really want your people (or yourself) to have to go through logs and configuration files from clients that are all claiming to be connecting to localhost:XXXX?

I’ve only ever had to use port-forwarding like this once, when I had to tunnel over an SSH connection to get to a DB server that was otherwise inaccessible, due to security constraints. It was a development environment and I’d never use something like this in production – at least not without raising a lot of fuss with the people forcing me to jump through hoops like this.

If you want all your client applications to connect to the same DB server, then this is a configuration issue. Treat it as you would if you wanted all your applications to use the same color theme or the same window layout:

• have them parse a common configuration file, using a common Java class to share the DB settings.

• have them read the same environment variable – although environment variables tend to be a bit finicky on some systems. Personally, I’d stay away from this alternative – it has all the disadvantages of the port-forwarding solution, except that your client application would know which DB server it would be really talking to.

• launch them via a single script with a shared DB-related option.

• use a centralized configuration framework to distribute the proper configuration to all clients – although then you would need to set the configuration server 🙂

Do not use obscure and fragile workarounds.

A friendly tip:

Don’t add more complexity to your life, it’s already complicated enough as it is.