Am Wed, 27 Sep 2017 14:17:14 +0200
Damjan Jovanovic <damjan....@gmail.com> schrieb:

> On Wed, Sep 27, 2017 at 1:16 PM, O. Hartmann <o.hartm...@walstatt.org>
> wrote:
> 
> > On Tue, 26 Sep 2017 16:26:51 +0200
> > Damjan Jovanovic <damjan....@gmail.com> wrote:
> >  
> > > On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann <o.hartm...@walstatt.org>
> > > wrote:
> > >  
> > > > On Tue, 26 Sep 2017 11:00:45 +0200
> > > > Damjan Jovanovic <damjan....@gmail.com> wrote:
> > > >  
> > > > > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann <  
> > ohartm...@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.


Stupid question here:

is this patch some kind of similar to that what the Linux folks call 
"CONNTRACK"?

Whenever I read about SIP and NAT in conjunction with Linux, this "conntrack" 
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 
"conntrack" is in
the Linux world.

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).

Attachment: pgpF7aFpeYCqB.pgp
Description: OpenPGP digital signature

Reply via email to