new iptables policy match

new iptables policy match

[Marco Berizzi]

Hello.
I'm testing the new iptables policy match on a snapshot kernel 
(2.6.15-git7).
This is my simple network diagram:

eth1                  eth0                                     eth0          
           eth1
10.1.2.0/24===172.16.1.247..[ipsec tunnel]..172.16.1.226===10.1.1.0/24
-----2.6.15-git7 linux box-----                         --------2.4/KLIPS 
box----------

I have setup a simple ipsec tunnel between the two linux boxes. So far, so 
good.
I'm pinging from 10.1.2.1 (a system connected to the 10.1.2.0/24 net) to 
10.1.1.1
(a system connected to the 10.1.1.0/24 net). This is iptables -L -v output:

root@Calimero:/tmp/RACOON# iptables -L -v
Chain INPUT (policy ACCEPT 70672 packets, 15M bytes)
pkts bytes target     prot opt in     out     source               
destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               
destination
   19  1140 ACCEPT     all  --  any    any     anywhere             anywhere 
            policy match dir out pol ipsec strict [0] [1] [2] [3] mode 
tunnel tunnel-dst 10.1.1.0/24 tunnel-src 10.1.2.0/24
    0     0 DROP       all  --  any    any     anywhere             anywhere 
            policy match dir in pol ipsec strict [0] [1] [2] [3] mode tunnel 
tunnel-dst 10.1.2.0/24 tunnel-src 10.1.1.0/24
    0     0 ACCEPT     all  --  any    any     10.1.2.0/24          
10.1.1.0/24
   19  1140 ACCEPT     all  --  any    any     10.1.1.0/24          
10.1.2.0/24

Chain OUTPUT (policy ACCEPT 39941 packets, 7146K bytes)
pkts bytes target     prot opt in     out     source               
destination

As you can see the 2nd rule should drop ipsec packets but they aren't 
dropped:
I'm getting back the echo reply packets from 10.1.1.1 to 10.1.2.1
Also the 3rd rule counter doesn't increment.
Deleting the 1st and 2nd rule counter are fine:

root@Calimero:/tmp/RACOON# iptables -L -v
Chain INPUT (policy ACCEPT 73891 packets, 15M bytes)
pkts bytes target     prot opt in     out     source               
destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               
destination
   66  3960 ACCEPT     all  --  any    any     10.1.2.0/24          
10.1.1.0/24
   66  3960 ACCEPT     all  --  any    any     10.1.1.0/24          
10.1.2.0/24

Chain OUTPUT (policy ACCEPT 41881 packets, 7285K bytes)
pkts bytes target     prot opt in     out     source               
destination

I know that this patches are "work in progress" and my apologies if this is
a know problem, but I would like to know is this is a know issue.
PS: I'm using iptables v1.3.4-20060109 on Slackware 10.2

Re: new iptables policy match

[Patrick McHardy]

Marco Berizzi wrote:
> Hello.
> I'm testing the new iptables policy match on a snapshot kernel 
> (2.6.15-git7).
> This is my simple network diagram:
> 
> eth1                  eth0                                     
> eth0                    eth1
> 10.1.2.0/24===172.16.1.247..[ipsec tunnel]..172.16.1.226===10.1.1.0/24
> -----2.6.15-git7 linux box-----                         
> --------2.4/KLIPS box----------
> 
> I have setup a simple ipsec tunnel between the two linux boxes. So far, 
> so good.
> I'm pinging from 10.1.2.1 (a system connected to the 10.1.2.0/24 net) to 
> 10.1.1.1
> (a system connected to the 10.1.1.0/24 net). This is iptables -L -v output:
> 
> root@Calimero:/tmp/RACOON# iptables -L -v
> Chain INPUT (policy ACCEPT 70672 packets, 15M bytes)
> pkts bytes target     prot opt in     out     source               
> destination
> 
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source               
> destination
>   19  1140 ACCEPT     all  --  any    any     anywhere             
> anywhere            policy match dir out pol ipsec strict [0] [1] [2] 
> [3] mode tunnel tunnel-dst 10.1.1.0/24 tunnel-src 10.1.2.0/24
>    0     0 DROP       all  --  any    any     anywhere             
> anywhere            policy match dir in pol ipsec strict [0] [1] [2] [3] 
> mode tunnel tunnel-dst 10.1.2.0/24 tunnel-src 10.1.1.0/24

