Ipsec, policy match and PROTO=4

Ipsec, policy match and PROTO=4

[Thomas Heinz]

Hallo guys

I have the following standard ipsec tunnel:

[tun_A] host_A [pub_A]-------------[pub_B] host_B [tun_B]

pub_A/B: public IP of host_A/B
tun_A/B: tunnel IP of host_A/B

After establishing the ipsec connection, putting two simple log-all rules 
in INPUT and OUTPUT like this:
# iptables -I INPUT -j LOG
# iptables -I OUTPUT -j LOG
and pinging tun_B from host_A, I get the following log entries:

IN= OUT=eth0 SRC=tun_A DST=tun_B LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF 
PROTO=ICMP TYPE=8 CODE=0 ID=16181 SEQ=1
IN= OUT=eth0 SRC=pub_A DST=pub_B LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF 
PROTO=ESP SPI=0xxxxxxxxx

Very nice so far: the packet is seen twice, once clear and once encrypted. 
Now, let's look at the ICMP reply.

IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B 
DST=pub_A LEN=136 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=ESP 
SPI=0xxxxxxxxx
IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B 
DST=pub_A LEN=104 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=4

Here, we see the packet also twice but the cleartext one has PROTO=4 
(ipencap, ipip tunnel).

This has been observed in e.g. this thread: 
http://marc.theaimsgroup.com/?l=netfilter-devel&m=114010374229806&w=2

However, I don't see any solution. What is your approach to filter 
cleartext packets? Adding a rule to allow all PROTO=4 packets does not 
count ;-)
Is the issue considered a bug?

Thanks for your support.


Best regards,

Thomas

Re: Ipsec, policy match and PROTO=4

[Marco Berizzi]

Thomas Heinz wrote:


> Hallo guys

Ciao

> I have the following standard ipsec tunnel:
>
> [tun_A] host_A [pub_A]-------------[pub_B] host_B [tun_B]
>
> pub_A/B: public IP of host_A/B
> tun_A/B: tunnel IP of host_A/B
>
> After establishing the ipsec connection, putting two simple log-all
rules
> in INPUT and OUTPUT like this:
> # iptables -I INPUT -j LOG
> # iptables -I OUTPUT -j LOG
> and pinging tun_B from host_A, I get the following log entries:
>
> IN= OUT=eth0 SRC=tun_A DST=tun_B LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0
DF
> PROTO=ICMP TYPE=8 CODE=0 ID=16181 SEQ=1
> IN= OUT=eth0 SRC=pub_A DST=pub_B LEN=136 TOS=0x00 PREC=0x00 TTL=64
ID=0 DF
> PROTO=ESP SPI=0xxxxxxxxx
>
> Very nice so far: the packet is seen twice, once clear and once
encrypted.
> Now, let's look at the ICMP reply.
>
> IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B
> DST=pub_A LEN=136 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=ESP
> SPI=0xxxxxxxxx
> IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B
> DST=pub_A LEN=104 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=4
>
> Here, we see the packet also twice but the cleartext one has PROTO=4
> (ipencap, ipip tunnel).

You aren't seeing the clear text packet
because because you should log also the
FORWARD chain: 'iptables -I FORWARD -j LOG'

> This has been observed in e.g. this thread:
> http://marc.theaimsgroup.com/?l=netfilter-devel&m=114010374229806&w=2
>
> However, I don't see any solution. What is your approach to filter
> cleartext packets?

You must filter packets in the FORWARD
chain, nor INPUT nor OUTPUT

> Is the issue considered a bug?

Yes, the issue in the above thread is a
know bug to the netfilter team.

Re: Ipsec, policy match and PROTO=4

[Thomas Heinz]

Hi Marco

Thanks for your reply.

You wrote:
> You aren't seeing the clear text packet
> because because you should log also the
> FORWARD chain: 'iptables -I FORWARD -j LOG'
>
> > This has been observed in e.g. this thread:
> > http://marc.theaimsgroup.com/?l=netfilter-devel&m=114010374229806&w=2
> >
> > However, I don't see any solution. What is your approach to filter
> > cleartext packets?
>
> You must filter packets in the FORWARD
> chain, nor INPUT nor OUTPUT

