|
||||||||
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 explicit redirection. 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. Fred Wright |