How did you add these rules? It looks like you used "--next" multiple
times without specifying a policy element ..

Re: new iptables policy match

[Marco Berizzi]

Patrick McHardy wrote:

>Marco Berizzi wrote:
>>Hello.
>>I'm testing the new iptables policy match on a snapshot kernel 
>>(2.6.15-git7).
>>This is my simple network diagram:
>>
>>eth1                  eth0                                     eth0        
>>             eth1
>>10.1.2.0/24===172.16.1.247..[ipsec tunnel]..172.16.1.226===10.1.1.0/24
>>-----2.6.15-git7 linux box-----                         --------2.4/KLIPS 
>>box----------
>>
>>I have setup a simple ipsec tunnel between the two linux boxes. So far, so 
>>good.
>>I'm pinging from 10.1.2.1 (a system connected to the 10.1.2.0/24 net) to 
>>10.1.1.1
>>(a system connected to the 10.1.1.0/24 net). This is iptables -L -v 
>>output:
>>
>>root@Calimero:/tmp/RACOON# iptables -L -v
>>Chain INPUT (policy ACCEPT 70672 packets, 15M bytes)
>>pkts bytes target     prot opt in     out     source               
>>destination
>>
>>Chain FORWARD (policy DROP 0 packets, 0 bytes)
>>pkts bytes target     prot opt in     out     source               
>>destination
>>   19  1140 ACCEPT     all  --  any    any     anywhere             
>>anywhere            policy match dir out pol ipsec strict [0] [1] [2] [3] 
>>mode tunnel tunnel-dst 10.1.1.0/24 tunnel-src 10.1.2.0/24
>>    0     0 DROP       all  --  any    any     anywhere             
>>anywhere            policy match dir in pol ipsec strict [0] [1] [2] [3] 
>>mode tunnel tunnel-dst 10.1.2.0/24 tunnel-src 10.1.1.0/24
>
>How did you add these rules? It looks like you used "--next" multiple
>times without specifying a policy element ..

This is the command:

iptables -P FORWARD DROP
iptables -A FORWARD -m policy --next --dir out --next --pol ipsec --next 
--mode tunnel
--tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 --strict -j ACCEPT
iptables -A FORWARD -m policy --next --dir in --next --pol ipsec --next 
--mode tunnel
--tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 --strict -j DROP

Are they wrong?

Re: new iptables policy match

[Patrick McHardy]

Marco Berizzi wrote:
> 
> Patrick McHardy wrote:
> 
>>> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>>> pkts bytes target     prot opt in     out     source               
>>> destination
>>>   19  1140 ACCEPT     all  --  any    any     anywhere             
>>> anywhere            policy match dir out pol ipsec strict [0] [1] [2] 
>>> [3] mode tunnel tunnel-dst 10.1.1.0/24 tunnel-src 10.1.2.0/24
>>>    0     0 DROP       all  --  any    any     anywhere             
>>> anywhere            policy match dir in pol ipsec strict [0] [1] [2] 
>>> [3] mode tunnel tunnel-dst 10.1.2.0/24 tunnel-src 10.1.1.0/24
>>
>>
>> How did you add these rules? It looks like you used "--next" multiple
>> times without specifying a policy element ..
> 
> 
> This is the command:
> 
> iptables -P FORWARD DROP
> iptables -A FORWARD -m policy --next --dir out --next --pol ipsec --next 
> --mode tunnel
> --tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 --strict -j ACCEPT
> iptables -A FORWARD -m policy --next --dir in --next --pol ipsec --next 
> --mode tunnel
> --tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 --strict -j DROP
> 
> Are they wrong?

Yes, --next is needed only if your policy has multiple elements, like
"--mode tunnel --tunnel-src 1.2.3.4/32 --next --mode transform". I'll
fix up the userspace part to reject this incorrect use.

Re: new iptables policy match

[Patrick McHardy]

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

