From: Fabian W. <fa...@we...> - 2012-11-18 17:21:25
|
Hello Antonio On 14.11.2012 07:16, Antonio Querubin wrote: >> On Sun, 11 Nov 2012, Fabian Wenk wrote: >>> I am not really sure regarding FreeBSD ipfw (bsd-ipfw action). >> >>> In newer FreeBSD versions (I think since around 6.x) the ipfw >>> command does support IPv4 and IPv6 addresses. In older versions >>> there was an ip6fw command available, but it was merged into >>> ipfw. I guess this will not be a problem, but there is probably >>> an other issue. >> >>> On my FreeBSD 7.4 system 'ipfw tables' does not support IPv6 >>> addresses. According to the thread "ipfw table support for ipv6" >>> [1] it should be available in 10.x and eventually in 9.x. But it >>> is not clear to me, if IPv4 and IPv6 addresses can be mixed in >>> the same table. I will setup a system for doing this tests, >>> unless somebody else can confirm if mixing is working or not. > > FreeBSD ipfw has supported merged IPv6 rules since around 7.0: > > http://www5.us.freebsd.org/releases/7.0R/relnotes.html#NET-PROTO This was already done in FreeBSD 6.0 ("The ipfw(4) and dummynet(4) systems now support IPv6.") [1], but back then ip6fw was also still available, which was then removed in 7.0. [1] http://www.ch.freebsd.org/releases/6.0R/relnotes-amd64.html#NET-PROTO > However, this may or may not apply to you but it's possible you may be > running into the problem of a broken socket API, specifically the > protocol-independent features. FreeBSD's default setting of > ipv6_ipv4mapping="NO" in /etc/defaults/rc.conf can trip you up if you're > setting up dual stack IPv6/IPv4 servers since it breaks the > protocol-independent feature of the socket API and in turn affects ipfw. > Ie. if you want and expect ipfw and other programs to behave in a > protocol-independent manner using mapped addresses internally, then you > need to set > > ipv6_ipv4mapping="YES" > > in /etc/rc.conf to return RFC compliance (with the socket API). I am using IPv4 / IPv6 dual stack systems since many years, dating back to the use with FreeBSD 4.11. Since then it was only one time when changing ipv6_ipv4mapping to YES would have been needed. But if I recall correctly, in the end it was not really need, but it is still set on that system. Regarding the IPFW tables, this does not change the fact, that tables only in recent FreeBSD 10-CURRENT (and eventually already backported to 9.x) do support IPv6. I did just test on my existing FreeBSD 7.4 systems, one with ipv6_ipv4mapping to YES and the other to NO: out of /etc/rc.d/network_ipv6: if checkyesno ipv6_ipv4mapping; then echo 'IPv4 mapped IPv6 address support=YES' ${SYSCTL_W} net.inet6.ip6.v6only=0 >/dev/null else echo 'IPv4 mapped IPv6 address support=NO' ${SYSCTL_W} net.inet6.ip6.v6only=1 >/dev/null fi Test on the system with ipv6_ipv4mapping="YES": root@batman:~ # sysctl net.inet6.ip6.v6only net.inet6.ip6.v6only: 0 root@batman:~ # ipfw table 23 add 2001:8a8:1005:1::23 ipfw: hostname ``2001:8a8:1005:1::23'' unknown root@batman:~ # And on the other with ipv6_ipv4mapping="NO": root@superman:~ # sysctl net.inet6.ip6.v6only net.inet6.ip6.v6only: 1 root@superman:~ # ipfw table 23 add 2001:8a8:1005:1::23 ipfw: hostname ``2001:8a8:1005:1::23'' unknown root@superman:~ # There were and are also other IPFW features which are missing or not properly working yet with IPv6 addresses, e.g. ipfw fwd rules [2] which I discovered and reported 5 years ago. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=117214 >>> I really would like to be able to continue to use fail2ban in >>> such a manner. Should I do the test with 'ipfw tables' and mixed >>> IPv4 and IPv6 addresses in the same table? Or would the above >>> described setup be possible with the addition of IPv6 to >>> fail2ban, or could this easily be added? > > I suspect fail2ban will need to support both types of behaviour depending > on the OS (ie. merged rules under BSD systems using ipfw vs. separate > protocol dependent rules under Linux using iptables/ip6tables). As far as I see it, with the proposed solution from Yaroslav this would also be possible. bye Fabian |