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?