ChangelogDownloads
HomeGuidesChangelog
ChangelogDownloadsSupportMulti-service IoT Edge GatewaysEUROTECH
SupportMulti-service IoT Edge GatewaysEUROTECH
These docs are for v5.1.0. Click to read the latest docs for v7.4.0.

Firewall Configuration

Suggest Edits

ESF offers easy management of the Linux firewall iptables included in an IoT Gateway. Additionally, ESF provides the ability to manage network access security to an IoT Gateway through the following:

  • Open Ports (local service rules)

  • Port Forwarding

  • IP Forwarding and Masquerading (NAT service rules)

  • 'Automatic' NAT service rules

Open Ports, Port Forwarding, and IP Forwarding and Masquerading are configured via respective Firewall configuration tabs. 'Automatic' NAT is enabled for each local (LAN) interface using the DHCP & NAT tab of the respective interface configuration.

Firewall Linux Configuration

This section describes the changes applied by ESF at the Linux networking configuration. Please read the following note before proceeding with manual changes of the Linux networking configuration.

🚧

Avoid Conflicting Configuration Changes

Eurotech does NOT recommend performing manual editing of the Linux networking configuration files when the gateway configuration is being managed through ESF. While Linux may correctly accept manual changes, ESF may not be able to interpret the new configuration resulting in an inconsistent state.

When a new firewall configuration is submitted, the /etc/init.d/firewall script is modified with iptables rules that match the desired configuration and executed for the rules to take effect. Custom firewall rules (ones that cannot be handled by the web console) may be added to the /etc/init.d/firewall_cust script manually. These rules are applied/reapplied every time the /etc/init.d/firewall script is executed.

Open Ports

If ESF is running on a gateway, all TCP/UDP ports are closed by default unless they are listed in the custom local service rules section of the /etc/init.d/firewall file (controlled by ESF), or in the /etc/init.d/firewall_cust script. Therefore, if a user needs to connect to a specific port on a gateway, it is insufficient to have an application listening on the desired port; the port also needs to be opened in the firewall.

To open a port using the ESF Gateway Administration Console, select the Firewall option located in the System area. The Firewall configuration display appears in the main window. With the Open Ports tab selected, click the New button. The New Open Port Entry form appears.

The New Open Port Entry form contains the following configuration parameters:

  • Port - specifies the port to be opened. (Required field.)

  • Protocol - defines the protocol (tcp or udp). (Required field.)

  • Permitted Network - only allows packets originated by a host on this network.

  • Permitted Interface Name - only allows packets arrived on this interface.

  • Unpermitted Interface Name - blocks packets arrived on this interface.

  • Permitted MAC Address - only allows packets originated by this host.

  • Source Port Range - only allows packets with source port in the defined range.

Complete the New Open Port Entry form and click the Submit button when finished. Once the form is submitted, a new port entry will appear. Click the Apply button for the change to take effect.

2432

Port Forwarding

Port forwarding rules are needed to establish connectivity from the WAN side to a specific port on a host that resides on a LAN behind the gateway. In this case, a routing solution may be avoided since the connection is made to a specified external port on a gateway, and packets are forwarded to an internal port on the destination host; therefore, it is not necessary to add the external port to the list of open ports.

To add a port forwarding rule, select the Port Forwarding tab on the Firewall display and click the New button. The Port Forward Entry form appears.

The Port Forward Entry form contains the following configuration parameters:

  • Input Interface - specifies the interface through which a packet is going to be received. (Required field.)

  • Output Interface - specifies the interface through which a packet is going to be forwarded to its destination. (Required field.)

  • LAN Address - supplies the IP address of destination host. (Required field.)

  • Protocol - defines the protocol (tcp or udp). (Required field.)

  • External Port - provides the external destination port on gateway unit. (Required field.)

  • Internal Port - provides the port on a destination host. (Required field.)

  • Enable Masquerading - defines whether masquerading is used (yes or no). If enabled, the gateway replaces the IP address of the originating host with the IP address of its own output (LAN) interface. This is needed when the destination host does not have a back route to the originating host (or default gateway route) via the gateway unit. The masquerading option is provided with port forwarding to limit gateway forwarding only to the destination port. (Required field.)

  • Permitted Network - only forwards if the packet is originated from a host on this network.

  • Permitted MAC Address - only forwards if the packet is originated by this host.

  • Source Port Range - only forwards if the packet's source port is within the defined range.