Marco Berizzi wrote:
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source               
> destination
>   19  1140 ACCEPT     all  --  any    any     anywhere             
> anywhere            policy match dir out pol ipsec strict [0] [1] [2] 
> [3] mode tunnel tunnel-dst 10.1.1.0/24 tunnel-src 10.1.2.0/24
>    0     0 DROP       all  --  any    any     anywhere             
> anywhere            policy match dir in pol ipsec strict [0] [1] [2] [3] 
> mode tunnel tunnel-dst 10.1.2.0/24 tunnel-src 10.1.1.0/24

There was actually a real problem, the first rule should never have
matched because its length doesn't match the number of used transforms.
I've fixed it with this patch (and added the additional checks to
the userspace part).

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1305 bytes --]

[NETFILTER]: Check policy length in policy match strict mode

Signed-off-by: Patrick McHardy <kaber@trash.net>

---
commit d98b092ef1a291d2fd31cbf1152bd16cca2e925d
tree bceb1f3d982e680b9ab3eb02e04e07a401bcd5db
parent a4fc7ab1d065a9dd89ed0e74439ef87d4a16e980
author Patrick McHardy <kaber@trash.net> Thu, 12 Jan 2006 10:38:26 +0100
committer Patrick McHardy <kaber@trash.net> Thu, 12 Jan 2006 10:38:26 +0100

 net/ipv4/netfilter/ipt_policy.c  |    2 +-
 net/ipv6/netfilter/ip6t_policy.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/netfilter/ipt_policy.c b/net/ipv4/netfilter/ipt_policy.c
index 709debc..8d1111e 100644
--- a/net/ipv4/netfilter/ipt_policy.c
+++ b/net/ipv4/netfilter/ipt_policy.c
@@ -89,7 +89,7 @@ match_policy_out(const struct sk_buff *s
 			return 0;
 	}
 
