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).
pgpF7aFpeYCqB.pgp
Description: OpenPGP digital signature
