Re: FreeBSD, IPFW and the SIP/VoIP NAT problem

On Tue, 26 Sep 2017 11:00:45 +0200
Damjan Jovanovic <damjan.jov_at_gmail.com> wrote:

> On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann <ohartmann_at_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 ...