On Mon, 5 Jul 2021 10:58:52 -0700 Jonathan Thornburg <jthorn4...@gmail.com> wrote:
> +--------------+ > (internet) --------| $ISP DSL | > | modem/router | > +--------------+ > | > | > +----------+ +-----------+ > | OpenBSD |----| Omma Telo |.......... analog > | firewall | | VOIP box | telephones > +----------+ +-----------+ > | | > +--------+ | | > | Wifi |-----+ +------ wired client > | access | (or network switch for > | point | multiple wired clients) > +--------+ > > This design would allow pf to protect the Ooma box as well as the > local computers. > > The problem is that (as is pretty standard for VOIP systems) the Ooma > Telo carries voice traffic on UDP packets, and the UDP port numbers > can span a wide (dynamically-chosen) range, rather like ftp. The > Ooma documentation says it needs the following ports: > https://support.ooma.com/home/advanced-connections-and-service-ports/ > outgoing UDP/TCP 53, 1194, 1294 > outgoing TCP 80, 110, 443 > outgoing UDP 67, 123, 3480 > incoming UDP 10000 to 30000 > > So, there are the usual problems of NAT with dynamically-chosen ports. One thing the OpenBSD host cannot know, is what specific port in that 10000:30000 range, is being used at any particular time. I note they don't ask you to expose port 5060/udp, so presumably the device is _not_ receiving SIP traffic directly from incoming callers, but rather tunnels it via some sort of STUN-type arrangement or VPN (port 1194 smells like OpenVPN). What also we don't know, is whether the RTP traffic (the 10000:30000/udp range) is going to come from a single subnet, or from global addresses. If you can find this information out, then it's possible to just expose yourself to your VSP (voice service provider) and be closed to everybody else. Finally, you don't mention if the service is operating on IPv4, IPv6 or dual-stack, but the concepts are the same regardless. You _could_ NAT the traffic seen by the ISP router, but I'm not convinced much is gained by doing this, particularly for the Omma Telco ATA. VoIP protocols are notoriously bad at traversing NAT, so the fewer layers you can put between you and your VSP, the better. Packet filtering will stop a lot of nasties, NAT behind the border router (ISP-supplied in your case) is just "security" through obscurity. I would do the following: 1. Set aside a private subnet address (RFC-1918 for IPv4, RFC-4193 for IPv6) that your ATA will "live" on. Separate VLAN or physical Ethernet segment. 2. Configure your ATA and your OpenBSD router so they can ping each-other. 3. On your ISP-supplied border router, configure a static route to your ATA's subnet *via* your OpenBSD router. Update its NAT rules to forward traffic to the ATA's new IP address. 4. Configure `pf` to pass through just the port ranges specified in the directions required. Do *NOT* apply NAT in either direction: let the ISP-supplied router handle that. Better yet, if you can, maybe consider setting up Asterisk or similar directly on the OpenBSD router, then configure your ATA to talk to that. The Asterisk installation can then "sanitise" the traffic going to your ATA, and is in your control for updates. This is the approach I've taken with my network here (with Internode NodePhone VoIP as VSP and a handful of IP phones and one ATA). By doing this, I better shield the IP phones/ATA from the outside traffic since the border router is transcoding the audio passed to these devices. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