The packets do not traverse the FORWARD chain. I just added log rule, 
i.e. 'iptables -I FORWARD -j LOG'. Even after issueing 'iptables -I 
FORWARD -j DROP', the ipsec connection works perfectly (assuming that I 
accept PROTO=4 packets).

BTW, I used 2.6.16 this time since I currently cannot restart the system. 
In fact, I would be surprised to see either the ESP or the cleartext 
packet in FORWARD since both are destined to the local host.

> > Is the issue considered a bug?
>
> Yes, the issue in the above thread is a
> know bug to the netfilter team.

Hm, ok. I wonder how the current state of this issue is and how hard it is 
to fix this bug.


Best regards,

Thomas

Re: Ipsec, policy match and PROTO=4

[Marco Berizzi]

Thomas Heinz wrote:

>Hi Marco
>
>Thanks for your reply.
>
>You wrote:
> > You aren't seeing the clear text packet
> > because because you should log also the
> > FORWARD chain: 'iptables -I FORWARD -j LOG'
> >
> > > This has been observed in e.g. this thread:
> > > http://marc.theaimsgroup.com/?l=netfilter-devel&m=114010374229806&w=2
> > >
> > > However, I don't see any solution. What is your approach to filter
> > > cleartext packets?
> >
> > You must filter packets in the FORWARD
> > chain, nor INPUT nor OUTPUT
>
>The packets do not traverse the FORWARD chain. I just added log rule,
>i.e. 'iptables -I FORWARD -j LOG'. Even after issueing 'iptables -I
>FORWARD -j DROP', the ipsec connection works perfectly (assuming that I
>accept PROTO=4 packets).

Apologies, I misread your post.

>BTW, I used 2.6.16 this time since I currently cannot restart the system.
>In fact, I would be surprised to see either the ESP or the cleartext
>packet in FORWARD since both are destined to the local host.

Yes sure, my fault.

What are you policy for INPUT and OUTPUT chain? ACCEPT or DROP?

Re: Ipsec, policy match and PROTO=4

[Thomas Heinz]

You wrote:
> Apologies, I misread your post.

Ok, no problem :)

> What are you policy for INPUT and OUTPUT chain? ACCEPT or DROP?

DROP but I don't see how the relation to my problem.

I'm probably going to ask on netfilter-devel about the current state of 
this bug.


Best regards,

Thomas

Ipsec, policy match and PROTO=4

[Thomas Heinz]

Hello guys

I have the following standard ipsec tunnel:

[tun_A] host_A [pub_A]-------------[pub_B] host_B [tun_B]

pub_A/B: public IP of host_A/B
tun_A/B: tunnel IP of host_A/B

After establishing the ipsec connection, putting two simple log-all rules 
in INPUT and OUTPUT like this:
# iptables -I INPUT -j LOG
# iptables -I OUTPUT -j LOG
and pinging tun_B from host_A, I get the following log entries:

IN= OUT=eth0 SRC=tun_A DST=tun_B LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF 
PROTO=ICMP TYPE=8 CODE=0 ID=16181 SEQ=1
IN= OUT=eth0 SRC=pub_A DST=pub_B LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF 
PROTO=ESP SPI=0xxxxxxxxx

Very nice so far: the packet is seen twice, once clear and once encrypted. 
Now, let's look at the ICMP reply.

IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B 
DST=pub_A LEN=136 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=ESP 
SPI=0xxxxxxxxx
IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B 
DST=pub_A LEN=104 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=4

Here, we see the packet also twice but the cleartext one has PROTO=4 
(ipencap, ipip tunnel).

This has been observed in e.g. this thread: 
http://marc.theaimsgroup.com/?l=netfilter-devel&m=114010374229806&w=2

Moreover, I have previously sent this posting to the netfilter user mailing 
list.

Could you please tell me about the current state regarding this bug? Is it 
already addressed? Is it hard to fix? 

Is it correct that there is currently no way to filter incoming clear text 
packets? Accepting PROTO=4 packets of course works but it is rather a 
workaround.

Thanks for your support.


Best regards,

Thomas

Re: Ipsec, policy match and PROTO=4

[Thomas Heinz]

Hi