Complete the Port Forward Entry form and click the Apply button for the desired port forwarding rules to take effect.

Port Forwarding over VPN

Port forwarding rules may also be applied over a VPN connection. The initial setup is described below.

  • A RaspberryPi and an IoT Gateway share the same LAN over Ethernet.

  • The RaspberryPi is running Eclipse Kura and is configured as follows:

    • The eth0 interface static with IP address of 172.16.0.5.
    • There is no default gateway.

  • The IoT Gateway is running ESF and is configured as follows:

    • The eth0 interface LAN/static with IP address of 172.16.0.1/24 and no NAT.
    • The cellular (ppp0) interface is WAN/DHCP client.
    • Both eth1 and wlan0 interfaces are disabled.

  • The gateway is connected to the cloud via ppp0 interface and a VPN connection is established.

  • A laptop is connected to the same VPN server and can ping the tun0 interface of the gateway.

The purpose of this gateway configuration is to enable access to the Kura Gateway Administration Console running on the RaspberryPi (port 80) by connecting to the gateway's port 8080 over the VPN. This scenario assumes that the VPN connection is established by both the gateway and connecting laptop, and that IP addresses are assigned as follows:

  • Gateway tun0 - 10.234.0.6

  • Laptop tun0 - 10.234.0.10

The following port forwarding entries for this VPN configuration are added as described above using the Port Forward Entry form:

  • Input Interface - tun0

  • Output Interface - eth0

  • LAN Address - 172.16.0.5

  • Protocol - tcp

  • External Port - 8080

  • Internal Port - 80

  • Masquerade - yes

The Permitted Network, Permited MAC Addrress, and Source Port Range fields are left blank.

The following iptables rules are added to the custom port forward service rules section of the /etc/init.d/firewall script:

#custom port forward service rules
iptables -t nat -A PREROUTING -i tun0 -p tcp -s 0.0.0.0/0 --dport 8080 -j DNAT --to 172.16.0.5:80
iptables -t nat -A POSTROUTING -o eth0 -p tcp -d 172.16.0.5 -j MASQUERADE
iptables -A FORWARD -i tun0 -o eth0 -p tcp -s 0.0.0.0/0 --dport 80 -d 172.16.0.5 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -p tcp -s 172.16.0.5 -m state --state RELATED,ESTABLISHED -j ACCEPT

The following iptables commands may be used to verify that the new rules have been applied:

iptables -v -n -L
iptables -v -n -L -t nat

At this point, it is possible to try to connect to http://10.234.0.6 and to http://10.234.0.6:8080 from the laptop. Note that when a connection is made to the gateway on port 80, it is to the ESF configuration page on the gateway itself. When the gateway is connected on port 8080, you are forwarded to the Kura Gateway Administration Console on the RaspberryPi. The destination host can only be reached by connecting to the gateway on port 8080.

Another way to connect to the Kura Gateway Administration Console on the RaspberryPi would be to add an IP Forwarding/Masquerading entry as described in the next section. In this case, the following additional iptables rules need to be added to the custom NAT service rules section of the /etc/init.d/firewall script:

#custom port forward service rules
iptables -t nat -A PREROUTING -i tun0 -p tcp -s 0.0.0.0/0 --dport 8080 -j DNAT --to 172.16.0.5:80
iptables -A FORWARD -i tun0 -o eth0 -p tcp -s 0.0.0.0/0 --dport 80 -d 172.16.0.5 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -p tcp -s 172.16.0.5 -m state --state RELATED,ESTABLISHED -j ACCEPT

#custom automatic NAT service rules (if NAT option is enabled for LAN interface)

