Reverse Proxy

The Reverse Proxy feature enables reverse SSH tunnels that allow connections from a Demilitarized Zone (DMZ) container or external SSH server to reach internal resources within your infrastructure. This is accomplished by establishing an outbound SSH connection to an external server, which then allows that server to forward traffic back through the tunnel to your internal listeners.

Note

The external SSH server/container serves as the access point for users connecting through the Reverse Proxy. Instead of connecting directly to Fudo, clients establish their connection to this external server, which then forwards traffic through the reverse SSH tunnel into the internal environment. As a result, this server is not just an auxiliary host — it is the endpoint that users will connect to when accessing internal resources.

Prerequisites

Before configuring a Reverse Proxy, ensure the following requirements are met.

• External SSH Server

  • A proxy server can be a hardware or virtual machine, or a container with SSH enabled that allows tunnel forwarding with the -R option.

  • The external SSH server must have the following configuration in its sshd_config file: GatewayPorts clientspecified. This setting allows the SSH daemon to bind to specific addresses as requested by the client.

• Authentication Setup

  • Add the SSH public key (corresponding to the private key you’ll use) to the authorized_keys file on the external SSH server to enable key-based authentication.

• Network Requirements

  • You must select a specific Bind IP address for the outbound connection—labels and Any are not permitted.

  • Each Reverse Proxy configuration must use a unique combination of server address and port.

Configuration Steps

For illustration purposes, the example below uses a container-based SSH server.

Example SSH Container Configuration

The following Dockerfile defines a minimal SSH server suitable as an External SSH Server for Reverse Proxy tunneling.

Dockerfile

The example uses Ubuntu 22.04 LTS, but any Linux base image with OpenSSH Server installed can be used.

FROM ubuntu:22.04

RUN apt-get update && apt-get install -y openssh-server \
    && mkdir -p /var/run/sshd

# Create a dedicated user
RUN useradd -m reverseproxy && mkdir -p /home/reverseproxy/.ssh \
    && chown -R reverseproxy:reverseproxy /home/reverseproxy/.ssh

# Update SSH configuration to allow reverse tunnels
RUN sed -i 's/#GatewayPorts no/GatewayPorts clientspecified/' /etc/ssh/sshd_config

# (Optional) Disable password authentication for security
RUN sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config

EXPOSE 22

CMD ["/usr/sbin/sshd", "-D"]

Build the Container

docker build -t external-ssh-server .

Run the Container

Expose port 22 to your host. You can use any port on the host. Using a non-standard port (e.g., 2222) is recommended for basic hardening.

docker run -d -p 2222:22 --name external-ssh external-ssh-server

Configure Key-Based Authentication

Note

The public key required for authentication on the external SSH server can be obtained directly from the Reverse Proxy configuration in Fudo Enterprise.

After starting the container, copy the SSH public key that the Reverse Proxy will use.

docker exec -it external-ssh bash

Inside the container:

su - reverseproxy
echo "YOUR_PUBLIC_KEY" > =/.ssh/authorized_keys
chmod 700 =/.ssh
chmod 600 =/.ssh/authorized_keys

Validate the Configuration

To verify that the external SSH server accepts key-based authentication and supports reverse SSH connections, you can perform a manual test from any host that will initiate the tunnel (e.g., the Reverse Proxy host).

SSH Key Authentication

ssh -i private_key reverseproxy@<server-ip> -p 2222 true

Reverse Port Forwarding

ssh -i private_key -R 0.0.0.0:8080:localhost:80 reverseproxy@<server-ip> -p 2222

If successful, the container is ready to be used as the External SSH Server for Reverse Proxy.

Note

If the key pair was generated in Fudo, make sure that the private key was downloaded and stored securely before performing this test.

If the private key is missing, authentication will fail. In this case, generate a new key pair or upload your own public key to Fudo.

Configuration Steps in Fudo Enterprise

1. Select Settings > Network Configuration.

2. Open the REVERSE PROXY tab.

3. Click + Add Reverse Proxy.

SETTINGS TAB

Note

Settings tab configures the SSH connection parameters and determines whether the User Access Gateway (UAG) is proxied through this connection.

1. In the Name field, enter a descriptive name for this Reverse Proxy configuration, for example Reverse Proxy – DMZ or SSH Tunnel to Reporting Server.

