Access Com-Server & Web-IO via the Internet

There are various ways to enable access to services from COM servers, USB servers, or Web-IOs from the Internet. Some of these are discussed in more detail below, along with their respective requirements, advantages, and disadvantages.

Requirements

Intranets are typically connected to the internet via a perimeter router, yet simultaneously separated from it. In terms of IPv4, the entire intranet, including all participants, is connected to the internet via an official or public IPv4 address of the respective internet provider. The standard setup of many perimeter routers is therefore often based on the “everything out, nothing in” principle. Intranet clients can therefore establish virtually unhindered connections to the internet, but are not accessible and certainly not visible from the other way around.

There are two basic requirements for setting up connections from the Internet to the intranet:

Access the router configuration

Accessing the router configuration is certainly not a problem in smaller networks. However, with an externally managed or administered infrastructure or in the case of an in-house IT department, the help of the administrators is required at this point.

Knowledge of the public IP address of the perimeter router

Public IP address: Static or dynamic?

A static IP address means that a fixed IPv4 address has been agreed upon with the respective internet provider for each internet connection. The intranet is therefore always connected to the internet via the same public IP address. If you want to access the intranet from outside, i.e., from the internet, you only need to know this public IP address. However, static IPv4 addresses are scarce and therefore expensive, so most WAN connections use a dynamic IP address from the provider. This address changes every time the router connects to the provider and is usually subject to cyclical forced changes.

In these cases, the services of a DynDNS provider must be used. The principle is that you reserve a hostname (e.g., webio.hallo.biz) for your WAN connection. Using a special API from the DynDNS provider, the internet router notifies the DynDNS provider of any change in the public IP address, which then updates its DNS entries. In addition to paid DynDNS offerings, there are also free options (e.g., no-ip.com, duckdns.org). However, it’s worth checking the router beforehand to see which DynDNS providers are supported. In a Fritz!Box, for example, the DynDNS client is hidden on a dedicated tab in the Internet -> Permissions menu .

Remote access via port forwarding (NAT/NAPT)

The classic, simplest, but also most insecure way to enable access from the internet to the intranet is static port forwarding. This involves setting up a simple firewall rule in the perimeter router that forwards incoming WAN connections to a specific port number to an IP address on the intranet.

Remote access via port forwarding (NAT/NAPT)

One advantage of port forwarding is, of course, the ease of setup and the broad support by almost every router and firewall.

The list of disadvantages, however, is quite long and quickly raises the blood pressure of admins and security managers:

No client authentication:
Every connection to the internet-side forward port is forwarded to the destination on the intranet. The only remaining protection against access to, for example, the outputs of a Web-IO is the (hopefully set) password.
A WAN-side port number can only be assigned to one destination IP address in the LAN. For example, if multiple web servers located in the LAN are to be accessible from outside using TCP/443, multiple TCP ports must be opened on the WAN side.
Port forwarding does not offer any additional security. Data exchanged unencrypted between communication partners remains unencrypted even as it travels across the internet.

WireGuard VPN between client and perimeter router

Setting up a VPN has long been considered a secure alternative to transparent port forwarding. However, the setup and configuration of previously established IPsec and OpenVPN solutions were – quite rightly – criticized for being difficult and error-prone. This is precisely where the increasingly popular WireGuard comes in. Simple configuration on both the server and client side, high data throughput, and fast connection establishment, combined with secure encryption, have led more and more router manufacturers to integrate WireGuard into their firmware as a remote access alternative.

All of the disadvantages and risks of pure port forwarding mentioned above are eliminated by a WireGuard tunnel. The tunnel’s endpoints are cryptographically authenticated. This means that the server only accepts and responds to network packets that have been encrypted and signed with keys known to it.

Furthermore, the encryption is essentially overlaid on the data streams transmitted within the tunnel. Therefore, even unprotected plaintext protocols such as HTTP or Telnet can be transmitted securely through the VPN tunnel.

Ultimately, a VPN tunnel also offers significantly more transparent and easier access to the remote network. Depending on the configuration, the remote client is completely integrated into the intranet from an IP perspective, for example. This means that remote connections appear like local connections to applications, and the original IP addresses are used.

WireGuard VPNs in segmented intranets

Even in larger and more deeply segmented intranets, secure remote access can be achieved with the help of small firewalls.

Unlike the previous example, the WireGuard server endpoint is no longer located directly in the perimeter router. Instead, several of them exist on small routers distributed throughout the intranet, for example, for automation or sensor/actuator islands. This setup offers all the advantages of VPN tunnels already described. In addition, access by VPN clients is strictly limited to the network islands behind the microwalls – cross-connections to the upstream intranet or other islands are excluded.

Naturally, this infrastructure, with multiple VPN server endpoints distributed across the intranet, requires appropriate port forwarding in the perimeter router. However, due to the WireGuard concept’s strict communication restrictions to known, authenticated clients, the risk is manageable.

A tutorial for setting up WireGuard endpoints within an intranet can be found here.

 

Trying is better than studying!

We would be happy to provide you with a Microwall free of charge for a period of four weeks.
Write in Order in note: “Wanted as a test device.”

Request a test device >>

 
 
 
 
Mr. Clever

Questions?
Mr. Clever will be happy to help.
Tel.: +49 202 2680-110

Read more:

Firewalls, segmentation and isolation

Benefits of segmenting and isolating individual network segments to protect internal company data and devices.

Secure communication between machines and systems

The Microwall enables secure communication with near and far communication partners.

WireGuard VPN tunnel between 2 networks

This tutorial guides you through the configuration necessary to connect two PCs from two different network areas.