On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann <ohartm...@walstatt.org>

> 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


It might be easier if you just enable STUN on Asterisk, and build FreeBSD
from source with my [largely neglected :( ] patch on

That way Asterisk should dynamically discover consistent external mappings
for connections, making port forwarding RTP unnecessary.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to