-	return strict ? 1 : 0;
+	return strict ? i == info->len : 0;
 }
 
 static int match(const struct sk_buff *skb,
diff --git a/net/ipv6/netfilter/ip6t_policy.c b/net/ipv6/netfilter/ip6t_policy.c
index 13fedad..33bd60e 100644
--- a/net/ipv6/netfilter/ip6t_policy.c
+++ b/net/ipv6/netfilter/ip6t_policy.c
@@ -91,7 +91,7 @@ match_policy_out(const struct sk_buff *s
 			return 0;
 	}
 
-	return strict ? 1 : 0;
+	return strict ? i == info->len : 0;
 }
 
 static int match(const struct sk_buff *skb,

Re: new iptables policy match

[Marco Berizzi]

Patrick McHardy wrote:

>Marco Berizzi wrote:
>>
>>Patrick McHardy wrote:
>>
>>>>Chain FORWARD (policy DROP 0 packets, 0 bytes)
>>>>pkts bytes target     prot opt in     out     source               
>>>>destination
>>>>   19  1140 ACCEPT     all  --  any    any     anywhere             
>>>>anywhere            policy match dir out pol ipsec strict [0] [1] [2] 
>>>>[3] mode tunnel tunnel-dst 10.1.1.0/24 tunnel-src 10.1.2.0/24
>>>>    0     0 DROP       all  --  any    any     anywhere             
>>>>anywhere            policy match dir in pol ipsec strict [0] [1] [2] [3] 
>>>>mode tunnel tunnel-dst 10.1.2.0/24 tunnel-src 10.1.1.0/24
>>>
>>>
>>>How did you add these rules? It looks like you used "--next" multiple
>>>times without specifying a policy element ..
>>
>>
>>This is the command:
>>
>>iptables -P FORWARD DROP
>>iptables -A FORWARD -m policy --next --dir out --next --pol ipsec --next 
>>--mode tunnel
>>--tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 --strict -j ACCEPT
>>iptables -A FORWARD -m policy --next --dir in --next --pol ipsec --next 
>>--mode tunnel
>>--tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 --strict -j DROP
>>
>>Are they wrong?
>
>Yes, --next is needed only if your policy has multiple elements, like
>"--mode tunnel --tunnel-src 1.2.3.4/32 --next --mode transform". I'll
>fix up the userspace part to reject this incorrect use.

Ok, my fault sorry. Here is my corrected (I hope) iptables rules:

iptables -P FORWARD DROP
iptables -F

iptables -A FORWARD -m policy --dir out --pol ipsec --mode tunnel 
--tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 -j DROP
iptables -A FORWARD -m policy --dir in  --pol ipsec  --mode tunnel 
--tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 -j DROP

iptables -A FORWARD -m policy --dir in --pol ipsec --mode tunnel 
--tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 -j DROP
iptables -A FORWARD -m policy --dir out  --pol ipsec  --mode tunnel 
--tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 -j DROP


iptables -A FORWARD -s 10.1.2.0/24 -d 10.1.1.10/24 -j ACCEPT
iptables -A FORWARD -d 10.1.2.0/24 -s 10.1.1.10/24 -j ACCEPT

iptables -L -v output:

root@Calimero:/tmp/RACOON# iptables -L -v
Chain INPUT (policy ACCEPT 11574 packets, 2434K bytes)
pkts bytes target     prot opt in     out     source               
destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               
destination
    0     0 DROP       all  --  any    any     anywhere             anywhere 
            policy match dir out pol ipsec mode tunnel tunnel-dst 
10.1.1.0/24 tunnel-src 10.1.2.0/24
    0     0 DROP       all  --  any    any     anywhere             anywhere 
            policy match dir in pol ipsec mode tunnel tunnel-dst 10.1.2.0/24 
tunnel-src 10.1.1.0/24
    0     0 DROP       all  --  any    any     anywhere             anywhere 
            policy match dir in pol ipsec mode tunnel tunnel-dst 10.1.1.0/24 
tunnel-src 10.1.2.0/24
    0     0 DROP       all  --  any    any     anywhere             anywhere 
            policy match dir out pol ipsec mode tunnel tunnel-dst 
10.1.2.0/24 tunnel-src 10.1.1.0/24
1074 64440 ACCEPT     all  --  any    any     10.1.2.0/24          
10.1.1.0/24
1074 64440 ACCEPT     all  --  any    any     10.1.1.0/24          
10.1.2.0/24

Chain OUTPUT (policy ACCEPT 5983 packets, 933K bytes)
pkts bytes target     prot opt in     out     source               
destination

Ipsec policy match are never matched: I can ping-pong from-to both sites.
I'm not understand what is wrong.

Re: new iptables policy match

[Patrick McHardy]

Marco Berizzi wrote:

> Ok, my fault sorry. Here is my corrected (I hope) iptables rules:
> 
> iptables -P FORWARD DROP
> iptables -F
> 
> iptables -A FORWARD -m policy --dir out --pol ipsec --mode tunnel 
> --tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 -j DROP
> iptables -A FORWARD -m policy --dir in  --pol ipsec  --mode tunnel 
> --tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 -j DROP
> 
> iptables -A FORWARD -m policy --dir in --pol ipsec --mode tunnel 
> --tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 -j DROP
> iptables -A FORWARD -m policy --dir out  --pol ipsec  --mode tunnel 
> --tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 -j DROP
> 
> 
> iptables -A FORWARD -s 10.1.2.0/24 -d 10.1.1.10/24 -j ACCEPT
> iptables -A FORWARD -d 10.1.2.0/24 -s 10.1.1.10/24 -j ACCEPT
> 
> iptables -L -v output:
> 
> root@Calimero:/tmp/RACOON# iptables -L -v
> Chain INPUT (policy ACCEPT 11574 packets, 2434K bytes)
> pkts bytes target     prot opt in     out     source               
> destination
> 
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source               
> destination
>    0     0 DROP       all  --  any    any     anywhere             
> anywhere            policy match dir out pol ipsec mode tunnel 
> tunnel-dst 10.1.1.0/24 tunnel-src 10.1.2.0/24
>    0     0 DROP       all  --  any    any     anywhere             
> anywhere            policy match dir in pol ipsec mode tunnel tunnel-dst 
> 10.1.2.0/24 tunnel-src 10.1.1.0/24
>    0     0 DROP       all  --  any    any     anywhere             
> anywhere            policy match dir in pol ipsec mode tunnel tunnel-dst 
> 10.1.1.0/24 tunnel-src 10.1.2.0/24
>    0     0 DROP       all  --  any    any     anywhere             
> anywhere            policy match dir out pol ipsec mode tunnel 
> tunnel-dst 10.1.2.0/24 tunnel-src 10.1.1.0/24
> 1074 64440 ACCEPT     all  --  any    any     10.1.2.0/24          
> 10.1.1.0/24
> 1074 64440 ACCEPT     all  --  any    any     10.1.1.0/24          
> 10.1.2.0/24
> 
> Chain OUTPUT (policy ACCEPT 5983 packets, 933K bytes)
> pkts bytes target     prot opt in     out     source               
> destination
> 
> Ipsec policy match are never matched: I can ping-pong from-to both sites.
> I'm not understand what is wrong.

What does "ip xfrm policy" show?

Re: new iptables policy match

[Marco Berizzi]

Patrick McHardy wrote:

>Marco Berizzi wrote:
>
>>Ok, my fault sorry. Here is my corrected (I hope) iptables rules:
>>
>>iptables -P FORWARD DROP
>>iptables -F
>>
>>iptables -A FORWARD -m policy --dir out --pol ipsec --mode tunnel 
>>--tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 -j DROP
>>iptables -A FORWARD -m policy --dir in  --pol ipsec  --mode tunnel 
>>--tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 -j DROP
>>
>>iptables -A FORWARD -m policy --dir in --pol ipsec --mode tunnel 
>>--tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 -j DROP
>>iptables -A FORWARD -m policy --dir out  --pol ipsec  --mode tunnel 
>>--tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 -j DROP
>>
>>
>>iptables -A FORWARD -s 10.1.2.0/24 -d 10.1.1.10/24 -j ACCEPT
>>iptables -A FORWARD -d 10.1.2.0/24 -s 10.1.1.10/24 -j ACCEPT
>>
>>iptables -L -v output:
>>
>>root@Calimero:/tmp/RACOON# iptables -L -v
>>Chain INPUT (policy ACCEPT 11574 packets, 2434K bytes)
>>pkts bytes target     prot opt in     out     source               
>>destination
>>
>>Chain FORWARD (policy DROP 0 packets, 0 bytes)
>>pkts bytes target     prot opt in     out     source               
>>destination
>>    0     0 DROP       all  --  any    any     anywhere             
>>anywhere            policy match dir out pol ipsec mode tunnel tunnel-dst 
>>10.1.1.0/24 tunnel-src 10.1.2.0/24
>>    0     0 DROP       all  --  any    any     anywhere             
>>anywhere            policy match dir in pol ipsec mode tunnel tunnel-dst 
>>10.1.2.0/24 tunnel-src 10.1.1.0/24
>>    0     0 DROP       all  --  any    any     anywhere             
>>anywhere            policy match dir in pol ipsec mode tunnel tunnel-dst 
>>10.1.1.0/24 tunnel-src 10.1.2.0/24
>>    0     0 DROP       all  --  any    any     anywhere             
>>anywhere            policy match dir out pol ipsec mode tunnel tunnel-dst 
>>10.1.2.0/24 tunnel-src 10.1.1.0/24
>>1074 64440 ACCEPT     all  --  any    any     10.1.2.0/24          
>>10.1.1.0/24
>>1074 64440 ACCEPT     all  --  any    any     10.1.1.0/24          
>>10.1.2.0/24
>>
>>Chain OUTPUT (policy ACCEPT 5983 packets, 933K bytes)
>>pkts bytes target     prot opt in     out     source               
>>destination
>>
>>Ipsec policy match are never matched: I can ping-pong from-to both sites.
>>I'm not understand what is wrong.
>
>What does "ip xfrm policy" show?

root@Calimero:/usr/src/linux-2.6.15/net/ipv4/netfilter# ip xfrm policy
src 10.1.1.0/24 dst 10.1.2.0/24
        dir in priority 2344
        tmpl src 172.16.1.226 dst 172.16.1.247
                proto comp reqid 16386 mode tunnel
                level use
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16385 mode transport
src 10.1.2.0/24 dst 10.1.1.0/24
        dir out priority 2344
        tmpl src 172.16.1.247 dst 172.16.1.226
                proto comp reqid 16386 mode tunnel
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16385 mode transport
src 10.1.1.0/24 dst 10.1.2.0/24
        dir fwd priority 2344
        tmpl src 172.16.1.226 dst 172.16.1.247
                proto comp reqid 16386 mode tunnel
                level use
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16385 mode transport
src 0.0.0.0/0 dst 0.0.0.0/0
        dir in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        dir in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        dir in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        dir out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        dir out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        dir out priority 0

Re: new iptables policy match

[Patrick McHardy]

Marco Berizzi wrote:
> 
> Patrick McHardy wrote:
> 
>> Marco Berizzi wrote:
>>
>>> Ok, my fault sorry. Here is my corrected (I hope) iptables rules:
>>>
>>> iptables -P FORWARD DROP
>>> iptables -F
>>>
>>> iptables -A FORWARD -m policy --dir out --pol ipsec --mode tunnel 
>>> --tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 -j DROP
>>> iptables -A FORWARD -m policy --dir in  --pol ipsec  --mode tunnel 
>>> --tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 -j DROP
>>>
>>> iptables -A FORWARD -m policy --dir in --pol ipsec --mode tunnel 
>>> --tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 -j DROP
>>> iptables -A FORWARD -m policy --dir out  --pol ipsec  --mode tunnel 
>>> --tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 -j DROP
>>>
> root@Calimero:/usr/src/linux-2.6.15/net/ipv4/netfilter# ip xfrm policy
> src 10.1.1.0/24 dst 10.1.2.0/24
>        dir in priority 2344
>        tmpl src 172.16.1.226 dst 172.16.1.247

These are the addresses you need to use for --tunnel-src/dst, not the
outer addresses. Those can be match with -s and -d are usual.

Re: new iptables policy match

[Marco Berizzi]

Patrick McHardy wrote:

>Marco Berizzi wrote:
>>
>>Patrick McHardy wrote:
>>
>>>Marco Berizzi wrote:
>>>
>>>>Ok, my fault sorry. Here is my corrected (I hope) iptables rules:
>>>>
>>>>iptables -P FORWARD DROP
>>>>iptables -F
>>>>
>>>>iptables -A FORWARD -m policy --dir out --pol ipsec --mode tunnel 
>>>>--tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 -j DROP
>>>>iptables -A FORWARD -m policy --dir in  --pol ipsec  --mode tunnel 
>>>>--tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 -j DROP
>>>>
>>>>iptables -A FORWARD -m policy --dir in --pol ipsec --mode tunnel 
>>>>--tunnel-src 10.1.2.0/24 --tunnel-dst 10.1.1.0/24 -j DROP
>>>>iptables -A FORWARD -m policy --dir out  --pol ipsec  --mode tunnel 
>>>>--tunnel-dst 10.1.2.0/24 --tunnel-src 10.1.1.0/24 -j DROP
>>>>
>>root@Calimero:/usr/src/linux-2.6.15/net/ipv4/netfilter# ip xfrm policy
>>src 10.1.1.0/24 dst 10.1.2.0/24
>>        dir in priority 2344
>>        tmpl src 172.16.1.226 dst 172.16.1.247
>
>These are the addresses you need to use for --tunnel-src/dst, not the
>outer addresses. Those can be match with -s and -d are usual.

Aha! ;-)) It's working. Thanks a lot. Perhaps _IMHO_ this should be
clarified in iptables man page. After all --tunnel-src/dst are the two
IPsec endpoint addresses. Right?

