Skip site navigation (1)Skip section navigation (2)
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+0v+Q@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: <http://docs.FreeBSD.org/cgi/mid.cgi?20170928222638.49e3f476>