From owner-freebsd-ipfw@freebsd.org Tue Sep 26 12:35:12 2017 Return-Path: Delivered-To: freebsd-ipfw@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 4391AE0984A; Tue, 26 Sep 2017 12:35:12 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 BD0F0642E1; Tue, 26 Sep 2017 12:35:11 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LdHLB-1dWs2o3hw1-00iUcD; Tue, 26 Sep 2017 14:35:04 +0200 Date: Tue, 26 Sep 2017 14:35:03 +0200 From: "O. Hartmann" To: freebsd-current , freebsd-ipfw@freebsd.org Subject: FreeBSD, IPFW and the SIP/VoIP NAT problem Message-ID: <20170926143503.66f6532c@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:SF2EdouQVPAh1+Mjc4FHM8gH9ziNKTD0RWJhZKJC13xlNzYuO0f GX9mWpeCFGgZ7juf/xDp8yDxNbw78UxBMlLf2ZXCLD2Qq5b2VJsLrQS2DWpcv6p/P9YehHg JqnsCHzd4XjbYc4yYyp902jXsfb4G5/HIQTlHMaqcTT40HKsB1iJ7GQvawr051xtAewyRJA AuiJ9nnU2wHhAOHb4baGg== X-UI-Out-Filterresults: notjunk:1;V01:K0:v21T0mBV0C4=:Qj4N/n9dmtnLC4tGEEKDu9 I88wyUpTxV9Klfs9WDk7XV7O6+WE2wcW6KiNCxGCaB65zc1LiZ4WCA/GMcE1cUrpDi7mryDZz AGbTiUn14tYPefA6RNcK33uafyjdjaArF+5qH/WjOvDskQfPTBOXXSvmzhp2M9e5Al0/J15FN tS7rPxjg65q3VT4bjM9wJrCgqDm/MxcRNp2wGi35gKzKhQqB62h324RQPQii6AtXQaDUBCb6C 2A2fx08sYZGRSLm0BRFhM9T71SUOpl3t718RPsUlSYo27Zi+yXSVjEuyuwGzX25bSlThia0Va wHhj0YB4VCv+w3T7ugxWahEKrA125ONe4B4GeX1vnfWoVAoxgLyuJjwd7fUOcvdYP26qae95Z HI7TdSgWlc3FIH7JkQG707TAFLMu6RM1pFU2Pm9NsasySN82P0737gCrw7NzN78z8XaSYsp1s pL4ZQm2QFU0OxCSQ7jTQ3sJ3RvzafuJ4XFb6urBtCkKXl7eiwh+H2N0usS4GeaPiko0kg3QlL 8+VERP1Sky3jBZDgTz2mV92WyjWHUgGuNdAHj+C6DnMGixoZWmczrb2ziqPN93EtzlS0u3Qp8 R4MJ5DhZ9Gz29GmuKkstNxm5xK34IVvxYyByR9748D78wwOhCCVuUUdzscR5pSF0BqK007Blq YA+Z4tIq7iC9vUAhHGAx5To5E7CshKcB5JPNYs2uCQO27mvNYQlrbxdcAel0yXbPj1g9r93F4 2sJskZGMpvx+kD8YXHwsYWRTzNC4tUt7bzHOVqtISXd2hZOFRp4BA4KS+FmfxZiYG1wlzzOK0 Dlu7pYeyCl/gmP4+kVsYBBoAByRqKIhpQIxo7SnbeQzhmbU8T0= X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 12:35:12 -0000 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