Project

General

Profile

Bug #1091

Wrong kernel policy configuration for ICMP[v6] on big-endian architectures

Added by Alexander Velkov about 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Category:
kernel
Target version:
Start date:
31.08.2015
Due date:
Estimated time:
Affected version:
5.3.2
Resolution:
Fixed

Description

Hi,

I try to configure an IPsec tunnel between two IPv6 peers (both running StrongSwan 5.3.2) in transport mode. I configure passthrough policies in order to get Neighbor Discovery packets to flow freely without being encrypted for ICMP types 135 and 136.

An example passthrough policy for the Neighbor Solicitation messages for ICMP type 135:

ipsec.conf:

conn ike1-ip6
        left=fc00:9999::51
        right=fc00:9999::8
...
conn ike1-ip6-pass1
        type=passthrough
        auto=route
        leftsubnet=fc00:9999::51/128[ipv6-icmp/135]
        rightsubnet=fc00:9999::8/128[ipv6-icmp/135]

The tunnel between both peers is successfully established in case the two peers are running on little-endian architectures. The resulting policies in the kernel differ for little- and big-endian architectures which leads to Neighbor Discovery packets not being passed:

Intel Core i5 Processor - little-endian:

ip -6 xfrm policy

...
src fc00:9999::8/128 dst fc00:9999::51/128 proto ipv6-icmp type 135 code 0 
        dir in priority 1024 
src fc00:9999::51/128 dst fc00:9999::8/128 proto ipv6-icmp type 135 code 0 
        dir out priority 1024 
src fc00:9999::8/128 dst fc00:9999::51/128 proto ipv6-icmp type 135 code 0 
        dir fwd priority 1024
...

X-Scale 425 Processor - arm big-endian:

ip -6 xfrm policy

...
src fc00:9999::51/128 dst fc00:9999::8/128 proto ipv6-icmp type 0 code 135 
        dir fwd priority 512 
src fc00:9999::51/128 dst fc00:9999::8/128 proto ipv6-icmp type 0 code 135 
        dir in priority 512 
src fc00:9999::8/128 dst fc00:9999::51/128 proto ipv6-icmp type 0 code 135 
        dir out priority 512
...

I tried to set the subnets' ports using the alternative configuration for ICMP type and code as stated in the man page for ipsec.conf:

man ipsec.conf:

If the protocol is icmp or ipv6-icmp the port is interpreted as ICMP message type if it is less than 256 
or as type and code if it is greater or equal to 256, with the type in the most significant 8 bits and the code in the least significant 8 bits.

An example passthrough policy for the Neighbor Solicitation messages for ICMP type 135:

ipsec.conf:

conn ike1-ip6
        left=fc00:9999::51
        right=fc00:9999::8
...
conn ike1-ip6-pass1
        type=passthrough
        auto=route
        leftsubnet=fc00:9999::51/128[ipv6-icmp/34560] <-- 135 * 256 = 34560
        rightsubnet=fc00:9999::8/128[ipv6-icmp/34560]

That did not solve the problem and the resulting policies in the kernel were identical to the ones in the previous example above. I think there is a bug in the ICMP type and code calculation on big-endian architectures. What do you think ?

kinfocenter.desktop (6.46 KB) kinfocenter.desktop Alexander Velkov, 31.08.2015 12:15

Associated revisions

Revision 7b20ab0a (diff)
Added by Tobias Brunner about 5 years ago

kernel-netlink: Properly set port mask for ICMP type/code if only set on one side

If only one traffic selector had a port (type/code) the other side had
the port mask set to 0, which canceled out the applied type/code.

It also fixes the installation of ICMP type/code on big-endian hosts.

Fixes #1091.
References #595.

History

#1 Updated by Tobias Brunner about 5 years ago

  • Status changed from New to Feedback

I think there is a bug in the ICMP type and code calculation on big-endian architectures. What do you think ?

Could you please try the code (or just the last four patches, or in particular, just the one updating kernel-netlink) from the 595-shunt-dynamic branch (see #595-4 for details).

#2 Updated by Alexander Velkov about 5 years ago

Could you please try the code (or just the last four patches, or in particular, just the one updating kernel-netlink) from the 595-shunt-dynamic branch (see #595-4 for details).

Hey Tobias,

I applied revision 481c2ffa from the 595-shunt-dynamic branch and that solved the issue.

Configuration on arm:

...
conn ipsectest-ignore$0
        leftsubnet=fd00::18/128[58/34560] or leftsubnet=fd00::18/128[58/135]
        rightsubnet=fd00::4/128[58/34560] or rightsubnet=fd00::4/128[58/135]
        type=passthrough
        auto=route

ends up in ip -6 xfrm policy:

...
src fd00::4/128 dst fd00::18/128 proto ipv6-icmp type 135 
        dir fwd priority 512 
src fd00::4/128 dst fd00::18/128 proto ipv6-icmp type 135 
        dir in priority 512 
src fd00::18/128 dst fd00::4/128 proto ipv6-icmp type 135 
        dir out priority 512

Is this revision going to be integrated in the next release 5.3.3 ?

Thank you very much for the quick reply!

#3 Updated by Tobias Brunner about 5 years ago

  • Tracker changed from Issue to Bug
  • Subject changed from Wrong kernel policy configuration for big-endian architectures to Wrong kernel policy configuration for ICMP[v6] on big-endian architectures
  • Assignee set to Tobias Brunner
  • Target version set to 5.3.3
  • % Done set to 0
  • Resolution set to Fixed

I applied revision 481c2ffa from the 595-shunt-dynamic branch and that solved the issue.

Thanks for testing.

Is this revision going to be integrated in the next release 5.3.3 ?

Yes, I've applied the two kernel plugin fixes from that branch to master.

#4 Updated by Alexander Velkov about 5 years ago

Yes, I've applied the two kernel plugin fixes from that branch to master.

OK, great!

#5 Updated by Tobias Brunner about 5 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF