[strongSwan] IPComp and IPv6 tunneled on IPv4 on Debian

Heiko Wundram modelnine at modelnine.org
Wed Oct 21 23:08:38 CEST 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hey,

Am 21.10.2015 um 15:00 schrieb Tobias Brunner:
> Have a look at the latest two commits in the master branch (in 
> particular [1]).
> 
> Regards, Tobias
> 
> [1]
> https://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=382f8a33

thanks
> 
for that explicit hint, but I added those rules manually
already based on the documentation and it didn't make any difference
(as no packets matched protocol 41 in the IPv6 firewall).

Anyway, what I gather the problem is is the actual policy, which isn't
set up correctly for the IPv6 in IPv4 tunnel:

src 192.168.178.2 dst 46.4.15.36
        proto esp spi 0xc43d3310 reqid 4 mode transport
        replay-window 32
        auth-trunc hmac(sha1) ... 96
        enc cbc(aes) ...
        encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
        sel src 0.0.0.0/0 dst 0.0.0.0/0
src 192.168.178.2 dst 46.4.15.36
        proto comp spi 0x00002275 reqid 4 mode tunnel
        replay-window 0 flag af-unspec
        comp deflate
src 46.4.15.36 dst 192.168.178.2
        proto esp spi 0xccc07fea reqid 4 mode transport
        replay-window 32
        auth-trunc hmac(sha1) ... 96
        enc cbc(aes) ...
        encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
        sel src 0.0.0.0/0 dst 0.0.0.0/0
src 46.4.15.36 dst 192.168.178.2
        proto comp spi 0x00005632 reqid 4 mode tunnel
        replay-window 0 flag af-unspec
        comp deflate

Those are the policies that get set up for the IPv6 in IPv4 tunnel:

     mgmt-v6{4}:  INSTALLED, TUNNEL, reqid 4, ESP in UDP SPIs: x_i x_o
     mgmt-v6{4}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o,
rekeying in 42 minutes
     mgmt-v6{4}:   fd92:2dff:d232:3f::/64 === fd92:2dff:d232::/64

(I took that corresponding grab of the setup _after_ I deactivated
IPCOMP again, so that the corresponding IPCOMP info is no longer
displayed, but it was negotiated between the peers, see the proto comp
tunnels)

Is this a known problem that IPv6 in IPv4 tunnels and IPCOMP don't set
up their policies properly? Or is this possibly a problem with the
Debian 8 default kernel that's in use on the system (some 3.16.x)?

Thanks for any heads up, and for now, I'll leave it off for the
moment. :-)

- -- 
Heiko Wundram.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWJ/7WAAoJEJ/eyTFUqXhdRg4P/RVIClrhLgxiY9611Xs9N+ci
XIM+IL2PriyZMgA/HuTRwWGmOvPheWajPNVCyadqKI9DBzoNAh5fg4Q+xqIO/CeN
dhBRr/bdAQCvqc41h8kPpdjWwBMiuFdkLaPvPCmD7ybG4L53dhRpJS45zHMKmw7q
DF3il73zlSKvFTk4kWXP9tX1tUdZrPyprHDcyX7QB4fHLKJpLcJYY7Tgwgpdp1f4
jwHEEU4znI502GEnueihxgCTwPhWO8nIMM8Ek++XYQ1sdOTwLl/c86I44/+uUBQO
LzwrEcj+VMAYGWpodbcxI7r9YrcQzztbysU5oRJQtDKvxNr6EF45gq1QyKEJxYxd
LV25CvQEPzs2M6yvqL+x53GepsKTWX4U1YAdEDu1hovrXaEGZDUjykn7bCRRvN7x
PLfLa4BA6MHaVlQPJv6uQNYWvVlZEZMmxWHXYO7VePOP6FRG15vZg/yJA4Vk/Ywg
lGrRV4YCF787BoIwp2DKMCy4V42hRKp8HKnhww6J5lsFOZPqk892lMdJCcOhL9QV
kD2gY4fpww88wE5oSx4D7hkAWnt3/gBOXryc/luLrPgyfJhhzageS3h4AHlVNcBv
bduXjv5tuixAq+ht3OSJ68dVb1rUL8FrlHNDJXNkCtL/OkW8uBZO9hdxywLNP/7c
93iL35qouaqRWyWldJGP
=lni3
-----END PGP SIGNATURE-----


More information about the Users mailing list