Hello Volker,
Thanks again for sharing your experience and ideas.
>Did you try to disable IPComp? That's compress=no in ipsec.conf. And
>just to be sure disable IPComp for every connection. You can still
>re-enable it if everything works.
You guess was right to the point!
I replaced in all the instances
#compress=yes
compress=no
[root@wave ~]# strongswan up spb-hmnet
initiating IKE_SA spb-hmnet[2] to xx.xx.221.28
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
sending packet: from xx.xx.122.170[500] to xx.xx.221.28[500] (708 bytes)
received packet: from xx.xx.221.28[500] to xx.xx.122.170[500] (465 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ
N(MULT_AUTH) ]
received cert request for "OU=CA, CN=certauth"
sending cert request for "OU=CA, CN=certauth"
authentication of 'hq.spb@ucp' (myself) with RSA signature successful
establishing CHILD_SA spb-hmnet
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr AUTH SA TSi TSr
N(MOBIKE_SUP) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from xx.xx.122.170[4500] to xx.xx.221.28[4500] (556 bytes)
received packet: from xx.xx.221.28[4500] to xx.xx.122.170[4500] (524 bytes)
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.ucp"
certificate status is not available
reached self-signed root ca with a path length of 0
using trusted certificate "OU=hmnet, CN=karma.ucp"
authentication of 'karma.ucp' with RSA signature successful
IKE_SA spb-hmnet[2] established between
xx.xx.122.170[hq.spb@ucp]...xx.xx.221.28[karma.ucp]
scheduling reauthentication in 10145s
maximum IKE_SA lifetime 10685s
connection 'spb-hmnet' established successfully
Now we have 2 tunnels up and running:
Security Associations (2 up, 0 connecting):
spb-hmnet[2]: ESTABLISHED 8 minutes ago,
xx.xx.122.170[hq.spb@ucp]...xx.xx.221.28[karma.ucp]
spb-hmnet[2]: IKEv2 SPIs: 986512b316f3f146_i* ce50d928ca13b439_r, public key
reauthentication in 2 hours
spb-hmnet{2}: 192.168.0.0/24 === 192.168.4.0/24
spb-frqx[1]: ESTABLISHED 8 minutes ago, xx.xx.122.170[OU=spb,
CN=wave.spb]...xx.xx..230.112[OU=frqx, CN=vpn.ucp]
spb-frqx[1]: IKEv2 SPIs: 39d18a0f01e844a7_i* 64798b5e2576b99b_r, public key
reauthentication in 2 hours
spb-frqx{1}: 192.168.0.0/24 === 192.168.169.0/24
[root@wave ~]# ping karma.hmnet
PING karma.hmnet (192.168.4.10) 56(84) bytes of data.
64 bytes from karma.hmnet (192.168.4.10): icmp_seq=1 ttl=64 time=110 ms
64 bytes from karma.hmnet (192.168.4.10): icmp_seq=2 ttl=64 time=110 ms
64 bytes from karma.hmnet (192.168.4.10): icmp_seq=3 ttl=64 time=112 ms
The second tinnel:
[root@wave ~]# ping aah.prs
PING aah.prs.ucp (192.168.169.60) 56(84) bytes of data.
64 bytes from ns.prs (192.168.169.60): icmp_seq=1 ttl=63 time=105 ms
64 bytes from ns.prs (192.168.169.60): icmp_seq=2 ttl=63 time=105 ms
From the other side:
[root@karma ~]# ping wave.spb
ping: unknown host wave.spb
[root@karma ~]# ping 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_seq=1 ttl=64 time=109 ms
64 bytes from 192.168.0.100: icmp_seq=2 ttl=64 time=110 ms
64 bytes from 192.168.0.100: icmp_seq=3 ttl=64 time=113 ms
As you have noticed, there is net segment "spb" name resolution problem.
How could the wave.spb domain name resolution be enabled?
The necessary setting has been added here:
[root@wave ~]# cat /etc/strongswan/strongswan.conf
charon {
# ...
dns1 = 192.168.0.100
nbns1 = 192.168.0.100
}
Is anything else necessary to be checked or enabled?
Thanks again,
Serge
> ----- Original Message -----
> From: Volker Rümelin
> Sent: 01/19/14 06:20 PM
> To: s s
> Subject: Re: [strongSwan] strongswan-5.1.x, tunnel and routing pb
>
> Hello Serge,
>
> > Hello Volker,
> >
> > We have an ongoing routing problem since the attempt to migrate from
> > strongswan-4.x.x to strongswan-5.1.x
> >
> > Are there any ideas of what is going wrong ?
> >
>
> sorry, no. I looked at your logs but couldn't find anything obvious.
>
> Did you try to disable IPComp? That's compress=no in ipsec.conf. And
> just to be sure disable IPComp for every connection. You can still
> re-enable it if everything works.
>
> Regards,
> Volker
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