Thanks again and sorry for wasting your time.
Ciao.

PS: I'm compiling right now 2.6.15-git8 with your latest patch: Check
policy length in policy match strict mode.

Re: new iptables policy match

[Patrick McHardy]

Marco Berizzi wrote:
> 
> Patrick McHardy wrote:
> 
>> These are the addresses you need to use for --tunnel-src/dst, not the
>> outer addresses. Those can be match with -s and -d are usual.
> 
> 
> Aha! ;-)) It's working. Thanks a lot. Perhaps _IMHO_ this should be
> clarified in iptables man page. After all --tunnel-src/dst are the two
> IPsec endpoint addresses. Right?

Yes. I don't see how it could be made any clearer, but feel free to
send a suggestion :)

        --tunnel-src addr[/mask]
               Matches the source address of a tunnel. Only valid with 
--mode tunnel.

        --tunnel-dst addr[/mask]
               Matches the destination address of a tunnel. Only valid 
with --mode tunnel.

Re: new iptables policy match

[Marco Berizzi]

Patrick McHardy wrote:

>Marco Berizzi wrote:
>>
>>Patrick McHardy wrote:
>>
>>>These are the addresses you need to use for --tunnel-src/dst, not the
>>>outer addresses. Those can be match with -s and -d are usual.
>>
>>
>>Aha! ;-)) It's working. Thanks a lot. Perhaps _IMHO_ this should be
>>clarified in iptables man page. After all --tunnel-src/dst are the two
>>IPsec endpoint addresses. Right?
>
>Yes. I don't see how it could be made any clearer, but feel free to
>send a suggestion :)
>
>        --tunnel-src addr[/mask]
>               Matches the source address of a tunnel. Only valid with 
>--mode tunnel.
>
>        --tunnel-dst addr[/mask]
>               Matches the destination address of a tunnel. Only valid with 
>--mode tunnel.

