Hello! There are some incongruities between the expected behavior (the IPv6 error packet response) of ip6tables firewall rules that are configured via the "-reject-with" option of the libip6t_REJECT.so module and the actual ICMPv6 packet types that are returned by netfilter upon matching this target. Below is the results of some reproducible experimentation on a stock CentOS 5.0 installation. Notice the "(WRONG)" cases. ############################################################################### # ip6tables -I INPUT 1 -i lo -p tcp --dport 22 -j REJECT --reject-with icmp6-no-route # ip6tables -nxvL INPUT | head -3 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT tcp lo * ::/0 ::/0 tcp dpt:22 reject-with icmp6-no-route # ssh -6 ::1 ssh: connect to host ::1 port 22: Network is unreachable # tcpdump -i lo -t -nn -s0 ip6 ### on separate xterm listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes IP6 ::1.42177 > ::1.22: S 3397247390:3397247390(0) win 32752 <mss 16376,sackOK,timestamp 3440778339 0,nop,wscale 7> IP6 ::1 > ::1: ICMP6, destination unreachable, unreachable route ::1, length 88 # Results/Conclusion: # Firewall config using ip6tables: icmp6-no-route # Actual packet sent by netfilter: icmp6-no-route (CORRECT) ############################################################################### # ip6tables -D INPUT 1 # ip6tables -I INPUT 1 -i lo -p tcp --dport 22 -j REJECT --reject-with icmp6-adm-prohibited # ip6tables -nxvL INPUT | head -3 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT tcp lo * ::/0 ::/0 tcp dpt:22 reject-with icmp6-adm-prohibited # ssh -6 ::1 ssh: connect to host ::1 port 22: Permission denied # tcpdump -i lo -t -nn -s0 ip6 ### on separate xterm listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes IP6 ::1.42178 > ::1.22: S 3576912899:3576912899(0) win 32752 <mss 16376,sackOK,timestamp 3440961112 0,nop,wscale 7> IP6 ::1 > ::1: ICMP6, destination unreachable, unreachable prohibited ::1, length 88 # Results/Conclusion: # Firewall config using ip6tables: icmp6-adm-prohibited # Actual packet sent by netfilter: icmp6-adm-prohibited (CORRECT) ############################################################################### # ip6tables -D INPUT 1 # ip6tables -I INPUT 1 -i lo -p tcp --dport 22 -j REJECT --reject-with icmp6-not-neighbor ip6tables v1.3.5: unknown reject type `icmp6-not-neighbor' Try `ip6tables -h' or 'ip6tables --help' for more information. # Results/Conclusion: # Firewall config using ip6tables: icmp6-not-neighbor (NOT IMPLEMENTED) # Actual packet sent by netfilter: (UNKNOWN) ############################################################################### # ip6tables -I INPUT 1 -i lo -p tcp --dport 22 -j REJECT --reject-with icmp6-addr-unreachable # ip6tables -nxvL INPUT | head -3 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT tcp lo * ::/0 ::/0 tcp dpt:22 reject-with icmp6-addr-unreachable # ssh -6 ::1 ssh: connect to host ::1 port 22: No route to host # tcpdump -i lo -t -nn -s0 ip6 ### on separate xterm listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes IP6 ::1.48925 > ::1.22: S 3832598225:3832598225(0) win 32752 <mss 16376,sackOK,timestamp 3441187480 0,nop,wscale 7> IP6 ::1 > ::1: ICMP6, destination unreachable, beyond scope ::1, source address ::1, length 88 # Results/Conclusion: # Firewall config using ip6tables: icmp6-addr-unreachable # Actual packet sent by netfilter: icmp6-not-neighbor (WRONG) ############################################################################### # ip6tables -D INPUT 1 # ip6tables -I INPUT 1 -i lo -p tcp --dport 22 -j REJECT --reject-with icmp6-port-unreachable # ip6tables -nxvL INPUT | head -3 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT tcp lo * ::/0 ::/0 tcp dpt:22 reject-with icmp6-port-unreachable # ssh -6 ::1 ssh: connect to host ::1 port 22: No route to host # tcpdump -i lo -t -nn -s0 ip6 ### on separate xterm listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes IP6 ::1.56801 > ::1.22: S 4127549216:4127549216(0) win 32752 <mss 16376,sackOK,timestamp 3441476533 0,nop,wscale 7> IP6 ::1 > ::1: ICMP6, destination unreachable, unreachable address ::1, length 88 # Results/Conclusion: # Firewall config using ip6tables: icmp6-port-unreachable # Actual packet sent by netfilter: icmp6-addr-unreachable (WRONG) ############################################################################### # ip6tables -D INPUT 1 # ip6tables -I INPUT 1 -i lo -p tcp --dport 22 -j REJECT --reject-with icmp6-echo-reply ip6tables v1.3.5: unknown reject type `icmp6-echo-reply' Try `ip6tables -h' or 'ip6tables --help' for more information. # ip6tables -I INPUT 1 -i lo -p tcp --dport 22 -j REJECT --reject-with icmp6-echoreply ip6tables v1.3.5: unknown reject type `icmp6-echoreply' Try `ip6tables -h' or 'ip6tables --help' for more information. # Results/Conclusion: # Firewall config using ip6tables: icmp6-echo-reply (NOT IMPLEMENTED) # Actual packet sent by netfilter: (UNKNOWN) ############################################################################### # ip6tables -I INPUT 1 -i lo -p tcp --dport 22 -j REJECT --reject-with tcp-reset # ip6tables -nxvL INPUT | head -3 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT tcp lo * ::/0 ::/0 tcp dpt:22 reject-with tcp-reset # ssh -6 ::1 ssh: connect to host ::1 port 22: Connection refused # tcpdump -i lo -t -nn -s0 ip6 ### on separate xterm listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes IP6 ::1.56371 > ::1.22: S 25897503:25897503(0) win 32752 <mss 16376,sackOK,timestamp 3441643437 0,nop,wscale 7> IP6 ::1 > ::1: ICMP6, destination unreachable, unreachable port, ::1 tcp port 22, length 88 # Results/Conclusion: # Firewall config using ip6tables: tcp-reset # Actual packet sent by netfilter: icmp6-port-unreachable (WRONG) ############################################################################### I traced this misbehavior to conflicting enumerations of constants in different header files from iptables vs the kernel: iptables-1.3.5/include/linux/netfilter_ipv6/ip6t_REJECT.h --------------------------------------------------------- 1:#ifndef _IP6T_REJECT_H 2: #define _IP6T_REJECT_H 3: 4: enum ip6t_reject_with { 5: IP6T_ICMP6_NO_ROUTE, 6: IP6T_ICMP6_ADM_PROHIBITED, 7: IP6T_ICMP6_ADDR_UNREACH, 8: IP6T_ICMP6_PORT_UNREACH, 9: IP6T_TCP_RESET 10: }; 11: 12: struct ip6t_reject_info { 13: enum ip6t_reject_with with; /* reject type */ 14: }; 15: 16: #endif /*_IP6T_REJECT_H*/ linux-2.6.18/include/linux/netfilter_ipv6/ip6t_REJECT.h ------------------------------------------------------- 1: #ifndef _IP6T_REJECT_H 2: #define _IP6T_REJECT_H 3: 4: enum ip6t_reject_with { 5: IP6T_ICMP6_NO_ROUTE, 6: IP6T_ICMP6_ADM_PROHIBITED, 7: IP6T_ICMP6_NOT_NEIGHBOUR, 8: IP6T_ICMP6_ADDR_UNREACH, 9: IP6T_ICMP6_PORT_UNREACH, 10: IP6T_ICMP6_ECHOREPLY, 11: IP6T_TCP_RESET 12: }; 13: 14: struct ip6t_reject_info { 15: u_int32_t with; /* reject type */ 16: }; 17: 18: #endif /*_IP6T_REJECT_H*/ I looked into why this problem does not manifest when using a custom iptables built from the tarball, even though these two header files are inconsistent in the upstream tarball, whereas the RHEL5 and CentOS 5 builds are affected. It turns out to be due to these instructions in the %build section of the iptables.spec file for building under rpmbuild: iptables.spec ------------- 79: %build 80: TOPDIR=`pwd` 81: OPT="$RPM_OPT_FLAGS -I$TOPDIR/include -fPIC" 82: make COPT_FLAGS="$OPT" KERNEL_DIR=/usr LIBDIR=/%{_lib} 83: make COPT_FLAGS="$OPT" KERNEL_DIR=/usr LIBDIR=/%{_lib} iptables-save iptables-restore 84: make COPT_FLAGS="$OPT" KERNEL_DIR=/usr LIBDIR=/%{_lib} ip6tables-save ip6tables-restore Instead of building iptables against the kernel source, as per the netfilter documentation, the setting KERNEL_DIR=/usr is used. This does allow the tests such as iptables-1.3.5/extensions/.REJECT-test6 for the conditional modules to pass against the system header files, but the search path -I/usr/include is ignored by gcc (as it is a standard system include dir). Then -I$TOPDIR/include is redundantly prepended to the search path. This makes the old iptables header file in the iptables package's own include directory take precedence over the netfilter header files. This is reversed from how the iptables build system does it, and the tests on the kernel headers can be obviated! Eg., the compilation line for the libip6t_REJECT module when building the Red Hat spec file under rpmbuild is cc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -I/home/luser/RPMBUILD/BUILD/iptables-1.3.5/include -fPIC -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\"1.3.5\" -fPIC -o extensions/libip6t_REJECT_sh.o -c extensions/libip6t_REJECT.c in contranst to custom build cc -O2 -Wall -Wunused -I/usr/src/kernels/2.6.18-8.1.6.el5-i686/include -Iinclude/ -DIPTABLES_VERSION=\"1.3.5\" -fPIC -o extensions/libip6t_REJECT_sh.o -c extensions/libip6t_REJECT.c I'm no expert, but IMHO iptables ought to be built against the kernel source. Please see the thoughtful comments regarding this by David Greenhouse here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191331#c8 In any case upstream needs to fix the header file in the iptables package. The attached patch merely updates the old ip6t_REJECT.h header file in the iptables package to the newer one from the kernel-headers package. I tested that it does indeed correct this bug. Best Regards!
Created attachment 161669 [details] Updates the old ip6t_REJECT.h header file in the iptables package to the newer one from the kernel-headers package.
This bug report is against iptables-ipv6-1.3.5-1.2.1 in RHEL5, but I noticed that the wrong ip6t_REJECT.h header file still appears in the upstream tarball for iptables-1.3.8. I tried to alert upstream by making a bug report at https://bugzilla.netfilter.org but their bugzilla appears to be down at the moment.
Netfilter bugzilla appears to be down for months, so I posted this on netfilter- devel list here: https://lists.netfilter.org/pipermail/netfilter-devel/2007-August/029077.html
Upstream has applied the above patch in svn.netfilter.org today. See here: https://lists.netfilter.org/pipermail/netfilter-devel/2007-August/029122.html http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/iptables/include/linux/ netfilter_ipv6/ip6t_REJECT.h?rev=7009&view=log I found that FC6, F7, F8-Testing-1, and likely RHEL 5.1 are all affected as well. Should I bother to file more bug reports?
I cloned this bug to be against Fedora 8 Test2 (also affected), where it will hopefully receive some attention. The number is Bug #295181 https://bugzilla.redhat.com/show_bug.cgi?id=295181
Proposing for RHEL-5.3, waiting with final ACK on developer review. Read ya, Phil
ping ... RHEL 5.4 or 5.5?
Hey Mike. 5.4 :) Now gimme a Diet Coke! Regards, Phil
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1414.html