|
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.
|
