Project

General

Profile

Bug #123

IKEv2 does not work if both socket-default and socket-raw are loaded

Added by Georg Müller almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Category:
charon
Target version:
Start date:
13.10.2010
Due date:
Estimated time:
Affected version:
4.4.1
Resolution:

Description

Starting an IKEv2 tunnel where both plugins socket-default and socket-raw are loaded fails.

loaded plugins: curl ldap aes des sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem openssl fips-prf xcbc hmac agent gmp attr kernel-netlink
 socket-default socket-raw socket-dynamic farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 nm dhcp resolve

When starting my connection, I get the following output:

initiating IKE_SA home[1] to X.X.X.X
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
sending packet: from 192.168.0.145[500] to X.X.X.X[500]
retransmit 1 of request with message ID 0
sending packet: from 192.168.0.145[500] to X.X.X.X[500]
retransmit 2 of request with message ID 0
sending packet: from 192.168.0.145[500] to X.X.X.X[500]

Running wireshark, I can see that I get a reply for from the server for each packet sent (X.X.X.X), but they are not handled by strongswan.

When removing either libstrongswan-socket-raw.* or libstrongswan-socket-default.* everything works fine, but not if both are available. I could explicitly select the plugins in /etc/strongswan.conf, but I think this is a bug to be fixed.

History

#1 Updated by Georg Müller almost 10 years ago

As an additional note, if both socket-default and socket-raw are loaded, the sockets are opened twice, as netstat shows:

netstat -ulnp | grep charon
udp        0      0 0.0.0.0:68              0.0.0.0:*                           16471/charon    
udp        0      0 0.0.0.0:4500            0.0.0.0:*                           16471/charon    
udp        0      0 0.0.0.0:4500            0.0.0.0:*                           16471/charon    
udp        0      0 0.0.0.0:500             0.0.0.0:*                           16471/charon    
udp        0      0 0.0.0.0:500             0.0.0.0:*                           16471/charon    
udp6       0      0 :::4500                 :::*                                16471/charon    
udp6       0      0 :::4500                 :::*                                16471/charon    
udp6       0      0 :::500                  :::*                                16471/charon    
udp6       0      0 :::500                  :::*                                16471/charon    

#2 Updated by Gerd v. Egidy almost 10 years ago

This is something which hit me too:

The order of loading the plugins is important. Make sure socket-raw is loaded BEFORE socket-default. Then it works.

This is a common problem because to run pluto and charon together and use features only available via netlink (e.g. marks),
you need to load those two plugins. To load them in the right order you have to manually specify the plugins. This is a hassle
and often e.g. distributors get this wrong. All features of strongswan should be available without having to manually mess
with the plugin list. There is a reason the documentation reads "It is not recommended to specify the plugin list manually...".

I already told Andreas about this, I think there should be either
a) a priority logic for automatically loading plugins in the right order
or
b) charon and pluto should detect that both plugins are available and pick the right one

#3 Updated by Tobias Brunner almost 10 years ago

Gerd v. Egidy wrote:

The order of loading the plugins is important. Make sure socket-raw is loaded BEFORE socket-default. Then it works.

That's true.

The problem here is that if both plugins are loaded, only the raw socket actually receives the packets. But because charon, in its current implementation, reads packets only from the first registered socket implementation, loading multiple socket implementations only works if socket-raw is loaded before the other socket implementations.

A bit more technical: Both plugins open and bind UDP sockets on port 500 and 4500, the raw socket does so to easily send packets, but actually receives the packets on a raw socket. Now, it seems that it is the last socket bound to a specific port which receives the packets. Because socket-raw does not actually read from its bound sockets, it does not matter if socket-default binds to the same ports, too. That's the reason why it works when socket-raw is loaded before socket-default, but not the other way around.

This is a common problem because to run pluto and charon together and use features only available via netlink (e.g. marks),
you need to load those two plugins.

No, you only need socket-raw to run pluto and charon together. Are you perhaps confusing the socket plugins with the kernel plugins (kernel-pfkey/kernel-netlink)? Concerning those, it's actually rarely useful to load the kernel-pfkey plugin on a Linux host (it's mainly for BSD based systems).

#4 Updated by Gerd v. Egidy almost 10 years ago

Tobias Brunner wrote:

This is a common problem because to run pluto and charon together and use features only available via netlink (e.g. marks),
you need to load those two plugins.

No, you only need socket-raw to run pluto and charon together. Are you perhaps confusing the socket plugins with the kernel plugins (kernel-pfkey/kernel-netlink)? Concerning those, it's actually rarely useful to load the kernel-pfkey plugin on a Linux host (it's mainly for BSD based systems).

I remember that I had problems with charon when not loading socket-default but using kernel-netlink. But I'm not totally sure that I don't confuse something there.

#5 Updated by Tobias Brunner almost 10 years ago

  • Status changed from New to Resolved
  • Assignee changed from Martin Willi to Tobias Brunner
  • Target version set to 4.5.0

I pushed a fix for this issue to our master: fa20849431

#6 Updated by Andreas Steffen almost 10 years ago

  • Status changed from Resolved to Closed

#7 Updated by Gerd v. Egidy almost 10 years ago

Tobias, thanks for fixing this so quickly. I can confirm that pluto & charon now work together with kernel-netlink and without any manual plugin configuration.

Also available in: Atom PDF