Ok. Here is my suggestion:

--tunnel-src addr[/mask]
matches the source end-point address of the SA. Only valid
with --mode tunnel

--tunnel-dst addr[/mask]
matches the destination end-point address of the SA. Only valid
with --mode tunnel

Re: new iptables policy match

[Patrick McHardy]

Marco Berizzi wrote:
> Ok. Here is my suggestion:
> 
> --tunnel-src addr[/mask]
> matches the source end-point address of the SA. Only valid
> with --mode tunnel
> 
> --tunnel-dst addr[/mask]
> matches the destination end-point address of the SA. Only valid
> with --mode tunnel

Thanks, I've updated the man-page.

RE: new iptables policy match

[Greg Scott]

Just to be completely anal because I'm just a skinny 
bald guy from Minnesota - is this ASCII art right?
If this is right, maybe this would make the man page
even clearer.  Of course, if it's wrong, that means
I still don't get it.


LAN    FW   Internet   FW    LAN
<----+----+----------+----+----->
     |    |          |    |
Private  Public   Public  Private
    IP    IP        IP     IP

 Tunnel   SA        SA   Tunnel
 endpoint                endpoint


- Greg Scott


-----Original Message-----
From: netfilter-devel-bounces@lists.netfilter.org
[mailto:netfilter-devel-bounces@lists.netfilter.org] On Behalf Of
Patrick McHardy
Sent: Thursday, January 12, 2006 10:31 AM
To: Marco Berizzi
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: new iptables policy match


