NAT Information for Routers

This is a general overview to getting a TRBO repeater online.  While typically, it is plug n play, there have been issues with NAT'ing in some router and when trying to run multiple repeaters and or peers on the same subnet.

Written by JP, KC9KKO and posted in the MotoTRBO Yahoo Group on 7-15-2012 (and again on 8-19-3023) in response to a thread about problems in getting RDAC to see repeaters connected to the same LAN as well as one-way issues.

I suspect that the Hairpin NAT implementation does not support full cone NAT

It appears that MotoTrbo TCPIP CONFIGURATION prefers to use a FULL-CONE NAT such that it allows any external host to use this opened window (IP Address/Source/Destination Port Combination) , where all incoming packets addressed to the mapped external address are translated to the mapped internal address and forwarded through the NAT.

Additionally MotoTrbo appears to require that the Router or Firewall NAT utilize a Port Binding Behavior called "Port Preservation" where the source and destination ports are preserved in the NAT translation of the source IP addressing. Viewing those packets will show the source port with the port number configured in CPS.

The following is what I have previously written to others where they have had problems.

First I am going qualify what i have written is only what I have learned and interpreted, and it may contain errors or omissions.

Mototrbo is plug and play, provided that you have the right parts.

I have an enterprise class commercial firewall and did not give any thought of having issues with installing a Mototrbo Repeater inside our net work and adding the standard firewall rules to masquerade or expose the address of the repeater to the outside world. After all we have done the same with mail servers, web servers and database servers. Having used port address translation and global address translation on three different internet carriers gave us a confidence that a single Mototrbo repeater would reduce to serious head scratching.

Instead of blindly changing parts until it worked, I set out to find out what to look for when it worked and when it didn't.

First, READ the MOTOTRO SYSTEM PLANNER and THE BEGINNERS GUIDE TO MOTOTRBO.

While I strongly reinforce the READ part, I will caution you on what it doesn't say.

It doesn't tell you how to figure out what is wrong.

I discovered that there are TWO things that are the evil enemies of reliable Mototrboing.

One is bandwidth. While I would say that it is the least likely to be the problem, it needs to be ruled out because it will hide or mask the real problem. A low capacity DSL line will be problematic if the base bandwidth calculated with the system planner is more than the DSL provides. See the attached spreadsheet. It should do the math similar to that in the MOTOTRO SYSTEM PLANNER.

Bandwidth needs to have low latency. That means that ping times are very consistent over a long period of time and the return time needs to be low. How low is low, that is hard to say, but it should be closer to 10 or 20ms rather than 200ms.

The other issue with bandwidth is reliability, and not that it is on today or off. But it needs to deliver consistent packets in both directions. Mototrbo uses small packets transmitted in both directions and their timely delivery is critical to assembling the audio packets into sounds that resemble the audio that was encoded.

An example where the media that supplies the internet is where it is delivered with a half duplex radio that switched from transmit to receive to provide what appears to be a full duplex connection. A number of early 802.11 wireless radios used the half duplex with high speed transmit/receive switching to provide a data connection, combined with a store and forward packet buffer to emulate a full duplex connection. This type of media fails to support the low jitter rate required by VOIP traffic such as Mototrbo when the link is loaded at more than a 30% capacity. Initially a lightly loaded link may initially provide acceptable connectivity but as the link gets more fully loaded it may no longer provide the timing that a VOIP link requires. Changing the way internet is connected by changing suppliers or connectivity. I would only do this after the firewall has been validated as Mototurbo Compliant

Second is that a firewall that separates the repeater from direct internet exposure needs to have a specific kind of design. There are about four fundamental designs of firewalls. These different designs are what causes Mototrbo to transmit one way audio. And worse, an improperly connected repeater can cause unstable audio on one or more of the peers and or the master.

How does one know what router works and what doesn't?

Since firewalls don't have a label or description that describes how they work, is mostly trial and error. The models listed below were in the system planner or identified by other Mototrbo administrators.

Cradlepoint MBR-1000

D-Link EBR-2310
Netopia 3347 DSL
CISCO PIX 501
Linksys RVS-4000

The hard part is to determine the difference between misconfiguration and a firewall that incapable of supporting Mototrbo Packets.  Using a packet "sniffer" or analyzer such as wireshark to reveal the source and destination ip address' and source and destination ports will show how the firewall is properly or improperly.

With a packet sniffer attached to a hub or a switch with port mirroring so that every packet entering or leaving the outside wan port of the firewall looking at the source and destination ip address' and source and destination ports, a proper configured firewall will preserve the port address of packets destinated for other peers or masters where the source port and the destination port are equal to the port address configured in CPS for each of the peer repeaters. That port address is also listed in the RDAC display.

