RCI, VoIP and Firewalls

From TCBWiki
Jump to: navigation, search



RCI (Remote Control Interface) is the Windows(tm) software used to set up and manage most TCB (Tactical Communications Bridge) products including the TCB2, TCB3, TCB4, TCB-IP2, and MSAT-IP. In addition to its set up and control features, it also provides a way to exchange VoIP (voice over IP) audio between your PC and the TCB so you can use the computer's speakers to listen to connected radios and the computer's microphone to transmit on those radios.

Enabling VoIP

The TCB uses port 5 as a VoIP connection to RCI, when it is enabled. To enable it, start RCI using a network connection (not serial port), then from the VoIP Console menu select VoIP Settings. That will open the VoIP Settings form. From there, make sure the top checkbox is checked ("Enable VoIP between computer and controller"). In most cases, you will also want to check the box at the bottom of the screen ("Use dispatch console-style controls to manage VoIP connection (port 5)"). Then close that form. Back on the main grid interface screen, a new set of square "selection" buttons with a "+" symbol in them will appear to the right of the radio names (just left of the port group management "green dots"). Click one or more of those selection buttons (they will turn yellow) to listen to the audio from those radios. You can also press the PTT button at the bottom of the RCI screen (you might have to scroll down) to transmit from your computer's mic to those radios.

Network Connections

RCI can communicate with a TCB using either a RS-232 serial port connection or an Ethernet network connection. VoIP works only with a network connection. To connect using a network connection, RCI needs to know the IP address of the TCB. It then opens a telnet connection and uses it to issue control commands to the TCB and receive status information back from the TCB. In order for RCI to be able to establish such a telnet connection, it needs to be able to contact the TCB using its IP address. If both the computer running RCI and the TCB are on the same LAN (local area network), this is relatively straightforward (see RCI Connection Setup for detailed instructions). It gets more complicated if the connection goes over the Internet, primarily because most routers used for Internet connections use NAT (network address translation) and/or other firewall features to block some kinds of data transfers. If you can control the settings in the router (or have an IT department), it is generally possible to configure the router so RCI can continue to work while still providing the needed security. It may be necessary to make configuration changes on the routers used to provide a connection to the Internet for the computer and/or the TCB, as described below.

TCB is Behind NAT

It is often convenient to be able to use any computer with Internet access to connect to and manage a TCB. For this to work, the TCB needs to have a "public" IP address, one that can be accessed from anywhere on the Internet. This can be done in several different ways:

  • If your Internet router (often integrated with a cable or DSL modem) has a DMZ port, the TCB can be connected to that. Then on a computer connected to that router go to http://www.whatsmyip.org/. The IP address listed there is the one that RCI will need to connect to in order to reach the TCB.
  • The TCB can be connected to the Internet router (the one performing NAT) and the router can be configured to "port forward" incoming telnet (TCP port 23) and/or SSH (port 22) connections to the IP address of the TCB. As in the previous case, on a computer connected to that router go to http://www.whatsmyip.org/. The IP address listed there is the one that RCI will need to connect to in order to reach the TCB.
  • Your ISP (Internet Service Provider) may be able to provide you with multiple "static" public IP addresses (there is often an additional monthly fee for this). In this case, you can set the TCB for one of those static IP addresses and connect it "directly" (without going through NAT) to the Internet. RCI would then connect to the TCB's configured IP address.
    • Note that this kind of arrangement may require additional networking equipment. A typical example would be a DSL or cable modem configured in pass-through mode (necessary for it to handle multiple IP addresses), a network switch (to allow connecting the devices configured for each of your static IP addresses such as the TCB and a router, described next), and a router with NAT which is then connected to your computers and other networked devices.

Change the TCB's Password

Note that with any of the above methods of providing access to the TCB through the Internet, that the TCB's password needs to be changed or it will be open to unauthorized access using the default password. On the TCB-IP2, this can be done from the root:~> prompt by running the "passwd" command. The password set that way will also need to be entered when connecting using RCI (or any other telnet/ssh client). If you forget the password, connect to the TCB's serial port and run the passwd command again.

Computer is Behind NAT

In general, any computer with an Internet connection will be able to connect to and manage a TCB that is configured to allow such remote connections (as described above). There is one feature (VoIP to the PC) that may require additional configuration of the router that the computer running RCI uses to connect to the Internet. Note that this may not be possible if the router configuration cannot be easily changed (such as when using a hotel or other public Internet connection).

