From owner-freebsd-current@freebsd.org Tue Sep 26 13:44:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54017E0C204; Tue, 26 Sep 2017 13:44:34 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 60D6866617; Tue, 26 Sep 2017 13:44:32 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LiTJE-1dMfvW25pk-00cjZn; Tue, 26 Sep 2017 15:44:30 +0200 Date: Tue, 26 Sep 2017 15:44:29 +0200 From: "O. Hartmann" To: Damjan Jovanovic Cc: "O. Hartmann" , freebsd-current , freebsd-ipfw@freebsd.org Subject: Re: FreeBSD, IPFW and the SIP/VoIP NAT problem Message-ID: <20170926154429.1c79d842@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <20170926103543.0aa03c7a@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:x6/3FELAFpyMg93sjhTdiuvoU182tuoOefvuYTiMytPfULC6BZM Qy0a3G7FIaBLyx5xjXpdOEoXiQQJvnfQMCf/luEp9prrRcX+f0paFLvyZv0ahTlJR4POxh1 ToGgGAsIf3/cE980TPugvPTyClgRYpou/KEW1a9uAN9PnUyFIDRQVHBxkX/PMdaQa3eL1GC Ce7vMwonkcYQkLZXM60FA== X-UI-Out-Filterresults: notjunk:1;V01:K0:GKDajNlfr5E=:MFqkx33eA1Ydwh5hMgRm4g 80rNpU8C6EoB3V9sNAGFwfkHl4IPQ8cGK23I+Ix5Bsy8grAL+6QyZtMdBD9SCieQLNdwyuIdV G2sDdToqljL3IXhw+7irxBLemfOMT+JXhBIUzgLsZcvh8eRkvqhZo8sVF9Ul59CvZqRLkmh6+ ZwXmk8ug991cdSN/0M/YIlekhUmvEl3AKk3l0ltW2VEEN/q+LQrcBHWSdBuRqAOJZkTcKUZW2 JqCkvMdlpbheunOeiedBPux67D3+Q/NerVzq17SRfylRicesvvIR6DqVoy/o4nrEgVjwT8iN0 GWlraGScE7WrhBr0TAyr096mfLQ67dIKjczqlixcyyuBllCO0BGQmRAYsPFXlbEYCNzove18g ORpwWaFXkzTpMe0VFhfRk7KdlI4RZZJOmQxYU2ZvNEexwkz7fHz8fThvM964XvMxj5xCnAQqM LvS16YguzgvT/ijujR91SQejviAJmQv5QSp+ajshI+Y1m29WcwaE61CErLdtTHsOgiYER+OVP NqBJGdG8eZTj9fTX/+ExQIcFgqipBW/T4ILsFWsQaO/FC3oExFk0rXW12qhzSkvXDIgakGz5y msgKEbSbQVETuUsfI4M3UAFR0vDAD85MBpoxTvn0m7aNqeyuE/gLsergo4lAhthi2S23h1Amn c2yAAx7frckqGlcEOc53u4j2K0+7KpLhGryxoADpn/Y0MkJwfJ/c26sPdH6g0qX2VG6NgqIg7 n8UQs6TYfdxUuCGggIxynV0gu6v3yfYel7ZfHMj1htglkDj89yU9nfav8drrAcZm6lHPuXG8e 0brTUMG3MB4smzfujwJBZfg3HQxDCDhfsbdwUL2fhKweh8czPs= X-Mailman-Approved-At: Tue, 26 Sep 2017 17:24:54 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 13:44:34 -0000 On Tue, 26 Sep 2017 11:00:45 +0200 Damjan Jovanovic wrote: > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann > wrote: > > > Hello, > > > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran > > into > > several problems. My questions might have a "noobish" character, so my > > apology, > > my experiences with IPFW are not as thorough as they should be. > > > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 about > > coming soon also supported? > > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform > > (assumed > > having 2 GB of RAM)? > > > > My main concern is about IPFW (we do not use PF for some reasons, I have to > > stay with IPFW). > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet > > IPv6. > > The FreeBSD system acting as a router is supposed to have a jail soon > > containing the Asterisk 13 IP PBX (at the moment running on the main > > system). > > To provide access to the VoIP infrastructure inside/behind the router/NAT > > system, the in-kernel NAT facility of FreeBSD is forwarding the relevant > > UPD/TCP ports for VoIP to its destination network, and here I have a > > problem to > > solve. > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, > > it > > is a mess and pain in the arse to forward a whole range, say 11000/udp - > > 35000/udp, which is a range one of my providers is sending RTP on. A second > > provider uses another range for RTP, starting at 5000/udp. So, the logical > > consequence would be a union set up UDP range to forward, which exapnds > > then > > form 5000/udp to 45000/udp - which is much more a pain ... > > > > One of the most disturbing and well known problems is that due to the > > stateful > > firewall the RTP session very often is half duplex - it seems one direction > > of the RTP connection doesn't make it through IPFW/NAT. As often I search > > the > > net, I always get informed this is a typical problem and solutions are > > provided by so called ALGs - since SIP protocol's SDP indicates within the > > payload of the packets on which UDP ports both ends wish to establish their > > RTP session, it would be "easy" to pinhole the IPFW on exactly those ports > > for > > a theoretical large number of sessions, if IPFW could "divert" those > > packets > > to an instance inspecting SDP (or whatever is used for the RTP port > > indication, I'm new to that, sorry for the terminology) and then pinholing > > the > > NAT/IPFW for exactly this purpose without the forwarding mess. I came along > > netgraph() while searching for hints and hooks, but it seems a complete > > Linux > > domain, when it somes to appliances like VoIP/IP PBX. > > > > Either, the problem is that trivial on FreeBSD, so no further mentioning is > > necessary (which would explain the vast emptyness of explanations, hints > > and > > so on) or FreeBSD is a complete wasteland on this subject - which I also > > suspect, since pfSense and OPNsense must have come along with such problems > > and I simply do not know or recognise the software used for those purposes. > > > > So, if someone enlightened in this matter stumbles over my question and > > could > > delegate me onto the right way (ports, ng_XXX netgraph ficilities to look > > at, > > some ipfw techniques relevant to the problem apart from the stupid simple > > forwarding large ranges of ports) - I'd appreciate this and > > > > thanks in advance for patience and help, > > > > Oliver > > > > > Hi > > It might be easier if you just enable STUN on Asterisk, and build FreeBSD > from source with my [largely neglected :( ] patch on > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219918 > > That way Asterisk should dynamically discover consistent external mappings > for connections, making port forwarding RTP unnecessary. > > Damjan STUN is enabled, but my providers do not support STUN. I try to figure out how SIP works exactly to make my problem more precise. I also try to understand the aim of your patch - as far as I know, it does exactly as it is needed for the IPW/NAT/VoIP case. And I really regret that there are objections to commit the patch ...