To analyze network problems like timeouts, missing routing configuration or blocking firewalls, there are some tools available on Airlock like telnet, curl, and tcpdump (resp. snoop). This article tells you how to use them to detect misconfigured Airlock systems and problems in the networks around it.
Note: Some network administrators like to use ping to check network connectivity. Because some devices like firewalls and even Airlock itself may block ping packets but still let pass regular tcp connection data, using telnet and curl for these kinds of short tests usually yields better results.
Please take a look at "Tracing network traffic (tcpdump, tshark)" for examples for the use of tcpdump.
Please note that all examples are shown for network interface eth1 but could be done using any other interface. The interface names can be found in the System Setup menu in the Airlock Configuration Center.
Use the following command to check network traffic (examples given for Airlock 5 using tcpdump):
tcpdump -i eth1
You should see at least some packets received on the interface. If you see nothing at all, the network cable may be disconnected or broken, the switch may be disconnected or a firewall in front of Airlock is blocking all traffic to it.
If you see some packets, please check the IP addresses to be certain that the interface is plugged to the appropriate network.
Use the following command to check if HTTPS packets on standard port 443 reach Airlock
tcpdump -i eth1 port 443
You should at least see some incoming packets from your client IP address. If there are no packets at all, a firewall in front of Airlock is blocking the packets or routing is broken on the client or somewhere between the client and Airlock.
If there are some packets, but they are not responded to by Airlock, then the routing config is wrong on Airlock.
Now you should be able to reach the Airlock Configuration Center!
Use the following command to check if a TCP connection can be established to a back-end server listening on TCP port 8080:
tcpdump -i eth1 port 8080
You should at least see some outgoing packets for the back-end server's IP address. If there are no packets at all, the routing configuration on Airlock is wrong.
If you see packets going out of Airlock to the back-end application but nothing coming back, a firewall may block either outgoing or incoming packets from and/or to the back-end application. It is also possible that the routing config on the back-end application server and/or on the firewalls between Airlock and the back-end application is blocking the traffic.
The requests may be forced by using a browser accessing a Virtual Host on Airlock. To simplify such tests, use the following command:
curl -i http://192.168.1.123:8080/
Curl should receive a valid HTTP response from the back-end server.