Disclaimer
In order to fully understand what is happening and to debug the setup it is necessary to have knowledge about networking and firewall rules. Furthermore the document is not a complete setup to a production case. It is a proof of concept which the user must be able to adapt it for his own case.
Overview
The idea is access devices that are locally accessible by the ctrlX CORE. For this tutorial we want to access the IndraControl XM22, as shown in the picture below.
Fig. 1.: Overview
Equipment used
The test has been done with:
- ctrlX CORE release 21.11
- eth0 set to IP address: eth0 set to 192.168.1.1, eth1 set to: 192.168.2.1
- ctrlX App Firewall 1.12.0
Transfer data packets
Step 1: Forward data packets
In order to forward data packets it is necessary to allow it from the eth0 and eth1 interfaces:
Fig. 2.: Setting of eth0 and eth1
From firewall point of view it is also necessary to allow the packet forwarding (by default it is allowed).
Step 2: NAT Setting
While we can access the ctrlX CORE itself without problems, it is still not possible to also access the other devices in our network. Why is this? If a device in the local network (192.168.1.0/24) receives a packet from a device in our external lan, it still has as source IP the IP address of this device. As this is an IP address in the external network, how should the device know how to route the answer-packet back to our access device. There are two solutions for this:
- Setting the default gateway in the XM22 to the IP address of our ctrlX (192.168.1.1)
- By configuring a source NAT rule, what will be done in the following and explained below
Fig. 3.: NAT Settings
Step 3: PC routing
After everything has been set up in ctrlX CORE it is necessary to setup the right rules also inside the PC. Being the PC address 192.168.2.X and the ctrlX CORE eth1 address = 192.168.2.1 the rule to be entered is the following:
- route add 192.168.1.0 mask 255.255.255.0 192.168.2.1
It means that when the PC tries to reach the 192.168.1.X it routes them through 192.168.2.1 which is the ctrlX CORE. It is possible to check if this work as assumed using the command "tracert".
Fig. 4.: PC settings and routing check.
Step 4: XM22 access
Now it is all set up!! When entering http://192.168.1.25 to the browser the XM22 WebAssistant page should be reachable!
Fig. 5.: WebAssistant
Now Even Indraworks should be able to program the XM22 passing through ctrlX.
Fig. 6.: XM22 programming
Explanation
The structure of the network packets is close to what is represented in the picture below:
Fig. 7.: Data Packet
The image is just indicative, what is important to us is that our packet has:
- A destination address (where the packet should arrive)
- A source address (who is sending the packet)
- A Payload ( the data exchanged)
The packet takes 3 main steps to get to destination and 3 also to get back. 
Fig. 8.: ctrlX CORE Firewall structure
Setting the routing rules on our PC in step 3 we're able to send packets destined for 192.168.1.25 to ctrlX core. Here is where the trick is starting.
Once the packets are inside the ctrlX CORE we can do many things, first of all we could change the destination IP applying a Destination NAT in (Number 1 in Fig.8 but this is not our case, the packets are going directly to the the forward filter (Number 2 in Fig.8 )) . Here we must be sure that the packets are not being filtered!! To do that the step number 1 of the guide is mandatory, also it is good to check inside the "Forward Filter" part of the firewall that there are no other rules that may block the packets.
The last part is the most important, before the packets leave the ctrlX the packets are passing through a SNAT (Source NAT: number 3 in Fig.8 ). In this last step the source address of the packet that, till now, is something like 192.168.2.x is then changed to 192.168.1.1 which is the ctrlX CORE address of the interfaces that is connected to the XM22.
Why that? Once the XM22 receives the packet it answers to the address in the source field. Now the XM22 knows the address of the device which sent the packet to it, as it is the address of the ctrlX CORE and can thereby send the packet back to ctrlX CORE. The rules to setup this last part are explained in step 2.
The packets that have to come back from the XM22 to the PC are automatically translated by ctrlX CORE itself on they way back.
This tutorial does not have the aim to explain all routing capabilities the ctrlX can offer. We're just using a subset of features useful to obtain our goal. To fully understand what is behind the ctrlX firewall and routing configuration a basic knowledge on computer networks and firewall rules is necessary. Starting from iptables and NFT tables.
Continues...
The settings and experience about routing coupled with a VPN will follow in an own blog.
