On Sun, 15 Aug 2004, Quark IT - Hilton Travis wrote:
> Hi Christian,
> > From: Christian van Eeden [mailto:christian at infinitebang dot com]
> > Sent: Sunday, 15 August 2004 03:34
> > I have read through the various postings about VoIP setups,
> > but there doesn't seem to be a clear "best approach" with the
> > new features in 1.1 This is the setup:
> > Cable Modem -> m0n0wall -> Switch -> VoIP (D-Link DVG-1120)
> > -> Computers
> > From my providers documentation I have forwarded the
> > following ports to the VoIP: (there is no recommendation for
> > min bandwidth)
> > - 2427 (tcp+udp)
> > - 16384 - 32767 (udp)
> Please tell me this was a misprint. Your VoIP provider wants you to
> have 1/4 of the universe open to your VoIP computer? Are they complete
> idiots? Do they not realize how infinitely stupid this is?
Not at all. "Open" ports are harmless unless something is actually
listening on them. Any dynamically assigned ("ephemeral") port where the
initial contact is incoming (e.g. FTP data connections in "active" mode)
needs to be allowed "manually", since stateful filtering doesn't handle
that case automatically. And for anything other than TCP (e.g. UDP),
there isn't a well-defined way to know which party is "initiating" the
connection, so all that matters is who sends the first data. E.g.
client-side RTSP has problems with both firewalls and NAT, since the UDP
data starts incoming, even though the TCP control connection is outgoing.
The "official" ephemeral port range is 49152-65535, so it's not at all
uncommon to open it. Also, the "old" ephemeral port range is 1024-5000,
which is unfortunate since it's in the "registered" range, but again, it
doesn't really hurt to open it if there aren't services listening there.
Note that only services *on the firewall* are relevant on NATted
addresses, since incoming connections can't reach other machines without
The "tcp+udp" part is a bit strange, since it sounds like there's a
control connection plus data connection setup, and there's no terribly
good reason to use UDP for a control connection. The unusual range of
dynamic ports might be to allow the entire block to be forwarded to the
VoIP box in order to avoid NAT problems.
If they were clever enough to have the initial dynamic-port packet be
outgoing, then m0n0wall should need no special firewall setup for that
range, since the stateful filtering would handle it, but NAT redirection
would still be needed just because the NAT code in m0n0wall doesn't
operate in the "try to avoid remapping the port number" mode. Otherwise,
both the NAT redirection and the corresponding pass rule would be needed.