Marco Berizzi wrote:
> Ok. Here is my suggestion:
> 
> --tunnel-src addr[/mask]
> matches the source end-point address of the SA. Only valid with --mode

> tunnel
> 
> --tunnel-dst addr[/mask]
> matches the destination end-point address of the SA. Only valid with 
> --mode tunnel

Thanks, I've updated the man-page.

Re: new iptables policy match

[Patrick McHardy]

Greg Scott wrote:
> Just to be completely anal because I'm just a skinny 
> bald guy from Minnesota - is this ASCII art right?
> If this is right, maybe this would make the man page
> even clearer.  Of course, if it's wrong, that means
> I still don't get it.
> 
> 
> LAN    FW   Internet   FW    LAN
> <----+----+----------+----+----->
>      |    |          |    |
> Private  Public   Public  Private
>     IP    IP        IP     IP
> 
>  Tunnel   SA        SA   Tunnel
>  endpoint                endpoint

No, the tunnel endpoints are the hosts using the tunnel-mode SA,
so in this case both firewalls.

RE: new iptables policy match

[Greg Scott]

> No, the tunnel endpoints are the hosts using the 
> tunnel-mode SA, so in this case both firewalls.

OK, so now I'm confused.  And admittedly, IPSEC has made
me crazy for several years.  Which NICs on the firewalls
are the endpoints?  Is this picture better and more accurate?


  LAN             Internet             LAN
 <----+--FW---+-------------+--FW---+----->
      |       |             |       |
