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 _______________________________________________ firstname.lastname@example.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"