FreeBSD, IPFW and the SIP/VoIP NAT problem
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 ___ 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
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 ... ___ 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
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 on
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
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
ipfw: manpage: semantics of "receive" and "xmit" interfaces
I feel confused by the ipfw manpage, while trying to setup a set of filtering rules on a small router project with in-kernel NAT. It is a kind of hard based on the ipfw man page to figure out, what the meaning is of the receive and xmit interface. Maybe it is only me that has problems, but I doubt it, since I tried to ask around my department and it broke loose a discussion - based upon what one can read in the manpage - not reading source codes. In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is also an example: ipfw add deny ip from any to any out recv ed0 xmit ed1 Can someone explain a bit more what the semantics of these is? I get especially confused by the subsequent blocks of text following the line I mentioned above. Since not everybody using FreeBSD is capable of studying the kernel sources, I have difficulties to put those statements in line with a visualization of the packet flow. A local host receiving a packets destined for the local host can not have xmit interface? If I imagine, that the recv interface might be the interface adjacent directly to the in/out port depicted in section PACKET FLOW it doesn't give me any idea why there is no xmit interface. If it's my dumb brain missing things, I'm sorry. Otherwise I'd be glad to have some more informations and maybe the manpage could be enriched with some notes helping other poor people like me. Thanks in advance, Oliver ___ 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: ipfw: manpage: semantics of "receive" and "xmit" interfaces
On Tue, 9 Jan 2018 21:23:54 +0300 "Andrey V. Elsukov" wrote: > On 09.01.2018 12:28, O. Hartmann wrote: > > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is > > also an example: > > > > ipfw add deny ip from any to any out recv ed0 xmit ed1 > > > > Can someone explain a bit more what the semantics of these is? I get > > especially confused by the subsequent blocks of text following the line I > > mentioned above. Since not everybody using FreeBSD is capable of studying > > the kernel sources, I have difficulties to put those statements in line > > with a visualization of the packet flow. A local host receiving a packets > > destined for the local host can not have xmit interface? If I imagine, that > > the recv interface might be the interface adjacent directly to the in/out > > port depicted in section PACKET FLOW it doesn't give me any idea why there > > is no xmit interface. > > When your system has two interfaces ed0 and ed1, and it acts as router, > a forwarded packet can be checked by firewall two times: > > 1. When a packet is received on ed0 interface, mbuf associated with this > packet gets a property "receiving interface". This packet is checked for > inbound direction and can be matched by "in" and "recv ed0" opcodes. > If it was not dropped by rules, it will go through IP stack and can be > forwarded according to routing table via interface ed1. > > 2. When the routing decision was made (i.e. outbound interface is > determined) a packet checked by firewall again, now for outbound > direction. And it can be matched by "out" and "xmit ed1" opcodes. The > opcode "recv ed0" still can be matched too, but "in" opcode will not > matched. > > A packet destined for local host is consumed by local IP stack and will > not forwarded. It is checked by firewall only one time (usually). Thus > it can not have xmit interface. > Thanks very much for the explanation. ___ 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: ipfw -N show
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Tue, 11 Dec 2018 17:55:34 +0100 Claudio Eichenberger schrieb: > /usr/src/sbin/ipfw/ipfw2.c Isn't /usr/src/sbin/ and fellows supposed to install only via "make installworld"? - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXA/syAAKCRDS528fyFhY lKSVAgCioB3+iRWwNojTa7ivU7l6j9BzVvonbadj9dcYQaBrimX0ZZXSUM6LC6RU B0xhbUq723Mtb4xXbfAsY0Xg9UOuAf9RxKk9EEiwMmeq3Az580w0Jk3xzmDLG/uk QFbyhl1LShHvYImi04OerJjQcfg4cbeivYI0SdxuyjpRuNS9+Omq =6rZR -END PGP SIGNATURE- ___ 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"
IPFW: something similar to pfsync?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Is there something similar to pfsync(4) in pf(4) for FreeBSD's native ipfw(8) filter? - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXFimfgAKCRA4N1ZZPba5 R0NCAQCpQLWgjTvCDI7XLWWBC/xcZeg5MGPmVoeIJgweO9MFPwD9GeMUKZKwhDN1 tfcdJJZ7zEbcy3+JTiwW0grbp5ghego= =eFEh -END PGP SIGNATURE- ___ 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"