NIC with  NIC with      NIC with  NIC with
private    public        public   private
  IP        IP <---------> IP       IP
                   SA
          Tunnel          Tunnel
         endpoint        endpoint

So the public NICs are the tunnel endpoints?

- Greg



-----Original Message-----
From: Patrick McHardy [mailto:kaber@trash.net] 
Sent: Friday, January 13, 2006 1:02 AM
To: Greg Scott
Cc: Marco Berizzi; netfilter-devel@lists.netfilter.org
Subject: Re: new iptables policy match


Greg Scott wrote:
> Just to be completely anal because I'm just a skinny
> bald guy from Minnesota - is this ASCII art right?
> If this is right, maybe this would make the man page
> even clearer.  Of course, if it's wrong, that means
> I still don't get it.
> 
> 
> LAN    FW   Internet   FW    LAN
> <----+----+----------+----+----->
>      |    |          |    |
> Private  Public   Public  Private
>     IP    IP        IP     IP
> 
>  Tunnel   SA        SA   Tunnel
>  endpoint                endpoint

No, the tunnel endpoints are the hosts using the tunnel-mode SA, so in
this case both firewalls.

Re: new iptables policy match

[Patrick McHardy]

Greg Scott wrote:
>>No, the tunnel endpoints are the hosts using the 
>>tunnel-mode SA, so in this case both firewalls.
> 
> 
> OK, so now I'm confused.  And admittedly, IPSEC has made
> me crazy for several years.  Which NICs on the firewalls
> are the endpoints?  Is this picture better and more accurate?
> 
> 
>   LAN             Internet             LAN
>  <----+--FW---+-------------+--FW---+----->
>       |       |             |       |
> NIC with  NIC with      NIC with  NIC with
> private    public        public   private
>   IP        IP <---------> IP       IP
>                    SA
>           Tunnel          Tunnel
>          endpoint        endpoint
> 
> So the public NICs are the tunnel endpoints?

Yes. Its very simple, the endpoints are the addresses you specify
in the policy in the tunnel section (x.x.x.x and y.y.y.y):

spdadd net/mask net/mask any ipsec out
	tunnel/x.x.x.x-y.y.y.y/require;

Re: new iptables policy match

[Tom Eastep]

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

On Thursday 12 January 2006 00:43, Patrick McHardy wrote:

>
> Yes, --next is needed only if your policy has multiple elements, like
> "--mode tunnel --tunnel-src 1.2.3.4/32 --next --mode transform". I'll
> fix up the userspace part to reject this incorrect use.

The second of those patches (Revision 6395 -- Move empty policy element check 
to also catch last element) has broken compatibility with previous versions 
of policy match.

Previously, the following command succeeded and matched any traffic that is to 
be subsequently transformed:

gw:~ # iptables -A foo -m policy --pol ipsec --dir out -j ACCEPT
iptables v1.3.4: policy match: empty policy element
Try `iptables -h' or 'iptables --help' for more information.
gw:~ #

Is this incompatibility intentional? If so, I need to change Shorewall 
accordingly. 

Thanks,
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

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

Re: new iptables policy match

[Patrick McHardy]

Tom Eastep wrote:
> On Thursday 12 January 2006 00:43, Patrick McHardy wrote:
> 
> 
>>Yes, --next is needed only if your policy has multiple elements, like
>>"--mode tunnel --tunnel-src 1.2.3.4/32 --next --mode transform". I'll
>>fix up the userspace part to reject this incorrect use.
> 
> 
> The second of those patches (Revision 6395 -- Move empty policy element check 
> to also catch last element) has broken compatibility with previous versions 
> of policy match.
> 
> Previously, the following command succeeded and matched any traffic that is to 
> be subsequently transformed:
> 
> gw:~ # iptables -A foo -m policy --pol ipsec --dir out -j ACCEPT
> iptables v1.3.4: policy match: empty policy element
> Try `iptables -h' or 'iptables --help' for more information.
> gw:~ #
> 
> Is this incompatibility intentional? If so, I need to change Shorewall 
> accordingly. 

Its a bug, thanks for catching this. I've fixed it up in SVN.