2. In the IP address field, provide the hostname or IP address of the external SSH server that Fudo should connect to.

3. In the Port field, enter the SSH port number on the external server. This is typically 22, unless the server uses a non-standard port.

4. In the Login field, enter the SSH username used on the external server (e.g., fudo, tunnel, proxyuser).

5. In the Private Key field, paste the private key used for authentication on the external SSH server.

   Note

   Remember that only key-based authentication is supported — password authentication is not available.

6. In the Bind IP field, choose a specific IP address that will be used as the source for the outbound SSH connection.

   Note

   You cannot use labels or the Any option. The selected IP determines which node establishes the SSH connection.

7. In the Server Verification section, select the Public Key option (recommended) and paste the external server’s SSH public key into the Server Public Key field.

   Note

   Although this field is optional, it is strongly recommended to provide the key. If the field is left empty, the key will be retrieved automatically on every tunnel establishment attempt. Providing the key manually is recommended because it reduces the risk of man-in-the-middle attacks and ensures you are connecting to the expected server.

8. In the User Access Gateway (UAG) section, decide whether UAG should be accessible through this Reverse Proxy.

   If you enable the Allow UAG connections option for this configuration, users connecting through this tunnel will receive a filtered view of resources based on their assigned permissions.

   When UAG access is enabled, provide the UAG address and port.

Note

If the User Access Gateway (UAG) is exposed through the Reverse Proxy under a different hostname or IP address, the TLS certificate used by the UAG must include all such addresses. Otherwise, TLS validation will fail and connections will be rejected.

LISTENERS TAB

1. Go to the LISTENERS tab.

   Note

   Listeners tab allows you to map internal listeners to remote ports on the external SSH server, creating tunnels that forward traffic from the remote server back to your internal resources.

2. Click Add Listener to create listener mapping.

3. From the Listener drop-down list, select the Fudo listener (identified by its listen IP and listen port) that will receive the tunneled traffic.

4. In the Address field specify the IP address on the external server that will accept incoming connections.

5. In the Port field specify the port on the external server that will accept incoming connections. This port must be unique within this Reverse Proxy configuration.

Note

Important Constraints:

• Node Affinity - The listener’s IP address must be from the same node as the Bind IP configured in the Settings Tab. Reverse proxy tunnels operate on a single node, so the outbound SSH connection and the internal listener must reside on the same node.

• Any Listener Exception - If a listener is configured with Any as its listen IP, it will also accept traffic for the specific node where the Bind IP is located.

• Remote Port Uniqueness - Each remote port must be unique for the given Reverse Proxy address. You cannot map multiple listeners to the same remote port on the same external server.

User Access Gateway Connections

Accessing the User Access Gateway

To access the User Access Gateway through a Reverse Proxy connection, enter the IP address and port specified in the Reverse Proxy configuration under the Allow UAG connections toggle. Use these values directly in your browser. For example, as shown in Figure 3, if the configuration lists the address as 10.0.230.55 and the port as 4647, you would access UAG by navigating to: http://10.0.230.55:4647/.

Resource Visibility Through UAG

When users access the UAG through a Reverse Proxy connection, they will see a filtered subset of resources rather than all available resources. Specifically, users will only see resources from ANY configured Reverse Proxy in the system, not limited to the specific Reverse Proxy they connected through.

What Qualifies as a Proxied Resource

A resource is considered proxied and will be visible through UAG if it meets any of the following criteria:

• Mapped Listeners - Any listener that has been mapped in the Listener tab of any Reverse Proxy configuration.

• Accounts Using Proxied Listeners - Any account that is configured to use a listener which has been mapped in any Reverse Proxy.

• Webclient Listeners for Proxied Accounts - If an account uses a proxied listener, then any webclient listeners associated with that account are also considered proxied resources.

Enabling and Disabling Reverse Proxy

Each Reverse Proxy configuration includes an enable/disable toggle that controls whether the tunnel is active. This toggle takes effect immediately without requiring you to save the configuration.

When Reverse Proxy is Disabled:

• All configuration fields are editable, including connection settings.

• No tunnel is established.

• No connections can be made through this Reverse Proxy.

When Reverse Proxy is Enabled:

• You can only modify UAG proxying settings.

