On 22.07.2017 19:57, Dusan Ilic wrote: > Okey, the remote endpoint dont know that the other side have changed its IP, > however according to below a connection should still be able to be made if > the end with the new IP initiates it. > > "parameter right|leftallowany parameters helps to handle > the case where both peers possess dynamic IP addresses that are > usually resolved using DynDNS or a similar service. > > The configuration > > right=peer.foo.bar <http://peer.foo.bar> > rightallowany=yes > > can be used by the initiator to start up a connection to a peer > by resolving peer.foo.bar <http://peer.foo.bar> into the currently allocated > IP address. > Thanks to the rightallowany flag the connection behaves later on > as > > right=%any > > so that the peer can rekey the connection as an initiator when his > IP address changes. An alternative notation is > > right=%peer.foo.bar <http://peer.foo.bar> > > which will implicitly set rightallowany=yes > " > > However, Strongswan on the side that have changed IP is obviously aware of > its new IP without restarting (how?), so why does it give the following > output when trying to initiate the connection? > > initiating IKE_SA to 94.254.123 <tel:94.254.123>.x > generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) > N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] > sending packet: from 85.24.244 <tel:85.24.244>.x[500] to 94.254.123 > <tel:94.254.123>.x[500] (464 bytes) > received packet: from 94.254.123 <tel:94.254.123>.x[500] to 85.24.244 > <tel:85.24.244>.x[500] (36 bytes) > parsed IKE_SA_INIT response 0 [ N(NO_PROP) ] > received NO_PROPOSAL_CHOSEN notify error > establishing connection 'wesafe' failed
The remote peer sends that error. What does it log? > > Why does it report no proposal chosen, until i restart the remote endpoint? > IF I have understood it right, the use of % in front of the hostname should > allow a connection attempt from whatever the IP May be? > > ---- Noel Kuntze skrev ---- > > Seems like it. > > On 22.07.2017 11:17, Dusan Ilic wrote: >> Hi Noel, >> >> So, are you saying that there is no way to make Strongswan aware of a domain >> name have changed IP-address without restarting it manually? >> >> >> Den 2017-07-22 kl. 01:49, skrev Noel Kuntze: >>> Hi Dusan, >>> >>> I took a "quick" look at the code[1] and it seems the DNS names are only >>> resolved once the result replaces the original destination. >>> So it has nothing to do with caching. Just with a disadvantageous design >>> decision. >>> >>> Kind regards >>> >>> Noel >>> >>> [1] >>> https://github.com/strongswan/strongswan/blob/master/src/libcharon/sa/ike_sa.c#L1470 >>> >>> On 21.07.2017 00:19, Dusan Ilic wrote: >>>> Okey, so I just did a forced release/renew on the same endpoint, dynamic >>>> DNS updated shortly the new IP (ttl 5 min) and after like 10 min or so >>>> another endpoint reconnected again (a fortigate, I have two endpoints), >>>> however the troubling endpoint (also strongswan) havent connected yet. >>>> >>>> When logging in to the remote endpoint and pinging the domain name, it >>>> resolves to the new IP, but below are the output from both sides of the >>>> tunnel when trying to manually run ipsec up-command. >>>> >>>> On the remote endpoint: >>>> >>>> First of, running ipsec statusall connection shows as if the tunnel is >>>> still up, maybe thats the problem that Strongswan thinks its up even if it >>>> isn't? >>>> >>>> ESTABLISHED 46 minutes ago, >>>> 94.254.123.x[local.host.name]...85.24.241.x[85.24.241.x] >>>> IKE SPIs: 1dffaab2cafa2f48_i 15e867fa149370f0_r*, pre-shared key >>>> reauthentication in 22 hours >>>> IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 >>>> INSTALLED, TUNNEL, ESP SPIs: cf0473a2_i c45028cb_o >>>> AES_CBC_128/HMAC_SHA1_96, 8275 bytes_i (2616s ago), 81235 bytes_o (8s >>>> ago), rekeying in 7 hours >>>> 192.168.1.0/24 === 10.1.1.0/26 >>>> >>>> Command ipsec up connection >>>> >>>> initiating IKE_SA to 85.24.241.x >>>> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] >>>> sending packet: from 94.254.123.x[500] to 85.24.241.x[500] >>>> retransmit 1 of request with message ID 0 >>>> sending packet: from 94.254.123.x[500] to 85.24.241.x[500] >>>> >>>> On the local endpoint (with new IP): >>>> >>>> initiating IKE_SA to 94.254.123.x >>>> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) >>>> N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] >>>> sending packet: from 85.24.244.x[500] to 94.254.123.x[500] (464 bytes) >>>> received packet: from 94.254.123.x[500] to 85.24.244.x[500] (36 bytes) >>>> parsed IKE_SA_INIT response 0 [ N(NO_PROP) ] >>>> received NO_PROPOSAL_CHOSEN notify error >>>> establishing connection 'wesafe' failed >>>> >>>> And when restarting Strongswan on the remote endpoint, it connects again... >>>> >>>> Den 2017-07-20 kl. 12:00, skrev Dusan Ilic: >>>>> Hi, >>>>> >>>>> I have some issues with a site to site tunnel with two dynamic endpoints. >>>>> One side almost never changes IP-adress (it is DHCP however), the other >>>>> side changes more frequently. Both endpoints IP-adresses are using >>>>> dynamic DNS and have a corresponding domain name associated at all times. >>>>> >>>>> Today one side changed IP, and the new IP have been updated in public >>>>> DNS. I understand DNS propagation and caching, but I seem to not >>>>> understand how Strongswan handles and acts upon it. >>>>> >>>>> For example, I have set keyingtries to %forever on both sides, so that >>>>> they continuesly tries to reconnect when connections is lost. I have also >>>>> changed the global initiation parameter from default 0 to 60 s, so that >>>>> it retries unsuccesful connections attempts. >>>>> Now the other side is trying to reconnect to the old IP still, however if >>>>> I ping the hostname from that endpoint it resolves to the new, correct >>>>> IP. It seems like Strongswan is caching the old DNS some how? >>>>> At last I tried to restart Strongswan and then it picked up the new IP. >>>>> >>>>> I would like to have a system that solves this by itself, so I don't need >>>>> to manually have to intervene each and everythime any of the endpoints >>>>> get a new IP. How can this best be achieved? >>>>> >> >
signature.asc
Description: OpenPGP digital signature
