ipsec patches test: minor compilation and policy match issues

ipsec patches test: minor compilation and policy match issues

[Ivan Mitev]

[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]

hi,

i'm using the CVS (20040415) version of iptables and pom-ng, and kernel
2.6.5, to test the new ipsec patches (ipsec-XX + policy).  
when compiling, iptables seems unhappy about the definition of 2 
includes added by the ipsec-02-input-hooks patch in
include/linux/netfilter_ipv4.h  :

#include <linux/netdevice.h>
#include <net/protocol.h>

with them, the kernel compiles fine, but iptables complains (output
attached). if i comment these 2 includes, iptables compiles cleanly (but then
the kernel fails to compile); see attached iptables compilation output.

another minor problem i had was that, oddly, pom didn't copy the policy
patch's files into the kernel (net/..., include/...), nor did update the
Makefile and Kconfig. 
it copied the iptables files libipt_policy.man and .c, but didn't copy
.policy-test. i didn't try to reproduce this though, so maybe i did 
something wrong. 

anwyway, with the comment/uncomment of the 2 includes, plus with some manual
tweaks for the policy patch, i got everything running.

now, the real testing, so here is the setup (very basic for now): 

all nets are 172.16.x.x/24

               --------                           --------
 .1.0 --- 1.10 | rtr1 | 2.10 --- "inet" ---- 3.10 | rtr2 | 4.10 --- .4.0
          eth0 -------- eth1                 eth1 -------- eth0


rtr1 is the 2.6 ipsec gw where i test the new ipsec patches

"inet" is in fact another router where i can tcpdump to
check that i only have ESP and/or AH packets between 2.10 and 3.10

i only have a tunnel for .1.0 <-> .4.0 networks, and no transport mode.

after a bit of tests, i saw that the ipsec match doesn't work when i specify 
--tunnet-dst/src; otherwise it works very well, at least for this basic setup.

so, for example that rule works:

iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec --strict --proto esp --mode tunnel -j ACCEPT

while these don't:

iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec --strict --proto esp --mode tunnel --tunnel-dst 172.16.4.0/24 -j ACCEPT

or

iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec --strict --proto esp --mode tunnel --tunnel-src 172.16.1.0/24 -j ACCEPT

or 

iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec --strict --proto esp --mode tunnel --tunnel-src 172.16.1.0/24 --tunnel-dst 172.16.4.0/24 -j ACCEPT


that's it for now; later i'll try to migrate/test a part of a (really) 
more complex setup, with lots of iptables and tc rules (so i expect some 
problems where the packets are seen twice, in their encrypted/de-encrypted 
form). i also have some user-space apps that use ip_queue, so i'll see 
if they'll be broken.

if some of you are interested in more tests for the transport mode, i can
investigate that too...

regards,
ivan