There are several key configuration items that need to be considered. The Master UDP port ( This is the port that a peer repeater contacts the Master ), The UDP port ( This is the port that is used for Peer to Peer Communication, The TCP CPS port ( this is the port number that is used to remotely program XPR8400 repeaters ). The way these ports are translated by your firewall or router will make or break how you repeater connect to a remote IPSC network.

Port forwarding is used for UDP port that is programed in the CPS as Target Repeater's UDP port. Do not confuse the master's UDP port. The target's UDP port is the second one listed or lower one in the Link Establishment section in the Network configuration. So make sure that the UDP ports are properly forwarded to the repeater.

If the source port and destination port are not equal then the firewall does not support port preservation as used in a full cone Network Address Translation (NAT).

We opened the ports and pointed them towards the internal address of the Mototrbo Repeater. We tried to place the MotoTrbo Repeater in what is called a DMZ, that is where all the internet traffic is sent to an internal device on the network, in this case our MotoTrbo Repeater. Too many configuration changes to count all resulted in a variety of failures in making the MotoTrbo properly network.

Until we changed the router we experienced one way audio and the inability for RDAC to list a repeater connected to the master. One way audio and the inability for a RDAC connection to communicate with a peer repeater is based on the type of NAT ( or masquerade ) that each type of router or firewall performs to preserve the source and destination ports as the Static Address Translation.

I think that there are two issues which contribute to the problem. One is that it appears that Mototrbo UDP communication requires Full Cone NAT support in a router or firewall connecting to the Internet or open a inbound port translated to the repeater address as specified in the repeater code plug. Further it appears that the router must support "Port Preservation".

But how do you tell if you router support your new Mototrbo repeater. The answer is it either does or does't. The easiest way to configure the router is to setup the router in a DMZ mode where the internal MotoTrbo repeater in made to appear on the outside of the firewall or router using the internet address assigned to the router or firewall.

In the Router or firewall the configuration rules must preserve the source and destination port numbers as well as permit inbound connections on the Peer UDP port specified in the peer repeater code plug.

It appears that MotoTrbo TCPIP CONFIGURATION prefers to use a FULL-CONE NAT such that it allows any external host to use this opened window (IP Adresss/Source/Destination Port Combination) , where all incoming packets addressed to the mapped external address are translated to the mapped internal address and forwarded through the NAT.

Additionally MotoTrbo appears to require that the Router or Firewall NAT utilize a Port Binding Behavior called "Port Preservation" where the source and destination ports are preserved in the NAT translation of the source IP addressing. Viewing those packets will show the source port with the port number configured in CPS.

Packet traces showed that C-Bridge's don not use the source or destination ports in the same way as the Peer or Master Repeaters. Their source ports vary while the destination port is typically the same as the Peer Port programmed in CPS.

Another way to configure the router is to map a UDP port to the internal MotoTrbo repeater. Additionally a port must be mapped for TCP to accommodate remote programming with CPS.

And if it works, it is a good thing, of not it will be a long series of configuration changes to find that magic configuration that works for your model router. And in the end, replacing the router may be the only option.

To trouble shoot our configuration I setup an packet analyzer on the outboard side of our internet router. That enables the analyzer to see the raw packets directly on the internet side of the firewall. We used an open source program called Wireshark.

The address and port discovery method used by the master is regenerative in nature. That means the a misconfiguration will cause the master to misinterpret source port that is being used and the master will communicate that to the other peers which will then use the port to contact the target peer. To properly reset this cycle requires that the repeater be powered off for a period of six or eight minutes. Simply unplugging the repeater does not do the same thing. It is the reboot combined with the other peers not receiving packets from the target repeater that resets the memory of the ports numbers for a repeater.

All the peers will contact the target repeater using the source port that the master deciphered from the packets received from the target when it booted up and contacted the master. The packets from the peers and master destined for the target repeater will have the source and destination ports equal and also equal to the port programmed in the target repeaters CPS.

If they are different then alter the firewall configuration, power off the repeater for six to eight minutes and reboot the repeater, then capture additional packets to verify proper operation.

Initially the Cradlepoint MBR-1000 that I am using did not work until the Network Address Translation (NAT) mode was changed to preserve the source and destination ports. The Cradlepoint MBR-1000 has a setting that changed it NAT mode, otherwise it would have simply replacing the firewall.

Once you have the source and destination ports equal you should notice that the repeater shows up in RDAC consistently. I will forewarn you that a misconfigured firewall will inconsistently permit RDAC to show the repeater in question, and it will fall off the list in time. It will also suffer from one way audio.

The explanation of the packet traces and what the expected results of router or firewall configuration should help others to diagnose and configure connection Mototrbo Repeaters to the Internet using routers or firewalls.

Hope that this helps you,

..jpw
73 OM
KC9KKO


Presented here with permission.

-
Contact DCI

Revised: 10/06/2014 08:06

Webmaster

Sitemap