[strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
s s
y52 at europe.com
Sat Jan 11 20:59:52 CET 2014
Hello Volker,
I appreciate a lot your participation and the help in sorting out the problem.
> I still think it's your NAT router. Tcpdump shows you do NAT somewhere.
Yes, the bt host is NAT'ed behind the 192.168.4.87 host.
>I think so. But why don't you store the certificates on both sides and
>tell strongswan not to send the certificates?
I thought I have already implemented this setting. Now looking at the conn section, it was commented out throughout the numerous trials.
So I've added back on both sides:
leftcert=xxx.hostCert.pem
leftsendcert = never
leftid=@xxx.hmnet
Launching the connection:
root at bt:/etc/ipsec.d# ipsec up karmaIKE2
initiating IKE_SA karmaIKE2[1] to 192.168.4.10
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
sending packet: from 10.0.2.15[500] to 192.168.4.10[500]
received packet: from 192.168.4.10[500] to 10.0.2.15[500]
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
local host is behind NAT, sending keep alives
received cert request for "OU=CA, CN=certauth"
sending cert request for "OU=CA, CN=certauth"
authentication of 'btvm at hmnet' (myself) with RSA signature successful
establishing CHILD_SA karmaIKE2
generating IKE_AUTH request 1 [ IDi CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ]
sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500]
received packet: from 192.168.4.10[4500] to 10.0.2.15[4500]
parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_6_ADDR) ]
using trusted ca certificate "OU=CA, CN=certauth"
checking certificate status of "OU=hmnet, CN=karma.hmnet
certificate status is not available
using trusted certificate "OU=hmnet, CN=karma.hmnet"
authentication of 'karma.hmnet' with RSA signature successful
scheduling reauthentication in 10016s
maximum IKE_SA lifetime 10556s
IKE_SA karmaIKE2[1] established between 10.0.2.15[btvm at hmnet]...192.168.4.10[karma.hmnet]
Statusall:
karmaIKE2: 10.0.2.15...192.168.4.10
karmaIKE2: local: [btvm at hmnet] uses public key authentication
karmaIKE2: cert: "OU=testbed, CN=btvm.hmnet"
karmaIKE2: remote: [karma.hmnet] uses any authentication
karmaIKE2: cert: "OU=hmnet, CN=karma.ucp-is.com, E=serge at ucp-is.com"
karmaIKE2: child: 10.0.2.0/24 === 192.168.4.0/24
Security Associations:
karmaIKE2[1]: ESTABLISHED 13 minutes ago, 10.0.2.15[btvm at hmnet]...192.168.4.10[karma.hmnet]
karmaIKE2[1]: IKE SPIs: 3dfee9f7c9c91fef_i* 83e5786735bd203d_r, public key reauthentication in 2 hours
karmaIKE2[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
karmaIKE2{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: c2b04454_i c4d8a1ad_o
karmaIKE2{1}: AES_CBC_128/HMAC_SHA1_96, rekeying in 30 minutes, last use: 4s_i 4s_o
karmaIKE2{1}: 10.0.2.0/24 === 192.168.4.0/24
karma side:
tcpdump
2346: isakmp 2.0 msgid 00000000: parent_sa ikev2_init[]:
(sa: len=44
(p: #1 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0080))
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp2048 )))
(v2ke: len=256 group=modp2048)
(nonce: len=32 data=(b1923e094f0413d97907...6dc4a7fbe9561b9f34cc71a70000000800004014))
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(v2cr: len=21)
(n: prot_id=#0 type=16404(status))
20:32:05.016640 IP (tos 0x0, ttl 63, id 18023, offset 0, flags [none], proto: UDP (17), length: 556) 192.168.4.87.52347 > 192.168.4.10.ipsec-nat-t: NONESP-encap: isakmp 2.0 msgid 00000001: child_sa ikev2_auth[I]:
(v2e: len=492)
20:32:05.117023 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 556) 192.168.4.10.ipsec-nat-t > 192.168.4.87.52347: NONESP-encap: isakmp 2.0 msgid 00000001: child_sa ikev2_auth[]:
(v2e: len=492)
Apparently the packets are not fragmented.
Everything works "automagically". The routhing does work as well:
[root at karma ~]# ip route list table 220
10.0.2.0/24 via 192.168.4.87 dev eth0 proto static src 192.168.4.10
[root at karma ~]# ping 10.0.2.15
PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data.
64 bytes from 10.0.2.15: icmp_seq=1 ttl=64 time=3.58 ms
[root at karma ~]# ssh 10.0.2.15
root at 10.0.2.15's password:
Linux bt 2.6.38 #1 SMP Thu Mar 17 22:59:29 EDT 2011 x86_64 GNU/Linux
[root at karma ~]# ip xfrm state
src 192.168.4.87 dst 192.168.4.10
proto esp spi 0xce979fb5 reqid 3 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0xfaa044b6c05801aed6bbf0e68d9cccd24be13448
enc cbc(aes) 0xf236e713b7053d774a12714f03f634ef
encap type espinudp sport 52347 dport 4500 addr 0.0.0.0
src 192.168.4.10 dst 192.168.4.87
proto esp spi 0xc0ddb7a7 reqid 3 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0x99e88b87cd2c1adf1ee14a1a57ddb3ee2d0ed447
enc cbc(aes) 0xbd6f78be1edf392131bb40f217edb6ab
encap type espinudp sport 4500 dport 52347 addr 0.0.0.0
Based on this experience, I shall try to implement the settings and certificates infrastructure to the production environment.
Thanks once again for your persistance, help and good ideas.
Regards,
Serge
> ----- Original Message -----
> From: Volker Rümelin
> Sent: 01/11/14 05:26 PM
> To: s s
> Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
>
> Hello Serge,
>
> > Hello Volker,
> > My yesterday's conclusions regarding the networks MTU shortcomings were probably wrong.
>
> right, both your hosts work just fine.
>
> > I've looked into the MTU's issues and found ethernet compliant MTU 1500 from both sides
> > 1500=1472+28 :
> > [root at karma ~]# ping -c 5 -M do -s 1472 192.168.4.87
> > PING 192.168.4.87 (192.168.4.87) 1472(1500) bytes of data.
> > 1480 bytes from 192.168.4.87: icmp_seq=1 ttl=128 time=3.29 ms
> > 1480 bytes from 192.168.4.87: icmp_seq=2 ttl=128 time=8.03 ms
> >
> > Then to eliminate the the doubts I stopped down the iptbales and ran the same
> > root at bt:~# ipsec up karmaIKE2
> >
> > What I found is (merging the log the way you did):
> >
> > root at bt:~# ipsec up karmaIKE2
> > establishing CHILD_SA karmaIKE2
> > generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ]
> > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500]
> >
> > Jan 10 23:27:53 bt charon: 10[IKE] establishing CHILD_SA karmaIKE2
> > Jan 10 23:27:53 bt charon: 10[ENC] generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ]
> > Jan 10 23:27:53 bt charon: 10[NET] sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500]
> >
> > 23:27:53.426525 IP (tos 0x0, ttl 64, id 20103, offset 0, flags [+], proto UDP (17), length 1500)
> > 10.0.2.15.4500 > 192.168.4.10.4500: NONESP-encap: isakmp 2.0 msgid 00000001: child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1484/ip 1468)
> > 23:27:53.427322 IP (tos 0x0, ttl 64, id 20103, offset 1480, flags [none], proto UDP (17), length 36)
> > 10.0.2.15 > 192.168.4.10: udp
> >
> >
> > The Karma side reply:
> > 23:27:52.189035 IP (tos 0x0, ttl 63, id 7625, offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.4.87.49325 > 192.168.4.10.ipsec-nat-t: NONESP-encap: isakmp 2.0 msgid 00000001: child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1484/ip 1468)
> > 23:27:52.189057 IP (tos 0x0, ttl 63, id 7625, offset 1480, flags [none], proto: UDP (17), length: 36) 192.168.4.87 > 192.168.4.10: udp
> >
> > meaning, that karma sends back 2 packet segments due to the fragemntation as required
> >
> > But the bt receives only one of them:
> > 192.168.4.10.4500 > 10.0.2.15.4500: NONESP-encap: isakmp 2.0 msgid 00000001: child_sa ikev2_auth[R]: [|v2e] (len mismatch: isakmp 1612/ip 1468)
> >
> > The second completing udp packet (without the header) is missing. Hence the initial large packet could not be reassembled.
> >
> > What could drop the fragmented packets on their pathway? What could be considered further?
>
> I still think it's your NAT router. Tcpdump shows you do NAT somewhere.
>
> >
> > Can another authentication method reduce the packet size? Could a PSK shared key form a smaller sized packets?
>
> I think so. But why don't you store the certificates on both sides and
> tell strongswan not to send the certificates?
>
> > If a smaller packets authentication is possible, it would allow to troubleshoot the issue.
> >
> > You also mentioned that strongswan >= 5.0.2 supports fragmentation for IKEv1. Why IKEv1 only supports fragmentation and not IKEv2?
>
> Ikev1 and ikev2 are different protocols. It's only implemented for
> ikev1. For ikev2 there only exists a internet draft at the moment.
> http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-05
>
> >
> > Thanks again,
> > Serge
> >
>
> Regards,
> Volker
More information about the Users
mailing list