[-- Attachment #2: iptables_compilation --]
[-- Type: text/plain, Size: 23570 bytes --]

Extensions found: IPv4:policy IPv4:recent IPv6:ah IPv6:esp IPv6:frag IPv6:ipv6header IPv6:hbh IPv6:dst IPv6:rt
cc -O2 -Wall -Wunused -I/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2//include -Iinclude/ -DIPTABLES_VERSION=\"1.2.10\"  -fPIC -o extensions/libipt_ah_sh.o -c extensions/libipt_ah.c
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:25:1: warning: "IFNAMSIZ" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:128:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:29:1: warning: "IFF_UP" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:46:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:30:1: warning: "IFF_BROADCAST" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:48:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:31:1: warning: "IFF_DEBUG" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:50:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:32:1: warning: "IFF_LOOPBACK" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:52:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:33:1: warning: "IFF_POINTOPOINT" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:54:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:34:1: warning: "IFF_NOTRAILERS" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:56:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:35:1: warning: "IFF_RUNNING" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:58:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:36:1: warning: "IFF_NOARP" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:60:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:37:1: warning: "IFF_PROMISC" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:62:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:38:1: warning: "IFF_ALLMULTI" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:66:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:40:1: warning: "IFF_MASTER" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:69:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:41:1: warning: "IFF_SLAVE" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:71:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:43:1: warning: "IFF_MULTICAST" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:74:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:47:1: warning: "IFF_PORTSEL" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:77:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:48:1: warning: "IFF_AUTOMEDIA" redefined
In file included from include/libiptc/ipt_kernel_headers.h:14,
                 from include/libiptc/libiptc.h:5,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/usr/include/net/if.h:79:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netdevice.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:10,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:92: error: redefinition of `struct ifmap'
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:128: error: redefinition of `struct ifreq'
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/if.h:178: error: redefinition of `struct ifconf'
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:11,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/in6.h:31: error: redefinition of `struct in6_addr'
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/in6.h:52: error: redefinition of `struct sockaddr_in6'
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/in6.h:60: error: redefinition of `struct ipv6_mreq'
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:11,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/in6.h:129:1: warning: "IPPROTO_HOPOPTS" redefined
In file included from /usr/include/netdb.h:28,
                 from extensions/libipt_ah.c:3:
/usr/include/netinet/in.h:36:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:11,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/in6.h:130:1: warning: "IPPROTO_ROUTING" redefined
In file included from /usr/include/netdb.h:28,
                 from extensions/libipt_ah.c:3:
/usr/include/netinet/in.h:58:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:11,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/in6.h:131:1: warning: "IPPROTO_FRAGMENT" redefined
In file included from /usr/include/netdb.h:28,
                 from extensions/libipt_ah.c:3:
/usr/include/netinet/in.h:60:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:11,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/in6.h:132:1: warning: "IPPROTO_ICMPV6" redefined
In file included from /usr/include/netdb.h:28,
                 from extensions/libipt_ah.c:3:
/usr/include/netinet/in.h:70:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:11,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/in6.h:133:1: warning: "IPPROTO_NONE" redefined
In file included from /usr/include/netdb.h:28,
                 from extensions/libipt_ah.c:3:
/usr/include/netinet/in.h:72:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:11,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/in6.h:134:1: warning: "IPPROTO_DSTOPTS" redefined
In file included from /usr/include/netdb.h:28,
                 from extensions/libipt_ah.c:3:
/usr/include/netinet/in.h:74:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:11,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/in6.h:164:1: warning: "IPV6_ADD_MEMBERSHIP" redefined
In file included from /usr/include/netinet/in.h:253,
                 from /usr/include/netdb.h:28,
                 from extensions/libipt_ah.c:3:
/usr/include/bits/in.h:129:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:28,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:11,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/in6.h:165:1: warning: "IPV6_DROP_MEMBERSHIP" redefined
In file included from /usr/include/netinet/in.h:253,
                 from /usr/include/netdb.h:28,
                 from extensions/libipt_ah.c:3:
/usr/include/bits/in.h:130:1: warning: this is the location of the previous definition
In file included from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4.h:11,
                 from /home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/linux/netfilter_ipv4/ip_tables.h:25,
                 from include/libiptc/libiptc.h:6,
                 from include/iptables.h:5,
                 from extensions/libipt_ah.c:8:
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:39: warning: `struct sk_buff' declared inside parameter list
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:39: warning: its scope is only this definition or declaration, which is probably not what you want
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:40: error: parse error before "u32"
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:40: warning: `struct sk_buff' declared inside parameter list
/home/builds/kernels/build/linux-2.6.5-netfilter-cvs2/include/net/protocol.h:63: error: field `list' has incomplete type
make: *** [extensions/libipt_ah_sh.o] Error 1

Re: ipsec patches test: minor compilation and policy match issues

[Patrick McHardy]

Ivan Mitev wrote:

 > [...]
> 
> anwyway, with the comment/uncomment of the 2 includes, plus with some manual
> tweaks for the policy patch, i got everything running.

I'm going to look into these problems, thanks.

> now, the real testing, so here is the setup (very basic for now): 
> 
> all nets are 172.16.x.x/24
> 
>                --------                           --------
>  .1.0 --- 1.10 | rtr1 | 2.10 --- "inet" ---- 3.10 | rtr2 | 4.10 --- .4.0
>           eth0 -------- eth1                 eth1 -------- eth0
> 
> 
> rtr1 is the 2.6 ipsec gw where i test the new ipsec patches
> 
> "inet" is in fact another router where i can tcpdump to
> check that i only have ESP and/or AH packets between 2.10 and 3.10
> 
> i only have a tunnel for .1.0 <-> .4.0 networks, and no transport mode.
> 
> after a bit of tests, i saw that the ipsec match doesn't work when i specify 
> --tunnet-dst/src; otherwise it works very well, at least for this basic setup.
> 
> so, for example that rule works:
> 
> iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec --strict --proto esp --mode tunnel -j ACCEPT
> 
> while these don't:
> 
> iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec --strict --proto esp --mode tunnel --tunnel-dst 172.16.4.0/24 -j ACCEPT
> 
> or
> 
> iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec --strict --proto esp --mode tunnel --tunnel-src 172.16.1.0/24 -j ACCEPT
> 
> or 
> 
> iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec --strict --proto esp --mode tunnel --tunnel-src 172.16.1.0/24 --tunnel-dst 172.16.4.0/24 -j ACCEPT

 From your diagram above I'd say that you need
--tunnel-src x.y.2.10 --tunnel-dst x.y.3.10. tunnel-src
and tunnel-dst match the ipsec-tunnel peers, not the
addresses of the encapsulated packets.

> that's it for now; later i'll try to migrate/test a part of a (really) 
> more complex setup, with lots of iptables and tc rules (so i expect some 
> problems where the packets are seen twice, in their encrypted/de-encrypted 
> form). i also have some user-space apps that use ip_queue, so i'll see 
> if they'll be broken.

I'm looking forward to your tests.

> if some of you are interested in more tests for the transport mode, i can
> investigate that too...

Sure, anything helps. Thanks for your help ;)

Regards,
Patrick

> 
> regards,
> ivan
> 

Re: ipsec patches test: minor compilation and policy match issues

[Ivan Mitev]

hi !

i tried to use the ipsec policy for a transport mode, AH+ESP, but i don't
manage to get it working (ie pkts are not matched by the ipsec policy rule)
however AH or ESP alone work fine.

btw, maybe no one uses AH + ESP, but that's only a test...

setup:

 --------                           --------
 | rtr1 | 2.10 --- "inet" ---- 3.10 | rtr2 |
 -------- eth1                 eth1 --------

setkey on rtr1:

spdadd 172.16.3.10 172.16.2.10 any -P out ipsec
        esp/transport//require
        ah/transport//require;

spdadd 172.16.2.10 172.16.3.10 any -P in ipsec
        esp/transport//require
        ah/transport//require;

assuming OUTPUT is wide open, the following rules are not matched by 
incoming pkts from rtr2 (i do a ping from rtr2 to rtr1)

iptables -A INPUT  -m policy --dir in --pol ipsec -j ACCEPT

iptables -A INPUT  -m policy --dir in --proto ah --pol ipsec -j ACCEPT
iptables -A INPUT  -m policy --dir in --proto esp --pol ipsec -j ACCEPT

tcpdump on rtr1 eth1:

1:28:05.801812 IP 172.16.3.10 > 172.16.2.10: AH(spi=0x08aac272,seq=0x2): ESP(spi=0x0cf46759,seq=0x2)

as soon as i "free" INPUT, packets begin to flow; packets also flow when
i set the following rule, so it seems that AH+ESP is not reconized as ipsec:
iptables -A INPUT  -m policy --dir in --pol none -j ACCEPT 

a word about other tests:
 - multiple (>10) concurrent tunnels work fine; once some appropriate user
   chains are set up, the ipsec policy match is very flexible, and provides
   more control than with the ipsec+ devices of freeswan ; cool!
 - i didn't have time yet to test that mangle works fine (eg. test that packets
   keep their fwmark while being encrypted/decrypted, and that seeing the 
   packet in both its encrypted and decrypted form doesn't mess up with tc).
 - SNAT is working well with tunnel mode; eg when the hosts behind rtr1 are
   s-natted with rtr1's private ip; i didn't test very complicated S/DNAT
   setups though.

ivan



On Fri, Apr 16, 2004 at 04:11:41PM +0200, Patrick McHardy wrote:
> Ivan Mitev wrote:
> 
> > [...]
> >
> >anwyway, with the comment/uncomment of the 2 includes, plus with some 
> >manual
> >tweaks for the policy patch, i got everything running.
> 
> I'm going to look into these problems, thanks.
> 
> >now, the real testing, so here is the setup (very basic for now): 
> >
> >all nets are 172.16.x.x/24
> >
> >               --------                           --------
> > .1.0 --- 1.10 | rtr1 | 2.10 --- "inet" ---- 3.10 | rtr2 | 4.10 --- .4.0
> >          eth0 -------- eth1                 eth1 -------- eth0
> >
> >
> >rtr1 is the 2.6 ipsec gw where i test the new ipsec patches
> >
> >"inet" is in fact another router where i can tcpdump to
> >check that i only have ESP and/or AH packets between 2.10 and 3.10
> >
> >i only have a tunnel for .1.0 <-> .4.0 networks, and no transport mode.
> >
> >after a bit of tests, i saw that the ipsec match doesn't work when i 
> >specify --tunnet-dst/src; otherwise it works very well, at least for this 
> >basic setup.
> >
> >so, for example that rule works:
> >
> >iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec 
> >--strict --proto esp --mode tunnel -j ACCEPT
> >
> >while these don't:
> >
> >iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec 
> >--strict --proto esp --mode tunnel --tunnel-dst 172.16.4.0/24 -j ACCEPT
> >
> >or
> >
> >iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec 
> >--strict --proto esp --mode tunnel --tunnel-src 172.16.1.0/24 -j ACCEPT
> >
> >or 
> >
> >iptables -A FORWARD -i eth0 -o eth1 -m policy --dir out --pol ipsec 
> >--strict --proto esp --mode tunnel --tunnel-src 172.16.1.0/24 --tunnel-dst 
> >172.16.4.0/24 -j ACCEPT
> 
> From your diagram above I'd say that you need
> --tunnel-src x.y.2.10 --tunnel-dst x.y.3.10. tunnel-src
> and tunnel-dst match the ipsec-tunnel peers, not the
> addresses of the encapsulated packets.
> 
> >that's it for now; later i'll try to migrate/test a part of a (really) 
> >more complex setup, with lots of iptables and tc rules (so i expect some 
> >problems where the packets are seen twice, in their encrypted/de-encrypted 
> >form). i also have some user-space apps that use ip_queue, so i'll see 
> >if they'll be broken.
> 
> I'm looking forward to your tests.
> 
> >if some of you are interested in more tests for the transport mode, i can
> >investigate that too...
> 
> Sure, anything helps. Thanks for your help ;)
> 
> Regards,
> Patrick
> 
> >
> >regards,
> >ivan
> >
> 

-- 

Re: ipsec patches test: minor compilation and policy match issues

[Patrick McHardy]

Hi Ivan,

Ivan Mitev wrote:
> hi !
> 
> i tried to use the ipsec policy for a transport mode, AH+ESP, but i don't
> manage to get it working (ie pkts are not matched by the ipsec policy rule)
> however AH or ESP alone work fine.
> 
> btw, maybe no one uses AH + ESP, but that's only a test...
> 
> setup:
> 
>  --------                           --------
>  | rtr1 | 2.10 --- "inet" ---- 3.10 | rtr2 |
>  -------- eth1                 eth1 --------
> 
> setkey on rtr1:
> 
> spdadd 172.16.3.10 172.16.2.10 any -P out ipsec
>         esp/transport//require
>         ah/transport//require;
> 
> spdadd 172.16.2.10 172.16.3.10 any -P in ipsec
>         esp/transport//require
>         ah/transport//require;
> 
> assuming OUTPUT is wide open, the following rules are not matched by 
> incoming pkts from rtr2 (i do a ping from rtr2 to rtr1)
> 
> iptables -A INPUT  -m policy --dir in --pol ipsec -j ACCEPT
> 
> iptables -A INPUT  -m policy --dir in --proto ah --pol ipsec -j ACCEPT
> iptables -A INPUT  -m policy --dir in --proto esp --pol ipsec -j ACCEPT
> 
> tcpdump on rtr1 eth1:
> 
> 1:28:05.801812 IP 172.16.3.10 > 172.16.2.10: AH(spi=0x08aac272,seq=0x2): ESP(spi=0x0cf46759,seq=0x2)
> 
> as soon as i "free" INPUT, packets begin to flow; packets also flow when
> i set the following rule, so it seems that AH+ESP is not reconized as ipsec:
> iptables -A INPUT  -m policy --dir in --pol none -j ACCEPT 

Did you have rules to accept the encrypted packets ? The policy match
only matches the decapsulated packets, so you need to accept the outer
protocol using the protocol match. AH+ESP works fine with this setup:

setkey:
spdadd 192.168.0.23/32 0.0.0.0/0 any
         -P out ipsec
         esp/tunnel/0.0.0.0-192.168.0.1/require
         ah/transport//require;

spdadd 0.0.0.0/0 192.168.0.23/32 any
         -P in ipsec
         esp/tunnel/192.168.0.1-0.0.0.0/require
         ah/transport//require;

policy match:
iptables -A INPUT -m policy --dir in --pol ipsec --strict --proto esp
  --mode tunnel --tunnel-src 192.168.0.1 --tunnel-dst 192.168.0.23 --next
  --proto ah --mode transport

iptables -A OUTPUT -m policy --dir out --pol ipsec --strict --proto esp
  --mode tunnel --tunnel-src 192.168.0.23 --tunnel-dst 192.168.0.1 --next
  --proto ah  --mode transport

All packets are accepted, the rules are just there for counting.
I have not tried nested transport-mode SAs yet, but I will try after
recompling the kernel.

> a word about other tests:
>  - multiple (>10) concurrent tunnels work fine; once some appropriate user
>    chains are set up, the ipsec policy match is very flexible, and provides
>    more control than with the ipsec+ devices of freeswan ; cool!
>  - i didn't have time yet to test that mangle works fine (eg. test that packets
>    keep their fwmark while being encrypted/decrypted, and that seeing the 
>    packet in both its encrypted and decrypted form doesn't mess up with tc).
>  - SNAT is working well with tunnel mode; eg when the hosts behind rtr1 are
>    s-natted with rtr1's private ip; i didn't test very complicated S/DNAT
>    setups though.

Thanks for your testing.

Regards
Patrick

> 
> ivan
> 

Re: ipsec patches test: minor compilation and policy match issues

[Patrick McHardy]

Just to avoid confusion, there is a small mistake in my setkey script.
I replaced the local tunnel-address with 0.0.0.0 to see if it will be
set automatically. It works, but I haven't tested the policy match with
this configuration.

Patrick McHardy wrote:

> setkey:
> spdadd 192.168.0.23/32 0.0.0.0/0 any
>         -P out ipsec
>         esp/tunnel/0.0.0.0-192.168.0.1/require
                      ^192.168.0.23
>         ah/transport//require;
> 
> spdadd 0.0.0.0/0 192.168.0.23/32 any
>         -P in ipsec
>         esp/tunnel/192.168.0.1-0.0.0.0/require
                                  ^192.168.0.23
>         ah/transport//require;
> 
> policy match:
> iptables -A INPUT -m policy --dir in --pol ipsec --strict --proto esp
>  --mode tunnel --tunnel-src 192.168.0.1 --tunnel-dst 192.168.0.23 --next
>  --proto ah --mode transport
> 
> iptables -A OUTPUT -m policy --dir out --pol ipsec --strict --proto esp
>  --mode tunnel --tunnel-src 192.168.0.23 --tunnel-dst 192.168.0.1 --next
>  --proto ah  --mode transport

Re: ipsec patches test: minor compilation and policy match issues

[Ivan Mitev]

hello patrick,

AH+ESP actually works well ; that was my mistake - i played with some other
things and accidentaly dropped AH proto pkts :(  - sorry

thanks for your reply !

ivan


On Sat, Apr 24, 2004 at 01:51:39PM +0200, Patrick McHardy wrote:
> Just to avoid confusion, there is a small mistake in my setkey script.
> I replaced the local tunnel-address with 0.0.0.0 to see if it will be
> set automatically. It works, but I haven't tested the policy match with
> this configuration.
> 
> Patrick McHardy wrote:
> 
> >setkey:
> >spdadd 192.168.0.23/32 0.0.0.0/0 any
> >        -P out ipsec
> >        esp/tunnel/0.0.0.0-192.168.0.1/require
>                      ^192.168.0.23
> >        ah/transport//require;
> >
> >spdadd 0.0.0.0/0 192.168.0.23/32 any
> >        -P in ipsec
> >        esp/tunnel/192.168.0.1-0.0.0.0/require
>                                  ^192.168.0.23
> >        ah/transport//require;
> >
> >policy match:
> >iptables -A INPUT -m policy --dir in --pol ipsec --strict --proto esp
> > --mode tunnel --tunnel-src 192.168.0.1 --tunnel-dst 192.168.0.23 --next
> > --proto ah --mode transport
> >
> >iptables -A OUTPUT -m policy --dir out --pol ipsec --strict --proto esp
> > --mode tunnel --tunnel-src 192.168.0.23 --tunnel-dst 192.168.0.1 --next
> > --proto ah  --mode transport

-- 

Re: ipsec patches test: minor compilation and policy match issues

[Michael Richardson]

>>>>> "Ivan" == Ivan Mitev <imitev@obs.bg> writes:
    Ivan> i tried to use the ipsec policy for a transport mode, AH+ESP,
    Ivan> but i don't manage to get it working (ie pkts are not matched
    Ivan> by the ipsec policy rule) however AH or ESP alone work fine.

    Ivan> btw, maybe no one uses AH + ESP, but that's only a test...

  There is really no point in mixing them.
  ESP in RFC2401 IPsec (vs 1827) provides authentication.

--
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

Re: ipsec patches test: minor compilation and policy match issues

[Patrick McHardy]

Michael Richardson wrote:
>>>>>>"Ivan" == Ivan Mitev <imitev@obs.bg> writes:
> 
>     Ivan> i tried to use the ipsec policy for a transport mode, AH+ESP,
>     Ivan> but i don't manage to get it working (ie pkts are not matched
>     Ivan> by the ipsec policy rule) however AH or ESP alone work fine.
> 
>     Ivan> btw, maybe no one uses AH + ESP, but that's only a test...
> 
>   There is really no point in mixing them.
>   ESP in RFC2401 IPsec (vs 1827) provides authentication.

You're right, especially no one uses AH tunnel + ESP tunnel,
but Linux supports it, so testing these cases is at least at
important as testing the common cases, because bugs in
common setups are likely to show up soon.

Regards
Patrick

Where is DROP target implemented {Virus Scanned}

[Qiang]

I am trying to read the Netfilter kernel, can't find where is the DROP
Target implemented? Any hints which file to look at ? thanks!

Re: Where is DROP target implemented {Virus Scanned}

[Patrick McHardy]

Qiang wrote:
> I am trying to read the Netfilter kernel, can't find where is the DROP
> Target implemented? Any hints which file to look at ? thanks!
> 

Interesting question, I didn't know either until just now ;)
DROP/ACCEPT/RETURN (and I think QUEUE) are handled by
ipt_standard_target (net/ipv4/netfilter/ip_tables.c).

Regards
Patrick

Re: ipsec patches test: minor compilation and policy match issues

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

* Ivan Mitev (imitev@obs.bg) wrote:
> i'm using the CVS (20040415) version of iptables and pom-ng, and kernel
> 2.6.5, to test the new ipsec patches (ipsec-XX + policy).  

I'm doing basically the same thing.  20040710 or so of POM and iptables
and 2.6.7.  Got everything built/compiled/installed/etc.  IPSEC is all
working and whatnot.  My problem is matching things.  I've been trying
to match using spi and I just can't seem to get it to work.  I'm using
the spi I get from setkey -D and from tcpdump but no matter what I try
it doesn't work.

Sorry I can't give more details, but is this supposted to work?  I'll
see about adding something to ipt_policy.c to get it to print out what
it thinks the SPI is tommorow, hopefully.  Anyone else tried this?

The match works if I don't have --spi 0x<blah>, doesn't work if I do. :/

	Thanks,

		Stephen

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ipsec patches test: minor compilation and policy match issues

[Patrick McHardy]

Stephen Frost wrote:
> * Ivan Mitev (imitev@obs.bg) wrote:
> 
>>i'm using the CVS (20040415) version of iptables and pom-ng, and kernel
>>2.6.5, to test the new ipsec patches (ipsec-XX + policy).  
> 
> 
> I'm doing basically the same thing.  20040710 or so of POM and iptables
> and 2.6.7.  Got everything built/compiled/installed/etc.  IPSEC is all
> working and whatnot.  My problem is matching things.  I've been trying
> to match using spi and I just can't seem to get it to work.  I'm using
> the spi I get from setkey -D and from tcpdump but no matter what I try
> it doesn't work.
> 
> Sorry I can't give more details, but is this supposted to work?  I'll
> see about adding something to ipt_policy.c to get it to print out what
> it thinks the SPI is tommorow, hopefully.  Anyone else tried this?
> 
> The match works if I don't have --spi 0x<blah>, doesn't work if I do. :/

The --spi option matches the spi given in the setkey policy with
unique:number. I'll update the manpage ..

Regards
Patrick

> 
> 	Thanks,
> 
> 		Stephen

Re: ipsec patches test: minor compilation and policy match issues

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

* Patrick McHardy (kaber@trash.net) wrote:
> Stephen Frost wrote:
> >I'm doing basically the same thing.  20040710 or so of POM and iptables
> >and 2.6.7.  Got everything built/compiled/installed/etc.  IPSEC is all
> >working and whatnot.  My problem is matching things.  I've been trying
> >to match using spi and I just can't seem to get it to work.  I'm using
> >the spi I get from setkey -D and from tcpdump but no matter what I try
> >it doesn't work.
> >
> >Sorry I can't give more details, but is this supposted to work?  I'll
> >see about adding something to ipt_policy.c to get it to print out what
> >it thinks the SPI is tommorow, hopefully.  Anyone else tried this?
> >
> >The match works if I don't have --spi 0x<blah>, doesn't work if I do. :/
> 
> The --spi option matches the spi given in the setkey policy with
> unique:number. I'll update the manpage ..

Ahhh, now that makes much more sense.  I just had 'require' before.  I'm
getting closer it seems.  Now, at least, I seem to be able to match the
number I put after the 'unique:' using '--reqid'.  Still doesn't work
when using '--spi' though.  Not sure that I care though, unless someone
can tell me a reason why I should?  It's important, of course, to match
the right packets, since I'm doing tunneling and different remote sites
will have access to different things and so different firewall rules to
handle them...

	Thanks,

		Stephen

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ipsec patches test: minor compilation and policy match issues

[Patrick McHardy]

Stephen Frost wrote:
> * Patrick McHardy (kaber@trash.net) wrote:
>
>>The --spi option matches the spi given in the setkey policy with
>>unique:number. I'll update the manpage ..
> 
> 
> Ahhh, now that makes much more sense.  I just had 'require' before.  I'm
> getting closer it seems.  Now, at least, I seem to be able to match the
> number I put after the 'unique:' using '--reqid'.  Still doesn't work
> when using '--spi' though.  Not sure that I care though, unless someone
> can tell me a reason why I should?  It's important, of course, to match
> the right packets, since I'm doing tunneling and different remote sites
> will have access to different things and so different firewall rules to
> handle them...

Ooops, right, that was the --reqid option. I need to update the manpage
again ;) Not sure what the problem with --spi is, I will test is myself
soon.

Regards
Patrick


> 
> 	Thanks,
> 
> 		Stephen

Re: ipsec patches test: minor compilation and policy match issues

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

* Patrick McHardy (kaber@trash.net) wrote:
> Stephen Frost wrote:
> >Ahhh, now that makes much more sense.  I just had 'require' before.  I'm
> >getting closer it seems.  Now, at least, I seem to be able to match the
> >number I put after the 'unique:' using '--reqid'.  Still doesn't work
> >when using '--spi' though.  Not sure that I care though, unless someone
> >can tell me a reason why I should?  It's important, of course, to match
> >the right packets, since I'm doing tunneling and different remote sites
> >will have access to different things and so different firewall rules to
> >handle them...
> 
> Ooops, right, that was the --reqid option. I need to update the manpage
> again ;) Not sure what the problem with --spi is, I will test is myself
> soon.

Okay, thanks.  For --reqid...  Do you think that's sufficient to base
firewall rules off of?  Can it be somehow 'faked' by the
remote/potentially untrusted side?  That's my main issue.  If it can't
and will only match if the ipsec packet is valid and coming from that
network then I don't need to care about --spid and will just use
--reqid...

	Thanks,

		Stephen

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ipsec patches test: minor compilation and policy match issues

[Patrick McHardy]

Stephen Frost wrote:
> Okay, thanks.  For --reqid...  Do you think that's sufficient to base
> firewall rules off of?  Can it be somehow 'faked' by the
> remote/potentially untrusted side?  That's my main issue.  If it can't
> and will only match if the ipsec packet is valid and coming from that
> network then I don't need to care about --spid and will just use
> --reqid...

It can't be faked, it will always match the reqid of the used SA.
But policy checks happen after the PRE_ROUTING/LOCAL_IN/FORWARD
hooks, so you can't be sure that a packet matching a reqid really
has a source/destination address that is configured in the policy.
Invalid packets will be dropped by the network stack before socket
delivery/forwarding. But this can also happen with --spi matching.

Maybe we should add new policy checks to protect conntrack from these
packets. If they are invalid it shouldn't change state.

Regards
Patrick

> 
> 	Thanks,
> 
> 		Stephen

Re: ipsec patches test: minor compilation and policy match issues

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

* Patrick McHardy (kaber@trash.net) wrote:
> Stephen Frost wrote:
> >Okay, thanks.  For --reqid...  Do you think that's sufficient to base
> >firewall rules off of?  Can it be somehow 'faked' by the
> >remote/potentially untrusted side?  That's my main issue.  If it can't
> >and will only match if the ipsec packet is valid and coming from that
> >network then I don't need to care about --spid and will just use
> >--reqid...
> 
> It can't be faked, it will always match the reqid of the used SA.

Okay, cool.

> But policy checks happen after the PRE_ROUTING/LOCAL_IN/FORWARD
> hooks, so you can't be sure that a packet matching a reqid really
> has a source/destination address that is configured in the policy.

Well, as standard practice I check the source address of any packet
coming in to make sure it matches the interface it's coming in on.  It's
basically rp_filter implemented manually w/ iptables because I have to
turn off iptables due to some complex routing I'm doing.

Anyway, my intent is to use the reqid in my checks to ensure that only
valid source addresses are coming in from ipsec tunnels, as well as to
implement some other rules for each tunnel according to what the remote
side needs access to.  Do you think there'd be any problem with that?

I've also run into an interesting problem that perhaps you can help
with...  First off, is there any way to get the kernel to log packets
which it expects to be IPSEC'd due to 'required' in the policy but
aren't?  I've got the following setup:

Using 192.168.0.0/16 internally for everyone.  Then I have some local
networks at the main site using 192.168.1.0/24, 192.168.2.0/24, etc.
Then I've got a couple of remote sites which have addresses like
192.168.10.0/24, 192.168.11.0/24.  Now, in my IPSEC policy I'd like to
be able to define a policy on the remote side like:
spdadd 192.168.10.0/24 192.168.0.0/16 any -P out ipsec ...
spdadd 192.168.0.0/16 192.168.0.0/24 any -P in ipsec ...

The problem is that when I have these rules in place, the machines
behind the gw on the remote side (192.168.10.x) can't talk to the gw
anyway, everything just gets dropped.  My guess is that this is because
the kernel is expecting them to be IPSEC'd or coming from the remote
side of the tunnel or something.

Any thoughts?

	Thanks,

		Stephen

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ipsec patches test: minor compilation and policy match issues

[Patrick McHardy]

Stephen Frost wrote:
> * Patrick McHardy (kaber@trash.net) wrote:
> 
>>Stephen Frost wrote:
>>
>>>Okay, thanks.  For --reqid...  Do you think that's sufficient to base
>>>firewall rules off of?  Can it be somehow 'faked' by the
>>>remote/potentially untrusted side?  That's my main issue.  If it can't
>>>and will only match if the ipsec packet is valid and coming from that
>>>network then I don't need to care about --spid and will just use
>>>--reqid...
>>
>>It can't be faked, it will always match the reqid of the used SA.
> 
> 
> Okay, cool.
> 
> 
>>But policy checks happen after the PRE_ROUTING/LOCAL_IN/FORWARD
>>hooks, so you can't be sure that a packet matching a reqid really
>>has a source/destination address that is configured in the policy.
> 
> 
> Well, as standard practice I check the source address of any packet
> coming in to make sure it matches the interface it's coming in on.  It's
> basically rp_filter implemented manually w/ iptables because I have to
> turn off iptables due to some complex routing I'm doing.
 >
> Anyway, my intent is to use the reqid in my checks to ensure that only
> valid source addresses are coming in from ipsec tunnels, as well as to
> implement some other rules for each tunnel according to what the remote
> side needs access to.  Do you think there'd be any problem with that?

It should work fine. The check for valid addresses (policy-check) is
performed by ipsec automatically, but after some netfilter hooks have
been hit. The policy match should be sufficient to relate traffic to the
tunnel it came from. If you notice anything that is missing, please let
me know.


> I've also run into an interesting problem that perhaps you can help
> with...  First off, is there any way to get the kernel to log packets
> which it expects to be IPSEC'd due to 'required' in the policy but
> aren't?  I've got the following setup:

Unless it was added recently and I missed it, no. But all these packets
will be caught by xfrm4_policy_check(), so you can just log them there.

> Using 192.168.0.0/16 internally for everyone.  Then I have some local
> networks at the main site using 192.168.1.0/24, 192.168.2.0/24, etc.
> Then I've got a couple of remote sites which have addresses like
> 192.168.10.0/24, 192.168.11.0/24.  Now, in my IPSEC policy I'd like to
> be able to define a policy on the remote side like:
> spdadd 192.168.10.0/24 192.168.0.0/16 any -P out ipsec ...
> spdadd 192.168.0.0/16 192.168.0.0/24 any -P in ipsec ...
> 
> The problem is that when I have these rules in place, the machines
> behind the gw on the remote side (192.168.10.x) can't talk to the gw
> anyway, everything just gets dropped.  My guess is that this is because
> the kernel is expecting them to be IPSEC'd or coming from the remote
> side of the tunnel or something.

Do you do masquerading on the 192.168.10.0/24 gateway ? Are the packets
dropped on the local or the remote gateway, or are the replies dropped ?

Regards
Patrick

> 
> Any thoughts?
> 
> 	Thanks,
> 
> 		Stephen

Re: ipsec patches test: minor compilation and policy match issues

[Henrik Nordstrom]

On Wed, 14 Jul 2004, Patrick McHardy wrote:

> Maybe we should add new policy checks to protect conntrack from these
> packets. If they are invalid it shouldn't change state.

This general problem of conntrack when applying policies on packets
flows.. Spoofed packets arriving from an untrusted source will disrupt
conntrack states unless filtering is applied before conntrack.

In normal traffic this can be solved by using the raw table to enforce the
anti-spoof policy by dropping illegal traffic flows before seen by
conntrack.  I suppose something similar could be done with ipsec traffic?

It would obviously be very nice for conntrack if the ipsec policy checks
could be applied in prerouting before conntrack, but I am not sure how
feasible this is.. It is not exacly a natural point for ipsec to apply 
policy checks in prerouting..

Regards
Henrik

Re: ipsec patches test: minor compilation and policy match issues

[Patrick McHardy]

Henrik Nordstrom wrote:
> 
> This general problem of conntrack when applying policies on packets
> flows.. Spoofed packets arriving from an untrusted source will disrupt
> conntrack states unless filtering is applied before conntrack.
> 
> In normal traffic this can be solved by using the raw table to enforce the
> anti-spoof policy by dropping illegal traffic flows before seen by
> conntrack.  I suppose something similar could be done with ipsec traffic?

Yes.

> It would obviously be very nice for conntrack if the ipsec policy checks
> could be applied in prerouting before conntrack, but I am not sure how
> feasible this is.. It is not exacly a natural point for ipsec to apply 
> policy checks in prerouting..

It can be done easily, when the packets hit netfilter decapsulation is
already done, we just need to add a call to xfrm4_policy_check().
The drawback is that policy checks would be performed twice on valid
packets.

Regards
Patrick

Re: ipsec patches test: minor compilation and policy match issues

[Henrik Nordstrom]

On Wed, 14 Jul 2004, Patrick McHardy wrote:

> It can be done easily, when the packets hit netfilter decapsulation is
> already done, we just need to add a call to xfrm4_policy_check().
> The drawback is that policy checks would be performed twice on valid
> packets.

Two question here:

a) Can the raw table be used for enforcing ipsec flow policies without 
disturbing conntrack, like it can for normal traffic?

b) If you check policies with xfrm4_policy_check() before conntrack with
the purpose of avoiding disturbing conntrack you better do so on all
incoming traffic, not only ipsec decapsulated traffic.. If not you have a 
noticeable asymmetry in that illegal decapsulated traffic over ipsec is 
handled correctly but unencrypted packets still crashes conntrack.

Maybe there is room for a skb flag indicating the policy check has already
been passed? If so it should be possible to switch the ipsec policy check
to prerouting relatively easily when needed?

But seriously speaking I think conntrack may need to be split in two for
this to work properly: prerouting to associate packet with connection for
filtering purposes, postrouting & local_in to update the conntrack state,
windows etc. Until this is done it is in my opinion just as good to simply
refer to the raw table for anti-spoof filtering as other solutions will 
still only be partial and only protect from what is already reasonably 
well protected.

Regards
Henrik

Re: ipsec patches test: minor compilation and policy match issues

[Patrick McHardy]

Henrik Nordstrom wrote:
> On Wed, 14 Jul 2004, Patrick McHardy wrote:
> 
> 
>>It can be done easily, when the packets hit netfilter decapsulation is
>>already done, we just need to add a call to xfrm4_policy_check().
>>The drawback is that policy checks would be performed twice on valid
>>packets.
> 
> 
> Two question here:
> 
> a) Can the raw table be used for enforcing ipsec flow policies without 
> disturbing conntrack, like it can for normal traffic?

You mean by calling xfrm4_policy_check from a new target ? Yes.

> b) If you check policies with xfrm4_policy_check() before conntrack with
> the purpose of avoiding disturbing conntrack you better do so on all
> incoming traffic, not only ipsec decapsulated traffic.. If not you have a 
> noticeable asymmetry in that illegal decapsulated traffic over ipsec is 
> handled correctly but unencrypted packets still crashes conntrack.

Sure, everything needs to be checked.

> Maybe there is room for a skb flag indicating the policy check has already
> been passed? If so it should be possible to switch the ipsec policy check
> to prerouting relatively easily when needed?

We could do that, but all other places are coded to avoid duplicate
policy checks, so I'm unsure if Dave will accept it. But I'm going to
try at least ;)

> But seriously speaking I think conntrack may need to be split in two for
> this to work properly: prerouting to associate packet with connection for
> filtering purposes, postrouting & local_in to update the conntrack state,
> windows etc. Until this is done it is in my opinion just as good to simply
> refer to the raw table for anti-spoof filtering as other solutions will 
> still only be partial and only protect from what is already reasonably 
> well protected.

I've thought about this, but I can't imagine how it would work, you
have to deal with all kinds of races ..

Regards
Patrick

> 
> Regards
> Henrik
> 

Re: ipsec patches test: minor compilation and policy match issues

[Henrik Nordstrom]

On Fri, 23 Jul 2004, Patrick McHardy wrote:

> > But seriously speaking I think conntrack may need to be split in two for
> > this to work properly: prerouting to associate packet with connection for
> 
> I've thought about this, but I can't imagine how it would work, you
> have to deal with all kinds of races ..

conntrack should be manageable in this I think, but NAT looks like a
nightmare..  In any event it is a major change of connection tracking and 
most likely outside what is realistic to do during a "stable" kernel 
cycle.

For now I think it is better to make use of the raw table and accept the 
duplicate policy check on ipsec traffic, if of too heavy add a skb flag 
indicating the policy check is already done.

Regards
Henrik