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@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@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@hmnet]...192.168.4.10[karma.hmnet]

Statusall:
   karmaIKE2:  10.0.2.15...192.168.4.10
   karmaIKE2:   local:  [btvm@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=se...@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@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@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@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@karma ~]# ssh 10.0.2.15
root@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@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@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@bt:~# ipsec up karmaIKE2
> >
> > What I found is (merging the log the way you did):
> >
> > root@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


_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Reply via email to