• Connection settings (Host, Port, Login, Private Key, Server Public Key, Bind IP) are locked and cannot be changed.

• You can add, edit, or remove listener mappings.

Reverse Proxy Status Indicators

You can check the Reverse Proxy status in the Settings > Network configuration > Reverse Proxy list or in the edit form of the selected Reverse Proxy configuration.

The Reverse Proxy can display one of the following four status values:

Reverse Proxy Status Values

Status	Description
Offline	The Reverse Proxy is disabled. No tunnel is established and no connections are possible.
Dead	The Reverse Proxy is enabled but the tunnel is not functioning. The SSH connection has failed or has been disconnected. Check the Events Log for connection errors.
Degraded	The Reverse Proxy is enabled and the tunnel is established, but one or more listener mappings are not functioning correctly. The tunnel is partially operational, but some services may be inaccessible. Review the Events Log and verify listener configurations.
Running	The Reverse Proxy is enabled, the tunnel is established, and all listener mappings are functioning correctly. The configuration is fully operational.

SSH Tunnel Operation

Tunnel Establishment Process

When you enable a Reverse Proxy, the tunnel establishment process occurs asynchronously in the background:

1. The API immediately returns after you toggle the enable switch.

2. A background service handles the actual SSH connection establishment.

3. The status will transition from Offline → Dead → Degraded or Running as the service attempts to establish the tunnel and configure mappings.

4. Any issues during establishment (authentication failures, network errors, mapping problems) are logged to the Events Log

Important

Always check the Events Log if the status shows Dead or Degraded to diagnose connection or mapping issues.

Behavior of SSH Tunnels

Removing a listener mapping or disabling the Allow UAG connections option does not terminate the underlying SSH tunnel. As a result, existing connections that were established using this mapping remain active. Only new connections are blocked after the mapping is removed.

This behavior is inherent to how SSH tunnels operate when multiple mappings share the same SSH connection: the tunnel persists as long as the SSH session remains open, regardless of which individual mappings are removed.

If an administrator needs to forcibly terminate all existing connections associated with the tunnel, they can manually disable the Reverse Proxy either before or after removing the mapping. Disabling the Reverse Proxy closes the entire SSH tunnel, immediately terminating all active connections.

Workflow Recommendation

1. Configure all connection settings while the Reverse Proxy is disabled.

2. Add listener mappings for the resources you want to expose.

3. Enable the Reverse Proxy using the toggle.

4. Monitor the status as it transitions from Offline status.

5. Check the Events Log if the status does not reach Running within a reasonable time.

6. Test connections only after the status shows Running.

7. Make adjustments to UAG or listener mappings as needed. Note: Changing connection settings requires disabling the Reverse Proxy first.

Internal Routing Behavior

Connections received through the Reverse Proxy are routed to internal resources using the 127.0.9.1 address for:

• Listeners configured with Any as the listen IP.

• User Access Gateway (UAG) connections.

In the Events Log, any connection originating from 127.0.9.1 indicates traffic that arrived via a Reverse Proxy tunnel.

Security Considerations

• Always provide the Server SSH Public Key manually to avoid relying on automatic key retrieval during the connection. This ensures that the connection is established with the correct server and prevents man-in-the-middle attacks.

• Restrict access to the private key—store it securely and limit who can view it.

• Use specific Bind IPs to maintain clear audit trails of which node establishes each connection.

• Monitor the Events Log for connections from 127.0.9.1 to track Reverse Proxy usage.

• Review listener mappings regularly to ensure only necessary services are exposed.

Troubleshooting

The following guidance helps identify and resolve the most common issues encountered when working with Reverse Proxy configurations.

Troubleshooting Guide

Problem	Possible Solution
Connection fails to establish	Verify the external server has GatewayPorts clientspecified in sshd_config. Confirm the public key is added to authorized_keys on the external server. Check network connectivity from the Bind IP to the external server.
Listener mapping doesn’t work	Ensure the listener’s IP is from the same node as the Bind IP. Verify the remote port is unique within this Reverse Proxy configuration. Confirm the listener is active and accepting connections.
UAG not accessible through tunnel	Check that the Any listener mapping is configured correctly. Review Events Log entries from 127.0.9.1 to verify traffic is being received.

Related topics:

• Network interfaces configuration

• Time servers configuration