Date: Thu, 28 Sep 2017 22:26:38 +0200 From: "O. Hartmann" <ohartmann@walstatt.org> To: Damjan Jovanovic <damjan.jov@gmail.com> Cc: "O. Hartmann" <ohartmann@walstatt.org>, freebsd-current <freebsd-current@freebsd.org>, freebsd-ipfw@freebsd.org, Guido Falsi <madpilot@freebsd.org> Subject: Re: FreeBSD, IPFW and the SIP/VoIP NAT problem Message-ID: <20170928222638.49e3f476@thor.intern.walstatt.dynvpn.de> In-Reply-To: <CAJm2B-kr90UtMKxTK1sntUfPSKq7aZXOT-aQriKK2DbeumoHPA@mail.gmail.com> References: <20170926103543.0aa03c7a@freyja.zeit4.iv.bundesimmobilien.de> <CAJm2B-nLU5ZOCRjmbVzWJ-AoeUmF2kSfjfisif6V=CvNJye7Yg@mail.gmail.com> <20170926154429.1c79d842@freyja.zeit4.iv.bundesimmobilien.de> <CAJm2B-n4B8SaF_vAjKdWD0DTL7NhnuQL1kN4mvfvSMK1N%2B0v%2BQ@mail.gmail.com> <20170927131651.7346fd1f@freyja.zeit4.iv.bundesimmobilien.de> <CAJm2B-kr90UtMKxTK1sntUfPSKq7aZXOT-aQriKK2DbeumoHPA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <damjan.jov@gmail.com> schrieb: > On Wed, Sep 27, 2017 at 1:16 PM, O. Hartmann <o.hartmann@walstatt.org> > wrote: >=20 > > On Tue, 26 Sep 2017 16:26:51 +0200 > > Damjan Jovanovic <damjan.jov@gmail.com> wrote: > > =20 > > > On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann <o.hartmann@walstatt.org> > > > wrote: > > > =20 > > > > On Tue, 26 Sep 2017 11:00:45 +0200 > > > > Damjan Jovanovic <damjan.jov@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170928222638.49e3f476>