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

[O. Hartmann]

Am Wed, 27 Sep 2017 14:17:14 +0200
Damjan Jovanovic  schrieb:

> On Wed, Sep 27, 2017 at 1:16 PM, O. Hartmann 
> wrote:
> 
> > On Tue, 26 Sep 2017 16:26:51 +0200
> > Damjan Jovanovic  wrote:
> >  
> > > On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann 
> > > wrote:
> > >  
> > > > On Tue, 26 Sep 2017 11:00:45 +0200
> > > > Damjan Jovanovic  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  
> > > > > > 

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

[Damjan Jovanovic]

On Wed, Sep 27, 2017 at 1:16 PM, O. Hartmann 
wrote:

> On Tue, 26 Sep 2017 16:26:51 +0200
> Damjan Jovanovic  wrote:
>
> > On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann 
> > wrote:
> >
> > > On Tue, 26 Sep 2017 11:00:45 +0200
> > > Damjan Jovanovic  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 

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

[Damjan Jovanovic]

On Tue, Sep 26, 2017 at 11:27 AM, Guido Falsi  wrote:

> On 09/26/2017 10:35, O. Hartmann wrote:
>
> > 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
>
> This would require coding it in IPFW, and the load on the firewall could
> be significant.
>
> It could be done in userland maybe, leveraging divert(4) and having a
> daemon listening there and doing the extra work, but this would be quite
> expensive. Depending on your call volume the load could be too much for
> your firewall.
>
>
SIP headers like Proxy-Authorization need to send a cryptographic quality
hash of data that includes the password and the SDP when qop=auth-int, and
the ALG needs to change the IP address and port in the SDP, which changes
this hash. The ALG would have to know your password to calculate the new
hash.

A SIP ALG can thus only work with the weaker qop=auth protection, which
doesn't hash the SDP and is thus less secure (MITM attacks can
capture/modify RTP in transit), and even then it would have to be careful
not to change the SIP headers which are included in the hash.

Since it is the provider that chooses the allowed qop, a general SIP ALG is
impossible unless the ALG knows the password.

Linux has a SIP ALG in iptables, and it's full of problems and best
disabled.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[O. Hartmann]

On Tue, 26 Sep 2017 16:26:51 +0200
Damjan Jovanovic  wrote:

> On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann 
> wrote:
> 
> > On Tue, 26 Sep 2017 11:00:45 +0200
> > Damjan Jovanovic  wrote:
> >  
> > > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann 
> > > 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 

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

[Graham Menhennitt]

On 26/09/2017 10:35 PM, O. Hartmann 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.

...



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.


Does your VoIP provider allow IAX2 protocol as well as SIP? Many do. 
Then you can avoid the problem completely.


Graham
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Damjan Jovanovic]

On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann 
wrote:

> On Tue, 26 Sep 2017 11:00:45 +0200
> Damjan Jovanovic  wrote:
>
> > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann 
> > 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