VoIP from the TCB to RCI

To enable RCI's VoIP feature, from the VoIP Console menu select VoIP Settings and check the box at the top labeled "Enable VoIP between computer and controller" (also make sure that "Use dispatch-style controls" is selected at the bottom). If the TCB and computer are on the same LAN, the default "Connect via LAN" setting is OK; just click Done. Otherwise, select "Connect through firewall" and click on the "Get Public IP Address" button then enter the resulting address as the "Firewall Address" and click Done.

Back on the main RCI screen, you will now find square "selection" buttons to the right of each radio port name. When not selected, they are gray and have a "+" symbol in them; when selected they turn yellow. Select one of the radio ports, key a test radio and make sure that the activity indicator to the left of the radio port name turns green. If you are on a LAN, you should hear the audio from that radio on your computer's speakers (you can also press the PTT button at the bottom of the RCI screen to transmit from your computer's mic out the radio).

Port Forwarding

As mentioned above, VoIP from the TCB to the computer may not work without some additional configuration. Specifically, if you are not on a LAN (if your computer is connected to the Internet through a router that uses NAT), you may find that PTT (audio from RCI to the TCB) works but audio from the TCB to RCI and your computer's speakers does not. In this case you will probably need to set up port forwarding in the router between your computer and the Internet.


When running RCI behind a firewall that uses NAT (Network Address Translation) and connecting to a TCB that is outside the firewall, it is common to have trouble getting VoIP to work. VoIP is more problematic than just getting a Telnet data connection, because VoIP packets don't pass through a firewall as easily. That is because Telnet uses the TCP/IP protocol, which is "connection oriented" while VoIP uses UDP, which is "connectionless". Without getting into the details, firewalls have an easier time with Telnet because when RCI makes a TCP/IP connection, it creates a two-way path through the firewall, allowing data to flow in both directions.

VoIP, on the other hand, sends each data/voice packet as a separate entity, with just a destination IP address to control where it goes. It isn't typically a problem for a device behind a firewall (like a PC running RCI) to send UDP packets to device outside the firewall (like a TCB on a static IP address). Getting data/voice packets back from the TCB, through the firewall, and back to the PC is often difficult. This is because the NAT features of the firewall hides the IP address of the PC; that is one of the ways it provides security. The hidden address often begins with 192.168..., which indicates that it is a private address that couldn't be routed over the Internet even if the firewall didn't hide it.

So how does any data, even TCP/IP data, get from the TCB to the PC? When the PC makes a TCP/IP connection through the firewall to the TCB, the firewall sets up a "connection", translates the PC's private address to the firewall's address (which is visible from outside), then forwards the data to the TCB. The TCB sends data back to the firewall's address, where the firewall looks up the "connection" information and finds that it needs to forward the data to the PC's hidden address. The TCB never has to know what the PC's address is because it can just send the data to the firewall and let the firewall take care of the translation and forwarding the data.

To get VoIP data from the TCB to the PC, we need the firewall to do the same thing, accept the packets from the TCB and forward them to the PC. To do that, configure the firewall to "port forward" (also sometimes called "packet filtering") UDP packets received on port 23000 to the IP address of the PC (typically 192.168.x.x or 10.x.x.x) on the same port (23000). Often a systems administrator will need to do that, because it involves changing the firewall's security settings. Fortunately, it requires forwarding only a very specific type of data/voice packet from a specific address, so the security risk is very small. If desired, the source address for the packets can be restricted to the address of the PC running RCI (or its router's address) to reduce the risk even further.

Packet Flood Attacks

Even after getting port forwarding set up, some firewalls see all of the data coming from the TCB (about 128 packets per second) and think that they are getting hit with a flood attack (from a hacker trying to crash the system), and discard the packets rather than forwarding them. This should show up in the firewall's log. On the CyberGuard SG560, the solution is to set up a destination NAT rule to specify that packets from the TCB's IP address to the PC's local IP address should be translated (very similar to the port forwarding rule).


If the configuration described above doesn't work, it might be possible to get more information about what the firewall is doing by accessing its logs or opening a telnet connection to it and running "tcpdump" at the command line.

Personal tools