My questions regarding the "ipsec PROTO=4" problem (see below) has not been 
answered yet. I hate to be so impatient but I can imagine that this issue 
concerns quite a number of users. I would greatly appreciate it if someone 
could shortly comment on it.

Thanks a lot.


Best regards,

Thomas


On Thursday 27 July 2006 01:31, I wrote:
> Hello guys
>
> I have the following standard ipsec tunnel:
>
> [tun_A] host_A [pub_A]-------------[pub_B] host_B [tun_B]
>
> pub_A/B: public IP of host_A/B
> tun_A/B: tunnel IP of host_A/B
>
> After establishing the ipsec connection, putting two simple log-all
> rules in INPUT and OUTPUT like this:
> # iptables -I INPUT -j LOG
> # iptables -I OUTPUT -j LOG
> and pinging tun_B from host_A, I get the following log entries:
>
> IN= OUT=eth0 SRC=tun_A DST=tun_B LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0
> DF PROTO=ICMP TYPE=8 CODE=0 ID=16181 SEQ=1
> IN= OUT=eth0 SRC=pub_A DST=pub_B LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=0
> DF PROTO=ESP SPI=0xxxxxxxxx
>
> Very nice so far: the packet is seen twice, once clear and once
> encrypted. Now, let's look at the ICMP reply.
>
> IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B
> DST=pub_A LEN=136 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=ESP
> SPI=0xxxxxxxxx
> IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B
> DST=pub_A LEN=104 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=4
>
> Here, we see the packet also twice but the cleartext one has PROTO=4
> (ipencap, ipip tunnel).
>
> This has been observed in e.g. this thread:
> http://marc.theaimsgroup.com/?l=netfilter-devel&m=114010374229806&w=2
>
> Moreover, I have previously sent this posting to the netfilter user
> mailing list.
>
> Could you please tell me about the current state regarding this bug? Is
> it already addressed? Is it hard to fix?
>
> Is it correct that there is currently no way to filter incoming clear
> text packets? Accepting PROTO=4 packets of course works but it is rather
> a workaround.
>
> Thanks for your support.
>
>
> Best regards,
>
> Thomas

Re: Ipsec, policy match and PROTO=4

[Patrick McHardy]

Thomas Heinz wrote:
> Hello guys
> 
> I have the following standard ipsec tunnel:
> 
> [tun_A] host_A [pub_A]-------------[pub_B] host_B [tun_B]
> 
> pub_A/B: public IP of host_A/B
> tun_A/B: tunnel IP of host_A/B
> 
> After establishing the ipsec connection, putting two simple log-all rules 
> in INPUT and OUTPUT like this:
> # iptables -I INPUT -j LOG
> # iptables -I OUTPUT -j LOG
> and pinging tun_B from host_A, I get the following log entries:
> 
> IN= OUT=eth0 SRC=tun_A DST=tun_B LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF 
> PROTO=ICMP TYPE=8 CODE=0 ID=16181 SEQ=1
> IN= OUT=eth0 SRC=pub_A DST=pub_B LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF 
> PROTO=ESP SPI=0xxxxxxxxx
> 
> Very nice so far: the packet is seen twice, once clear and once encrypted. 
> Now, let's look at the ICMP reply.
> 
> IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B 
> DST=pub_A LEN=136 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=ESP 
> SPI=0xxxxxxxxx
> IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B 
> DST=pub_A LEN=104 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=4
> 
> Here, we see the packet also twice but the cleartext one has PROTO=4 
> (ipencap, ipip tunnel).

The cleartext packet should also be seen with the real protocol after
that. What do your policies look li

Re: Ipsec, policy match and PROTO=4

[Thomas Heinz]

Hi Patrick

Thanks for your reply.

You wrote:
> The cleartext packet should also be seen with the real protocol after
> that.

Oh, you're right. Sorry for being so unobservant.

Is the fact that the packet with PROTO=4 is seen in between the encrypted 
and cleartext packet considered a bug?


Best regards,

Thomas

Re: Ipsec, policy match and PROTO=4

[Patrick McHardy]

Thomas Heinz wrote:
> Is the fact that the packet with PROTO=4 is seen in between the encrypted 
> and cleartext packet considered a bug?

Not sure right now, I need to look into this again.