[strongSwan] IKE exchange - strange packets

[Noel Kuntze]

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

Hello Alexey,

Stop trying to debug a black box.
Make charon write a log[1] and find out what it sends and why the other side doesn't like it.
Making that other router write logs, too. That will help you find out the reason.

[1] https://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 12.07.2015 um 13:42 schrieb Alexey GERASIMOV:
>
> Hello all!
>
> We use strongSwan version 4.5.2 for two IPSEC tunnels between Linux and two hardware routers (Router 1 and Router 2 hereinafter). Both tunnels  works perfectly.
>
> We try to reinstall the configuration on the other server using  strongSwan 5.2.1. The first tunnel is established successfully, but the other tinnel (with the same parameters but another hardware router model)  have the trouble during phase2 negotiation. Phase1 is Ok.
>
> I used tcpdump to analyze the packets exchange during tunnel creation and found the next:
>
> 
>
> SS 4.5.2 <-> Router 2
>
> 12:47:29.800834 IP StrongSwan452.isakmp > Router2.isakmp: isakmp: phase 1 I ident
>
> 12:47:29.824558 IP Router2.isakmp > StrongSwan452.isakmp: isakmp: phase 1 R ident
>
> 12:47:29.824902 IP StrongSwan452.isakmp > Router2.isakmp: isakmp: phase 1 I ident
>
> 12:47:29.858313 IP Router2.isakmp > StrongSwan452.isakmp: isakmp: phase 1 R ident
>
> 12:47:29.858618 IP StrongSwan452.isakmp > Router2.isakmp: isakmp: phase 1 I ident[E]
>
> 12:47:29.894223 IP Router2.isakmp > StrongSwan452.isakmp: isakmp: phase 1 R ident[E]
>
> 12:47:29.894573 IP StrongSwan452.isakmp > Router2.isakmp: isakmp: phase 2/others I oakley-quick[E]
>
> 12:47:29.961807 IP Router2.isakmp > StrongSwan452.isakmp: isakmp: phase 2/others R oakley-quick[E]
>
> 12:47:29.988256 IP StrongSwan452.isakmp > Router2.isakmp: isakmp: phase 2/others I oakley-quick[E]
>
> 
>
> Well, it is the standard IKE exchange – 6 packets for  phase 1 and 3 packets for phase2, no questions. I read RFC 2409 and found that it is expected behavior.
>
> 
>
> But SS 5.2.1 have the another one suddenly:
>
> 
>
> SS 5.2.1 <-> Router 1
>
> 
>
> 12:42:48.280898 IP StrongSwan521.isakmp > Router1.isakmp: isakmp: phase 1 I ident
>
> 12:42:48.339787 IP Router1.isakmp > StrongSwan521.isakmp: isakmp: phase 1 R ident
>
> 12:42:48.341346 IP StrongSwan521.isakmp > Router1.isakmp: isakmp: phase 1 I ident
>
> 12:42:48.401882 IP Router1.isakmp > StrongSwan521.isakmp: isakmp: phase 1 R ident
>
> 12:42:48.403264 IP StrongSwan521.isakmp > Router1.isakmp: isakmp: phase 1 I ident[E]
>
> 12:42:48.462499 IP Router1.isakmp > StrongSwan521.isakmp: isakmp: phase 1 R ident[E]
>
> *12:42:48.463006 IP StrongSwan521.isakmp > Router1.isakmp: isakmp: phase 2/others I #6[E]*
>
> *12:42:48.523154 IP Router1.isakmp > StrongSwan521.isakmp: isakmp: phase 2/others R #6[E]*
>
> 12:42:48.524140 IP StrongSwan521.isakmp > Router1.isakmp: isakmp: phase 2/others I oakley-quick[E]
>
> 12:42:48.585046 IP Router1.isakmp > StrongSwan521.isakmp: isakmp: phase 2/others R oakley-quick[E]
>
> 12:42:48.586575 IP StrongSwan521.isakmp > Router1.isakmp: isakmp: phase 2/others I oakley-quick[E]
>
> 
>
> I found two strange additional packets before the standard quick mode packets for phase 2,  initiation packet from SS and the answer packet  from Router 1. I couldn’t recognize them. But tunnel is Ok because Router 1 is able to answer to this package. Well, but…
>
> 
>
> SS 5.2.1 <-> Router 2
>
> 
>
> 13:23:56.200783 IP StrongSwan521.isakmp > Router2.isakmp: isakmp: phase 1 I ident
>
> 13:23:56.225261 IP Router2.isakmp > StrongSwan521.isakmp: isakmp: phase 1 R ident
>
> 13:23:56.226277 IP StrongSwan521.isakmp > Router2.isakmp: isakmp: phase 1 I ident
>
> 13:23:56.259911 IP Router2.isakmp > StrongSwan521.isakmp: isakmp: phase 1 R ident
>
> 13:23:56.260966 IP StrongSwan521.isakmp > Router2.isakmp: isakmp: phase 1 I ident[E]
>
> 13:23:56.296592 IP Router2.isakmp > StrongSwan521.isakmp: isakmp: phase 1 R ident[E]
>
> *13:23:56.296970 IP StrongSwan521.isakmp > Router2.isakmp: isakmp: phase 2/others I #6[E]*
>
> *13:24:00.297122 IP StrongSwan521.isakmp > Router2.isakmp: isakmp: phase 2/others I #6[E]*
>
> 
>
> etc…
>
> 
>
> It looks that Router 2 couldn’t recognize this package too, not me only… It simply doesn’t answer to it. Well, I suppose it is the reason why phase 2 couldn’t be established.
>
> 
>
> So, what the sense of these packages? How can I prevent them using ipsec.conf?
>
> 
>
> Current version of ipsec.conf
>
> 
>
> conn dtn-ovh
>
>         # rekeymargin=3m
>
>         # keyingtries=1
>
>         keyexchange=ikev1
>
>         type=tunnel
>
>         authby=secret
>
>         left=x.x.x.x
>
>         leftsourceip=q.q.q.q
>
>         leftsubnet=a.a.a.a/a
>
>         right=y.y.y.y
>
>         rightsubnet=c.c.c.c/c
>
>         ike=aes192-sha-modp1024
>
>         esp=aes192-sha-modp1024
>
>         dpdaction=restart
>
>         dpddelay=15s
>
>         ikelifetime=28800s
>
>         #pfs=yes
>
>         auto=start
>
> 
>
> conn paris-ovh2
>
>         # rekeymargin=3m
>
>         # keyingtries=1
>
>         keyexchange=ikev1
>
>         type=tunnel
>
>         authby=secret
>
>         left=x.x.x.x
>
>         leftsourceip=q.q.q.q
>
>         leftsubnet=b.b.b.b/b
>
>         right=z.z.z.z
>
>         rightsubnet=b.b.b.b/b
>
>         #rightauth=psk
>
>         ike=aes192-sha-modp1024
>
>         esp=aes192-sha1-modp1024
>
>         #esp=aes128-sha1-modp2048
>
>         dpdaction=restart
>
>         dpddelay=15s
>
>         ikelifetime=28800s
>
>         #pfs=yes
>
>         auto=start
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVou9bAAoJEDg5KY9j7GZYYawP+wabaZAyVcDqo7TL/vk1R7ON
OeclQtv6LUky/n+1ujkGmooovWgb98UurP13x/yrVATAQW56s8ktmeAqImXxDeq/
kuGoAWGY3vd1/khi16J+BH8Y2gsHJDfNLNBPcnN+KyycwcflbbKwwZs5mHDSEqz0
o2ozBZ8RFeFRKBuapeXqDAg1SMS5XDBhRhdm9t9yCcbbEZUd+WOhS6+Wq+7m/g0e
VNF7Wkr7oea/jeVKW23B8cDny0aP/f/YZgnGfn6fpabagJ5481AkqiWcdxSpF0xe
gRwcePnvWMlpK+Ufk+IaPJSON2TQAYq3BAfde5bs1pWNUxY6GT56f8Cd8G2Epjyn
RgcciXXYc8920xi6o6s+/8ipX21VJAv0OXxBrMWqxv4oeFYylAOuzwWFS21tdC4E
CwuPid96xNSXQfhhzxjQTvHgNfvzMYkIPZICWOaTF4yOyqQvI3Hlybw8a07+hYg1
96AdDLZvwcVrFCtM4LFtb7kkpz0rlQfnwlLkFiJH85bJDuNVfFqIe7fIGI3wd898
ZHiYqXDRqdGS6oMyCvMLrnAIyavNeao99EDX6udlHlUM6JzoBoLrVHKwmU/6d1tb
5A1YTi4+FdU4KVoeEVFTocGSxj4kva82NY350/InnaCauU069hdXkpuPNq3Zsd/k
39cLhxoE1um8htKlIISr
=d8Dg
-----END PGP SIGNATURE-----