Project

General

Profile

Issue #2231

Cannot create IPv4-via-IPv6 tunnel

Added by Thomas S about 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
kernel
Affected version:
5.2.1
Resolution:
No change required

Description

Hello!

Using the test scenario "net2net-ip4-in-ip6-ikev2" (https://www.strongswan.org/testresults.html) I configured two machines. One is configured as responder, the other as initiator (auto=add vs. auto=start). Other than that, the conf files are pretty much the same (left/right switched around, of course.

Upon starting strongSwan on the initiator it starts the connection fine and establishes phases 1 and 2, but when trying to add the route to the kernel I receive the following error:

Jan 24 17:37:29 initiator ipsec[18930]: 13[KNL] adding SAD entry with SPI 209f6d4c and reqid {1}  (mark 0/0x00000000)
Jan 24 17:37:29 initiator ipsec[18930]: 13[KNL]   using encryption algorithm AES_CBC with key size 256
Jan 24 17:37:29 initiator ipsec[18930]: 13[KNL]   using integrity algorithm HMAC_SHA1_96 with key size 160
Jan 24 17:37:29 initiator ipsec[18930]: 13[KNL]   using replay window of 32 packets
Jan 24 17:37:29 initiator ipsec[18930]: 13[KNL] *received netlink error: Invalid argument (22)*

These plugins have been loaded:

charon aes rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc hmac attr kernel-netlink resolve socket-default stroke updown

And this is the output of `lsmod`:

Module                  Size  Used by
sha1_generic            2337  0 
sha1_arm_neon           6403  0 
sha1_arm                3660  1 sha1_arm_neon
sha256_generic          9327  0 
hmac                    2959  0 
deflate                 1845  0 
zlib_deflate           20226  1 deflate
xfrm6_mode_tunnel       1697  0 
xfrm4_mode_tunnel       1825  0 
ip_tunnel              13258  0 
esp6                    6158  0 
ah6                     5700  0 
binfmt_misc             6388  1 
xfrm4_tunnel            1914  0 
tunnel4                 2310  1 xfrm4_tunnel
ipcomp                  2148  0 
xfrm_ipcomp             3942  1 ipcomp
esp4                    6682  0 
ah4                     5858  0 
af_key                 27668  0 
bnep                   10340  2 
hci_uart               17943  1 
btbcm                   5929  1 hci_uart
bluetooth             326105  22 bnep,btbcm,hci_uart
ftdi_sio               31321  1 
brcmfmac              186403  0 
brcmutil                5661  1 brcmfmac
cfg80211              428431  1 brcmfmac
rfkill                 16037  4 cfg80211,bluetooth
snd_bcm2835            20447  0 
snd_pcm                75762  1 snd_bcm2835
snd_timer              19288  1 snd_pcm
bcm2835_wdt             3225  0 
bcm2835_gpiomem         3040  0 
snd                    51908  3 snd_bcm2835,snd_timer,snd_pcm
ch341                   4932  2 
usbserial              22115  8 ch341,ftdi_sio
uio_pdrv_genirq         3164  0 
uio                     8000  1 uio_pdrv_genirq
ipv6                  347594  78 ah6,esp6,xfrm6_mode_tunnel

The used configuration is based on this (auto=start/add and left/right depending on responder/initiator):

conn net-net
    also=host-host
    leftsubnet=10.0.1.0/24
    rightsubnet=192.168.1.0/24

conn host-host
    keyexchange=ikev2
    mobike=no
    left=<local IPv6 address>
    leftid=@left
    leftfirewall=yes
    right=<remote IPv6 address>
    rightid=@right
    auto=start
    esp=aes256-sha256-modp2048!
    ike=aes256-sha256-modp2048!
    leftauth=psk
    rightauth=psk
    dpdaction=clear
    dpddelay=300s

I've been trying to find the reason for the "Invalid Argument" error, but my knowledge in this area is not enough to dig deep into the source code.

What could be the reason for the "Invalid Argument (22)" error caused?

Related issues

Related to Issue #939: UDP Encapsulation for IPv6 Traffic on LinuxClosed

History

#1 Updated by Noel Kuntze about 6 years ago

I guess you need the tunnel6 module as well.

#2 Updated by Thomas S about 6 years ago

I added 

tunnel6
and 
xfrm_tunnel6
but still receive the same error. I would try using 
kernel-libipsec
, but the system package (Debian Jessie) is compiled without and I have some trouble starting a self-compiled instance (hangs an loading feature RNG_WEAK ...).

Any other ideas?

#3 Updated by Noel Kuntze about 6 years ago

Well, does IPv4 in Ipv4 work and IPv6 in IPv6?

I have a working setup with the following modules:

#4 Updated by Thomas S about 6 years ago

IPv6 in IPv6 results in the same "Invalid Argument" error from netlink. IPv4 in IPv4 can't be tested in this case because the machines have just IPv6 WAN connections (hence the wish for an IPv4 tunnel through IPv6).

#5 Updated by Thomas S about 6 years ago

Recompiled with --enable-kernel-libipsec and the routes are added without problems.

What could be the problem when using strongSwan without the kernel-libipsec plugin?

#6 Updated by Tobias Brunner about 6 years ago

  • Category changed from kernel-interface to kernel
  • Status changed from New to Feedback

What could be the problem when using strongSwan without the kernel-libipsec plugin?

Missing modules (could also be crypto modules). Did you compare your output of lsmod with that of Noel?

#7 Updated by Thomas S about 6 years ago

Yes, compared and modprobe'd the missing modules (except for things like cdrom). Still the same error.

Is there any way to get more details out of what is happening there? There must be a way to get a more detailed reason as for why the error Invalid Argument (22) is returned.

#8 Updated by Tobias Brunner about 6 years ago

Is there any way to get more details out of what is happening there?

No.

There must be a way to get a more detailed reason as for why the error Invalid Argument (22) is returned.

Unless you are willing to modify the kernel sources and recompile it there isn't.

Can you establish the IPv6-only host-to-host connection? Since the installation of the SAs is exactly the same in both cases, and the negotiated algorithms are probably the same, that should fail too (that IPv4 is tunneled and not IPv6 only comes into play when installing the policies).

#9 Updated by Thomas S about 6 years ago

The IPv6 connections cannot be established, either. Does that mean that there are probably crypto modules missing from the kernel?

Here is cat /proc/crypto | grep aes:

name         : rfc3686(ctr(aes))
driver       : rfc3686(ctr(aes-generic))
name         : ctr(aes)
driver       : ctr(aes-generic)
name         : ctr(aes)
driver       : ctr(aes-generic)
name         : cbc(aes)
driver       : cbc(aes-generic)
name         : aes
driver       : aes-generic

And this is cat /proc/crypto | grep sha256:

driver       : drbg_nopr_hmac_sha256
driver       : drbg_pr_hmac_sha256
name         : hmac(sha256)
driver       : hmac(sha256-generic)
module       : sha256_generic
name         : sha256
driver       : sha256-generic
module       : sha256_generic

From what I have gathered everything looks fine ...

#10 Updated by Tobias Brunner about 6 years ago

And this is cat /proc/crypto | grep sha256:

Actually, you need to look for sha1 as that's what the daemon tries to install, according to the log you posted. Otherwise, change your config so that the proposal string in ike/esp end with ! (see ConnSection).

#11 Updated by Thomas S about 6 years ago

That looks okay, too.

Running cat /proc/crypto | grep sha1 yields:

driver       : drbg_nopr_hmac_sha1
driver       : drbg_pr_hmac_sha1
name         : hmac(sha1)
driver       : hmac(sha1-neon)
name         : sha1
driver       : sha1-generic
module       : sha1_generic
name         : sha1
driver       : sha1-neon
module       : sha1_arm_neon
name         : sha1
driver       : sha1-asm
module       : sha1_arm

#12 Updated by Tobias Brunner about 6 years ago

Is the config you posted complete or are there settings in conn %default? What kernel version do you use? What strongSwan version? Is there an IPv6 NAT between the hosts or does the peer perhaps force UDP encapsulation (more of the log might help)?

#13 Updated by Thomas S about 6 years ago

There is no default section, uname -r produces 4.4.38-v7+ and yes, UDP encapsulation is forced by the responder.

#14 Updated by Thomas S about 6 years ago

The information above are based on a Raspberry Pi 3 running Raspbian, but I can reproduce these issues on a Ubiquity EdgeMax router as well.

#15 Updated by Tobias Brunner about 6 years ago

and yes, UDP encapsulation is forced by the responder.

Then this won't work. The Linux kernel currently doesn't support UDP encapsulation for IPv6.

#16 Updated by Tobias Brunner about 6 years ago

  • Related to Issue #939: UDP Encapsulation for IPv6 Traffic on Linux added

#17 Updated by Thomas S about 6 years ago

Ahhhh, okay. Thanks for the answer.

#18 Updated by Noel Kuntze almost 6 years ago

  • Status changed from Feedback to Closed
  • Resolution set to No change required

Also available in: Atom PDF