BMC Forwarding Gateways #

SynergyCP’s BMC Forwarding feature moves IPMI/BMC interfaces onto a private LAN where they do not consume public IP space and are not directly accessible from the internet. Access is controlled through IP-based ACLs managed automatically by SynergyCP. There are two forwarding methods: IP to IP (recommended) and Port to Port (deprecated).

How It Works #

When a customer or staff member needs to access a server’s BMC, SynergyCP creates a temporary forwarding rule on the gateway. The customer connects to the gateway’s public IP, and the gateway forwards all traffic through to the server’s private BMC IP on the internal network. From the customer’s perspective, it behaves as if they have direct access to the BMC.

Access is secured through an Access Control List (ACL). When a user ACLs their IP, a forwarding rule is created that matches their specific source IP and routes traffic to the target BMC. The ACL can be manually deleted by the customer when they are done, or it is automatically removed after 24 hours to ensure security.

IP to IP Forwarding (Recommended) #

IP to IP forwarding routes all traffic from a specific source IP through to the BMC IP without changing any ports. Because all ports are forwarded transparently, this method provides complete compatibility with any current or future IPMI interface, including web-based management consoles, KVM sessions, and virtual media.

How Gateway IPs Are Used #

The gateway uses the unique combination of source and destination IPs to manage connections. Each time a user ACLs their IP, the system creates a forwarding rule matching {user’s source IP} AND {a specific gateway public IP} to {the private BMC IP}.

This has several implications depending on the access pattern:

• Multiple customers accessing the same server. When different customers (with different source IPs) need to access the same server’s BMC, the gateway can route both connections through the same gateway IP. Because each customer has a unique source IP, the forwarding rules remain distinct. This enables scenarios like a customer and a vendor support technician connecting to the same server simultaneously for collaborative troubleshooting, without requiring session handovers.

• One customer accessing multiple servers. When the same customer needs to access multiple servers at the same location, the system automatically assigns a different gateway IP for each connection. For example, the first connection might route through 74.212.39.34, the second through 74.212.39.35, the third through 74.212.39.36, and so on. Each session consumes one gateway IP from the pool.

• Multiple customers accessing multiple servers. Gateway IPs are dynamically assigned and reused across different customers and connections to maximize utilization of the available IP pool. The system uses the unique combination of source and destination IPs to correctly forward each connection, so multiple customers can share the same gateway IPs as long as the source/destination pairs remain unique.

IP Pool Sizing #

Connection capacity is limited by the number of gateway IPs available in the pool. If all gateway IPs are in use, new connections cannot be established until an existing ACL is removed or expires.

In practice, you only need as many gateway IPs as you expect concurrent connections from the same source IP. The only scenario where this becomes a concern is if multiple staff members share the same source IP (for example, when connecting through a shared VPN). A good rule of thumb is to allocate one to two times as many public IPs on each gateway as you have staff who may need simultaneous BMC access. For most deployments, 3 to 5 IPs is generous. You can always add more IPs later if needed.

Setup #

1. Prepare the Private IPMI Network #

If you don’t have one already, add a subnet for IPMI devices on your router that is internal only (for example, 10.0.1.1/24). Make sure this subnet is accessible only to other devices in the same VLAN and that your customers cannot reach any IPMI device directly using the internal IP.

2. Provision the Gateway Server #

Provision a server with Debian 13 that has both public IP access and access to the private IPMI LAN. These can be on two different ethernet ports as long as the OS routing is configured so the server can reach the private LAN.

Make sure to install a fresh Debian 13 server. Do not reuse an existing server, as there may be port conflicts.

3. Install the Gateway #

Run the following command on the new gateway server as root (prefix apt-get and bash with sudo if running as a sudo user):

cd /tmp
rm -f gateway-installer.sh
apt-get install -yq wget
wget https://install.synergycp.com/bm/gateway-installer.sh
bash gateway-installer.sh

4. Register the Gateway in SynergyCP #

Copy the details displayed at the end of the installation into the form on the BMC Forwarding Gateways page in SynergyCP.

5. Configure Servers #

To enable forwarding on a server, select a server at the location where you added the gateway. If the server’s BMC is still using a public IP, go to its IPMI control panel and change its static IP to one from the internal subnet. Then edit the server in SynergyCP so that it has the internal IPMI IP and forwarding is enabled.

Go to the manage server page for that server and click Launch KVM to verify that forwarding is working correctly.

Port to Port Forwarding (Deprecated) #

The port-to-port method is deprecated as of SynergyCP 5.1 and will be removed in a future release. New installations should not use the port-to-port method, and troubleshooting will not be provided for new installs. If you are currently using port-to-port forwarding, please transition to IP to IP forwarding as soon as possible.

Port to Port forwarding assigns specific ports on the gateway that map to known ports on the BMC. The benefit of this approach is that it only requires one public IP for the gateway. However, it has two significant limitations. First, it can be confusing for end users accessing the IPMI web console, as features like launching KVM that depend on additional ports may not work (SynergyCP does provide a Launch KVM button in the application as a workaround). Second, the gateway must know all the ports a given BMC device uses, and since BMC APIs are not standardized across manufacturers, some devices may not be fully supported.