#custom NAT service rules
iptables -t nat -A POSTROUTING -p tcp -s 0.0.0.0/0 -d 172.16.0.5/32 -o eth0 -j MASQUERADE
iptables -A FORWARD -p tcp -s 172.16.0.5/32 -d 0.0.0.0/0 -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 172.16.0.5/32 -i tun0 -o eth0 -j ACCEPT

This solution is less desirable for the following reasons:

  • The IP Forwarding solution is no longer self-contained.

  • Extra FORWARDING rules are defined.

  • It allows the gateway to forward/masquerade all traffic to the destination host; therefore, if a connecting laptop has a route to the destination host, it provides a way to ssh to the RaspberryPi as well and may present a security problem.

IP Forwarding/Masquerading

The advantage of the Automatic NAT method is its simplicity. However, this approach does not handle reverse NATing, and it cannot be used for interfaces that are not listed in the Gateway Administration Console (such as VPN tun0 interface). To set up generic (one-to-many) NATing, select the IP Forwarding/Masquerading tab on the Firewall display. The IP Forwarding/Masquerading form appears.

The IP Forwarding/Masquerading form contains the following configuration parameters:

  • Input Interface - specifies the interface through which a packet is going to be received. (Required field.)

  • Output Interface - specifies the interface through which a packet is going to be forwarded to its destination. (Required field.)

  • Protocol - defines the protocol of the rule to check (all, tcp, or udp). (Required field.)

  • Source Network/Host - identifies the source network or host name (CIDR notation). Set to 0.0.0.0/0 if empty.

  • Destination Network/Host - identifies the destination network or host name (CIDR notation). Set to 0.0.0.0/0 if empty.

  • Enable Masquerading - defines whether masquerading is used (yes or no). If set to 'yes', masquerading is enabled. If set to 'no', only FORWARDING rules are be added. (Required field.)

As a use-case scenario, consider the same setup as in port forwarding, but with cellular interface disabled and eth1 interface configured as WAN/DHCP client. In this case, the interfaces of the gateway are configured as follows:

  • eth0 - LAN/Static/No NAT 172.16.0.1/24

  • eth1 - WAN/DHCP 10.11.5.4/24

To reach the RaspberryPi unit sitting on the 172.16.0.5/24 from a specific host on the 10.11.0.0/16 network, set up the following Reverse NAT entry:

  • Input Interface - eth1 (WAN interface)

  • Output Interface - eth0 (LAN interface)

  • Protocol - all

  • Source Network/Host - 10.11.5.21/32

  • Destination Network/Host - 172.16.0.5

  • Enable Masquerading - yes

This case adds the following iptables rules to the custom NAT section of the /etc/init.d/firewall script:

#custom NAT service rules
iptables -t nat -A POSTROUTING -p all -s 10.11.5.21/32 -d 172.16.0.5/32 -o eth0 -j MASQUERADE
iptables -A FORWARD -p all -s 172.16.0.5/32 -d 10.11.5.21/32 -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -p all -s 10.11.5.21/32 -d 172.16.0.5/32 -i eth1 -o eth0 -j ACCEPT

Additionally, a route to the 172.16.0.0/24 network needs to be configured on a connecting laptop as shown below:

sudo route add -net 172.16.0.0 netmask 255.255.255.0 gw 10.11.5.4

Since masquerading is enabled, there is no need to specify the back route on the destination host. Note that with this setup, the gateway only forwards packets originating on the 10.11.5.21 laptop to the 172.16.0.5 destination.

If the Source Network/Host and Destination Network/Host fields are empty, iptables rules appear as follows:

#custom NAT service rules
iptables -t nat -A POSTROUTING -p all -s 0.0.0.0/0 -d 0.0.0.0/0 -o eth0 -j MASQUERADE
iptables -A FORWARD -p all -s 0.0.0.0/0 -d 0.0.0.0/0 -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -p all -s 0.0.0.0/0 -d 0.0.0.0/0 -i eth1 -o eth0 -j ACCEPT

The gateway forwards packets from any external host (connected to eth1) to any destination on the local network (eth0 interface).

Updated less than a minute ago