Firewall, Proxy & SSH Tunnel

Table of Contents

1. SSH tunnel
2. Connecting through a proxy
3. Proxy bypass rules
4. TLS certificates behind a corporate proxy
5. Common database ports
6. Opening ports on Windows
7. Opening ports on macOS
8. Opening ports on Linux
9. Troubleshooting checklist
10. Additional considerations
11. FAQ

SSH Tunnel

An SSH tunnel reaches a database that only a jump host can talk to. DbSchema connects to the SSH server, and the SSH server connects to the database. Use it when the database should stay private and only a bastion is exposed.

A tunnel is a named configuration, stored once and reused. Several connections through the same bastion share one entry.

Open the Advanced tab of the Connection Dialog and pick a Configuration, or click the pencil to manage them.

Fill in the Name, the Host and Port of the SSH server, then choose how to authenticate:

• Password authentication — the user and password on the SSH server.
• Public key authentication — the user, the private key file in OpenSSH, PEM or PuTTY .ppk format, and its passphrase.
• SSH agent authentication — the user alone. The keys stay in the running agent, ssh-agent on Linux and macOS or Pageant on Windows, so DbSchema never sees the private key.
• No authentication — for a server that asks for none.

Test Tunnel checks the SSH server before you connect.

Set the database host and port on the Connection tab to the address as seen from the SSH host — often localhost, when the database runs on the SSH server itself. The local port DbSchema forwards is set in Edit → Settings → Network → SSH.

Connecting Through a Proxy

A proxy applies to everything DbSchema does online: JDBC driver downloads, update checks, licensing, AI, Git and bug reports.

Open Edit → Settings → Network → Proxy. The System Proxy list holds the proxy in use.

Proxies are named configurations, like SSH tunnels. Click the pencil to edit them.

A configuration works one of two ways:

• Auto-detect proxy settings — takes the proxy from your operating system, from the usual proxy environment variables, or from an automatic configuration (PAC) URL that you supply.
• Manual proxy configuration — you name the Protocol (HTTP or SOCKS), the Host name and the Port number.

Tick Proxy authentication when the proxy asks for a login and password.

One proxy serves all protocols.

Automatic detection and PAC files carry no credentials. If your SOCKS proxy asks for a login, configure it manually — a detected one has nowhere to hold the login, and the proxy answers as though the password were wrong.

Proxy Bypass Rules

No proxy for lists the hosts DbSchema reaches directly. Write one pattern per line. Internal database servers usually belong here, so their traffic never leaves your network.

Pattern	Matches
example.com, .example.com	that domain and any subdomain of it — never notexample.com
*.example.com	subdomains of example.com, but not example.com itself
db*.example.*	* stands for any characters, dots included, anywhere in the pattern
*	every host
<local>	any host whose name contains no dot and is not an IP address
10.1.2.3, ::1	that address, however it is written
10.0.0.0/8, fd00::/8	an address inside that block
any of the above, plus :8080	the same, but only for connections to that port

Matching ignores letter case. An address pattern matches only a target that is already an IP address: testing a host name would mean resolving it locally, which defeats the remote DNS of a SOCKS proxy.

TLS Certificates Behind a Corporate Proxy

DbSchema validates TLS certificates on all of its HTTP traffic. A proxy that inspects TLS replaces the certificate of every site with one of its own, signed by a company certificate authority. Unless DbSchema trusts that authority, the connection fails.

Open Edit → Settings → Network → SSL Certificates.

Custom Trust combines any of three sources:

• Trust JVM — the certificate authorities bundled with DbSchema.
• Trust OS — the authorities your operating system trusts. A company certificate installed machine-wide is usually already here.
• Trust Custom Certificates — the certificate files you add below, in PEM or DER format. Use this when the company certificate is only available to you as a file.

Trust All Certificates accepts every server certificate. It also accepts an attacker's, so keep it for a short diagnosis rather than for daily use.

Changing the trust settings takes effect after you restart DbSchema.

Common Database Ports

The firewall on the database server may block incoming TCP/IP connections. You need to open the port used by your database:

• MySQL — 3306
• PostgreSQL — 5432
• SQL Server — 1433
• Oracle Database — 1521
• MongoDB — 27017

If your database was configured to use a non-default port, substitute that value in the commands below.

Opening Ports on Windows

Using Command Prompt (recommended)

Open Command Prompt as Administrator and run (replace 3306 with your port):

netsh advfirewall firewall add rule name="DatabasePort" dir=in action=allow protocol=TCP localport=3306

Using Windows Firewall GUI

1. Open Windows Firewall with Advanced Security from the Start menu.
2. In the left pane, right-click Inbound Rules and select New Rule.
3. Follow the wizard:
   • Rule Type: Port
   • Protocol and Ports: TCP, specific port (e.g. 3306)
   • Action: Allow the connection
   • Profile: Select the profiles where the rule applies (Domain, Private, Public)
   • Name: Enter a descriptive name, e.g. Allow MySQL 3306 Inbound
4. Click Finish to save the rule.

Opening Ports on macOS

On macOS, the built-in Application Firewall usually controls app-level access rather than raw database ports. For remote databases, the safer and simpler option is often to use an SSH tunnel from DbSchema instead of opening the database port broadly.

If you must expose a local database service, configure the database to listen on the correct interface, then review any host firewall or packet-filter rules that apply in your environment.

Opening Ports on Linux

Choose the firewall tool used by your distribution.

ufw (Ubuntu/Debian)

sudo ufw allow 3306/tcp
sudo ufw reload

firewalld (RHEL/CentOS/Fedora)

sudo firewall-cmd --permanent --add-port=3306/tcp
sudo firewall-cmd --reload

iptables

sudo iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
sudo service iptables save

Replace 3306 with the port number for your database.

Troubleshooting checklist

If DbSchema still cannot connect after you open the firewall, check these in order:

1. the database server is actually running
2. the host name and port are correct
3. the database is configured for remote connections
4. the user is allowed to connect from your client host
5. an SSH tunnel is used when the database is intentionally private
6. a cloud security group or load balancer is not blocking the traffic upstream

For a download or update that fails rather than a database connection, run check network <url> in DbSchemaCLI. It prints the proxy and certificate trust in use, requests the URL with them, and explains what went wrong.

Additional Considerations

• Restrict access to trusted IP addresses only where possible, rather than opening the port to all traffic.
• For cloud-hosted databases (AWS RDS, Azure SQL, Google Cloud SQL), configure inbound rules in the cloud provider's security group or firewall settings instead of the OS firewall.
• If you still cannot connect after opening the firewall, verify that the database server itself is configured to accept remote connections (e.g. bind-address in MySQL, listen_addresses in PostgreSQL).

FAQ

When should I use an SSH tunnel instead of opening the database port?

Use an SSH tunnel when the database should remain private and only a secure jump host is exposed.

What port should I open for PostgreSQL, MySQL, or MongoDB?

The default ports are PostgreSQL 5432, MySQL 3306, and MongoDB 27017, unless your installation uses a custom port.

Why can DbSchema still fail after I open the firewall?

The most common causes are wrong host/port settings, the database listening only on localhost, missing user privileges, or a separate cloud firewall/security group still blocking traffic.

Why does DbSchema report an untrusted certificate on my company network?

A proxy that inspects TLS presents its own certificate instead of the site's. Add your company certificate authority under SSL Certificates, then restart DbSchema.

Does the proxy apply to my database connections too?

It applies to every connection that asks Java for a proxy, which includes the JDBC drivers. A driver that opens its own sockets ignores it; for a database that is meant to stay private, use an SSH tunnel.