Hello all,
for years we have used the following manual IPsec rules to decrypt broadcast
(all host multicast) messages:
===== snip ===========
#!/bin/bash
IP6ANYADDR=::/0
IP6BCAST=ff0e::1
KEY="0x7bef6ecaf06d29ef55b24aca6e19964b332e02e75be676a3"
IFNAME=lan1
IP6ADDR=fd01:1b10:1000::1
PREFIX6=64
SPI=0x1
ip link set dev ${IFNAME} up
ip addr add ${IP6ADDR}/${PREFIX6} dev ${IFNAME}
echo "flush; add ${IP6ADDR} ${IP6BCAST} esp ${SPI} -m tunnel -E aes-cbc
${KEY};" | setkey -c
echo "spdflush; spdadd ${IP6ANYADDR} ${IP6BCAST} any -P in ipsec
esp/tunnel/${IP6ADDR}-${IP6BCAST}/require;" | setkey -c
====================
The corresponding encryption rules still work perfectly fine:
===== snip ===========
#!/bin/bash
IP6ANYADDR=::/0
IP6BCAST=ff0e::1
KEY="0x7bef6ecaf06d29ef55b24aca6e19964b332e02e75be676a3"
IFNAME=lan1
IP6ADDR=fd01:1b10:1000::2
PREFIX6=64
SPI=0x1
ip link set dev ${IFNAME} up
ip addr add ${IP6ADDR}/${PREFIX6} dev ${IFNAME}
echo "flush; add ${IP6ADDR} ${IP6BCAST} esp ${SPI} -m tunnel -E aes-cbc
${KEY};" | setkey -c
echo "spdflush; spdadd ${IP6ANYADDR} ${IP6BCAST} any -P in ipsec
esp/tunnel/${IP6ADDR}-${IP6BCAST}/require;" | setkey -c
echo "spdadd ${IP6ANYADDR} ${IP6BCAST} any -P out ipsec
esp/tunnel/${IP6ADDR}-${IP6BCAST}/require;" | setkey -c
====================
Using "ping6 -I lan1 ff0e::1" I see outgoing ESP packets on the second host
(e.g. with fd01:1b10:1000::2) with both, 2.6.23 and 3.6.18:
14:40:36.398471 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d4),
length 136
14:40:37.398533 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d5),
length 136
14:40:38.398596 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d6),
length 136
14:40:39.398658 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d7),
length 136
14:40:40.398721 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d8),
length 136
14:40:41.398783 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5d9),
length 136
14:40:42.398846 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x5da),
length 136
On the receiving side (e.g. fd01:1b10:1000::1) I see the decrypted packets with
the 2.6.23 kernel:
18:17:58.517791 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x62c),
length 136
18:17:58.517791 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 119,
length 64
18:17:59.517836 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x62d),
length 136
18:17:59.517836 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 120,
length 64
18:18:00.517880 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x62e),
length 136
18:18:00.517880 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 121,
length 64
18:18:01.518734 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x62f),
length 136
18:18:01.518734 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 122,
length 64
18:18:02.518763 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x630),
length 136
18:18:02.518763 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 123,
length 64
18:18:03.518790 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x631),
length 136
18:18:03.518790 IP6 fd01:1b10:1000::2 > ff0e::1: ICMP6, echo request, seq 124,
length 64
but NOT with the newer kernel:
16:32:19.980862 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x98e),
length 136
16:32:20.980925 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x98f),
length 136
16:32:21.980987 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x990),
length 136
16:32:22.981050 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x991),
length 136
16:32:23.981112 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x992),
length 136
16:32:24.981175 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x993),
length 136
16:32:25.981237 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x994),
length 136
16:32:26.981300 IP6 fd01:1b10:1000::2 > ff0e::1: ESP(spi=0x00000001,seq=0x995),
length 136
BTW, the equivalent IPv4 IPsec rules (basically 255.255.255.255 as broadcast
and 0.0.0.0/0 as any address works fine with both, 2.6.23 and 3.6.18.
Since my application depends on this, I'm kind of stuck. Is this a known
problem with a fix in a later kernel?
Thanks in advance and kind regards
Joerg
________________________________
Industrieanlagen-Betriebsgesellschaft mbH
Sitz der Gesellschaft: Ottobrunn, Registergericht: Amtsgericht München, HRB 5499
Geschäftsführung: Prof. Dr.-Ing. Rudolf F. Schwarz
Vorsitzender des Aufsichtsrats: RA Engelbert Kupka MdL a.D.
