[Openswan Users] Strongswan 4.4.1 kernel-netlink problem?

Ed Spick es at soas.ac.uk
Wed May 2 10:41:01 EDT 2012


Thought I should reply to my own posting to say that I had chanced upon
a kernel bug previously noted here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629636

Moving to MD5 was the work-around I employed.

all the best

Ed

On 02/05/12 09:44, Ed Spick wrote:
> Hi list,
> 
> I have installed Strongswan 4.4.1 on Debian arm (2.6.32-5-kirkwood) and
> to connect a third party supplier to our network in a site-to-site
> configuration:
> 
> ipsec.d/unit4.conf
> 
> config setup
>     plutodebug=all
>     charonstart=no
> 
> conn %default
>         ikelifetime=8h
>         keylife=1h
>         rekeymargin=3m
>         keyingtries=1
>         keyexchange=ikev1
>         authby=secret
>         ike=aes256-sha1-modp1024
>         esp=aes256-sha1
>         pfs=yes
>         pfsgroup=modp1024
> 
> conn unit4
>         left=212.219.238.26
>         leftsubnet=212.219.139.96/28
>         leftfirewall=yes
>         right=194.73.112.61
>         rightsubnet=172.30.0.8/29
>         auto=start
> 
> strongswan.conf
> 
> pluto {
>   load = sha1 sha2 md5 aes des hmac gmp random kernel-netlink
> }
> 
> libstrongswan {
>   dh_exponent_ansi_x9_42 = no
> }
> 
> On ipsec start I see kernel-netlink failing to load:
> 
> pluto[5588]: plugin 'kernel-netlink' failed to load:
> /usr/lib/ipsec/plugins/libstrongswan-kernel-netlink.so: undefined
> symbol: policy_dir_names
> 
> The tunnel is set up but the problem is that we can send each other ESP
> but the packets don't come of at the other end:
> 
> ipsec statusall
> 000 Status of IKEv1 pluto daemon (strongSwan 4.4.1):
> 000 interface lo/lo ::1:500
> 000 interface bond0/bond0 2001:630:1b:6fff:d8cf:1db8:3126:68b:500
> 000 interface lo/lo 127.0.0.1:500
> 000 interface bond0/bond0 212.219.238.26:500
> 000 interface bond0/bond0 212.219.139.97:500
> 000 %myid = '%any'
> 000 loaded plugins: sha1 sha2 md5 aes des hmac gmp random
> 000 debug options: none
> 000
> 000 "unit4":
> 212.219.139.96/28===212.219.238.26[212.219.238.26]...194.73.112.61[194.73.112.61]===172.30.0.8/29;
> erouted; eroute owner: #2
> 000 "unit4":   ike_life: 28800s; ipsec_life: 3600s; rekey_margin: 180s;
> rekey_fuzz: 100%; keyingtries: 1
> 000 "unit4":   policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio: 28,29;
> interface: bond0;
> 000 "unit4":   newest ISAKMP SA: #1; newest IPsec SA: #2;
> 000 "unit4":   IKE proposal: AES_CBC_256/HMAC_SHA1/MODP_1024
> 000 "unit4":   ESP proposal: AES_CBC_256/HMAC_SHA1/MODP_1024
> 000
> 000 #2: "unit4" STATE_QUICK_I2 (sent QI2, IPsec SA established);
> EVENT_SA_REPLACE in 2965s; newest IPSEC; eroute owner
> 000 #2: "unit4" esp.31f6b9e3 at 194.73.112.61 (180 bytes, 26s ago)
> esp.ce388bef at 212.219.238.26 (0 bytes); tunnel
> 000 #1: "unit4" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE
> in 28084s; newest ISAKMP
> 000
> 
> ip xfrm state
> src 212.219.238.26 dst 194.73.112.61
> 	proto esp spi 0x31f6b9e3 reqid 16385 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth hmac(sha1) 0xd27007615fa9a95732da5462837f1bdb6f0869b1
> 	enc cbc(aes)
> 0x00cc37c0c121c63f7b526c787aa5361353b2c35b0f6c7ffe0cf00efc6a94ed70
> src 194.73.112.61 dst 212.219.238.26
> 	proto esp spi 0xce388bef reqid 16385 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth hmac(sha1) 0x5f6ec976accd3a3804e4a25a87faa008a04ed385
> 	enc cbc(aes)
> 0xbe9be8d335aa27378cfb627c318bdad3f2fa38335ff933497dfb3414ef7bd559
> 
> ip xfrm monitor
> Updated src 194.73.112.61 dst 212.219.238.26
> 	proto esp spi 0xce388bef reqid 16385 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth hmac(sha1) 0x5f6ec976accd3a3804e4a25a87faa008a04ed385
> 	enc cbc(aes)
> 0xbe9be8d335aa27378cfb627c318bdad3f2fa38335ff933497dfb3414ef7bd559
> src 172.30.0.8/29 dst 212.219.139.96/28
> 	dir in priority 2211 ptype main
> 	tmpl src 194.73.112.61 dst 212.219.238.26
> 		proto esp reqid 16385 mode tunnel
> src 172.30.0.8/29 dst 212.219.139.96/28
> 	dir fwd priority 2211 ptype main
> 	tmpl src 194.73.112.61 dst 212.219.238.26
> 		proto esp reqid 16385 mode tunnel
> src 212.219.238.26 dst 194.73.112.61
> 	proto esp spi 0x31f6b9e3 reqid 16385 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth hmac(sha1) 0xd27007615fa9a95732da5462837f1bdb6f0869b1
> 	enc cbc(aes)
> 0x00cc37c0c121c63f7b526c787aa5361353b2c35b0f6c7ffe0cf00efc6a94ed70
> src 212.219.139.96/28 dst 172.30.0.8/29
> 	dir out priority 2211 ptype main
> 	tmpl src 212.219.238.26 dst 194.73.112.61
> 		proto esp reqid 16385 mode tunnel
> Async event  (0x20)  timer expired
> 	src 194.73.112.61 dst 212.219.238.26  reqid 0x4001 protocol esp  SPI
> 0xce388bef
> Async event  (0x20)  timer expired
> 	src 212.219.238.26 dst 194.73.112.61  reqid 0x4001 protocol esp  SPI
> 0x31f6b9e3
> Async event  (0x20)  timer expired
> 	src 212.219.238.26 dst 194.73.112.61  reqid 0x4001 protocol esp  SPI
> 0x31f6b9e3
> Async event  (0x20)  timer expired
> 	src 212.219.238.26 dst 194.73.112.61  reqid 0x4001 protocol esp  SPI
> 0x31f6b9e3
> Async event  (0x20)  timer expired
> 	src 212.219.238.26 dst 194.73.112.61  reqid 0x4001 protocol esp  SPI
> 0x31f6b9e3
> 
> Does kernel-netlink need to be loaded for ipsec routing to complete? we
> have a site-to-site vpn with another supplier on an almost identical
> server and strongswan version which works fine. (only differences are in
> the strongswan.conf - our working server has the same set of algo
> available but nothing being explicitly loaded in its pluto stanza)
> 
> ipsec listall
> 000
> 000 List of registered IKEv1 Algorithms:
> 000
> 000   encryption: 3DES_CBC AES_CBC
> 000   integrity:  HMAC_MD5 HMAC_SHA1 HMAC_SHA2_256 HMAC_SHA2_384
> HMAC_SHA2_512
> 000   dh-group:   MODP_1024 MODP_1536 MODP_2048 MODP_3072 MODP_4096
> MODP_6144 MODP_8192 MODP_1024_160 MODP_2048_224 MODP_2048_256
> 000
> 000 List of registered ESP Algorithms:
> 000
> 000   encryption: DES_CBC 3DES_CBC CAST_CBC BLOWFISH_CBC NULL AES_CBC
> AES_CTR AES_CCM_8 AES_CCM_12 AES_CCM_16 AES_GCM_8 AES_GCM_12 AES_GCM_16
> CAMELLIA_CBC AES_GMAC SERPENT_CBC TWOFISH_CBC
> 000   integrity:  HMAC_MD5 HMAC_SHA1 HMAC_SHA2_256 HMAC_RIPEMD
> AES_XCBC_96 NULL HMAC_SHA2_256_96
> 
> ipsec version
> Linux strongSwan U4.4.1/K2.6.32-5-kirkwood
> 
> Any help very gratefully received.
> 
> Ed Spick
> 
> 
> 
> 
> _______________________________________________
> Users at lists.openswan.org
> https://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFEC12422.asc
Type: application/pgp-keys
Size: 1723 bytes
Desc: not available
URL: <https://lists.openswan.org/pipermail/users/attachments/20120502/f94861ce/attachment-0001.bin>


More information about the Users mailing list