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 From owner-freebsd-ipfw@freebsd.org Tue Sep 26 13:44:34 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 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-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 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 ... From owner-freebsd-ipfw@freebsd.org Tue Sep 26 14:27:14 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 6838DE0D1A2; Tue, 26 Sep 2017 14:27:14 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC47867BFF; Tue, 26 Sep 2017 14:27:13 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id m199so4728157lfe.3; Tue, 26 Sep 2017 07:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U6Nk1dzFPwcJM/CqFUnxO0JibOlKM8qChqzMRRekiKo=; b=Epe44ArCKEQV0KFmiEz5ajTeEWK9VUfT+M+6yihvg3hD3lH9fgQugKm8Nm+/p0T8tC SyfaQzQnQ+O5BxrNZedCGjt+DIcoRm6mnRI+Th6QFkvoKRXe0z2dOHNmecb3OyTfPEhV U1r0UpOvkcuNSS1krWg96Xc+ltOxcnAxoZUk/fcBH+xYBplmEMjpCAhH3Mw/+jFIPfTZ RpUZ1/AiVlV70uVrsU43309dOILgMLl5GTJSuBIpc2dRAwCVKzCyJT/8xGJ7UbCCCGMG epzUsLuuS2UwBp5+uAC3NZBgGMJDIACa7izeBIedcsQrXbdJGMqF2T6ERbVC15xQy2nS 0GmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U6Nk1dzFPwcJM/CqFUnxO0JibOlKM8qChqzMRRekiKo=; b=dyI8oL2QFUHdhmfsqtK40D88qmSmi9Uaup4x9NJ8fBSXjL4q1xFqmexSQ1OMdAsqs/ ZgOxjLYpTGj3Ve4PT1M8tr2NuCEldVi89+6tI9It2v7OL+O+U6kXrDzOEkr4s0oHazVB 1uNq9UHA4pbxgvwiufI+YykkgRP48JmFkDH2UrUY5+j37Nu7NMvmBYpG4QZx+lMJ10AY kArcOlQynx2JOuqV89EFSh8OoZ1/lf4NrQarnhkbaBIODuH9BqpO0g6oA+eJ1E4YUWvd 7TYGd9FZ4T6pT+sWKQYfWfu7MTTpJ0r/cME23EcIN5DW8WIeWEo25vX00JFO5/jx9N+O 3rog== X-Gm-Message-State: AHPjjUg/QTwqcCRST/wwoPiI7au0vTKQeCVBGuRx8mDAfHeolFmmYB97 UtcGcySWsXN7jovPQxQ2QdrkInHZrKt2Pm4o1QvSdQ== X-Google-Smtp-Source: AOwi7QCwSK04ERIBvKDYhdJzEWEdrV6HUoy7Thmg27ppIrdH7+zkkv/nqcGky48GT0qL0gwBmg6hSo6QDgAT1ZtKDJg= X-Received: by 10.46.56.8 with SMTP id f8mr4319481lja.189.1506436031680; Tue, 26 Sep 2017 07:27:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.89.13 with HTTP; Tue, 26 Sep 2017 07:26:51 -0700 (PDT) In-Reply-To: <20170926154429.1c79d842@freyja.zeit4.iv.bundesimmobilien.de> References: <20170926103543.0aa03c7a@freyja.zeit4.iv.bundesimmobilien.de> <20170926154429.1c79d842@freyja.zeit4.iv.bundesimmobilien.de> From: Damjan Jovanovic Date: Tue, 26 Sep 2017 16:26:51 +0200 Message-ID: Subject: Re: FreeBSD, IPFW and the SIP/VoIP NAT problem To: "O. Hartmann" Cc: "O. Hartmann" , freebsd-current , freebsd-ipfw@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 14:27:14 -0000 On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann wrote: > 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 ... > > Firstly, if your providers support NAT, you register to them (as opposed to they register to you, or no registration), and the only VoIP calls are to/from your providers and to/from the same IP:port you register to (as opposed to unknown external addresses), then none of this should be necessary. Just put these on every SIP peer in Asterisk (this is for chan_sip; not sure about chan_pjsip): directmedia=no nat=force_rport,comedia and register to your provider more often than your NAT timeout is (eg. every minute), and you should be good. Why? Every registration opens a NAT mapping that your provider can use to send you calls on. The provider will also send RTP to the source IP:port it received it from, so when you start sending RTP you will get RTP back even if it's arriving from an unexpected IP:port. NAT is not a big problem for SIP clients, only for SIP providers that have receive packets from unknown addresses. Otherwise... Why would your providers need to support STUN? Applications first use STUN to discover the external IP:port of their internal IP:port, and then communicate that IP:port to the other side however they usually would (eg. headers in SIP and SDP packets) - the other side doesn't know or care that they were discovered through STUN. Any STUN server anywhere on the Internet can be used for this and should give the same results; see https://www.voip-info.org/wiki/view/STUN for a list. My patch ensures UDP NAT hole punching logic can be used properly. With it, if a packet was sent from an internal IP:port through an external IP:port (eg. to a STUN server), then any future packet from that internal IP:port to any other external server:port will go out the same external IP:port, and no other internal IP:port will use that external IP:port. It's like the internal IP:port temporarily owns the unique external IP:port and can send and receive through it to and from anywhere. The same source IP:port will be seen by all servers, and they can send back to it. From owner-freebsd-ipfw@freebsd.org Tue Sep 26 23:51:37 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 70FCBE25F2E for ; Tue, 26 Sep 2017 23:51:37 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from homiemail-a125.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 531138088E for ; Tue, 26 Sep 2017 23:51:36 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from homiemail-a125.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a125.g.dreamhost.com (Postfix) with ESMTP id 8C60F60000E02 for ; Tue, 26 Sep 2017 16:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=menhennitt.com.au; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= menhennitt.com.au; bh=0Q0+I9Ea7SNmDAFsir5qLxalGQo=; b=OMJLDMuJ1k 4hzvr0u3aotN+fkZgJOZ0dXTGZKPdgKX4VGJlcZyQJ99ifvbJACJuVzvBAq7QNs0 Cx2rQ4OkCwGv5XyzbB45rl/r/Kx9zDyKg9K2IFshB9uCcAMfwqgGhD2Cd2uESa4C UaKZYuV0KiDwbHENxhGbB4Ysc9u+JYhLc= Received: from [137.237.172.142] (unknown [192.160.117.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: graham@menhennitt.com.au) by homiemail-a125.g.dreamhost.com (Postfix) with ESMTPSA id D9C6560000E00 for ; Tue, 26 Sep 2017 16:51:29 -0700 (PDT) Subject: Re: FreeBSD, IPFW and the SIP/VoIP NAT problem To: freebsd-ipfw@freebsd.org References: <20170926143503.66f6532c@freyja.zeit4.iv.bundesimmobilien.de> From: Graham Menhennitt Message-ID: <76cb9b72-53ac-eadc-f921-dc01808a9aeb@menhennitt.com.au> Date: Wed, 27 Sep 2017 09:51:25 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170926143503.66f6532c@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-AU 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 23:51:37 -0000 On 26/09/2017 10:35 PM, 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. > > ... > 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. Does your VoIP provider allow IAX2 protocol as well as SIP? Many do. Then you can avoid the problem completely. Graham From owner-freebsd-ipfw@freebsd.org Wed Sep 27 01:48:19 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 15604E28275 for ; Wed, 27 Sep 2017 01:48:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03F4C83AFA for ; Wed, 27 Sep 2017 01:48:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v8R1mHV1080378 for ; Wed, 27 Sep 2017 01:48:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 220078] [patch] [panic] [ipfw] repeatable kernel panic due to unlocked INADDR_TO_IFP usage Date: Wed, 27 Sep 2017 01:48:15 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 27 Sep 2017 01:48:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220078 --- Comment #20 from commit-hook@freebsd.org --- A commit references this bug: Author: ae Date: Wed Sep 27 01:47:54 UTC 2017 New revision: 324047 URL: https://svnweb.freebsd.org/changeset/base/324047 Log: MFC r323839: Use in_localip() function instead of unlocked access to addresses hash to determine that an address is our local. PR: 220078 Changes: _U stable/11/ stable/11/sys/netpfil/ipfw/ip_fw2.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ipfw@freebsd.org Wed Sep 27 04:36:45 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 51078E2A83D for ; Wed, 27 Sep 2017 04:36:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F077325A for ; Wed, 27 Sep 2017 04:36:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v8R4aivH040440 for ; Wed, 27 Sep 2017 04:36:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 220078] [patch] [panic] [ipfw] repeatable kernel panic due to unlocked INADDR_TO_IFP usage Date: Wed, 27 Sep 2017 04:36:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@freebsd.org X-Bugzilla-Flags: mfc-stable11+ X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 27 Sep 2017 04:36:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220078 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |mfc-stable11+ --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ipfw@freebsd.org Wed Sep 27 11:17:01 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 CC1EEE3150C; Wed, 27 Sep 2017 11:17:01 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 468EF6E016; Wed, 27 Sep 2017 11:17:00 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lubnw-1dF8Ls1J6e-00znZD; Wed, 27 Sep 2017 13:16:52 +0200 Date: Wed, 27 Sep 2017 13:16:51 +0200 From: "O. Hartmann" To: Damjan Jovanovic Cc: "O. Hartmann" , freebsd-current , freebsd-ipfw@freebsd.org, Guido Falsi Subject: Re: FreeBSD, IPFW and the SIP/VoIP NAT problem Message-ID: <20170927131651.7346fd1f@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <20170926103543.0aa03c7a@freyja.zeit4.iv.bundesimmobilien.de> <20170926154429.1c79d842@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:v3LzEPxmjXu2Ko9PCPGhR5SGOjVlzUFsXAypXZR7D7o8XVP4P8v FmuocXk4qW/qY9gSNavsPW+3O2NFr30d1HG9XX9JpNFJaQ6ns7DKWwGZQ7PCZSfzZwQPuQw HH4dcOQDdv/gtu+tOnAX4ujK3gaVlj5GgHAMKTzFsEKsDzjGubaqbzZ+jTUsxkMpxMcl4co z8aBVoo3ZwlqO2TfkM41w== X-UI-Out-Filterresults: notjunk:1;V01:K0:FeUxNHqNc70=:U3IkZfj5WUxukGcpcLaiEY RoTGSeMyYh9Jp/Zf5WXB8W4daoIIcZYjNH+98cAvRw91spOOIrCuuU2bdyU/Elw/wUzLPLcVl ZzL0bbQlfFROFoz1DvF7JUyFKxpPfKs0cp9P3ltr77cEz6ESXHLyuNga+zJSVGZ3W/ktb+Uqv tnZ9BXXf8FyH+fPKUw6eVq9RDo8zHdXwrHxMMvf+dX/7+Y1o263j3L9Kcs+aEiMsjyOKeOFqH F4r06VuULHucyhL/4UjYHa/ljjxU73WApWkEansmLy7Kk9v0UWL6c1HgbbQ7+VC0NFMFrVwXe J+LKMLzbHMVDyOv7txGg9RUkZmSyYxQ5zn3Malzt92dnb3dkhJ0jB7n4kNmvZqRFONbrm1e7K CWhqdz4O8SsGCtjp3dYhjwcFlYXjp0atew4N258rBdKfLUnz8qKdYFfmFCwCRecxCvvoQaqOM ODz1YF4tpEDLiyGtBQwn7+UC0spb8wWKXQxC7rJq/+DuGf/DmHF97tbIzUBJiRUXw5BANyCmH EIeazHWZYY7Kpc8VMhDxYsMMqDvi+Ueaqe0g4+MHG7RD/UtSwwh/O/PoNdbpIP4MltvS1ZSDH SA8XivzlMaumMbqQh0N85/WEXgebj2S/+2hApv9w3gwejRPvNLWwNvqLrKuJvXIVM/u1QEbQF qQKemeEF7t9Dt4c1wKc1NhfU70aB7SGGLYlgGUVHUvC/s4vZvuQcODSrSnAFr3e95wSETFaLb PnIlklShd+UKee59C0RW+f3dbXpE5a5Pv2oP/1dUnOd3mupb6XP3rAMXyQY7GoTCGA6kXKMXq uSQJB8bVq87qNhYByV3NkEp8rpYIzIeeSan43eqFjUP76UFwJg= 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: Wed, 27 Sep 2017 11:17:01 -0000 On Tue, 26 Sep 2017 16:26:51 +0200 Damjan Jovanovic wrote: > On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann > wrote: > > > 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 ... > > > > > Firstly, if your providers support NAT, you register to them (as opposed to > they register to you, or no registration), and the only VoIP calls are > to/from your providers and to/from the same IP:port you register to (as > opposed to unknown external addresses), then none of this should be > necessary. Just put these on every SIP peer in Asterisk (this is for > chan_sip; not sure about chan_pjsip): My providers do support NAT, I suppose, I'm sure with one. Not so sure about the iberian Telefonica/O2 - they claim, but they are a kind of not willing to provide substantial informations as they want to force customers to use the (crap) equipment they offer. Very often, calling from the outside through the NAT/firewall to the PBX, I have this half-duplex phenomenon well described in many palces regarding NAT. In most cases I can hear the answering machine/voicemail from the PBX, but I can not send an audio stream inside. When my PBX register to its provider, how is the RTP port port for the ingress media stream (from the view of my PBX) opened? As I understand stateful IPFW, someone from the inside needs first to punchhole the firewall. I must confess, I have a bit of an understanding problem here since I do know know the protocol. Is there anything on the net explaining this scenario? RFC3261 is describing SIP, but not the registration ... > > directmedia=no > nat=force_rport,comedia In chan_pjsip, I found these settings important for NAT on peers in avrious places on the net: rtp_symmetric= yes ;rtp_keepalive= 30 (not sure about ; the timing here, I use this value) force_rport= yes rewrite_contact= yes timers= yes direct_media= no disable_direct_media_on_nat= yes > > and register to your provider more often than your NAT timeout is (eg. > every minute), and you should be good. Why? Every registration opens a NAT > mapping that your provider can use to send you calls on. The provider will > also send RTP to the source IP:port it received it from, so when you start > sending RTP you will get RTP back even if it's arriving from an unexpected > IP:port. NAT is not a big problem for SIP clients, only for SIP providers > that have receive packets from unknown addresses. I tried to find lifetime settings or timeout, the only (documented) values I founf were located in ipfw(8): net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_short_lifetime: 5 > > Otherwise... > > Why would your providers need to support STUN? Applications first use STUN > to discover the external IP:port of their internal IP:port, and then > communicate that IP:port to the other side however they usually would (eg. > headers in SIP and SDP packets) - the other side doesn't know or care that > they were discovered through STUN. Any STUN server anywhere on the Internet > can be used for this and should give the same results; see > https://www.voip-info.org/wiki/view/STUN for a list. I can use the STUN of an other provider, but not sure this is necessary, since both providers I'm consumer do not offer STUN themselfes. > > My patch ensures UDP NAT hole punching logic can be used properly. With it, > if a packet was sent from an internal IP:port through an external IP:port > (eg. to a STUN server), then any future packet from that internal IP:port > to any other external server:port will go out the same external IP:port, > and no other internal IP:port will use that external IP:port. It's like the > internal IP:port temporarily owns the unique external IP:port and can send > and receive through it to and from anywhere. The same source IP:port will > be seen by all servers, and they can send back to it. That sounds plausible, but implies that, say the PBX behind the NAT at IP1:port, is not guaranteed to send exclusively via external IP2:port? From owner-freebsd-ipfw@freebsd.org Wed Sep 27 12:13:22 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 777F5E01ED1; Wed, 27 Sep 2017 12:13:22 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B9B7700F9; Wed, 27 Sep 2017 12:13:22 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: by mail-wr0-x22f.google.com with SMTP id h16so1841339wrf.6; Wed, 27 Sep 2017 05:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3nnVqT89k7JX7Jg7I5DZqTWoXTq+ldKiYFcWxZX7Kmg=; b=l0Cpie+iCo1BHTo+DbrPNJtAundH6npz3KLoJKPL/547EuxQD7VS1MQBYLAscnxdmp elQM76JNmq1VZ5QXMKigUF2Ocf0XSga8XdMSkPrCpD84RqSpWzsqxEfgDDlk8kC6nPeX 5wrkShZydoccC0BlrBKNhgNFzfK4jGA2XUVqHn7b1QBm1JMfNZk5UB6tBqLnOhuVJcQb q5FTQ3qKyjY/dcWWrbBk+fZ7wM1W3/X0xRhpjr+9iGWkjlIs4zt1AyiHteOboKzC0t+v 9NULyxbWyCbuOQuzFvxZNSA3kMqkUsrq0ajToBumNi8//MpXUcSfmeN89dc2kFqU3cL4 zKvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3nnVqT89k7JX7Jg7I5DZqTWoXTq+ldKiYFcWxZX7Kmg=; b=X3adIxRHQj+mApdHdPb9f2feuK0zC947dJGhVRhiZmP/9qByqfbn1t+ae6I9gGS/GJ Lrbq2HKYHlLl28A4NAOGkWPkKGPCME3SC1bq6sQGgn+ylhUcZctPZeKSEJrJnNp0gGcv QBPARbjDzR4DxUn1QMKetWqAyY4//SwTSvYduqrcFVrPQsAz9JAj1jb/d6slEbVjFpvA OqiSAFpku6L3JPST4EcmAZ8ZwL8ERXg4EXkcFpF+uluGFgmdmKEpzftdhcZrTHbIu/NC utOLCgj09yTKqgzhbP94Md+8TnO7os9MlsgVkTz7ra7c94tF7M7wPZEItb70tCw9uPeA x8Vg== X-Gm-Message-State: AMCzsaVUXT+/clfCKsW1O1Qu12OvCSXQNySGWDVgeilBDaKnwkmvEpG6 ZQdZpYO8IontU0pdagIQliO+yVCkr5YdvuyIHEu3lw== X-Google-Smtp-Source: AOwi7QAxp7AAYLVu7SYZia2NRNRgM4Ofivlm+6c5T1GzC6P+a9ajqpAX4A3eB0r6Vt2zrQoc3VTYTjQ/PO8z2cCwe2E= X-Received: by 10.25.24.231 with SMTP id 100mr467357lfy.241.1506514399417; Wed, 27 Sep 2017 05:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.89.13 with HTTP; Wed, 27 Sep 2017 05:12:58 -0700 (PDT) In-Reply-To: References: <20170926103543.0aa03c7a@freyja.zeit4.iv.bundesimmobilien.de> From: Damjan Jovanovic Date: Wed, 27 Sep 2017 14:12:58 +0200 Message-ID: Subject: Re: FreeBSD, IPFW and the SIP/VoIP NAT problem To: Guido Falsi Cc: "O. Hartmann" , freebsd-current , freebsd-ipfw@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Wed, 27 Sep 2017 12:13:22 -0000 On Tue, Sep 26, 2017 at 11:27 AM, Guido Falsi wrote: > On 09/26/2017 10:35, O. Hartmann wrote: > > > 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 > > This would require coding it in IPFW, and the load on the firewall could > be significant. > > It could be done in userland maybe, leveraging divert(4) and having a > daemon listening there and doing the extra work, but this would be quite > expensive. Depending on your call volume the load could be too much for > your firewall. > > SIP headers like Proxy-Authorization need to send a cryptographic quality hash of data that includes the password and the SDP when qop=auth-int, and the ALG needs to change the IP address and port in the SDP, which changes this hash. The ALG would have to know your password to calculate the new hash. A SIP ALG can thus only work with the weaker qop=auth protection, which doesn't hash the SDP and is thus less secure (MITM attacks can capture/modify RTP in transit), and even then it would have to be careful not to change the SIP headers which are included in the hash. Since it is the provider that chooses the allowed qop, a general SIP ALG is impossible unless the ALG knows the password. Linux has a SIP ALG in iptables, and it's full of problems and best disabled. From owner-freebsd-ipfw@freebsd.org Wed Sep 27 12:17:37 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 847D6E020C3; Wed, 27 Sep 2017 12:17:37 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 031CB7030B; Wed, 27 Sep 2017 12:17:37 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: by mail-wr0-x229.google.com with SMTP id l39so16097737wrl.12; Wed, 27 Sep 2017 05:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QRoM+U6TjlWHC/2oeXvRicioSbJ/ypD1ZpoHVzLt/fE=; b=Ekv44o+pXOS/vcS0CH0Ji9nzS6qrCz8kIDN4vIfNm8mPV+7+BC1FesgvtSF1aK0R2E XaO3WQaT3Ol5SlpOm7Hz3kKSYSle392bAk+FYMwL24+jKuG5vn40/pWaex+yB9/Xz+Xf wknxe7ZauW2jMHr+4vAKcJ0g8IhoYz/099zzIkMWI3q6BO4HybxiFt3NzADvGotmvCvn qsBdsIIWdf9UCegiGHQDtif/jUjI0hsFCuMYryXi4d/1sXrsAoIYb7gWOLkIA/bDi9kh r1iXWcG/quDvj//dQZxZj1T5rOMDbZLKN5Mki60nuWWxo5Bi3GsGbVaOBTRFCSXuSkzY +Lyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QRoM+U6TjlWHC/2oeXvRicioSbJ/ypD1ZpoHVzLt/fE=; b=dt/Xzy8pxi88y1aIKRrGQJJswIM060g5Jy+yKQJd0A7gCc9ekF1ad5jE8r7WCPMb02 jb7caynP8DQ4a5uHD9LWOk6z4qrGIXAlfrjpom4vPVa60j0J9A9+wZ6g6W3FArSGu2wC Vp2guwVoUoYbi2bHzNHyviuvdnvISG1YSFiVjI+nzMVikBGKKaWnvBmKbLVMDunW7nDc Lcsdd9yp03ppbcFH3/Clvy0Qjr7Z18B5GoXZUs6x5lCkg35OKBiu3ztUT6/VpPukdeuo fD4KKGEBUbNZx6VpqhNVbb0Xdz+Bov/e14omX4emWODgo51I7oxaImF+3zwyABNzXFik N6QQ== X-Gm-Message-State: AMCzsaVHByrOVMssai2uPlrZ4lacGAx/yDbXcZJg/euR6n8iliaCu1ii puCXe/1II5d1YJ+nJYUttYpjBo58ZiJTg7UehoY= X-Google-Smtp-Source: AOwi7QDIjOt1koTdQTbK5sWZxl3XzSd3+LjY4RyVHao8k00OdL15Par7UjYBqA/Jti463PTv0QkbN1TtUOMuHGI0JoQ= X-Received: by 10.25.19.95 with SMTP id j92mr483866lfi.138.1506514655196; Wed, 27 Sep 2017 05:17:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.89.13 with HTTP; Wed, 27 Sep 2017 05:17:14 -0700 (PDT) In-Reply-To: <20170927131651.7346fd1f@freyja.zeit4.iv.bundesimmobilien.de> References: <20170926103543.0aa03c7a@freyja.zeit4.iv.bundesimmobilien.de> <20170926154429.1c79d842@freyja.zeit4.iv.bundesimmobilien.de> <20170927131651.7346fd1f@freyja.zeit4.iv.bundesimmobilien.de> From: Damjan Jovanovic Date: Wed, 27 Sep 2017 14:17:14 +0200 Message-ID: Subject: Re: FreeBSD, IPFW and the SIP/VoIP NAT problem To: "O. Hartmann" Cc: "O. Hartmann" , freebsd-current , freebsd-ipfw@freebsd.org, Guido Falsi Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Wed, 27 Sep 2017 12:17:37 -0000 On Wed, Sep 27, 2017 at 1:16 PM, O. Hartmann wrote: > On Tue, 26 Sep 2017 16:26:51 +0200 > Damjan Jovanovic wrote: > > > On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann > > wrote: > > > > > On Tue, 26 Sep 2017 11:00:45 +0200 > > > Damjan Jovanovic wrote: > > > > > > > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann < > ohartmann@walstatt.org> > > > > 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 ... > > > > > > > > Firstly, if your providers support NAT, you register to them (as opposed > to > > they register to you, or no registration), and the only VoIP calls are > > to/from your providers and to/from the same IP:port you register to (as > > opposed to unknown external addresses), then none of this should be > > necessary. Just put these on every SIP peer in Asterisk (this is for > > chan_sip; not sure about chan_pjsip): > > > > My providers do support NAT, I suppose, I'm sure with one. Not so > sure about the iberian Telefonica/O2 - they claim, but they are a kind of > not > willing to provide substantial informations as they want to force > customers to > use the (crap) equipment they offer. > > Very often, calling from the outside through the NAT/firewall to the PBX, I > have this half-duplex phenomenon well described in many palces regarding > NAT. > In most cases I can hear the answering machine/voicemail from the PBX, but > I > can not send an audio stream inside. > > When my PBX register to its provider, how is the RTP port port for the > ingress > media stream (from the view of my PBX) opened? As I understand stateful > IPFW, > someone from the inside needs first to punchhole the firewall. I must > confess, > I have a bit of an understanding problem here since I do know know the > protocol. Is there anything on the net explaining this scenario? RFC3261 is > describing SIP, but not the registration ... > > Both sides usually send RTP to each other. When you send RTP through your NAT to a provider supporting NAT, it should see where you are externally sending from, and send its future RTP packets back there, even if that isn't the (internal) IP:port you previously said you would use in your SDP. This can obviously break in some cases: - If the voice is intentionally one-way throughout the call, such as phoning out into an announcement service that intentionally says "sendonly" in its SDP, so you aren't sending any RTP to it and its RTP can't route back to you. - If you use out of band ringback and transfer out an inbound call before it's answered, so the call hairpins from the provider through you and back. You have to send RTP to open NAT mappings, but you have nothing to send, as you first need to receive it, but can't as the NAT mappings aren't open: a cycle you can't exit. For those cases, NAT traversal can't be transparent, you have use some kind of software negotiated NAT traversal: static port forwarding and set Asterisk's external signaling and media addresses, use STUN with cone NAT (my patch + STUN/ICE settings in Asterisk's rtp.conf, sip.conf, etc.), or a NAT traversal protocol such as UPNP or NAT-PMP with supporting software (which Asterisk currently isn't). > > > > directmedia=no > > nat=force_rport,comedia > > In chan_pjsip, I found these settings important for NAT on peers in > avrious > places on the net: > > rtp_symmetric= yes > ;rtp_keepalive= 30 (not sure about > ; the timing here, I use this > value) > force_rport= yes > rewrite_contact= yes > timers= yes > direct_media= no > disable_direct_media_on_nat= yes > > > > > and register to your provider more often than your NAT timeout is (eg. > > every minute), and you should be good. Why? Every registration opens a > NAT > > mapping that your provider can use to send you calls on. The provider > will > > also send RTP to the source IP:port it received it from, so when you > start > > sending RTP you will get RTP back even if it's arriving from an > unexpected > > IP:port. NAT is not a big problem for SIP clients, only for SIP providers > > that have receive packets from unknown addresses. > > I tried to find lifetime settings or timeout, the only (documented) values > I > founf were located in ipfw(8): > > net.inet.ip.fw.dyn_ack_lifetime: 300 > > net.inet.ip.fw.dyn_syn_lifetime: 20 > > net.inet.ip.fw.dyn_fin_lifetime: 1 > > net.inet.ip.fw.dyn_rst_lifetime: 1 > > net.inet.ip.fw.dyn_udp_lifetime: 10 > > net.inet.ip.fw.dyn_short_lifetime: 5 > > > > Otherwise... > > > > Why would your providers need to support STUN? Applications first use > STUN > > to discover the external IP:port of their internal IP:port, and then > > communicate that IP:port to the other side however they usually would > (eg. > > headers in SIP and SDP packets) - the other side doesn't know or care > that > > they were discovered through STUN. Any STUN server anywhere on the > Internet > > can be used for this and should give the same results; see > > https://www.voip-info.org/wiki/view/STUN for a list. > > I can use the STUN of an other provider, but not sure this is necessary, > since > both providers I'm consumer do not offer STUN themselfes. > > > > > My patch ensures UDP NAT hole punching logic can be used properly. With > it, > > if a packet was sent from an internal IP:port through an external IP:port > > (eg. to a STUN server), then any future packet from that internal IP:port > > to any other external server:port will go out the same external IP:port, > > and no other internal IP:port will use that external IP:port. It's like > the > > internal IP:port temporarily owns the unique external IP:port and can > send > > and receive through it to and from anywhere. The same source IP:port will > > be seen by all servers, and they can send back to it. > > > That sounds plausible, but implies that, say the PBX behind the NAT at > IP1:port, is not guaranteed to send exclusively via external IP2:port? > > With my patch, every packet from IP1:port1 will be routed out of IP2:port2, no matter what the destination. Of course software must be written to detect IP2:port2 for every new socket using something like STUN, and report IP2:port2 to other parties it wants traffic from. From owner-freebsd-ipfw@freebsd.org Thu Sep 28 20:26:50 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 D43B9E08630; Thu, 28 Sep 2017 20:26:50 +0000 (UTC) (envelope-from ohartmann@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 413356CFAD; Thu, 28 Sep 2017 20:26:49 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.181.38.24]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LnPGI-1dQEWX07AM-00hfFk; Thu, 28 Sep 2017 22:26:47 +0200 Date: Thu, 28 Sep 2017 22:26:38 +0200 From: "O. Hartmann" To: Damjan Jovanovic Cc: "O. Hartmann" , freebsd-current , freebsd-ipfw@freebsd.org, Guido Falsi Subject: Re: FreeBSD, IPFW and the SIP/VoIP NAT problem Message-ID: <20170928222638.49e3f476@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20170926103543.0aa03c7a@freyja.zeit4.iv.bundesimmobilien.de> <20170926154429.1c79d842@freyja.zeit4.iv.bundesimmobilien.de> <20170927131651.7346fd1f@freyja.zeit4.iv.bundesimmobilien.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/.Z7l44Ng0_rTXip7PmIAyIk"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:Ud9Lcs6u92rJ4+EVEUEUdjsV41pO3JhEBP3eAONvMMo89xLJ/oE HbsAfAJB3hmlM0RyWhoa+NxN5Q8zoGAz4kgF5uKL1c/YSaqDoQwF3NtkKCZIL4578CtfDik Y0RO0o54u5hYomfzQYqiiGKjKxLy8Hwh1m0o6rygGGrUVDuvBGKFecl62oEtYCgwT+3OjV7 VQaxobDaGkdcqwrmPRrLw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Q3WIA9/2aeI=:oTEv46EO8vBmxo7TwFbQC8 VIQcZ8tM9SHNBbgixWHy37HqJvv1tb1SNny9BAVR/qzz8/TgDTBuayY9405VVy7s+CAzy0llo nH/6NXYguxDODDC7+jovDl/vrbFswgaPdiH1ScNVtB+VbvAsVz8kFGIBkzVqyUiW0lY2a/k5W yu3IZbXqg6ZcYhmhqPTB17kQ/c5oaMT7g5kQSooIsVEN773lobLv+Rf5b3/penCfdeAMbNjf+ Hxd6Ax/Ku+GI+rOIXNq2UX1KnL5AoaB0rJT53namX5sLRDcbf1jEp4wOBfG525FAn/nxlXN5f GTS3i5x/syD62Ooa/i7I+SQJ/48WP+9OKXBBNJGatiBA8jSfOSydiyX2KVLO7EY4OECOqrwGk kK1rnOFxJkX45yYX4ZZK9vAlIx3QQtcSKUN7G1aQkCMOf1DNUEcnyPfKDN7EgrmSQJNccm13q /oqyrEYDjvQM+MWG1XWkX0ewYgtx4ekBfK0DnayZv/9WbiO+z6Gr5hNmaatus+Sq67ZCrpE1h FZHcymmfAAaqNm1q9iD+1JOWbr8JN0TK0aObTn4x61NkbrBtwrD2FGobY/23I/Cl183JSupaN WYMneZyxDZL887yoK7qs4TYcCIvGUgR5ZOIF/HQNAzLH4kOfWmZwpD6aMqFlh8uyJzG1vOrvk nULJgmpSPfbZQSMkjcmw69nTki91UTRDC2V53tsVxdLEG483g/aXbJB8UVkfKDJh5nrdCNvFT jg2nnVkz7o75QlemQr6Z8qYPcLnwV4VJ9VDIgfTbgrbcaZ6U7h23Mdo653KPBBKPySbaNj3ax 5bPjBpwB877u/XveWSqNaexv/rsyQ== 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: Thu, 28 Sep 2017 20:26:51 -0000 --Sig_/.Z7l44Ng0_rTXip7PmIAyIk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Wed, 27 Sep 2017 14:17:14 +0200 Damjan Jovanovic schrieb: > On Wed, Sep 27, 2017 at 1:16 PM, O. Hartmann > wrote: >=20 > > On Tue, 26 Sep 2017 16:26:51 +0200 > > Damjan Jovanovic wrote: > > =20 > > > On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann > > > wrote: > > > =20 > > > > On Tue, 26 Sep 2017 11:00:45 +0200 > > > > Damjan Jovanovic wrote: > > > > =20 > > > > > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann < =20 > > ohartmann@walstatt.org> =20 > > > > > wrote: > > > > > =20 > > > > > > Hello, > > > > > > > > > > > > trying to build a FreeBSD based router/PBX (Asterisk 13) =20 > > appliance, I =20 > > > > ran =20 > > > > > > into > > > > > > several problems. My questions might have a "noobish" character= , =20 > > so my =20 > > > > > > 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 =20 > > aarch64 =20 > > > > about =20 > > > > > > coming soon also supported? > > > > > > - would a Pine64 running CURRENT (12) be sufficient as a PBX =20 > > platform =20 > > > > > > (assumed > > > > > > having 2 GB of RAM)? > > > > > > > > > > > > My main concern is about IPFW (we do not use PF for some reason= s, I =20 > > > > have to =20 > > > > > > stay with IPFW). > > > > > > > > > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT a= nd =20 > > not =20 > > > > yet =20 > > > > > > IPv6. > > > > > > The FreeBSD system acting as a router is supposed to have a jai= l =20 > > soon =20 > > > > > > containing the Asterisk 13 IP PBX (at the moment running on the= =20 > > main =20 > > > > > > system). > > > > > > To provide access to the VoIP infrastructure inside/behind the = =20 > > > > router/NAT =20 > > > > > > system, the in-kernel NAT facility of FreeBSD is forwarding the= =20 > > > > relevant =20 > > > > > > UPD/TCP ports for VoIP to its destination network, and here I h= ave =20 > > a =20 > > > > > > problem to > > > > > > solve. > > > > > > > > > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and o= ther =20 > > > > ports, =20 > > > > > > it > > > > > > is a mess and pain in the arse to forward a whole range, say =20 > > 11000/udp =20 > > > > - =20 > > > > > > 35000/udp, which is a range one of my providers is sending RTP = on. =20 > > A =20 > > > > second =20 > > > > > > provider uses another range for RTP, starting at 5000/udp. So, = the =20 > > > > logical =20 > > > > > > consequence would be a union set up UDP range to forward, which= =20 > > exapnds =20 > > > > > > 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 =20 > > the =20 > > > > > > stateful > > > > > > firewall the RTP session very often is half duplex - it seems o= ne =20 > > > > direction =20 > > > > > > of the RTP connection doesn't make it through IPFW/NAT. As ofte= n I =20 > > > > search =20 > > > > > > the > > > > > > net, I always get informed this is a typical problem and soluti= ons =20 > > are =20 > > > > > > provided by so called ALGs - since SIP protocol's SDP indicates= =20 > > within =20 > > > > the =20 > > > > > > payload of the packets on which UDP ports both ends wish to =20 > > establish =20 > > > > their =20 > > > > > > RTP session, it would be "easy" to pinhole the IPFW on exactly = =20 > > those =20 > > > > ports =20 > > > > > > for > > > > > > a theoretical large number of sessions, if IPFW could "divert" = =20 > > those =20 > > > > > > 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 the= n =20 > > > > pinholing =20 > > > > > > the > > > > > > NAT/IPFW for exactly this purpose without the forwarding mess. = I =20 > > came =20 > > > > along =20 > > > > > > netgraph() while searching for hints and hooks, but it seems a = =20 > > complete =20 > > > > > > Linux > > > > > > domain, when it somes to appliances like VoIP/IP PBX. > > > > > > > > > > > > Either, the problem is that trivial on FreeBSD, so no further = =20 > > > > mentioning is =20 > > > > > > necessary (which would explain the vast emptyness of explanatio= ns, =20 > > > > hints =20 > > > > > > and > > > > > > so on) or FreeBSD is a complete wasteland on this subject - whi= ch I =20 > > > > also =20 > > > > > > suspect, since pfSense and OPNsense must have come along with s= uch =20 > > > > problems =20 > > > > > > and I simply do not know or recognise the software used for tho= se =20 > > > > purposes. =20 > > > > > > > > > > > > So, if someone enlightened in this matter stumbles over my =20 > > question and =20 > > > > > > could > > > > > > delegate me onto the right way (ports, ng_XXX netgraph ficiliti= es =20 > > to =20 > > > > look =20 > > > > > > at, > > > > > > some ipfw techniques relevant to the problem apart from the stu= pid =20 > > > > simple =20 > > > > > > forwarding large ranges of ports) - I'd appreciate this and > > > > > > > > > > > > thanks in advance for patience and help, > > > > > > > > > > > > Oliver > > > > > > =20 > > > > > > > > > > > > > > > Hi > > > > > > > > > > It might be easier if you just enable STUN on Asterisk, and build= =20 > > FreeBSD =20 > > > > > from source with my [largely neglected :( ] patch on > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219918 > > > > > > > > > > That way Asterisk should dynamically discover consistent external= =20 > > > > mappings =20 > > > > > for connections, making port forwarding RTP unnecessary. > > > > > > > > > > Damjan =20 > > > > > > > > STUN is enabled, but my providers do not support STUN. > > > > > > > > I try to figure out how SIP works exactly to make my problem more = =20 > > precise. =20 > > > > I > > > > also try to understand the aim of your patch - as far as I know, it= =20 > > does =20 > > > > exactly as it is needed for the IPW/NAT/VoIP case. And I really reg= ret =20 > > that =20 > > > > there are objections to commit the patch ... > > > > > > > > =20 > > > Firstly, if your providers support NAT, you register to them (as oppo= sed =20 > > to =20 > > > they register to you, or no registration), and the only VoIP calls are > > > to/from your providers and to/from the same IP:port you register to (= as > > > opposed to unknown external addresses), then none of this should be > > > necessary. Just put these on every SIP peer in Asterisk (this is for > > > chan_sip; not sure about chan_pjsip): =20 > > > > > > > > My providers do support NAT, I suppose, I'm sure with one. Not so > > sure about the iberian Telefonica/O2 - they claim, but they are a kind = of > > not > > willing to provide substantial informations as they want to force > > customers to > > use the (crap) equipment they offer. > > > > Very often, calling from the outside through the NAT/firewall to the PB= X, I > > have this half-duplex phenomenon well described in many palces regarding > > NAT. > > In most cases I can hear the answering machine/voicemail from the PBX, = but > > I > > can not send an audio stream inside. > > > > When my PBX register to its provider, how is the RTP port port for the > > ingress > > media stream (from the view of my PBX) opened? As I understand stateful > > IPFW, > > someone from the inside needs first to punchhole the firewall. I must > > confess, > > I have a bit of an understanding problem here since I do know know the > > protocol. Is there anything on the net explaining this scenario? RFC326= 1 is > > describing SIP, but not the registration ... > > > > =20 > Both sides usually send RTP to each other. When you send RTP through your > NAT to a provider supporting NAT, it should see where you are externally > sending from, and send its future RTP packets back there, even if that > isn't the (internal) IP:port you previously said you would use in your SD= P. >=20 > This can obviously break in some cases: > - If the voice is intentionally one-way throughout the call, such as > phoning out into an announcement service that intentionally says "sendonl= y" > in its SDP, so you aren't sending any RTP to it and its RTP can't route > back to you. > - If you use out of band ringback and transfer out an inbound call before > it's answered, so the call hairpins from the provider through you and bac= k. > You have to send RTP to open NAT mappings, but you have nothing to send, = as > you first need to receive it, but can't as the NAT mappings aren't open: a > cycle you can't exit. >=20 > For those cases, NAT traversal can't be transparent, you have use some ki= nd > of software negotiated NAT traversal: static port forwarding and set > Asterisk's external signaling and media addresses, use STUN with cone NAT > (my patch + STUN/ICE settings in Asterisk's rtp.conf, sip.conf, etc.), or= a > NAT traversal protocol such as UPNP or NAT-PMP with supporting software > (which Asterisk currently isn't). >=20 >=20 > > > > > > directmedia=3Dno > > > nat=3Dforce_rport,comedia =20 > > > > In chan_pjsip, I found these settings important for NAT on peers in > > avrious > > places on the net: > > > > rtp_symmetric=3D yes > > ;rtp_keepalive=3D 30 (not sure about > > ; the timing here, I use this > > value) > > force_rport=3D yes > > rewrite_contact=3D yes > > timers=3D yes > > direct_media=3D no > > disable_direct_media_on_nat=3D yes > > =20 > > > > > > and register to your provider more often than your NAT timeout is (eg. > > > every minute), and you should be good. Why? Every registration opens = a =20 > > NAT =20 > > > mapping that your provider can use to send you calls on. The provider= =20 > > will =20 > > > also send RTP to the source IP:port it received it from, so when you = =20 > > start =20 > > > sending RTP you will get RTP back even if it's arriving from an =20 > > unexpected =20 > > > IP:port. NAT is not a big problem for SIP clients, only for SIP provi= ders > > > that have receive packets from unknown addresses. =20 > > > > I tried to find lifetime settings or timeout, the only (documented) val= ues > > I > > founf were located in ipfw(8): > > > > net.inet.ip.fw.dyn_ack_lifetime: 300 > > > > net.inet.ip.fw.dyn_syn_lifetime: 20 > > > > net.inet.ip.fw.dyn_fin_lifetime: 1 > > > > net.inet.ip.fw.dyn_rst_lifetime: 1 > > > > net.inet.ip.fw.dyn_udp_lifetime: 10 > > > > net.inet.ip.fw.dyn_short_lifetime: 5 =20 > > > > > > Otherwise... > > > > > > Why would your providers need to support STUN? Applications first use= =20 > > STUN =20 > > > to discover the external IP:port of their internal IP:port, and then > > > communicate that IP:port to the other side however they usually would= =20 > > (eg. =20 > > > headers in SIP and SDP packets) - the other side doesn't know or care= =20 > > that =20 > > > they were discovered through STUN. Any STUN server anywhere on the =20 > > Internet =20 > > > can be used for this and should give the same results; see > > > https://www.voip-info.org/wiki/view/STUN for a list. =20 > > > > I can use the STUN of an other provider, but not sure this is necessary, > > since > > both providers I'm consumer do not offer STUN themselfes. > > =20 > > > > > > My patch ensures UDP NAT hole punching logic can be used properly. Wi= th =20 > > it, =20 > > > if a packet was sent from an internal IP:port through an external IP:= port > > > (eg. to a STUN server), then any future packet from that internal IP:= port > > > to any other external server:port will go out the same external IP:po= rt, > > > and no other internal IP:port will use that external IP:port. It's li= ke =20 > > the =20 > > > internal IP:port temporarily owns the unique external IP:port and can= =20 > > send =20 > > > and receive through it to and from anywhere. The same source IP:port = will > > > be seen by all servers, and they can send back to it. =20 > > > > > > That sounds plausible, but implies that, say the PBX behind the NAT at > > IP1:port, is not guaranteed to send exclusively via external IP2:port? > > > > =20 > With my patch, every packet from IP1:port1 will be routed out of IP2:port= 2, > no matter what the destination. Of course software must be written to > detect IP2:port2 for every new socket using something like STUN, and repo= rt > IP2:port2 to other parties it wants traffic from. Stupid question here: is this patch some kind of similar to that what the Linux folks call "CONNT= RACK"? Whenever I read about SIP and NAT in conjunction with Linux, this "conntrac= k" module is always a kind of requisite. On a quick search, I found this page : https://voipmagazine.wordpress.com/2015/03/14/linux-nat-using-conntrack-and= -iptables/ and in some places I had the impression that your patch is exactly what "co= nntrack" is in the Linux world. --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/.Z7l44Ng0_rTXip7PmIAyIk Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWc1a/gAKCRDS528fyFhY lAI5Af0RcP/GO7dZfA3R267C6Gh4SbfuXrBrWZBsdrqi4y7LvPthCmpFKCNnAvNH 3n9aZAzMX39Z+kg5uSy7+PF5kxDmAf4kaQZz24fZy+DJM7Cx88AHUHs7+afbd8nB Aljxt+knzegKA4muKE4PGMyBofENRzTjm/92Z9XRirOqasu6Z3fw =1oUM -----END PGP SIGNATURE----- --Sig_/.Z7l44Ng0_rTXip7PmIAyIk--