Using Cloud Public IPs with On-Premises Infrastructure
Setting up public IPs on your own infrastructure can be challenging. In the cloud, however, the process is much simpler — you can create static public IPs effortlessly. Interestingly, you can also use cloud public IPs with your on-premises infrastructure.
Understanding Cloud and On-Premise Infrastructure
Think of on-premises infrastructure as a physical computer you can see, manage, and touch. It’s typically located in your own space, such as your home, school, or office building. On the other hand, cloud infrastructure refers to remote computers hosted elsewhere, which you rent as a service. In the cloud, creating servers, networks, and other utilities is as simple as a few clicks — everything is automated and ready in minutes.
Understanding Public IP
On the internet, devices communicate using IP addresses. For example, when you visit google.com, your browser translates this domain name into an IP address (like 103.6.117.2). This IP address points to a server that processes your request and delivers the correct webpage.
Problem
The Problem: Acquiring a Public IP Is Complex
If you want to host a website using infrastructure (servers, networks) located in your own space, you’ll need a public IP address so users can access it over the internet. However, obtaining a static public IP is a complicated and uncertain process.
Potential Solutions
Technical Overview: Forwarding Public Traffic to On-Premise Infrastructure
To enable this solution, follow these steps:
- Create a Cloud Server with a Public IP: Spawn a cloud server and assign it a public IP address.
- Set Up the Cloud Server as a VPN Server: Configure the cloud server to act as a VPN server.
- Connect Your On-Premises Devices to the VPN Server: Configure your on-premises devices (router/server) to establish a connection with the VPN server.
Once the cloud server can communicate with your on-premises infrastructure, it can forward traffic (such as HTTP/S web requests) to servers within your on-premises network.
Here’s a case I’ve personally experienced, and the details that I will explain:
Cloud Pricing Overview
Knowing Virtual Private Network (VPN)
A VPN allows multiple networks that don’t have a direct connection to communicate securely over a public shared network. It creates a “pipeline” for data to travel securely, as if the networks were in the same location.
Configuring OpenVPN as a VPN Server
OpenVPN is a popular, free, and open-source VPN technology that you can use for self-managed infrastructure. While I won’t go into the installation details here, you can refer to these valuable resources for setup instructions:
- Guide To Set Up & Configure OpenVPN Client/Server VPN
- Creating OpenVPN User
- OpenVPN: Assigning Static IP Addresses to Clients
Instead, I’ll share some insights I gained through hours of troubleshooting, which might save you time and effort.
MikroTik Router Compatibility
Enable/Disable Comp-LZO
By default, OpenVPN enables packet compression using the — comp-lzo parameter. However, the generated OpenVPN client configuration often doesn’t include this setting. As a result, when the server tries to decompress the data, it fails.
This issue is particularly common with MikroTik routers, which don’t support enabled comp-lzo. To resolve this, you’ll need to disable comp-lzo on the OpenVPN server side.
How I figured this out: I checked the OpenVPN server logs and noticed decompression errors. Disabling comp-lzo resolved the issue.
Disable TLS Key Authentication
MikroTik routers currently don’t support TLS key authentication, and this is a known issue with no resolution in sight. To work around this, you’ll need to disable TLS key authentication on the OpenVPN server side.
MikroTik Router Local Network Advertising
If you’re familiar with basic network engineering, you know that when two hosts are connected, you can configure static routing to allow communication between the networks behind them. However, VPNs don’t work the same way. Instead, you need to configure the VPN to recognize the destination IP and the host that routes traffic to it.
In OpenVPN, this is done using iroute (internal routing). For a deeper understanding, I recommend reading this resource: OpenVPN and iroute « \1.
In my setup, the MikroTik router has local networks like 192.168.x.y/24. Here’s the configuration I used:
$ cat /etc/openvpn/ccd/mikrotik
ifconfig push 10.8.0.66 10.8.0.65
iroute 192.168.x.y 255.255.255.0The filename ‘mikrotik’ can be anything, depending on the OpenVPN profile name you create for your MikroTik router.
Configuring MikroTik as VPN Clients
I won’t go into detail about setting up the MikroTik client here. Instead, you can refer to these valuable resources for step-by-step instructions:
Once the MikroTik router is set up as a VPN client, the next step is to configure NAT Masquerade on the tunnel interface. This allows devices on the local network to access the internet through the VPN connection.
Forward HTTP/S Traffic to On-Premise Infrastructure
Since the MikroTik router is connected to the OpenVPN server (along with its local network), the OpenVPN server (which has a public IP address) can now reach the local network. This means it can forward traffic, such as HTTP/S requests, to the appropriate host on the local network.
Here’s an example of how to configure iptables to forward HTTP/S traffic:
$ cat /etc/sysconfig/iptables
*filter
:INPUT ACCEPT [16786:4918730]
:FORWARD ACCEPT [36:2092]
:OUTPUT ACCEPT [18402:16207576]
-A FORWARD -i tun0 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o tun0 -m state - state RELATED,ESTABLISHED -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [262:113983]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [8:608]
:POSTROUTING ACCEPT [11:760]
-A PREROUTING -s 10.0.0.0/8 -p tcp -m tcp - dport 80 -j RETURN
-A PREROUTING -s 172.16.0.0/12 -p tcp -m tcp - dport 80 -j RETURN
-A PREROUTING -s 192.168.0.0/16 -p tcp -m tcp - dport 80 -j RETURN
-A PREROUTING -p tcp -m tcp - dport 80 -j DNAT - to-destination 192.168.x.y:80
-A PREROUTING -s 10.0.0.0/8 -p tcp -m tcp - dport 443 -j RETURN
-A PREROUTING -s 172.16.0.0/12 -p tcp -m tcp - dport 443 -j RETURN
-A PREROUTING -s 192.168.0.0/16 -p tcp -m tcp - dport 443 -j RETURN
-A PREROUTING -p tcp -m tcp - dport 443 -j DNAT - to-destination 192.168.x.y:443
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMITThis configuration ensures that:
- HTTP (port 80) and HTTPS (port 443) traffic is forwarded to the specified on-premises server (192.168.x.y).
- NAT Masquerade is applied to allow devices on the 10.8.0.0/24 network to access the internet through the VPN.
More To Explore
- If managing an OpenVPN server seems too complex, consider using Cloudflare’s Zero Trust Network Access. It offers cloud-managed tunneling, simplifying the process of securing and managing your network connections.
Limitations
Well, it still comes with limitations. It’s our choice, will we tolerate this, or drop this solution.
Increased Network Latency
Because the OpenVPN connection is established over a public shared network, traffic must pass through multiple hosts to reach the target web applications. This can result in increased network latency, which may affect the performance of time-sensitive applications.
Increased Data Transfer Costs
Since the connection between your on-premises infrastructure and the cloud is made over the internet, data transfer costs can add up quickly. If not monitored closely, these costs can become significant. To avoid unexpected expenses, make sure to:
- Regularly monitor data transfer usage.
- Set up alerts to notify you of unusual spikes in data usage.
Conclusion
Using cloud public IPs with on-premises infrastructure is a practical solution, but it comes with trade-offs. By understanding the setup process and limitations, you can make an informed decision.
